Editor’s note:
Capabilities are fundamental to Business Architecture, making it essential to understand how to implement them effectively. To help you navigate Capability-Based Planning, we’ve created the ultimate eBook, packed with insights, strategies, and practical guidance to set you on the right path. This blog post focuses on Business Capability Maps, and is an excerpt from the eBook, providing a glimpse into the valuable content you’ll find inside.
Value is delivered to the enterprise when Business Capability Maps are readily accepted and adopted as a strategic planning tool. Business stakeholders can make data-driven decisions and align and prioritize investment decisions, among other things. In part 1 of our blog series on Business Capability Maps, we’ve identified design principles focusing on the stakeholders consuming the Capability Maps, the general structure of a map, and its visual appeal.
In this post, we share principles for the definition/ decomposition of a Business Capability Map and the first steps of how to start.
There are two general principles that you need to follow when you define Capabilities:
Try to avoid duplicate or overlapping capability definitions, although this may be difficult in your first version of the Capability Map. You won’t know whether you have duplicates until you have created the first map! Business capabilities should be unique and mutually exclusive, and together they should cover your entire business. However, you may have variants of capability names such as Performance Measuring for financial performance, production, sales, etc. Always keep in mind the main stakeholder and the intended usage of your Capability Maps.
The name of a capability needs to be clear for business leaders because they often don’t understand techspeak. Use business language that resonates with senior managers and other stakeholders instead of rigid naming conventions.
The name of a capability should emphasize ‘what we do’ rather than ‘how we do it’. It’s important to adopt names that resonate with senior managers and stakeholders. Typically expressed as a compound noun or gerund (-ing form of a verb). E.g. ‘Project Management’, ‘Market Development’, and ‘Product Engineering’. Capabilities are often based on a business object, e.g. ‘Product Design’, ‘Risk Assessment’, ‘Materials Procurement’, but don’t make this a naming convention restriction to avoid turning your capability map into a business object map.
Add short descriptions to your capabilities to make the definition of it clear. This will steer the stakeholders’ thinking process in the direction you intended. When you’re adding short descriptions, be:
Business capabilities are stable and implementation-neutral
Judy Goldberg, former Executive Director at Sony and founder of Wondershift rightly mentioned: “You don´t need a digital strategy. You need a business strategy for the digital age“. When describing a Business Capability Map, don’t distinguish between business and IT capabilities.
A case in point is that an enterprise that produces fruits has been doing the “same” over decades. Techniques and technologies for producing fruit may have changed over the years, but what the company does has remained the same provided that they haven’t changed their business model.
An automated capability is still a business and not an IT capability. The description of how you realize a capability is important, but this should be part of the operating model description that you design in ArchiMate with core concepts, such as functions, processes, application components and other business/ application/ technology concepts. These differences are described in the blog: “Capabilities vs. Business Functions: Same Difference?”
Important and challenging questions are: “Which capability elements do you ‘bundle’ together, and how do you decompose a Capability Map?”
Identify the capability resources with the highest cohesion. This is a general architecture design principle and will guide you on the path to designing an adaptive enterprise. Aim for high cohesion inside of a capability and loose coupling between capabilities. Cohesion is defined by strong relations between resources. These resources form a business capability and usually consist of people and their roles and skills, process, technology, information, infrastructure, and natural resources. Questions you need to discuss include:
Tip!: Keep the depth of the Business Capability Map similar. Use 2-3 or 3-4 levels, and not 1-3 or 2-4 levels. This will make your mapping and analysis efforts easier.
Now that we’ve shared the design principles, you may wonder where to start. You need to have a mandate to architect a business capability map! Without proper sponsoring, you’ll have difficulty getting engagement from the required subject matter experts to resolve the inevitable issues/ conflicts. You also won’t have any customers for your Capability Map. Creating a Capability Map without a sponsor is, therefore, futile.
You’ll also need to know which analysis and decisions the sponsor wants to make based on the Business Capability Map. What’s the purpose? For a quick start, reuse existing internal and external information (e.g., previous Capability Maps, consultant findings), industry references (e.g., sector capability models), organizational charts, and process models. Use the design principles to define, refine, and test the Business Capability Map through socialization and validation cycles. Ensure that all the relevant business functions are included, not only IT.
If you have questions, please do not hesitate to contact us. We can give you a presentation that demonstrates the design principles described in this blog firsthand.
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.
Customer Success Consultant at Bizzdesign
Jeeps has 25 years of experience in defining and delivering strategic and operational change. He is a senior enterprise-wide business architect who has specialized in data and digital transformation and knows how to harness value across business, operations and technology.
