Capabilities in Enterprise Architecture – Part 2
How to Model Capabilities and Make Them Actionable
In Part 1, we explored how capabilities help bridge strategy and execution—offering a practical way to align business and IT, clarify strategic priorities, and guide decision-making.
This follow-up article focuses on what many architects ask next:
How do you actually model capabilities in a way that gets used?
Capability modeling may seem straightforward, but doing it well takes thoughtful structure, clear abstraction, and a solid connection to real-world needs.
💬 After publishing Part 1, I received many insightful comments—thank you! One clarification: EA and capabilities aren’t the link between strategy and execution, but one of several tools that can help bridge that gap. Also, the concept of a capability can mean different things in different contexts. In this series, I focus specifically on business capabilities. Capabilities can also be used in technology planning, but in my framework, technology is part of how business capabilities are realized (not a capability in itself).
Let’s walk through how to create a capability map that not only looks good, but works in practice.
What Makes a Capability?
A capability defines what an organization does—independently of how, by whom, or why. This abstraction makes capabilities stable and reusable, even as operations and technologies evolve. That’s also what makes them valuable in leadership dialogue and strategic planning: a good capability map should resonate across architects, executives, and delivery teams alike.
To model capabilities effectively, it’s useful to consider them in light of strategic goals. Which capabilities are critical for success, and which need development to meet future needs? Capabilities aren’t inherently good or bad. Rather, they’re either fit for purpose or in need of improvement.
While each capability is supported by processes, applications, data, and people, those realization elements are modeled separately to ensure the capability definition stays consistent even as its implementation changes.
How to Structure a Capability Map
A well-structured capability map provides a clear, consistent view of the organization’s functional landscape. It breaks down what the organization does into distinct, non-overlapping areas that can be evaluated, planned, and improved.
Some core modeling principles:
Use consistent levels of abstraction. Don’t mix broad domains like “Product Development” with narrow activities like “Market Research.” While some capabilities may naturally be broader in scope, they should still represent comparable levels of functional granularity.
Make sure the map covers all main activities. A helpful mental exercise: imagine designing your organization from scratch. What capabilities would it need to achieve its goals? That framing often helps clarify what really belongs on the map.
Avoid application and org-specific terms. Use neutral, functional names like “Customer Support” or “Invoice Management”—not “Digital Services” or “Sales Team Ops.” Still, use terms the business already understands. And avoid labeling everything as “Management.”
Aim for simplicity and clarity. Especially in early iterations, focus on a high-level view with a manageable number of elements. It’s fine to use one to three levels of detail in the map, but avoid going deeper. When the map is used in meetings, each capability will typically be reviewed individually. Therefore, they need to be clearly named, easy to understand, and limited in number.
Categorize capabilities logically. Capabilities are typically categorized to improve readability and navigation. I usually use three categories: Strategic Capabilities, Core Capabilities, and Enabling Capabilities. And “Strategic” here refers to scope, not importance.
Below is an example of a high-level capability map following these principles. It offers a concise overview of what a retail organization does, without diving into execution details. This type of capability map provides a shared starting point for planning, prioritization, and cross-functional collaboration. When kept clean and relevant, it becomes one of the most useful tools in your EA toolbox.
Linking Capabilities to Enterprise Architecture
Capabilities only become actionable when linked to the operational elements that support them—such as processes, applications, data, and organizational actors. Skills and competencies can also be included, typically as supporting text rather than formal architecture elements.
These relationships can be visualized using architecture tools (e.g., with Realization connectors in ArchiMate) or described in supporting materials like slide decks. Both approaches create traceability between what the organization needs to do and how it currently does it. To keep things simple, I usually model (as ArchiMate elements) only the capability level that directly connects to other elements, not higher-level categories.
For example, the below realization view of the “Product Sales” capability shows its supporting processes, organizational actors (also Customer is included for completeness), data groups, and applications (external ones in white). If the organization utilizes technologies like package handling systems, these could be included as well.
Making It Useful: Descriptions and Visualizations
Drawing a capability map alone isn’t enough. To make capability maps work in real planning scenarios, they need to be accessible, easy to interpret, and tailored for the people using them. This often means preparing a dedicated slide deck or creating custom views in your EA tool.
Each capability should have a concise, plain-language description explaining what it is, why it matters, and what activities it covers. These summaries can also include relevant attributes—such as ownership, development needs, and strategic importance—as long as they’re maintained and actually used. It’s also helpful to describe here how the capability is realized: through processes, applications, data, and people (typically covering organizational structures and required skillsets).
Visual indicators play a key role. Heatmaps can highlight performance or maturity levels, while priority markers show where focus and investment are needed most. I’ve found it especially effective to assess capabilities from the viewpoints of their supporting elements—processes, technologies, data, and people—to uncover gaps and guide targeted improvements.
Creating a Capability Map in Practice
Creating a capability map follows the same basic principles as other EA descriptions: it’s iterative, collaborative, and benefits from using structured tools. While each architect probably has their own approach, the practical process can look like this:
Collect source material: Start by reviewing organizational charts, strategy presentations, onboarding guides, and existing architecture artifacts. Capability map templates and AI-generated drafts can be helpful starting points.
Draft the initial map: Create a first version with 20–40 top-level capabilities, grouped into strategic, core, and enabling categories. Keep the abstraction level consistent across capabilities and avoid referencing applications, processes, or organizational structures.
Validate with stakeholders: Review the draft with domain experts, architects, and business leaders. Workshops are especially useful: walk through the map together and adjust based on shared understanding. Clarify overlaps and ensure capabilities reflect actual business activities. Remember to make it clear to everyone what you mean by capabilities.
Refine and approve: Iterate the structure and naming based on feedback. Include short descriptions for each capability to make the map easier to use. Describe capability realization. Get leadership approval to ensure alignment and organizational buy-in.
Add to repository: In a repository-based tool, create reusable capability elements. Link each capability to realizing elements like processes, applications, and actors as needed.
Final Thoughts
Modeling capabilities isn’t about completing a framework—it’s about enabling better conversations and better outcomes. Capabilities are one of the most practical ways to make EA part of daily leadership, planning, and delivery.
Even a lightweight, high-level map can bring clarity to strategy discussions, improve prioritization, and help guide change.
So don’t let capability maps sit in your repository. Keep them visible. Review them with stakeholders. Use them to support the discussions that really matter.
📬 Subscribe to get more hands-on content on making EA practical, collaborative, and impactful.
📖 Missed Part 1? You can catch up here.