Modeling Capability Increments and Capability Instances to Support Roadmapping
May 19, 2022
So far in our blog series, the capability models we’ve used are relatively simple in terms of their structure. In our previous blog post on capability measurement, we already promised to provide more detail on how you can model capabilities over time and how to describe different instances.
In larger organizations, the same business capability may be implemented in different ways across the enterprise in business units or regional organizations. For example, in a multi-national company, the same Human Resource Management capabilities may be realized in different ways in accordance with local customs and regulations. Each of these specific versions can be modeled as a specialization of the same generic capability, as shown in the figure below.
Figure 1. Regional capability instances specialize in the same generic capability
Each of these instances, in turn, is realized by various other elements (people, process, information, technology) from each region. Perhaps some of those are again standardized across the entire organization, say an HR application used globally. Others are local, like the individual HR departments of each business unit.
These instances can be assessed separately in the ways described in our previous blogs on capability measurement and maturity assessment. From these assessments, you can calculate an average maturity, but perhaps more importantly, you can analyze which instances perform best and share best practices with other instances. You can increase global maturity by fostering an internal learning process.
The evolution of capabilities is often expressed in so-called ‘increments .’Each increment represents a stable state of a capability that exists for a certain time. These increments can also be considered specializations of a generic capability. In this case, they don’t represent local differences like the capability instances discussed above, but differences that occur over time. If you need to use both increments and instances in conjunction, an instance will typically have its increments, not the other way around. For example, each of the regional HR capabilities above might evolve at its own pace.
The figure below shows a simple roadmap where the Customer Management capability is improved in stages by three ArchiMate work packages that model the change activities: to homogenize the information and data on customers across business units, to improve global access to that data, and to harmonize billing processes across different business units. The end date of each of these is when the corresponding capability increment is fully realized, so that’s the start date of the increment. You could mark this as a milestone on your roadmap.
Figure 2. Capability increments and projects realizing these
If we look at each of these changes in more detail, we would see that those change activities impact specific elements that contribute to the realization of the increment. For instance, ‘Harmonize billing process’ mainly impacts the project dimension of ‘Customer Management increment 3’ by improving the billing process, which underpins this capability dimension. See also our previous blog on capability assessment dimensions.
We can organize capability increments in releases resulting from a series of sprints (Figure 3). This view shows the release planning and, for Release 1, also the (simplified) sprint planning. This way, you can analyze what happens to the availability of your solution if an agile team decides to move a certain feature to a later sprint, for instance. In the underlying model (but not shown in the figure), all the elements created or changed in the two sprints contribute to the first capability increment. Of course, this is a highly simplified figure for explanatory purposes. The real roadmap is much more extensive and includes improvements to several capabilities.
Figure 3: High-level and detailed roadmap stages
The further you look ahead, the less tangible and specific your roadmap will be. Hence, the ArchiMate concepts for the near-term future are typically the concrete and detailed business, application, and technology layer elements. For the medium-term future, you might use the more abstract, high-level capability and resource concepts, and you might express the longer term using only goals and outcomes.
ArchiMate’s graphical notation for plateaus is mainly useful for mapping such an evolution rather than depicting the architecture itself since many elements in your architecture are part of several plateaus. For example, anything in the baseline that survives through the transitions above is part of all plateaus on the roadmap. That would clutter a figure like the above. For that reason, we often use plateaus in an architecture model but not necessarily in a view.
Often, we enter the aggregation relationships between plateaus and their content in a cross-reference table and use this in views and analyses. Figure 4 shows an example of such an analysis, highlighting elements based on the plateaus they’re part of, based on the same scenario shown above. Such a heatmap quickly shows the impact of changes to your architecture.
Figure 4: Highlighting plateaus in the architecture
Next to the coarse-grained capability-level roadmap outlined above, you can model that some elements in the architecture are improved in more specific ways. Using the same technique as for capability increments, you could, for instance, model the generic application component ‘General CRM System’ with specializations for versions like ‘General CRM System 3.2’, ‘General CRM System 3.3’ and ‘General CRM System 4.0’. Each of these can, in turn, be related to a plateau that starts on the release or deployment date of this version and ends when it is replaced by the next.
The same modeling technique can also model deployed instances of e.g. applications, as we explained in an earlier blog post. But be careful with modeling too much detail and tracking every individual release of an application or instance of a server type as a separate object in your enterprise architecture. This is probably more detail than you need or want to maintain.
Next to the architectural perspective with plateaus, we often see more precise dates being used. To avoid having many plateau objects tied to specific dates and periods, you can enrich your model with attributes. In this way, you can combine detailed release dates with high-level architecture plateau planning.
Much more can be said about roadmapping, lifecycles and the evolution of your architecture over time, and how Bizzdesign Horizzon’s features support this. Most importantly, we want to show you how to apply all the analysis and planning techniques discussed so far to support management decision-making and investment prioritization. This will be the topic of the next installments in this blog series. Stay tuned!
