12 Must‑Do Lessons for Getting Business Capabilities Right

I assume the reader already has a basic understanding of what business capabilities are; if not, you should read the introductory article first.

Many organizations start with business functions because they want to use them in a certain way, but business capability is a relatively new concept with little consensus in theory, especially regarding definitions, development methods, use cases, and standards.

Some organizations have tried to establish standards, but these are limited to their own boundaries, resulting in scarce guidance, varied outcomes, few success stories, and skeptical stakeholders.

To support organizations developing business capabilities, I have summarized the twelve most important lessons I have learned over the past few years.

1. Understand the Exact Use Cases

Identify what you truly need by understanding your use cases. Business capabilities can support many different scenarios, such as business‑IT alignment, post‑merger integration, or strategic planning for future budgeting and projects. Different use cases require different numbers, levels of detail, layers, and mapped information.

For example, a rationalization approach may only need a few capabilities and mapping information (applications, cost, underlying technology lifecycle, overall satisfaction), whereas a demand‑management approach may require detailed capabilities, mapping many capabilities to a single requirement.

In a merger, you may not need detailed capabilities, just a comparable level across companies.

2. Identify All Stakeholders

Determine every stakeholder relevant to the specific capability domain. Working with only one department will not yield a holistic capability map. For pricing, for instance, you need input from marketing, finance, logistics, and local sales stores.

Similarly, contract management involves customers, suppliers, and business partners, and different markets may have distinct departments, applications, and processes, all using the same capability stack.

3. Understand and Explain Process Differences

Be prepared for intense discussions with “process people.” Processes are often more mature than capabilities, and some process owners may initially resist capabilities as a viable alternative. Emphasize that capabilities are defined to be understandable across stakeholders, avoiding technical or process‑step details.

Capabilities consist of three components—process, people, and technology—making them more stable over time than any single component.

The purpose of capabilities is to provide a comprehensive, non‑overlapping view of the organization, enabling independent analysis and minimizing inter‑dependency between capabilities.

However, their theoretical nature means organizations must define and understand the concept themselves, which can be challenging without solid guidelines.

4. Communicate the Concept Repeatedly

Be ready to explain the business capability concept thousands of times at all levels. Sharing and reusing content should be a high priority.

Typical questions to anticipate include: Why capabilities? How do they help now? Why are they better than other concepts? What outcomes are expected? What are the administrative and commercial uses?

5. Provide Strict Guidance for Development

Define and communicate clear guidance on how the capability should look. Lack of standardization leads to varied results; even TOGAF 9.2 is attempting to address this with its business capability guidance.

Without centralized guidance, each stakeholder may create capabilities with differing detail, dimensions, components, and terminology, making later coordination difficult.

Providing concrete examples helps capture the desired level of detail, syntax, components, and scope.

6. Reuse and Leverage Existing Inputs

Reuse as many existing resources as possible, both internal and external. The first capability draft often reflects the current state, which is useful for gradually shifting the organization’s mindset.

Internal inputs may include strategic documents, process descriptions, org charts, or application functions; external inputs may include global process standards from APQC or FrameworX, each with its own pros and cons.

7. Recognize the Concept’s Drawbacks

Be aware that sources may bias toward one component—people, process, or technology—depending on the origin of the input. Starting from process descriptions may lead to process‑biased capabilities; starting from application functions may lead to technology bias.

Beginning with an org chart can produce a capability map that includes too much organizational detail, risking over‑specificity.

8. Take a Long‑Term View—Don’t Expect Short‑Term Results

Accept that business capabilities are highly theoretical and require time to deliver value. They need broad acceptance across the organization, data collection, analysis, and repeated communication.

Stakeholder support is essential; without it, added value may quickly disappear. Senior management must understand that real benefits materialize over the long term.

9. Look for Every Pilot and Showcase Opportunity

Stay sensitive to opportunities to demonstrate capability value through pilots or showcases. Continuously seek chances, especially with stakeholders who are more interested in your work.

10. Manage Expectations

Do not expect 100% accurate final results. Enterprise architects, especially business architects, know their work rarely provides definitive answers, while the business may expect concrete business cases.

Capabilities are conceptual tools meant to advise on a wide range of problems, not to deliver precise answers, due to missing detailed levels, unconsidered inter‑dependencies, uncaptured change data, and tacit knowledge from uninvolved domains.

11. Choose the Right Tools Based on Target State and Operating Model

Obtain tool support to manage the large amount of data you will generate. Options range from Excel lists and SharePoint solutions to specialized EA tools, from lightweight to highly complex.

Consider how much data you need to manage, who can view/edit it, desired visualizations, update frequency, and security requirements to select appropriate tooling.

12. Understand the Types of Capabilities You Need

Distinguish business capabilities from related concepts. IT/technical capabilities focus on technology and solutions that can span many business capabilities, while digital capabilities concentrate on digital‑focused aspects and are usually more detailed and single‑layered.

For deeper insight into business capability use cases and how they help organizational transformation, see my article “5 Use Cases of Business Capability‑Driven Transformation.”