When ArchiMate meets UML: how to conciliate Enterprise Architects and Software Application Designers
Nicolas Figay
Model Manager | Enterprise Architecture & ArchiMate Advocate | Expert in MBSE, PLM, STEP Standards & Ontologies | Open Source Innovator(ArchiCG)
If you like this post, don't hesitate to share and to validate my skills ;-)
A fundamental difference between UML and ArchiMate comes from the following:
" The concept of Class and instance of Class is not supported."
Let's consider what it means concerning intended usage of ArchiMate, and why it makes it a fundamental difference with UML.
With Archi, let's capture in a Business view a Product and a sub-product, which is a component of the product.
The previous figure shows that two model elements of type Product were created and connected with a composition relationship.
When drawing the diagram, it is also possible to draw the component:Product as contained in product:Product. It doesn't change the model on the left, just the visual representation. It is shown in the next figure. Two alternative visual representations can be used, without changing the model. Using one or the other will depend on communication consideration, mixing graphs and nested boxes in order making the diagram more understandable at the first sight.
No let's compare to what can be captured with UML.
Looking at previous figures, you can see that a Product Class was defined, with a Component Class as an inner element of the Product. The last point is visible in the model editor, not on the diagram which is just a view on the model. In addition, two components c1 and c2 were created as parts of the Product, and typed as Component. In addition an instanceSpecification typed as Component was created. Let's note that InstanceSpecification construct replaced the object instance construct used in previous version of UML. With such construct, multi-typing is possible. The part construct reflects a definition within the scope of the Product. The link between a part and an instance can be established through "mounting" of the instance as a part. All these constructs aims at resolving issues related to aggregation and composition related to the mutability of systems for which design models are to be produced. E.g. let's consider wheels of a car that you can mount and unmount at different places on the car. Mixing wheel as a part and as an instance make the choice difficult between composition and aggregation. It is not anymore the case since the introduction of "Part" and "InstanceSpecifcation" constructs, which are very convenient for system designers!
Let's compare now what the two modelling languages allow to capture, and what having nor Class neither Instance in ArchiMate implies.
- no cardinality can be indicated
- the question arise for people used to modelling with UML: how to reuse classes defined in UML? Does a model element in ArchiMate correspond to UML class, instanceSpecification or part?
- It is not possible to realize composite models with ArchiMate, with multiple granularity.
Concerning the point 2, what I learnt from practice in the IMAGINE or SIP projects is that an ArchiMate model element should correspond to an instanceSpecification.
As an engineer, it was initially a little disturbed, when trying to make the link between design models in UML and ArchiMate models.
The usage allowed to understand better what a "blueprint model" really is, and the intent of usage is: a "blueprint" model allows describing a plan, with description of what is, what will be and how to close the gaps, with links to work packages of projects to be launched in order achieving objectives of the enterprise, with strong alignment with the motivation of the different stakeholders.
ArchiMate if for blueprinting, UML is for designing
For defining a blueprint, a design language such as UML or SysML is not needed, as the purpose is not designing a system, just to agree on a common and agreed plan between all the stakeholders, in order to go from an AS IS to a TO BE situation.
Concerning the point 3, no support of composite models with multiple granularity is a real limitation for modelling a network of enterprise (cf. the "Advanced usage of ArchiMate for Dynamic Manufacturing Living Lab" article).
No support of composite models with multiple granularity is a real limitation for modelling a network of enterprise
So should the ArchiMate community extend the language in order adding Class, Instance or Part constructs, making it as complex than UML and less accurate for user wanting just to define blueprints? The SIP project was the opportunity for proposing a way for addressing it without changing ArchiMate, addressing how to combine Enterprise architects' models and Software Designers models.
This is described in some of my LinkedIn articles explaining how powerful it can be:
- "Solving ArchiMate limitations ... without changing ArchiMate",
- "Advanced usage of ArchiMate for Dynamic Manufacturing Living Lab"...
It is also the subject of one of my last research paper, "Dynamic Manufacturing Network - from flat Semantic Graphs to Composite Models", published in 2019 in the International Journal of Production Research.
Finally, it could lead to some non interoperability issues, when working with modeling tools which are using ArchiMate as a DSL (e.g. Archi) or as a UML profile (e.g. Enterprise Architect). When Archi using folders (which are not part of the specification) and EA UML packages or containment, we have an issue of interchange even using the open Model Exchange Format for ArchiMate proposed by the Open Group. This is detailed in the article ArchiMate and Interoperability: what are the potential issues you could have?
No support of composite models could lead to interoperability issues
For those not familiar with ArchiMate, let's have a look and experiment with the new Archi version (4.3.3), which implements ArchiMate 3. It's just out (February 2019) and it was just enriched with a scripting module, jArchi.
Let's enjoy :)
A TOGAF & ITIL/ITSM certified architect and registered professional engineer with 25+ years of experience in IT architectures.
2 年ArchiMate simplifies but does not replace the other notations such as UML or BPMN. The lack of Type & Instance can be fully covered and complemented by UML's Class & Object, and the semantic Collaboration & Interaction in ArchiMate could be refined with design detail in UML Activity, object interaction & Sequence. Composition, Aggregation, Specialization, and Implementation (i.e. Realization) are inherent parts of the UML (but ArchiMate specifies the same relationship notation and allows for applying these UML on all ArchiMate elements). Only that the tool needs to implement such integration. Note also UML Stereotype allows a tool or a profile customized within the tool to cover all standard ArchiMate elements. So in a sense, ArchiMate is like a subset of UML for its simplicity goal. I see the use of all notations (ArchiMate, UML, BPMN, etc.) in a complementary way. So the simple integration of the notations in a tool is probably what's needed. In fact, SparxSystems EA tool does quite a good job to support ArchiMate elements using the UML stereotype mechanism.
Business Architect - Modeling expertise with ArchiMate - System engineering enthusiast CESAMES & ARCADIA - PECB ISO27001 Lead implementer
8 年We have the same concern : how to do class model with Archimate. I think that a slight change in the Archimate model could be helpful. Maybe, at least add some new connectors to allow a UML class model. Who has already done it ? Thanks in advance.
CIO at NHIndustries
8 年When you say " the concept of Class and instance of Class is not supported" in Archimate, I would say that it is not entirely true. It is true in the "UML way", but not in the Archimate way. Archimate being a semantic language, you should not consider it as an alternative to UML because, despite the fact that it looks familiar, it is deeply different. Concepts are sorted in three categories: active structures, behavior and passive structure. All artifacts are "instances" of the semantic metamodel artifacts. The "part" case that PLM is facing is very particular for me. I don't know if I understood correctly what you mean because you propose a solution without really exposing your issue. A "part" can be a subsystem composed of various parts. I will suppose this is what you try to express. In Archimate (like in semantic modeling), the objective would just be to express to express the basic notions, in that case subsystem and part, the part being understood as a part that is not a subsystem. https://drive.google.com/open?id=0B0uP6socJOBdbm5BcTRxRmV2S1E In this diagram, you would express that some concepts can be composites and that, at a certain scale, you would have "composable parts". This would be done in a EA context, i.e. in a context where it is relevant at a EA standpoint to indicate this distinction. For your other concerns: 1. Lack of cardinality in Archimate is a design choice, because Archimate is not a design language. 2. I would say no. A data class is more a "software business concept". 3. For me it is possible but Archimate is not designed for that purpose. Archimate is not made for "blueprints" neither. The fact is Archimate is done for EA with a EA intention and not for system design or industrial design. Archimate 3 proposes a view of manufacturing but also in a EA perspective :)
Solutions Architect & Consultant | Finding a way to do more using less within the reason and the budget
8 年As you can not uniquely attribute UML to SW, you can not uniquely attribute ArchiMate to EA neither. Because both are only (in their core) - notations!
Model Manager | Enterprise Architecture & ArchiMate Advocate | Expert in MBSE, PLM, STEP Standards & Ontologies | Open Source Innovator(ArchiCG)
8 年I don't fully agree with you concerning the fact that ArchiMate is not a serious modelling language. Implemented by tools such as Archi, but I think also by many other solution of the market, it makes it more affordable for non modelling specialists and very accurate for blueprinting. ArchiMate provides about 60 modelling constructs, when UML proposes about 250 and BPMN about 150. And nor UML neither BPMN are accurate for blueprinting. Extending ArchiMate should result in increasing the learning curve of people in order to use it. I worked on a way making the composite pattern useable without extending ArchiMate, which will be presented in future posts and research papers.