Capability Governance: Roles and responsibilities in Capability-based Planning

Capability Governance: Roles and responsibilities in Capability-based Planning

Introduction

Capability-based planning is a crucial approach within the realm of Business Architecture that helps organizations align their strategic goals with operational execution. In Capability-Based Planning, defining clear roles and responsibilities is key to successful capability governance. This blog explores how to effectively manage business capabilities, drawing insights from the BIZBOK® Guide’s idealist approach and Bizzdesign’s practical framework for capability governance. Learn how to establish who does what to drive efficient and aligned decision-making within your organization.

Our comprehensive ebook is a must-read for a deeper dive into the world of Capability-Based Planning and how it can drive strategic alignment within your organization. This resource explores the step-by-step approach to implementing Capability-Based Planning, offering valuable insights and practical tools to help you future-proof your enterprise.

Subheadline BIZBOK® Roles in Business Capability Governance

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

• Business sponsor: Since the business owns business architecture, 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.
• 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 accountability for business ownership and provide expertise.
• Business architects: Their role is to look beyond traditional business concepts and create and socialize business architecture. In larger organizations, multiple subtypes of this role often exist, typically aligned with business subject area expertise.
• Architecture mapping expert: This role involves assembling and organizing capability analysis results into a formal knowledge base and developing the required formal and ad hoc blueprints. It also requires tool expertise to meet blueprint mapping and knowledge-base governance requirements.
• 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 architecture.

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 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 leaders 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 enterprise’s business 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 map that is too IT-focused 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 the 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 commodities 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?

Bizzdesign’s approach to Capability-based Governance

Bizzdesign’s approach to capability-based planning and ‘capability governance’ is similar to BIZBOK’s but more pragmatic. Most importantly, it takes into account that many business architecture initiatives start from the IT organization as well as from a lower level of maturity. We often see that the core of a capability mapping team comes from some architecture department or team that reports to the CIO. They, in turn, consult with leaders and experts from the business areas concerned, but these are often far from the mapping effort itself.

We distinguish between the following roles:

• Sponsor: Whoever is investing in creating a Capability Map needs insights to improve decision-making. This might be a business leader, but as we’ve argued before, it is often the CIO, Chief Digital Officer, or someone similar in practice. The sponsor in a sense is the capability map owner (but not the owner of the capabilities on the map!)
• Business capability representative: These are business leaders with roots and reporting responsibility. If the sponsor is located within IT (e.g. the CIO), business leaders are not always as closely involved as the BIZBOK® proposes, but they should at least be consulted and informed. We intentionally avoid terms such as ‘capability owner’, ‘manager’ or ‘accountability’ because that implies ‘being in control of something’. Since a capability model is independent of solution realization and organization structures, there could be too many relationships between capabilities and business leaders managing the organization. Hence, you can’t easily assign this kind of ownership to managers of teams, departments, or business units, since one capability might involve (parts of) many different departments. Moreover, when IT owns the overall Capability Map, subsets of it are unlikely to be owned by business leaders. Nevertheless, business leaders may identify with certain capabilities and therefore be suitable capability representatives.
• Subject matter expert: Someone who knows the day-to-day operations and details of the business in the area the capability describes. This professional is ideally from the business and an expert in a subject matter area. If this isn’t feasible, e.g. because of resource constraints, it could also be someone in IT who is in close contact with the business and has enough business expertise.
• Business architect: This person has a good understanding of the business and is in touch with the SMEs. Ideally, business architects report to the business. However, when IT owns the Capability Map, this role often falls in the enterprise architecture team, which may be part of the CIO/ Digitization/ Transformation Office.
• Capability steward: As part of their role, business architects are the stewards of one or more (groups of) capabilities. They are responsible for a sound structure of the capability model, no overlap, good naming and descriptions, and updated visualizations to support the sponsor’s decision-making. These stewards facilitate workshops or meetings to create and update the Capability Map, related visualizations, and reports.
• Business contact: Someone in the business domain of the relevant capability area. This is the contact of the Subject Matter Expert (or Business Architect) to be consulted to get insights and input for the business architecture. This role is typically the second line of support for SMEs, especially when they are not located in the business themselves.
• Benefits manager: A role that originated in project portfolio management. Someone who identifies, plans, measures, and tracks the benefits of business architecture and the business capabilities themselves. This is key to growing the maturity of your business capabilities and architecture practice.
• Mentor: As in the BIZBOK, an experienced business architect can guide the team and helps grow their business architecture approach.

The first three roles in the image below are ‘must-haves’ (Sponsor, Subject Matter Expert, Business Architect). The rest of the roles accelerate the usage of a Business Capability Map.

Again, the same individual might play more than one role, as is already apparent from the Capability Steward role, which forms part of what a Business Architect does. Note that we don’t distinguish separate roles for Team Leader and Architecture Mapping Expert. Business architects can often self-organize without needing a formal, hierarchical team leader. Moreover, any Business Architect worth their salt should be well-versed in capability mapping and other description techniques, so this doesn’t need to be a separate role. Nevertheless, in a larger business architecture team, some members might focus more on, e.g., stakeholder communication and engagement, and others on managing the architecture knowledge base or creating beautiful architecture artifacts.

We also introduced two specific roles: the Capability Steward and the Benefits Manager. The first is important because you can’t readily assign formal business ownership to capabilities. You’ll need the right architectural expertise to develop a sound capability structure. The second is key because we acknowledge that Capability-based Planning teams often start from a low level of maturity and need to grow their capabilities. To this end, you’ll need to track and measure what you’re doing as a Business Architecture /Capability-based Planning team and apply this to the actual business capabilities themselves. How is your work as a team impacting, and where can you improve your work and results?

Where to start? A pragmatic starting point

As you’ve seen, our approach to Capability Governance deviates somewhat from the BIZBOK® Guide and other frameworks stating that capabilities should be owned by ‘the business’. Although we agree in principle, we have to be realistic. Our approach reflects what we see in practice. It provides a starting point to demonstrate the value of using Capability Maps and Capability-based Planning for investment allocation of IT budgets. It explicitly states that it starts with deviating from best practices but keeps in touch with relevant business roles. That helps you avoid turning a business Capability Map into an IT Capability Map.

Once you have established the value of capability thinking in the context of business-focused IT investment planning, you can evolve this into ‘true’ business architecture, purely focused on the architecture of ‘the business of the business rather than the architecture of the business as IT interacts with it.

Schedule time with one of our experts if you need help with Capability-based Planning.

About the authors:

Marc Lankhorst

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 spread the word about the Open Group’s ArchiMate® standard for enterprise architecture modeling, which he has been managing the development of. His expertise and interests range from enterprise and IT architecture to business process management.

Bernd Ihnen

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.