As we stated in the introduction to this blog series, ArchiMate models can usefully be combined with models in other techniques, in order to zoom in on specific aspects of your enterprise. If these models are tied in to an overall enterprise architecture model in ArchiMate, an integrated model of the enterprise can be constructed that relates (sub)models from formerly separate domains in a meaningful way.
In our previous blogs, we already discussed the Business Motivation Model, Balanced Scorecard, Business Model Canvas and to BPMN. In this last blog of the series we will elaborate on how ArchiMate 3 can relate to languages UML, SysML and ERD.
The following tables provide an approximate mapping between ArchiMate concepts and those techniques. In these tables, the more abstract, high-level concepts are always on the left and the more concrete, detailed concepts are in the right-hand column. We finish this blog with showing you some examples on how Enterprise Studio supports some of this.
The Unified Modeling Language (UML) is the de-facto standard for software modelling. Several concepts in ArchiMate were strongly inspired by UML. The most obvious is the application component concept, which corresponds to the UML component. The node, artifact, device, system software, and path elements have also been taken more or less directly from UML (where system software is called execution environment). This close linkage facilitates a continuous development chain. between higher-level Enterprise Architecture models described in ArchiMate notation and lower-level solution architecture and implementation models in UML.
|Business Actor, Role||Actor|
|Requirement + Service||Use Case|
|Business Object, Data Object||Class|
|Node, Device, System Software||Node, Device, Execution Environment|
|Application Interface + Service||Interface|
|Aggregation, Composition, Specialization||Aggregation, Composition, Generalization|
There are also some important differences between the two. The ArchiMate serving relationship, although superficially similar in notation, is semantically different from UML’s dependency and often points in the opposite direction. A UML dependency is used to model, for example, function calls in software programs. At the architectural level at which the ArchiMate language is aimed, run-time operational details of such call graphs are less important than the more stable and generic notion of service provision. In ArchiMate, the direction of the serving relationship therefore denotes the direction of service delivery, independent of whether this service is called by the user or offered pro-actively by the provider.
This also points to another important difference: UML does not have a separate service concept, since in its object-oriented paradigm the behavior expressed by a service is encapsulated via (the operations of) an interface. The ArchiMate language differentiates between interfaces and the services they provide, in order to specify that the same service is offered through multiple interfaces. Hence, UML interface corresponds with the combination of an ArchiMate application interface and service.
The Systems Modeling Language (SysML) is an offshoot from UML for systems engineering and offers concepts for specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems. It is less software-centric than UML and a lot smaller and simpler to learn (although its diagrams can become quite complicated).
When designing physical systems (or systems with physical parts), SysML may be suited as a language for the more detailed design, in a context where ArchiMate is used for the architecture level of abstraction.
|Active Structure Element, e.g. Application Component,|
Business Actor, Device, Equipment, Faciltiy
|Service + Interface||Port|
One of the older type of modelling techniques in ICT is the entity-relationship (ER) model. An ER model comprises entity types, which classify the things of interest, and specific relationships between the instances of these types. There are various techniques to depict ER models in ER diagrams, one of the most popular being the so-called crow’s foot notation.
ER models are often used in data modelling, in particular in the design of relational databases. As such, they map most naturally on ArchiMate’s passive structure concepts, as shown in the next table. Attributes, keys or instances of entities would typically not be modeled in ArchiMate, as these are usually too detailed for the enterprise architecture level of abstraction. For the same reason, ArchiMate does not support cardinalities of relationships.
|Business Object, Meaning||Entity (conceptual)|
|Data Object||Entity (logical)|
|Association (with label)||Relationship|
ArchiMate, UML and ERD in Enterprise Studio
In Enterprise Studio users are able to make ArchiMate 3.0, UML and ERD models. You could choose to use just one modeling language, but you might want to use different languages next to each other. In order to support specific stakeholders, which have different needs for modeling. Data models in ArchiMate can be modelled using passive structure concepts like business objects and data objects.
If more details are required, you could choose to make more in depth UML Class diagrams of the in ArchiMate defined business and data objects.
If you are more a fan of Entity Relation Diagrams (ERD) you could choose to use ERD instead of UML for your data modeling (figure 3).
Enterprise Studio is capable of supporting all these different kind models. Either if you choose to use just one language or are using multiple languages like ArchiMate, BPMN and UML for example, you will see that making models will help you understand your business better and that Enterprise Studio is accommodating all your modeling needs.