ArchiMate 3.1: The New Version of the Standard
Nov 5, 2019
At the Open Group conference in Amsterdam in November 2019, the latest version of the ArchiMate modeling language for enterprise architecture was released. Version 3.1 is an update to the previous major version 3.0 (released in 2016). Despite being ‘just’ a minor version update, it holds a number of useful additions and improvements for EA practitioners.
The three most important improvements to the standard are:
The most important and visible of these changes in version 3.1 is the addition of a new value stream element in the Strategy layer. The standard defines this as follows:
“A value stream represents a sequence of activities that create an overall result for a customer, stakeholder, or end user.”
A value stream describes how an enterprise organizes its activities to create value. As described in the TOGAF Series Guide to Value Streams, a key principle of value streams is that value is always defined from the perspective of the stakeholder – the customer, end-user, or recipient of the product, service, or deliverable produced by the work. Value stream notions also appear elsewhere, in business architecture methods such as the Guide to the BIZBOK® and in agile methodologies like the Scaled Agile Framework (SAFe®). ArchiMate’s definition is sufficiently generic to cover these notions.
Value streams are different from business processes. The latter are concerned with the ‘how’, the tasks performed by an organization to produce some concrete product or service, whereas value streams are about the ‘what’, the value that is created. That value is in the eye of the beholder; it depends more on the stakeholder’s perception of the worth of the product, service, outcome, or deliverable than on its intrinsic value; i.e., the cost to produce. This is modeled in the ArchiMate language using the value element (which already existed in ArchiMate 1.0).
Value streams are typically realized by business processes. The stages in a value stream provide a framework for organizing and defining those processes, but different parts of the organization may have their own implementations of processes to realize the same value stream stage. Conversely, one business process may realize multiple stages in a value stream.
Resources can be assigned to value streams and capabilities can serve (i.e., enable) a value stream. This supports the common technique of capability–value stream cross-mapping, where you identify which capabilities the enterprise needs or uses to support the stages in a value stream. An example of this is shown in the figure below. It shows a model of a data analysis value stream from a business intelligence case study. Between the stages of the value stream, we see the value flows with associated value added by each stage, and at the end the business outcome of ‘well-founded decision making’ that this value stream realizes for a particular stakeholder. Each stage in the value stream requires a number of capabilities, shown below the stages and also exhibiting how you can use the improved grouping concept to model this cross-mapping efficiently.
Adding this value stream concept has created a neat symmetry in the language. Value streams and capabilities reflect an enterprise’s business model and value creation in an organization-independent way, whereas business processes and business functions reflect its operating model and are more organization-dependent. At their respective abstraction levels, value streams and business processes both represent the ‘enterprise in motion’, whereas capabilities and business functions both describe the ‘enterprise at rest’.
The addition of a directed association relationship is a small improvement with great potential. One common use case is to express navigability, for example that an insurance policy refers to the insured asset but not the other way around.
Especially when combined with ArchiMate’s notion of specializing concepts and the accompanying stereotype notation (see the chapter in the standard on Language Customization Mechanisms), it allows you to give more meaning to the relatively ‘meaningless’ association. The picture below shows the relationship between an application owner and the application they own, using such a directed, stereotyped association.
Now you do need to exercise some caution in using this feature. It would not be very helpful, for example, to define your own relationship if something very close is already offered natively by the standard.
Next to the additions and improvements mentioned above, the new specification also introduces refined rules for the derivation of relationships. This is a more specialized subject that for most of you will be hidden inside your ArchiMate tools.
These derivation rules let you draw conclusions or summaries about the relations that may (or must) exist between the end points in a chain of elements connected by various kinds of relationships. For example, if your Customer Service department performs (is assigned to in ArchiMate terms) a business process Handle Customer Request that in turn provides (i.e., realizes) a Helpdesk Service, you can conclude that the Customer Service department realizes this Helpdesk Service.
In the new version of the standard, we have formalized these rules (and the restrictions on applying them) to make sure they are understood and implemented consistently. This now looks more like a ‘mathematical’ specification but I won’t bore you with the details here.
We have also refined these rules to make a distinction between derivations that must or may be true. The first, the so-called ‘valid’ derivations are necessarily the case. For example, if A contains B and B contains C, A by definition contains C (using the composition relationship). This derivation is always valid.
It is also possible to draw conclusions about relationships that are only ‘potential’; whether they exist in reality depends on the specifics of your architecture. For instance, if an application service S serves a business process P that consists of sub-processes Q and R, either of these sub-processes could be served by (i.e., use) service S. Only a decision by an architect or detailed examination of Q and R in reality will tell which of these is really the case, but both serving relationships may be correct.
Note that all these derived relationships are also allowed in the ArchiMate language. Adding this notion of ‘valid’ and ‘potential’ relations has increased the analytical power of ArchiMate and expanded the possible relationships, giving modelers more freedom and options.
Next to the main improvements mentioned above, several larger and smaller changes have been made to the definitions of concepts in the language, both to clarify these and to improve alignment with other standards such as TOGAF. The icon notation is now allowed for all elements with a box-with-icon notation and not just a somewhat random subset. Finally, the depiction and structure of ArchiMate’s metamodel has been improved in various places. This is not something the average user of the language will notice, but it helps in better understanding the standard.
With these latest improvements and additions, ArchiMate’s coverage of the enterprise architecture discipline is pretty complete, at least in terms of the domains it can describe. Therefore we don’t expect major extensions of the language scope in the near future. There are some other aspects that would be up for improvement, though. For example, notation alternatives that look prettier to business stakeholders, or ways of using the language in earlier stages of the architectural design, when ideas haven’t crystallized yet. Moreover, we may want to look at simplifying the language structure (of course without reducing its expressive power).
Those are all long-term ideas, however. For now, ArchiMate 3.1 is fit for purpose and without serious competition, as its ever growing user base shows. If you have ideas on the standard and want to contribute to its evolution, or simply want to know more about it, please join the ArchiMate Forum of The Open Group or the LinkedIn ArchiMate group, where lively discussions take place on all aspects of the language.
And of course, if you are looking for the best available implementation of ArchiMate 3.1 in a modeling tool, you don’t need to look further than BiZZdesign’s HoriZZon platform!
Download your new ArchiMate 3.1 quick reference card here.
