How to model Business Capability Increments and Instances
May 19, 2022
Editor’s Note: Business Capabilities are a cornerstone of Business Architecture, and understanding how to implement them is key to success. To guide you through Capability-Based Planning, we’ve created an ultimate eBook, filled with expert insights, strategies, and practical advice to ensure you’re on the right track. This blog post is an excerpt from our eBook.
So far in our blog series, the Business Capability models we’ve used are relatively simple in structure. In our previous blog post on capability measurement, we promised to provide more detail on how to model capabilities over time and describe different instances.
The same business capability may be implemented differently across the enterprise in business units or regional organizations in larger organizations. For example, in a multi-national company, local customs and regulations may realize the same Human Resource Management capabilities differently. As shown in the figure below, these specific versions can be modeled as a specialization of the same generic capability.
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. The image below 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.
Schedule time with one of our experts if you need help with Capability-based Planning.
Managing Consultant & Chief Technology Evangelist at Bizzdesign
Marc contributes to Bizzdesign’s vision, market development, consulting, and coaching on digital business design and enterprise architecture. He also spreads the word on the Open Group’s ArchiMate® standard for enterprise architecture modeling, of which he has been managing the development. His expertise and interests range from enterprise and IT architecture to business process management.
Managing Consultant at Bizzdesign
Bernd has held various roles during career, including consultant, trainer, and global solutions manager. His expertise includes Business Architecture, Enterprise Architecture, Portfolio Management, and Business Intelligence, where he has guided customers in maximizing value from Bizzdesign Horizzon predominantly in finance and manufacturing sectors in DACH and EMEA region.
