Planning and Roadmapping : Modeling in ArchiMate
Oct 9, 2018
In our previous blog post on planning and roadmapping, we discussed the general idea of planning and roadmapping in the context of enterprise architecture and capability-based planning. We addressed different levels of roadmaps, ranging from short-term sprints of a few weeks to long-term, multi-year roadmaps. We also provided some first insights into the use of ArchiMate concepts for modeling roadmaps. In this installment, we want to go deeper into different ways of modeling the evolution of your architecture.
The most prominent feature of the ArchiMate language is the Plateau concept. In the standard, this is defined as: “a relatively stable state of the architecture that exists during a limited period of time.” The intention of this concept is to model fairly major changes to your architecture, hence the ‘relatively stable’; small-scale changes are too frequent to lend themselves easily for collecting them in plateaus. For example, you wouldn’t want to model each individual software patch this way. Since these seldom have architectural significance anyway (however important they may be for other reasons of course), an architecture model is not the best place to capture such changes. Hence this way of modeling is particularly useful at the strategic and tactical levels that enterprise architecture is typically concerned with.
A plateau is valid in some time span, so it will typically have a start and end date. A plateau may go into effect after some project or agile release train delivers a change, and stay in effect until the next change comes along. In terms of ArchiMate relationships, plateaus may aggregate any element or relationship in the architecture that is current in their designated time frame. Their architecture scope may be limited to a specific part of the architecture, say a business domain or a specific system. Multiple sub-plateaus can be aggregated in one larger one, say to model the overall roadmap consisting of the evolution of different business domains. Of course, you should then keep the time periods of the sub-plateaus consistent with their parent plateau, otherwise your model doesn’t make much sense.
You can also use plateaus to express alternative paths towards the future. The figure below gives an example of this, in a scenario after the merger of two organizations: In Transition A, a common CRM system is implemented first, whereas in Transition B the back-office systems are replaced first. Transition C is then the state in which both CRM and back-office systems have been consolidated.
The graphical notation for plateaus is mainly useful to map such an evolution, rather than to organize the architecture itself, since many elements in your architecture will be part of several plateaus. For example, anything in the baseline that survives through the transitions above may be aggregated in all plateaus.
For that reason, we often use plateaus in an architecture model but not necessarily in a view in the way shown above. Rather, we enter the aggregation relationships between plateaus and their content in a cross-reference table and use this in views and analyses. The figure below shows an example of this, highlighting elements based on the plateaus they are in, based on the same scenario shown above.
Next to the coarse-grained roadmap evolution outlined above, you may also want to model that some element in the architecture is improved. A common example of this is using ‘capability increments’ to express that the maturity of some capability grows over time. A good way to do this is to model each increment as a specialization of a higher-level generic element, in this case that specific capability, and aggregate these specializations in appropriate plateaus. This way, you can see both the overall structure of the architecture – e.g. which elements are needed to realize this capability – and show consecutive improvements. The same pattern works for modeling software releases, so you may model the generic element ‘PaymentApp’ with specializations like ‘PaymentApp 3.3’, ‘PaymentApp 3.4’ and ‘PaymentApp 4.0’. Each of these can in turn be related to a plateau that starts on the release or deployment date of that version and ends when it is replaced by the next. The figure below shows this.
In the next installment of this series, we will look into modeling time at a more detailed, fine-grained level. We will also discuss how you can model the lifecycles of individual elements and use dependencies between lifecycle stages of different elements in your architecture to identify, for instance, conflicts in your transition plans. Until then, if you’d like to learn more about these features and others in Enterprise Studio, watch one of our webinars or book a demo!
