- Adaptive Enterprise
Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.
This is the seventh posting in our series on using ArchiMate in practice. So far we have considered the mind of the architect as well as several ‘fundamentals’ in the language: the structure / behavior dichotomy, three layers, internal / external aspects of each domain, specialization, and the use of views & viewpoints. In this posting we will discuss some ‘philosophical’ and practical issues that you may run into when using ArchiMate.
The passive structure aspect of the ArchiMate framework is sometimes called the information aspect. Indeed, here we model such things as conceptual information structures (using business objects), logical data structures (using data objects) and physical / storage structures (with artifacts), all at a high level of abstraction. After all, we worry about the fundamental concepts or properties of a system, not the detailed design.
In (conceptual) data modeling, it is not uncommon to model attributes of elements. This is particularly useful when using specialization, since child objects inherit the attributes of their parents. The ArchiMate language does not include this mechanism (more precisely: ArchiMate does have the idea of ‘attributes’ of objects to capture such things as the owner of a system, the quality of a service etcetera. Here, though, we refer to the notion of attributes as we know it from ERD or UML modeling). The following example illustrates this. Suppose we are doing some modelling in the HR-domain. We want to model the fact that employees (always homo sapiens) work for employers (which may be a homo sapiens, or some organization). The following diagram shows this:
This small model is informative, but does not capture simple things such as: which attributes does Employee inherit from Person and Party? The only way to model those aspects is through the use of the aggregation relation which is not terribly elegant. Extensions to the language have been proposed to make that happen and move a little closer to the ERD notation. While this is a big issue in the data modeling community, in practice there are many workable solutions.
Our preferences is to take into account the separation of concerns between architecture modeling and (more detailed) design. This mechanism is of a more general interest: mapping architecture models to detailed design models is also important in e.g. linking ArchiMate to BMM, BPMN or UML. We propose to use two models and create links between the two models as follows:
Note that not all tools support this mechanism of linking between different types of models. If you are interested in details on how to do this in BiZZdesign Architect, please let us know.
Another aspect that has been debated extensively in various LinkedIn groups and other fora is the notion of modality of relations. Modality refers to (im)possibility, necessity and cardinality. More specifically, it refers to statements of “should have”, “must have”, “cannot have”. Often this is extended to the notion of cardinality, to express that a relation is “one-to-one” or “one-to-many”.
More concretely, we have seen many cases where modelers want to express such things as:
In many modeling languages (including UML, ORM2 and ERD) it is possible to express these aspects directly. The SBVR language makes it possible to express even more complex rules such as
ArchiMate does not have a built-in mechanism for representing modality, cardinality or such complex rules. However, through the extension mechanisms it should not be too hard to incorporate this for a specific setting. However, we feel that the approach that was mentioned previously (linking ArchiMate models to more detailed design models) is the most practical way of working.
A debate that we sometimes run into directly relates to the structure / behavior discussion that we discussed in posting 3 of this series. Recall that the structure elements can be further classified into active structure elements and passive structure elements: the former are said to perform the behavior, whereas the latter are otherwise related (i.e., input / output) to the behavior.
Now, ask yourself the question: is a computer an active structure element or not? Or more precisely: do we consider it to be active or passive? To solve the puzzle, we must answer the question: does the computer do something, or is it otherwise related to behavior?
These two statements appear to contradict each other. The following diagram illustrates the issue as well as why this conundrum rarely leads to serious issues in practice:
As usual, we start the process with the fact that the modeler perceives the real world, recognizing a ‘computer’ in the domain under consideration. Further, s/he recognizes that the computer may be represented by an active structure element in one context, and a passive structure element in another. This may lead to a situation where one object in the real world maybe represented by two model elements. However, since the two contexts rarely coincide, this doesn’t tend to cause too many issues in day to day modeling. And if both would occur in the same model, you could relate the two model elements with ArchiMate’s association relationship to denote that these two represent different aspects of the same real-world entity.
The last aspect that we want to discuss here pertains to links between the three domains. This appears to be the source of some confusion.
The most prominent example is the situation where we want to model a fully automated (straight-through) process. A first analysis may lead to the following insight:
The following diagram shows the two most common options:
There is a big difference in semantics between the two options – which are both valid ArchiMate models. In option A we’re trying to express the fact that a process uses some automated functionality (represented by a service, see also posting 4) that is realized by some component. By contrast, option B expresses the fact that the application component executes the process, which is what we were looking for in the first place.
It appears that many modelers have a built-in sense to use the assignment relation only within the bounds of a layer:
There is, however, no reason to apply this restriction. As the example above shows, in many cases a cross-domain assignment relation allows us to express exactly what we want!
In an overview posting that kicked off this series, we announced three series of postings related to ArchiMate: introduction & theory, modeling in practice, and worked example. This is the last posting of the introduction & theory series in which we have presented an extensive overview of the fundamentals of the ArchiMate language. Details of concepts and relations can be found in the specification.
This concludes the first series and sets the stage for the second. In the meantime, if you have any questions or topics you would like us to discuss, feel free to drop us a note.