Capability Governance: The ‘Who’ Dimension of Capability-based Planning (Part I of 2)

Capability Governance: The ‘Who’ Dimension of Capability-based Planning (Part I of 2)

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)

Subheadline BIZBOK® Roles in Capability Governance

The BIZBOK® Guide distinguishes the following roles in Capability-based Planning:

• Business sponsor: Since business architecture is owned by the business, sponsorship must be established within the business. Often, a CIO can assist with building sponsorship support within steering committees or transformation teams.
• Team leader: Business architecture teams should be led by business leaders with roots and reporting responsibility in the business.
• Subject matter expert: Business professionals with knowledge of all major aspects of the business, such as major customer-facing capabilities and value streams. They’re expected to participate in drafting level 1 and 2 capabilities in meetings that cross their subject area. They may also facilitate workshops to establish business ownership accountability and provide expertise.
• Business architect: Their role is to look beyond traditional business concepts and create and socialize business architecture. In larger organizations, multiple subtypes of this business architect role often exist, typically aligned with business subject area expertise.
• Architecture mapping expert: An expert in assembling and organizing capability analysis results into a formal knowledge base and developing the formal and ad hoc blueprints required. This role also requires tool expertise to meet blueprint mapping and knowledge base governance.
• Mentor: Someone well-versed in Capability Mapping and Business Architecture in general, who provides behind-the-scenes guidance for team building, governance, mapping, blueprint creation and integration into strategies, projects and related architectures.

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.

Practical considerations

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:

• Business relevance: Are these capabilities strategically relevant or business critical? Avoid spending too much time on commodity and supporting capabilities just to be complete.
• Cooperation between the right people: Can you involve the relevant leaders and experts in the area of interest, and are they willing to spend time on this?

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.