Bizzdesign’s Approach to Capability Governance Tailored to Customers’ Needs (Part 2 of 2)

Bizzdesign’s Approach to Capability Governance Tailored to Customers’ Needs (Part 2 of 2)

Bizzdesign’s approach to 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 at some distance from the mapping effort itself.

We distinguish between the following roles:

• Sponsor: Whoever is investing in creating a Capability Map and needs insights from it to improve decision-making. This might be a business leader, but as we’ve argued before, in practice, it is often the CIO, Chief Digital Officer, or someone similar. 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 in the business. 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: Has a good understanding of the business and is in touch with the SMEs. Ideally, business architects report to the business. However, when IT is the owner of the Capability Map, this role often sits 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, responsible for a sound structure of the capability model, no overlap, good naming, 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. 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 your business 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 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 having an impact and where can you improve your way of working and results?

Pragmatic starting point

As you’ve seen, our approach to Capability Governance intentionally deviates somewhat from the BIZBOK® Guide and other frameworks that state 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 and 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.

We hope our 2-part blog series helps you kick-start Business Architecture and Capability-based Planning in your organization. However, it may still not be smooth sailing: In the next post, we’ll address many common obstacles and how to overcome them. Stay tuned!