On Archimate 3.0
There’s a new version of the Archimate enterprise-architecture notation now out: version 3.0, launched at the IRM-EAC Enterprise Architecture conference in London last week.
With many thanks to Andrew Josey, Marc Lankhorst, Gerben Wierda and others, I’ve been working my way through the formal specification and accompanying notes, white-papers and the like.
So what’s in the new version? And is it a good fit – a better fit than the previous version – for the needs of enterprise-architecture, as the latter expands ever further outward towards a true whole-of-enterprise scope?
On the surface, and at first glance, yes, there’s a lot to like in the new version:
- There are new entities for strategy and motivation, with Outcome, Capability, Resource and more.
- There are clean-ups for some of the relationships, particularly between layers.
- There’s a new mechanism to define viewpoints.
- There are, at last, entities to describe some types of physical items beyond IT-hardware, and pathways along which physical goods might flow:
That last item will help people a lot if they’re working with Internet-of-Things and the like. It was sort-of possible, even with the previous version, to kludge Archimate to work with the physical-world – but now it’s possible to do it without kludges. For example, the new ‘physical layer’ does provide real support for modelling within the so-called ‘Industry 4.0‘, with sensors and other automation deeply embedded throughout manufacturing-lines and the like.
All of which is good news. In theory, at least.
But only ‘in theory’, because I’m still struggling with serious doubts about how well it’ll work in real-world practice…
Yes, I’ve seen a fair few people say it’s “just right” – just enough richness and versatility to support what they need. Yes, the new ‘physical-layer’ objects mean that we have a better chance now of being able to use Archimate to describe ‘internet-of-thing’ architectures and suchlike, which it certainly couldn’t do in the previous version. Some important gaps have now been filled – no doubt about that.
And yet… and yet…
Yeah, let’s face it: it’s still hopelessly IT-centric. Which, bluntly, was exactly what not to do at this point.
What’s the evidence for that? Well, take a look – you’ll need to explore the standard with some solid experience of dealing with architecture concerns from the world beyond IT, but it’s painfully evident once we do take a proper look at it. For example:
- There is now a Product entity – but it’s only available for use as ‘composite’-entity, an aggregation of IT-based services. Okay, yes, sure, that’s what bankers or insurance-folks might describe as a ‘product’. But according the relationships-model, there seems no way to describe anything physical as a ‘product’ – in other words, the most common meaning of ‘product’, like a vacuum cleaner, or a jar of strawberry jam from the supermarket. Oops…
- In principle we might be able to kludge the relationships so as to use the new Material entity to describe physical products – sort-of as in the diagram above. But try explaining to a marketing exec that we can’t use Product to describe a product, it can only be called Material instead? – no, that’s not gonna work, is it…?
- The Artifact entity, which would make more sense as a descriptor for a physical ‘thing’, is still defined as ‘an item of IT data’ that somehow kinda sits in the Technology layer.
- Applications are still IT-only – there’s still no concept that a human (or a machine, for that matter) might do something that is an exact logical analogue of an ‘application’. Or, more importantly, no means to describe such an activity. Which means, for example, that Archimate gives us no means to describe key aspects of architectures for business-continuity, disaster-recovery, load-balancing and more. Not helpful…
And these are by no means the only worries: for example, see Michael Poulin’s critique, particularly around Capability, Action and Service.
But the real problem is…
Actually, no, there are several really big problems with Archimate – and I’m not sure that they can be fixed, either in this version, or any future one. (Especially not whilst Archimate is under the control of Open Group – which is, after all, an IT-standards body, with rather too much of a vested-interest in keeping enterprise-architecture entrapped in IT-centrism for as long as possible…) Most of these problems interweave with each other, and include:
— The new entities and relationships merely add to the existing chaos of inconsistencies and special-cases in the underlying anatomy of Archimate.
— It still uses the BDAT-stack – or rather, a simplified variant of it, as ‘Business’, ‘Application’, Technology’ – which inherently entraps it into IT-centrism.
— Its concept of layering still embeds the same truly horrible set of conflations:
- ‘Business’ = anything-human + anything-relational + principle-based (‘vision/values’) decisions + higher-order abstraction + intent
- ‘Application’ = anything-computational + anything-informational + ‘truth-based’ (algorithmic) decisions + virtual (lower-order ‘logical’ abstraction)
- ‘Technology’ = anything-mechanical + anything-physical + physical-law (‘rule-based’) decisions + concrete (‘physical’/tangible abstraction)
(The few exceptions – such as ‘System-Software’ in the ‘Technology’ layer, and, now, ‘Contract’ in the ‘Business’ layer – merely add the confusion…)
— It’s now even more explicitly linked to TOGAF and its ‘Architecture Development Method‘ (ADM):
…which, again, rigidly locks it to the fundamental error of the BDAT-stack, and also rigidly locks it to an architecture-framework that is, increasingly, becoming much more of a hindrance than a help for real-world enterprise-architecture.
Oh well…
To be blunt, what this most reminds me of is the huge missed-opportunity of the launch of TOGAF 9, back in early 2009. Back then, there was a real chance – certainly a hope – that Open Group would have the courage to break out of the IT-centric box. In the event, they muffed it: they gave us instead a framework that had the pretence of a broader capability, but actually was even more locked into a kind of more-covert IT-centrism – and they’ve been pulling further and further backwards ever since.
And it’s much the same here, with this new version of Archimate. There’s a surface-appearance of improvement – in fact actually is a genuine improvement if (but only if) your architecture-focus is still in IT. But for the rest of us – and it’s a rapidly-increasing number of us now, in enterprise-architecture and beyond – it is, like TOGAF 9, a huge missed-opportunity: yet another step in the wrong direction. Which doesn’t help.
What Archimate 3.0 gives us is, yes, a worthy attempt towards what its creators no doubt think of as a greater completeness. But it’s still hopelessly IT-centric, which is frustrating as heck to those of us who work in whole-enterprise-architectures. Yet the most serious problem with this new version is that it’s moved yet further again towards a language that’s intended for design, not architecture – and that distinction is crucially important here. It’s far too complex and constrained for the much more free-form needs of early-stage architecture, over at the front-end of the Squiggle, yet it’s also not really complete enough for usage as a proper design-language, in the sense that UML or BPMN are, for example. The result is that it falls into a horrible dead-space, a kind of uncomfortable ‘Uncanny Valley‘, where it’s not really usable for anything – and in some ways getting worse with each new ‘upgrade’. Which, again, doesn’t help.
The blunt fact is that we still don’t have a usable, toolset-supported notation for enterprise-architecture, as architecture. What we need is something simple enough to use on a whiteboard or a paper notepad, fast, with the bare minimum of entities and relations – and then record that into a toolset, in a format that makes it easy to review and revise as much as we need. What we have instead with Archimate is a cumbersome, overly-complex design-language, hardwired to a fundamentally-misleading layers-model, that requires us to select and then specialise the right item from some 60 entity-types and a dozen different relationship types, all of which have to be linked together in exactly the right way for the model to work at all. The result is that not only is Archimate hopelessly slow to use for most architecture-practice, but it incites architects to do exactly what we should not do – namely settling too early to a design – simply because it’s too much effort to change the darn thing once we’ve finally managed to get it up on the whiteboard or the screen…
We need that simpler language for enterprise-architecture, and we need it now. Archimate won’t do that job – in fact is now perhaps further away from serving that need than it ever has been. As a community, we need to get together, urgently, to work out how best to resolve that need, before this new version of Archimate makes things even worse than they already are.
Hi Tom,
Some small comments (maybe more later). Product is now able to aggregate material in addition to services. The idea is that a product is usually more than just a thing, but a thing with additional services of some sort. So IMHO this can fit the usual definition of a product.
I agree that Archimate is mostly for design and doesn’t help too much for the early architecture phases (left side of the squiggle). But I wonder if the new “strategic” concepts could not be used for that. After all they are generic enough (well: just active structure -resource- and behavior -capability-), doesn’t require to decide whether they are business/application/technology and can later been reused for design (buy having some more “concrete” concepts realize them).
Last, while it’s true that the link with TOGAF and the BDAT is clearly shown, when reading between the lines be can see some important differences: the cross-layer dependancies now show that there are almost no layers at all: services from any layer can serve any other layer. Together with previous remark, this leads me to this (maybe unusual) conclusion: use Stategy concepts for left side of the squiggle and other concepts for right side, but with less constraints than before.
Regards,
JB
[Cross-post of my reply to your cross-posted comment on LinkedIn 🙂 ]
Thanks, JB, and okay, yes, I sit corrected re Product. It’s a kludge – especially when combined with the even worse kludge of Material – but I accept that it’s doable. (Sort of…)
“I wonder if the new “strategic” concepts could not be used for that” – from my previous work on Enterprise Canvas, I suspect not. Or rather, yes, we could just-about kludge it to work, if we bypass the relationship-constraints and suchlike – but the clashes with Archimate’s mostly IT-centric definitions and general incompatibility with a fractal approach to architecture mean that we’d almost certainly be better off starting from scratch, and then use a later mechanism to handle the translations to Archimate’s design-oriented entities. (Note too that the Archimate spec is explicit that the abstract active-structure and behaviour entities _cannot_ be used as-is – they must be instantiated to one of the hardwired entity-types. Which kinda defeats the aim of your suggestion there?)
On your conclusion – “use Strategy concepts for left side of the squiggle and other concepts for right side” – I’d agree that that’s the right kind of direction to go, for what we need in architectures. The catch is that with Archimate we’d be fighting against its underlying anatomy and design-principles pretty much every step of the way. Whether it’s worth that kind of fight is a point to consider, with some of the toolset-developers and suchlike. My suspicion is that it isn’t, and that it’d be simpler to scrap the whole thing and start again properly from scratch – but I’d be happy to be convinced otherwise on that.
Dear Tom,
I can see that you have many objections to Archimate. Well, according to your expertise I might take in account that you have a point.
Could you please explain in a few points what is from your point of view the biggest gap of Archimate as a EA tool?
To clarify my question… I have not seen better EA tool so far. I also read your article “Which EA tools?” a few days ago. It seems that you have very clear picture of how the tool should look like, but there is no EA tool so far.
It is very hard for me to understand what you are talking about when you just pointing at the wrong features of the tool. If you add an example how it should be, it might probably help the community to come with new ideas, based on your shared experience.
Thank you very much for any answer in advance,
Kind regards,
Roman
@Roman: I’ll let Tom answer, but I think you are confusing ArchiMate the modelling language, and Archi the modelling tool (which supports ArchiMate). Tom main concern is about ArchiMate and its lack of support for the whole Enterprise Architecture work, from early idea/sketching to the final design phase. If you carefully read his posts on this topic you’ll easily understand that prior even thinking about a tool we have to define a metamodel and a way of using it.
BTW, about the Archi tool, it already implements some non ArchiMate modelling (sketches and canvas) that could help you capture ideas, but that was mainly a POC and should be reworked (using Tom’s new/neat/simple metamodel for example).
Regards
Dear JB,
Thanks for reaction. Actually I am not confusing the Archi tool (which I like) and Archimate as a “language”.
I have been reading some of Tom’s articles and maybe I will find the answer to my question later. I think I have started to see the context of Tom’s objections.
However Tom’s articles always contains a significant part of description of the wrong things which makes the message unclear for me.
I am probably missing some understanding of the point of view. I don’t see the Archimate as a tool for everything in EA but it is great comunication and visualisation tool/language for linking the business with IT. It doesn’t necessary has to be understood as an IT centric language. For instance my IT colleagues would complain that they miss in Archimate concepts that they used to using in Visio. 🙂
Regards
Thanks again, Roman – though what worries me in what you’ve just said above is, of course, this:
“Tom’s articles always contains a significant part of description of the wrong things which makes the message unclear for me.”
Ouch… 🙁
What are the ‘wrong things’? What can I do to make the message less unclear for you?
My apologies, anyway… 🙁
Thanks for reply Tom,
Please do not take it personally.
I am also not native English speaker so I hope I haven’t hurt you. 😉 I like generally what you write.
I just explained my impression I got reading some of your articles where you were mostly criticizing the tools (focus on what is wrong instead of what would you propose to change and how). I think, even if you are right, that too much of criticism can hide the message. That is all I wanted to say.
I think that your comments and answers below are clear for me enough. And i very appreciate your open approach.
Thank you,
Regards,
Roman
Hi Roman – please, don’t worry, you haven’t offended me at all – I was apologising to you!
Yes, I acknowledge that the way I write is often not easy for people who aren’t native English speakers (and even for those who are…) English is useful as a trade-language, but it’s by no means the only language in the world… In your case, for example, English is what, your third or fourth language, after Czech, Slovak and probably Russian or Austrian-German? – so yes, I do need to be more careful about my vocabulary and so on than I sometimes am. My apologies, again.
On “[Y]ou were mostly criticizing the tools (focus on what is wrong instead of what would you propose to change and how). I think, even if you are right, that too much of criticism can hide the message” – on the second point, yes, agreed (and again, you’re right, I do occasionally get too hung up in the critique…). On the first point, though, do note that other posts usually then take the critique and rework into the positive. On toolsets, for example, see some of the other posts such as:
— ‘What do we need from our EA tools?‘
— ‘Pinball wizard‘
— ‘Toolsets for associative modelling‘
or, for more implementation-oriented detail, see, for example:
— ‘More notes on toolsets for EA‘
— ‘From tools to toolset‘
or even:
— ‘The game of enterprise-architecture‘
In short, it isn’t all critique… 🙂
Hi Roman – many thanks for the questions.
One point first, though: there’s a distinction we need here between ‘notation-as-tool’ (the sense in which you’re describing Archimate), versus ‘[automated] toolset’ (such as Casewise or Sparx or Visio, to name a few at random). This post is mainly about a notation (Archimate), whereas the post ‘What do we need from our EA tools?’ is mostly about toolsets, and their (lack of) support for the notations and more that we need in EA. We do need to keep that distinction in mind in what follows.
My core objections to Archimate are:
— it’s primarily about IT-architecture, whereas what I need in my work is support across the architecture of the enterprise as a whole (more on that in a moment)
— it’s essentially a design-notation – something you’d hand over to a solution-architect – rather than for the much ‘messier’ work that we do in architectures (design is more about the ‘What’ and ‘How’, whereas architecture is often much more about the ‘Why’ and ‘Who’)
— even more in this latest version, it’s just too complex, cumbersome and slow for the kind of high-speed exploratory-work that we need to do on a whiteboard or a large interactive screen – we need something much simpler, that we can use at speed, yet that can also extend smoothly and cleanly into the more complex descriptive-notations when we do move towards the design-phase
Some examples of what I need in my kind of work, that are available in Archimate only via some kind of horrible kludge, or are missing entirely:
— brands and other ‘aspirational-assets’ (needed when we’re describing relationships between, say, marketing and customer-service)
— human-based ‘applications’ that parallel IT-based ones (needed when we’re describing business-continuity, disaster-recovery, failover and suchlike)
— any means via which we could explain why we would intentionally choose a non-computer-based IT over a computer-based one (such as is often the case with kanban-boards and the like)
The Motivation elements and the new physical-world elements make some of this possible, where it wasn’t before – but pretty much every case where we’d do so requires a kludge of some kind, and definitely assumes that everything other than IT is somehow a ‘second-class citizen’.
For examples of tools (in the other sense) that tackle some of these issues much better than Archimate does, take a look at:
— CMAPTools (free, most platforms) – concept-maps
— Southbeach (30day trial, PC [or Mac via Parallels/VMWare]) – context-mapping, decision-dependency modelling and more
— Scapple (Mac and Windows, $14.99) context-mapping, concept-mapping
The catch is that, as far as I know, none of them will export to any kind of format that we could re-use in a conventional ‘EA-toolset’.
It’s the bridging between these two worlds – the ‘messy’ part at the front-end of the ‘Squiggle’, and the more structured part at the tail-end of the Squiggle – that we need most. And no-one seems to be doing it as yet. That’s the challenge. (But the first tool-vendor who really gets that challenge, and does something practical about it, will have a whole huge new market pretty much all to themselves… 🙂 )
Does that answer your questions? If not, please do feel free to ask more.
Hi Tom,
Thank you very much for clear explanation.
Now I see where are you seeing the Archimate as a notation.
Let me to share with you shortly my experience in EA field. More than tool I am missing the common understanding of what EA should take care for. My IT colleagues thinks I am the IT Architect (because they read some of the various definitions) and so they want me to design the IT layers more than the Business part. The Business colleagues do not understand well what Enterprise Architecture is at all. This would be a long story but in short I am doing my best to change this way of thinking.
For that I see the Archimate as a great means to explain all the “stakeholders” where are their Business Processes and how they are dependent on the Application “Services” and where the IT guys can see link to deployment issues etc. You know probably better than me how Business people tend to determine the technology which might be used and how IT people tend to find a solution from their point of view. This is hard to change without clear pictures descripting how they are far from the technology and where they should pay attention.
You may think I am also IT centric :-). However I believe that to change the paradigm of how people started to use IT tools will take some time.
Thank you very much for the list of tools. I will check them.
I am going to follow your articles and discussions so I will have opportunity to ask you more questions.
Thanks 🙂
Have a nice evening!
Thanks again, Roman.
On “More than tool I am missing the common understanding of what EA should take care for” – yes, this is a huge ongoing problem. And its one that Open Group and its various big-consultancy members have succeeded only in making much more complex than it needs to be, for at least a couple of decades now, by actively promoting a fundamentally-misleading, rigidly IT-centric concept of ‘enterprise’-architecture.
The core to the problem is actually a lazy conflation invented perhaps three decades back, where some decided that it was easier to say ‘enterprise-architecture’ than the correct term ‘enterprise-wide IT-architecture’. The result is that we have a fundamental confusion where the same term is used for two different things: the literal ‘the architecture of the enterprise’, and a tiny subset of that architecture-of-the-enterprise, namely the architecture of (some of) its IT. Courtesy of the hype-machine that is Open Group and the big-consultancies, there’s huge pressure to mislead people into thinking that the tiny subset-of-a-subset is all there is (otherwise known as a ‘term-hijack’). Unfortunately, in real-world practice, the only way that works is if we understand enterprise-architecture as its literal form, ‘the architecture of the enterprise’, with IT-architectures being merely one amongst many sub-domains of that space. Open Group et al have much to answer for….
The real core of EA comes down to a simple one-line phrase: “things work better when they work together, on purpose”. In practice, this means that the real task of EA is to help people link things together (again, any type of ‘thing’, with any other type of ‘thing’). Which means that, in human terms, what we most need to do is to get people talking, to act as ‘translator’, to facilitate collective sensemaking, that kind of thing. Enterprise-architects generally don’t (and generally shouldn’t) do much design: that’s the role of solution-architects, and we shouldn’t be treading on their turf or their authority. In terms of the Five Element cycle, EAs’ work would place much more emphasis on the Why and the Who, the far-future and people-time, rather than solution-architects’ How and with-What / Where / When, the near-future and NOW. (Many of us may do both types of roles, of course – but we need to be clear which role we’re enacting at each moment, and not mix them up!)
There’s more on that in the series of posts here on ‘Selling EA’, starting with ‘Selling EA – 1: What do EA clients want?‘.
On “You may think I am also IT centric” – nope. 🙂 Maybe IT-oriented, or IT-focussed, of necessity, but not IT-centric: there’s a key difference there. More on that, for example, in posts here such as ‘IT-oriented versus IT-centric‘ and How IT-centrism creeps into enterprise-architecture‘.
Hope that makes (some) sense, and thanks again!
Thanks Tom for useful comment!
Also for the links to other articles.
I am working on selling my EA now ;-), so i will be able to read them latter. However “Seling EA” I should check now.
Thank you again,
Regards
Hi Tom and all,
I followed you exchanges and reactions related to the new ArchiMate release.
I would like to share with you some feedback concerning my usage of ArchiMate within the context of my research work on interoperability of enterprise applications.
In this area, Importance of enterprise modeling was identified a long time ago. For this, I choose ArchiMate as a way for making the different stakeholders and architects talk together in order ensuring they will prepare and build expected operational interoperability between the applications supporting the process of the enterprises.
I identified importance of ArchiMate supporting viewpoints relying on ISO/IEC 42010:2007. Each stakeholder can consequently access to an ArchiMate model only through the appropriate views for their concerns.
For each view, a subset of concepts which are familiar for each kind of stakeholder is provided by ArchiMate, which is not as rich and complete than their usual specialist languages: BPMN for process architects, UML for Software designers, etc.
I think it is important for learning curve. ArchiMate 2.0 proposes about 50 modeling constructs (and many less per viewpoint), against about 150 for BPMN and 250 for UML. The intent is clearly not replacing UML or BPMN, but to propose a formal language making users of UML and BPMN able to connect their model and validate them according business motivations, providing support for architectural trade off, blueprinting (identification between AS IS and TO BE situation for completing usage of traditional project management tools).
Comparing it to UML or SysML, it appears that ArchiMate is definitively not a designer tool. The concept of Class and instance of Class is not supported, making it about impossible to use when willing to reuse software product architecture definition in UML.
In addition, the constructs proposed by ArchiMate are not at the same level of details than the specialized languages. E.g. only Process construct is proposed, but not activities or tasks as for workflow description languages. Idem for Project: only Workpackage construct is proposed, not task as for Project Management tools.
In order fully take advantage of ArchiMate, it appears that using it as a notation is not very interesting, as drawing doesn’t allow to be computer aided for producing and validating a model. For this reason, using a modeling tool such as Archi is highly recommended.
Definitively, ArchiMate is a language for architects, and is not so appropriate for communication with non specialists. There is still the need to learn the language and to rely on modeling. Many people don’t like it, and in this case, drawing and mindmapping which prevent learning a language (CMAP tool, Freemind, Xmind, etc.) are definitively more appropriate. But here again these tools are not modeling tools, only drawing tools. A way to take advantage of them should be to tag the mindmaps with the language constructs used by specialists which will have to use them, in order to exploit them. The mindmap can then be used as input for deriving an ArchiMate or a UML model.
Some issues identified when using ArchiMate and associated modeling tools:
I agree with you that it is too much ICT centric – ability to define at a high level a manufactured product or associated capabilities was missing in ArchiMate 2.0. I think that ArchiMate 3.0 is providing some new constructs that adress this issue.
Layering is important, as it really allow to make a clear differentiation between the objects of the models coming from ICT architects, Information System Architecs and Business Architects. What can be misleading is that Implementation&Migration or Stragegy&Motivation are not layers. Strategy&Motivation is trans-layers and provide a way for decision making, while Implementation&Migration is more about defining the blueprint between AS IS and TO BE, here again for the 3 layers. Gaps are to be solved by mean of realisation of the WPs of a project. When using ArchiMate only as a notation for communication, it is not so easy identify that ArchiMate can support such a blueprinting process (planification of work for going from AS IS to TO BE under the control of enterprise motivations, principles and constraints).
Other issue comes from the fact that many viewpoints are in fact describing concepts which are not part of the modeling construct of the language: Project, Organisation, etc. When using ArchiMate for enterprise controlled urbanisation (in order supporting trade off between numerous ICT projects in the enterprise) or for working on network of enterprises and organisations, it is clearly an important limitation. ArchiMate is multi-views, but not multi scales. It brings limitation for capturing complex interconnect organisations.
Not having ability to define classes (or categories) and instance of classes (or types individual) also brings a limitation. E.g. when willing to capture the fact that a software system installed on a machine (ICT layer) is an instance of a software product (Business Layer) is not supported, when it is very important for configuration management: a software system is an instance of a versionned software product, and it should be easy to capture for exemple when making a migration or willing to easily capture that organisation are not using the same versions of a software product. It is also not possible using multiple classifications like for semantic web language (OWL). It may occur that something can be described using different constructs of ArchiMate in orde to show it according different viewpoints. This is currently not well supported with ArchiMate.
Other issue: I think that ArchiMate is still to much attached to drawing tools, and it makes it difficult to take advantage of emerging interactive visualisation tools which support navigating in representations of complex organisation (semantic cartography). In Archi, some visualisation capabilities are provided (navigation on a interactive graph of the model) but other technics such as interactive treemaps should also be possible. It is all the difference between using a static paper map and in interactive GPS tool when travelling.
Finally, an enterprise model will have value if the different stakeholder can have access to it from intranet for the view concerning them as persons in organization with roles, e.g. allowing to have automatic filtering and publication of what concerns them. Many modeling tools propose publication of the models as static set of html pages which can be navigated with hyperlinks: Archi, Essential,etc. Such publications should be more interactive, in particular for the visual representations, taking one again advantage of semantic cartography, but also of emerging capabilities of Internet technologies for visual interactive models.
Unlike other enteprise modeling framework, no information layer is provided. As I’m working on exchange and sharing of data describing a manufactured product and associated processes, it is a little bit annoyng not having information made more appearant. ArchiMate is definitively more “service” oriented than “data” oriented or “Physical Product”(e.g. an Aircraft) oriented. Even if data concern is adressed with a dedicated cross layer viewpoint. But as stated previously, viewpoints are not so easy to use when drawing with ArchiMate.
So for sure no perfect tool and language suited for all the needs will never exist.
For my purpose: preparing and building operational interoperability of enteprise applications, ArchImate is clearly a very good language despite the issues and weaknesses I described.
Extensions of the language proposed in ArchiMate 3.0 at a first look really respond to something missing: description of physical things inside the enterprise which can be helpful for logistic and provide the ability to adress emerging needs for considering Internet of Things connected to physical products and associated products (e.g. Digital Twins, Digital Thread, Manufacturing 4.0). For these new use cases, usage of layers as defined by ArchiMate will have to evolve, as everything can be connected and will consequently be part of the information system for data acquisition and distribution of digital work orders.
How to deal with other issues: multi scales, classes, etc? Extending ArchImate for this could lead to make it as complex than the other specialized languages, making it more difficult to use for non specialists.
A way which is being explored in research (IMAGINE project, SIP project at IRT-SystemX) is to bring such missing modeling capabilities by using ArchiMate “over” languages having these capabilities (e.g. UML2 or SysML). ArchiMate is formalized as a set of UML Classes, UML Component or SysML blocks for objects, and as UML relations for ArchiMate relationships. It is then possible, using composite models, to use UML2 or SysML modeling environment as ArchiMate modeling environments, bringing ability to produce multi-scale composite models a collaborative way, but also to make the link with other models formalized with other languages used by other disciplines.
Then different set of simple views, at different levels of granularity, can be produced – that can be adapted to the stakeholders concerns. And the link with other disciplines can be formally defined: Business process architects, System Engineers, etc.
So what could be the conclusion.
I think that the appropriate tool is to be used for the appropriate intended usage by the appropriate skilled persons , and that for building an enterprise, you need different disciplines and tools. ArchiMate is definively a good language for the purpose it was defined for, and it will have to be combined with non modeling tools and more specialised modeling tools and languages: software design tools, business process modeling tools, Product&Process data management tools, etc.
Best regards.
Nicolas
I have been watching the evolution of the Archimate standard for the last couple of years with some interest. It would appear that they will need to introduce a more formal meta-modelling technique into their approach in order to resolve some of the key issues they are currently facing with the Archimate 3.0 standard.
In particular:
– recursion
– composition
– type-instance, and
– levels of abstraction
All need to be consistently applied across viewpoints in order to unlock improved usability and a simpler set of end user modelling experiences.
It should be easy to start with high level conceptual entities and to progressively decompose them into their constituent elements over time. The designers of the UML have been working on these issues for the last 15 years and deeply understand how these mechanisms need to be applied. I would hope that the Archimate language designers could reuse these techniques and draw on the strengths of the UML to unlock a better user experience.
Hi Shaun,
could you please add some example.
I am little bit afraid that your suggestion could lead into Archimate to UML (probably Deployment diagram) transition and that might not be the idea of Archimate.
Could you little bit clarify your idea please?
Thank you,
Roman