Our blog series on Capability-based Planning focused on the why, what, and how of this subject matter. We’ve discussed the meaning and value of the concept ‘capability’, its use in decision-making and planning, the design of Capability Maps, and how to model capabilities and other business architecture concepts in coherence, among other subjects.
This blog discusses the who dimension: the roles and responsibilities around capabilities and their use. We’ll look at the approach advocated by the BIZBOK® Guide from the Business Architecture Guild. You could say this represents an ‘idealist’ perspective. In the next blog, we’ll outline Bizzdesign’s approach to the who dimension in Capability-based Planning, which is perhaps of a more pragmatic nature.
An example of a roadmap showing the evolution of Capability-based Planning, starting from the OCIO (Office of the CIO)
The BIZBOK® Guide distinguishes the following roles in Capability-based Planning:
Note that the same individual can sometimes play multiple roles. For instance, a senior business architect may also be a mentor or team leader. Typically, these individuals form a virtual team and aren’t hierarchically subordinate to any single senior manager or executive.
As the BIZBOK® Guide rightly states: ‘Business architecture governance ‘must be based on the premise of business ownership, business sponsorship, and representation from essential business areas’. In practice, however, this approach requires a high level of maturity from the enterprise and its business architecture practice. Organizations that have just started on a business architecture journey may find it difficult to get the level of ownership and participation by business sponsors, management, and experts that this approach advocates.
Additionally, the conceptual way of thinking used in enterprise, business, and IT architecture is often unfamiliar to business stakeholders. It takes time to convince business leaders of the value of such an approach. The best way to overcome this is to: ‘show, don’t tell’. Build business architecture artifacts that provide value to decision-makers, and the demand for business architecture will grow.
Often, this will start in IT before closely involving the business because that’s where this architectural way of thinking originates. Hence it is easier to work with IT stakeholders and build your initial business architecture artifacts there, sharing them with business leaders and experts later.
Moreover, and despite its name, rather than starting directly from ‘the business’ (which is already an IT term for everything non-IT), IT leadership who recognize the value of a business perspective on IT architecture to support their decision-making often initiate a business architecture practice. From this business-oriented IT architecture, an architecture perspective on the business of the enterprise may evolve and as a result, a true business architecture discipline may be initiated.
For instance, a typical scenario is where a forward-looking CIO wants to base IT investment decisions on the envisaged future capabilities of the enterprise rather than on classical budgeting per department. To this end, a group of business architects is formed from the existing enterprise and IT architecture teams. This group is tasked with creating a Capability Map and other artifacts to support a capability-based planning initiative for IT investments.
The resulting Capability Map may still be quite IT-focused, reflecting subdivisions and functionalities of the application landscape rather than true business capabilities. That may not be all bad though: if the structure is sound enough to support IT decision-making with a business focus, you have already taken a first step in the right direction. If you restrict your Capability Map to two or three levels deep, you can limit the risk of creating a too IT-focused map because you typically think in more general terms at these higher levels. It also makes it easier to maintain and update the Capability Map; use documentation fields of your Enterprise Architecture tool if you like to capture more details of what happens ‘inside’ these capabilities, rather than creating sub-capabilities for everything. Progressively refactoring and refining the map to become a true business capability map may be a more fruitful approach than trying to get it right the first time, which is nearly impossible for an inexperienced team with limited business involvement.
In any case, we advise that you take an iterative and incremental approach. Too often, we’ve seen capability mapping initiatives that took many months or stalled before delivering any meaningful value, simply because of the perceived need to be complete in both breadth and depth.
Instead, we would start with a broad but shallow level 1 map, from which we zoom in on specific areas based on two criteria:
Complete your knowledge on the ‘who’ dimension of Capability-based Planning by reading part 2 of this blog series: Bizzdesign’s Governance Approach: Tailored to Our Customer’s Needs.