⏱ 25 min read
ArchiMate for Capability-Based Planning: A Practical Enterprise Architecture Guide ArchiMate training
Learn how to use ArchiMate for capability-based planning to map business capabilities, strategy, applications, and transformation roadmaps for better enterprise architecture decisions. ArchiMate tutorial for enterprise architects
ArchiMate, capability-based planning, ArchiMate capability mapping, enterprise architecture, business capabilities, capability model, strategic planning, transformation roadmap, business architecture, application portfolio, target operating model, TOGAF, enterprise transformation, architecture modeling, capability assessment ArchiMate layers explained
Introduction
Capability-based planning (CBP) gives enterprise architecture a durable planning anchor: what the business must be able to do. That sounds simple, but it changes the conversation. Projects come and go. Applications are replaced. Reporting lines are redrawn. The underlying business abilities the enterprise depends on usually persist. For that reason, capabilities are often a better basis for strategic planning than project portfolios, system inventories, or organizational charts.
ArchiMate is well suited to this style of planning because it provides a common modeling language across strategy, business, application, and technology domains. A capability map on its own can be useful, but its real value appears when capabilities are connected to goals, value streams, outcomes, processes, applications, data, and technology services. That traceability is what turns a static classification into a planning instrument. ArchiMate relationship types
This is where enterprise architecture often succeeds or fails. Senior leaders express intent in broad terms: improve customer experience, lower cost-to-serve, strengthen resilience, accelerate product launch, reduce regulatory exposure. Delivery teams work through initiatives, platforms, and release plans. The difficult part is maintaining a line of sight between the two. ArchiMate helps by making dependencies explicit. It shows which capabilities matter, what realizes them, where constraints sit, and which changes are likely to produce measurable results. ArchiMate modeling best practices
CBP also gives different stakeholder groups a shared frame of reference. Executives may want a high-level capability heatmap showing strategic importance and current condition. Portfolio managers need to see which initiatives improve which capabilities and where investment is clustered or duplicated. Domain architects need more detail: processes, applications, integrations, information objects, and technology services. With ArchiMate, those perspectives can be derived from one connected model rather than assembled from disconnected documents.
The approach only works, however, if capabilities are treated as more than labels. A useful capability model ties business ability to outcomes, ownership, assessments, and realization mechanisms. That allows better questions. Which capabilities are strategically differentiating? Which are underperforming? Which depend on brittle legacy platforms? Which are constrained by poor data quality rather than by missing functionality? Which receive disproportionate investment relative to business value? Those are more useful planning questions than an application-centric roadmap can answer on its own.
This article explains how ArchiMate can support capability-based planning in a practical, structured way. It begins with why CBP matters in enterprise architecture, then reviews the ArchiMate concepts used to model capabilities, shows how to structure capability maps and hierarchies, and examines how capabilities connect to strategy, value, operating design, and implementation. It closes with guidance on views, governance, and adoption.
Why Capability-Based Planning Matters in Enterprise Architecture
Enterprise architecture struggles when planning is driven primarily by organizational structure, application portfolios, or project pipelines. Those views are necessary, but none is especially stable. Operating models change. Products evolve. Technology platforms move on their own lifecycle. A capability-based view provides a more durable planning frame because it focuses on the enterprise’s required abilities, regardless of who performs the work or which systems currently support it.
That matters because architecture is expected to support coherent investment decisions across competing priorities. Without a capability lens, planning tends to fragment. Business units advocate local needs. Technology teams push platform upgrades. Transformation programs define scope around immediate delivery objectives. Each case may be reasonable in isolation, yet the combined result is often duplication, gaps, and misaligned spending. CBP gives architects a common basis for comparison. Instead of asking only which project deserves funding, the enterprise can ask which business abilities most need improvement and which investments materially strengthen them.
This becomes especially important when strategic ambition meets operational constraint. Most organizations carry some combination of legacy debt, regulatory obligations, integration complexity, and growth pressure. Planning at the capability level reveals where those forces intersect. A strategic objective such as expanding digital channels may depend not only on front-end applications, but also on identity management, product configuration, decision automation, analytics, customer communications, and service support. A capability view exposes enabling work that is easy to miss when attention stays fixed on visible customer-facing initiatives.
CBP also improves prioritization because it separates importance from implementation preference. In many enterprises, solution choices are made too early. A team decides that a new platform, a process redesign, or a sourcing change is the answer before the capability problem has been diagnosed. Architecture adds value by slowing that jump. Is the capability missing? Underperforming? Too expensive? Too slow to adapt? Weakly controlled? Overly fragmented? Different diagnoses point to different interventions.
Capabilities are also useful because strategically important business abilities usually cut across organizational and technical boundaries. They are rarely owned end-to-end by one team. They span business domains, data flows, applications, controls, and operational responsibilities. A capability model makes those dependencies visible. Improving onboarding, claims handling, or supplier collaboration, for example, may require coordinated changes in policy, information quality, integration architecture, user experience, and supporting platforms.
A practical example comes from retail banking. A bank may launch a mobile account opening initiative believing the main issue is user experience. Capability analysis often shows a different picture. The real constraint may sit in Customer Identity Management and Consent Management, where fragmented verification services and inconsistent consent records create delays and compliance risk. In that case, improving the mobile front end without strengthening those capabilities simply moves the bottleneck.
CBP is equally effective in modernization and portfolio rationalization. When applications and initiatives are mapped to capabilities, the enterprise can see whether too many systems support the same need, whether critical capabilities are underfunded, or whether a legacy platform has become a hidden single point of failure. That shifts architecture from inventory management to decision support: where to consolidate, where to standardize, where to differentiate, and where resilience justifies investment.
Identity and access management is a common illustration. Many organizations treat single sign-on, privileged access, and customer identity as separate technology programs. A capability view reframes them. They support distinct business abilities such as Workforce Access Management and Customer Identity Management, each tied to outcomes such as reduced fraud, faster onboarding, and improved auditability. That is a better basis for prioritization than a set of disconnected platform upgrades.
In short, capability-based planning gives enterprise architecture a stable planning logic that connects strategy, operating model evolution, and technology change. ArchiMate strengthens that logic by representing it as a connected model rather than a collection of unrelated artifacts.
Core ArchiMate Concepts for Modeling Capabilities
In ArchiMate, the foundation is the Capability element in the Strategy layer. A capability represents an ability that an enterprise, business unit, or domain possesses. It is not a process, a department, an application, or a service. It is a business ability that can be realized in different ways over time. That relative stability is what makes it useful in planning.
A frequent mistake is to treat capabilities as renamed business functions. In practice, a capability should describe an outcome-oriented business ability, not a department or an activity list. “Customer Identity Management” is a capability. “Contact Center Operations” is usually an organizational construct. “Approve Customer Request” is more likely a process. The distinction matters. Once capabilities collapse into workflow steps or org-chart labels, they lose much of their strategic value.
Capabilities become useful when they are connected to other ArchiMate concepts.
Capability and Resource
One of the most important relationships is between Capability and Resource. Resources represent the assets used to realize a capability: people, applications, data, infrastructure, specialist knowledge, and partner contributions. This relationship grounds capability assessment in operational reality. If a capability is strategically important but depends on poor-quality data, unsupported software, or scarce specialist skills, the model can make that visible.
Consider a manufacturer assessing Demand Forecasting. On paper, the capability may appear mature because forecasting processes exist in every region. A resource view may show that the capability depends on spreadsheets maintained by a handful of planners and inconsistent product hierarchies from different ERP instances. The issue is not the absence of process; it is the fragility of the resources that realize the capability.
Capability and Value Stream
The Value Stream concept links business ability to value creation. A capability expresses what the enterprise must be able to do; a value stream expresses how value is created for a stakeholder through stages. Connecting capabilities to value stream stages shows where a capability contributes to customer experience, throughput, compliance, or partner value. That is far more informative than keeping a standalone capability map with no link to how value is actually created.
Capability and the Business Layer
Capabilities are typically realized through elements in the Business Layer, especially Business Processes, Business Functions, and Business Services. This is the first major bridge from strategy into operations. A capability such as Case Management may be realized through several processes, exposed through business services, and assigned to multiple roles. Modeling those relationships helps determine whether a capability gap stems from process design, fragmented service delivery, weak controls, or unclear accountability.
Capability and the Application and Technology Layers
The Application and Technology layers provide implementation context. Applications support the business processes and services that realize a capability. Technology services, infrastructure, and platforms support those applications. This layered traceability is especially useful during transition planning because it helps architects see whether a capability weakness is rooted in integration issues, platform fragility, poor data handling, or excessive customization.
For example, an enterprise may describe a weak Order Tracking capability as a technology problem and propose event streaming as the answer. ArchiMate can show a more precise picture: the streaming platform may already exist, while the real issue lies in inconsistent event ownership, missing status standards, and weak schema governance across domains.
Outcome and Assessment
Two additional concepts make capability models decision-ready: Outcome and Assessment. Outcomes connect capability improvement to measurable business results. Assessments capture observations such as maturity, risk, performance, cost pressure, or fitness for purpose. Together they move the model beyond description. Instead of showing only that a capability exists, the architecture can show why it matters, how well it performs, what constrains it, and what change may be justified.
Taken together, these concepts allow ArchiMate to position capabilities as anchor points in a connected enterprise model. The next step is to structure those capabilities into a usable map and hierarchy.
Structuring Capability Maps and Capability Hierarchies in ArchiMate
A capability map is useful only if it works as a planning instrument rather than a decorative taxonomy. The aim is to provide enough structure for analysis, prioritization, and traceability while keeping the model stable enough to survive organizational and solution change.
A practical starting point is a small set of top-level capability domains that reflect the enterprise’s enduring business model. These should not mirror the org chart. Instead, they should represent broad areas of business ability such as customer management, product management, fulfillment, risk management, finance, workforce enablement, or digital enablement. In ArchiMate, these can all be modeled as Capability elements related through composition or aggregation to form a hierarchy.
In most enterprises, the hierarchy should stop after two or three levels unless there is a clear analytical reason to go deeper. Over-decomposition is a common failure mode. Once the structure becomes too granular, it starts to resemble a process model, system inventory, or responsibility matrix. Capabilities work because they are more stable than those constructs. If a capability cannot be assessed, owned, funded, or improved independently, it is probably too fine-grained to be useful.
Naming discipline matters as much as decomposition. Capability names should be expressed as business abilities, usually noun-based phrases such as “Supplier Collaboration,” “Fraud Detection,” or “Pricing Management.” Names that imply workflow sequence or solution choice should be avoided. In practice, disagreements over naming often surface hidden ambiguity in scope, which is useful because it exposes planning assumptions early.
The capability map itself is only one view. The real value comes from structuring the hierarchy so lower-level capabilities can be connected selectively to other elements without cluttering the top-level picture. High-level capabilities support executive communication and heat mapping. More detailed capabilities support links to value streams, assessments, applications, and initiatives. This layered design allows one repository to support different planning conversations at different levels of detail.
A mature practice usually classifies capabilities by role, even though ArchiMate does not prescribe a special notation for this. Common distinctions include core, enabling, and differentiating capabilities. These can be represented through properties, assessments, or specialized viewpoints. The classification shapes planning choices. A capability may be operationally necessary but not strategically unique, which suggests standardization or sourcing options. Another may be central to competitive advantage and justify bespoke investment and tighter governance.
Capability hierarchies should also be governed as enterprise assets. New capabilities should not be added simply because a program needs a label, and existing ones should not be renamed to fit temporary delivery language. The hierarchy should evolve deliberately alongside strategy and operating model changes.
A simple example is technology lifecycle governance. Rather than inventing a temporary “cloud migration capability” for each program, the enterprise keeps stable capabilities such as Hosting, Integration Management, and Security Engineering. Assessments then show which of those capabilities are constrained by end-of-life platforms or manual operating practices. This preserves the integrity of the model and keeps planning focused on enduring business and operational abilities.
With that structure in place, the next question is how capabilities connect to strategy, value, and outcomes.
Linking Capabilities to Strategy, Value, and Outcomes
A capability model becomes strategically useful only when it is connected to why the enterprise is changing and what results that change is intended to produce. In ArchiMate, that means linking capabilities to drivers, goals, outcomes, value, value streams, and, where needed, courses of action. Those links transform the capability map from a classification artifact into a planning tool.
Capabilities provide the stable anchor between strategic intent and implementation. Strategy expresses intent: grow market share, reduce fragility, respond to regulation, increase retention, shorten product launch cycles. But strategic intent is usually too broad to guide investment directly. ArchiMate helps by showing which capabilities must improve if those goals are to be achieved. A goal such as “increase digital channel adoption” may depend on capabilities such as customer onboarding, identity verification, personalization, service orchestration, and digital support. Without those links, strategy remains rhetorical. With them, it becomes analyzable.
The relationship to value is equally important. Not every capability contributes value in the same way. Some create direct customer-facing differentiation, such as tailored product design or superior case resolution. Others create internal value by improving control, resilience, compliance, or cost efficiency. By linking capabilities to value streams, outcomes, and stakeholders, architects can make those distinctions visible. That is especially useful when leaders compare investments that appear similar in cost but differ sharply in value contribution.
Connecting capabilities to outcomes adds precision. Outcomes describe what successful capability improvement should achieve in business terms: faster cycle times, fewer exceptions, improved accuracy, lower operational risk, greater scalability. This reduces a common planning problem: funding capability uplift without defining the business result that should justify it. Outcome statements should be specific enough to guide prioritization without being so solution-bound that they pre-judge implementation.
ArchiMate also supports the link between capabilities and courses of action, which is particularly useful in roadmap discussions. A capability gap does not imply a single response. The same target outcome might be pursued through process redesign, application consolidation, data remediation, platform modernization, sourcing changes, or policy simplification. Modeling alternative courses of action against the same capability and outcome set allows a more transparent comparison of options.
A healthcare example illustrates the point. A provider may identify weakness in Referral Management, with outcomes tied to shorter wait times and fewer lost referrals. One course of action might focus on replacing a scheduling application. Another might standardize referral data definitions, automate handoffs between clinics, and introduce a shared work queue before any platform replacement. The capability model helps compare those paths against the same outcome rather than treating software replacement as the default answer.
These links are also essential for portfolio governance. When initiatives are mapped only to budgets, programs, or technology domains, it is difficult to tell whether the portfolio is advancing strategy. When they are mapped through capabilities to goals and outcomes, distortions become easier to spot: over-investment in low-value areas, under-investment in strategically critical capabilities, or initiatives claiming strategic relevance without credible capability impact.
The communication benefit is just as significant. Executives can see how investment supports outcomes. Portfolio managers can see where value is concentrated. Delivery teams can see why some capabilities are prioritized over others. In that sense, ArchiMate provides a common planning language rather than merely another notation standard.
Connecting Capabilities to Processes, Applications, Data, and Technology
Once capabilities are linked to strategy and outcomes, they also need to be tied to the operating environment that realizes them. This is where ArchiMate moves from strategic framing into actionable architecture. The objective is not to prove that everything is connected. It is to show which relationships matter for planning and investment decisions.
Processes, Functions, and Services
At the business layer, capabilities are usually realized through a combination of Business Processes, Business Functions, and Business Services. These distinctions are worth preserving. A process shows how work flows across activities and actors. A function shows a stable grouping of behavior by responsibility or specialization. A business service shows externally visible behavior delivered to a consumer. By connecting a capability to these elements, architects can determine whether weakness lies in fragmented workflow, poor service design, inconsistent execution, or unclear accountability.
A regional insurance operation provides a familiar example. The enterprise may rate Claims Handling as weak and assume the answer is claims platform replacement. Process tracing may show that the larger issue is inconsistent triage and escalation between regions, with manual handoffs and different evidence requirements. In that case, the capability problem sits partly in operating design rather than solely in application architecture.
Applications
The application layer adds precision. Most capabilities depend on multiple applications accumulated over time through acquisitions, local optimization, and project-driven delivery. Capability tracing helps reveal whether one business ability is supported by too many overlapping applications, whether critical behavior depends on a fragile legacy platform, or whether a single application supports multiple capabilities and therefore creates transformation coupling.
This is important for modernization decisions. An application rationalization initiative may look attractive in isolation, but capability analysis may show that consolidation would create unacceptable risk for a strategically important business ability. In other cases, the same analysis reveals obvious duplication, where several systems support the same capability with little differentiated value.
Data
Data is often the missing link in capability-based planning. Many capability weaknesses are fundamentally information problems rather than process or application problems. In ArchiMate, Business Objects and Data Objects can be used to show the information structures that processes and applications rely on. This helps identify whether a capability depends on inconsistent master data, duplicated records, delayed event flows, weak governance, or poor information quality.
Organizations frequently misdiagnose data issues as application issues. A new system may improve user experience while leaving the underlying capability weak if core information remains fragmented or difficult to share across domains. Linking capabilities to data objects helps avoid that mistake.
A supply-chain example is straightforward. A company may invest in a new supplier portal to improve Supplier Collaboration. The capability model may show that the real constraint is inconsistent supplier master data across procurement, finance, and logistics systems. Without resolving that data issue, the portal improves presentation but not the capability itself.
Technology
Technology relationships complete the picture by showing the operational constraints beneath the application layer. Technology Services, Nodes, System Software, and infrastructure components may not appear in executive capability views, but they often determine whether a capability is scalable, resilient, secure, and cost-effective. A capability such as digital onboarding or real-time fulfillment may depend on platform characteristics like availability, integration throughput, identity services, or elastic infrastructure. If those enablers are weak, the capability remains constrained regardless of process redesign or application enhancement.
Selective Traceability
A practical modeling principle is to connect capabilities selectively rather than exhaustively. Not every process, application, data object, or technology component needs to be linked to every capability. The purpose is to capture architecturally significant relationships: those that are critical, duplicated, high-risk, high-cost, or transformation-relevant. This keeps the model usable and supports better analysis.
Selective traceability also reinforces a central point: capability-based planning is valuable because it helps locate where change must occur. If a capability assessment shows poor performance, architects can ask whether the constraint sits in process design, application fragmentation, data quality, integration architecture, or platform limitations. That leads to more targeted roadmaps and more credible investment cases.
Using ArchiMate Views to Support Planning, Roadmapping, and Investment Decisions
One of ArchiMate’s strongest advantages is not simply that it can model relationships, but that it can present them through targeted views for different planning decisions. The same underlying model should support executive prioritization, portfolio governance, domain planning, transformation sequencing, and solution scoping. A well-designed set of views makes that possible without requiring every audience to navigate the full repository.
Capability Heatmaps
For strategic planning, one of the most effective viewpoints is the capability heatmap. This typically shows capabilities with attributes such as business importance, current maturity, risk exposure, cost pressure, or urgency of change. Color coding is useful only if it is grounded in explicit assessments and agreed criteria. A heatmap should not be a manually assembled presentation artifact; it should be derived from traceable evidence in the model.
Capability-to-Initiative Mapping
A second important viewpoint is the capability-to-initiative mapping view. This is especially useful for portfolio and investment governance because it shows whether current or proposed initiatives are concentrated in the right areas. Many portfolios look balanced when viewed by budget or program, yet capability mapping reveals distortions: several initiatives targeting the same capability while other strategically important areas receive little attention. This view gives architecture teams a constructive basis for challenge.
Transition and Roadmap Views
For roadmap development, ArchiMate becomes more valuable when it shows transition states rather than only current and target pictures. Capability-based planning often fails when target architecture is presented as a single end-state with little clarity on how to move toward it incrementally. ArchiMate can represent plateaus, gaps, and deliverables in ways that connect capability improvement with staged implementation. A useful roadmap view shows which capabilities improve in each increment, which enabling changes must occur first, and where dependencies create sequencing constraints.
For example, a customer communications transformation may aim to improve Customer Notification Management. A transition view might show that the target state depends first on retiring an end-of-support middleware platform, then standardizing message templates and event triggers, and only after that consolidating outbound channels. Without that sequencing, the roadmap appears simpler than it really is.
Cross-Layer Decision Views
Another effective technique is the cross-layer decision view for high-priority capabilities. Instead of showing the whole enterprise, these views focus on one investment area and the few relationships that matter most. A view may show a capability, the business services that expose it, the applications that support it, the critical data objects involved, and the initiatives currently changing it. These focused views are often more useful than large reference diagrams because they support direct discussion of trade-offs such as modernization versus replacement, consolidation versus coexistence, or standardization versus differentiation.
Viewpoint Discipline
The quality of these views depends on viewpoint discipline. A view should be designed around a decision, not around a model export. If the audience is deciding investment priority, the view should emphasize capability condition, expected outcomes, and initiative overlap. If the audience is deciding sequencing, it should emphasize dependencies, transition constraints, and timing. If the audience is deciding scope, it should distinguish core impact from peripheral impact.
Used this way, ArchiMate views become planning instruments rather than documentation artifacts. They bring together capabilities, outcomes, realization, and transition into stakeholder-specific decision support.
Common Pitfalls, Governance Practices, and Adoption Guidance
Adopting ArchiMate for capability-based planning is rarely difficult because of notation alone. The harder challenge is establishing modeling discipline, decision relevance, and sustainable governance. Many organizations produce an initial capability map successfully, then struggle to keep it useful once portfolio pressures and delivery timelines take over.
One common pitfall is treating capabilities as a one-time classification exercise. Teams produce a map, socialize it, and then leave it disconnected from investment governance, transformation intake, and architecture review. In that situation, the model quickly becomes ceremonial. To avoid this, capabilities must become part of the decision path. Initiatives should identify which capabilities they improve. Assessments should be refreshed as change occurs. Roadmap discussions should use the capability structure as a standard reference.
A second pitfall is allowing the capability model to become politically negotiated rather than architecturally governed. Business units want their own terminology preserved, programs introduce temporary labels, and technology teams try to align capabilities too closely to platform domains. Without governance, the model fragments into overlapping concepts. That is why capability definitions, naming conventions, decomposition rules, and change criteria need central stewardship, even if the content is developed collaboratively.
Another frequent problem is false precision. Organizations often assign maturity scores, strategic importance ratings, and heatmap colors with little evidence behind them. That creates an illusion of rigor while weakening trust. Good governance requires explicit assessment methods: what criteria define maturity, who provides the input, how often scores are reviewed, and what evidence is acceptable. Not every capability needs exhaustive measurement, but high-priority planning decisions should not rely on subjective color coding alone.
There is also a risk of over-modeling. Because ArchiMate can connect capabilities to many kinds of elements, teams may try to document every relationship in the enterprise. That usually creates maintenance overhead without improving decision quality. A better approach is to model selectively around priority questions: strategic investment, modernization exposure, duplication, resilience risk, regulatory impact, or operating model change.
A practical governance model usually includes a few simple mechanisms:
- Clear ownership: business stakeholders own capability intent and priority; enterprise architecture owns modeling integrity and cross-domain consistency.
- Integrated governance: portfolio intake, business case templates, and architecture reviews should reference capabilities explicitly.
- Regular review cycles: capability assessments, initiative mappings, and transition views should be refreshed in line with planning cadences.
- Standard viewpoints: a small set of recurring views helps stakeholders see the model used in familiar, decision-oriented ways.
For adoption, a focused pilot is usually more effective than an enterprise-wide modeling campaign. A pilot in one domain or transformation theme allows the organization to test naming discipline, scoring methods, and governance workflows before scaling. It also demonstrates value quickly. If leaders can see how capability-based views improve prioritization or expose hidden dependencies, broader adoption becomes much easier.
Ultimately, success depends less on diagram quality than on institutional behavior. ArchiMate supports CBP well when the model is treated as a governed planning asset, tied to recurring decisions, and kept deliberately lean.
Conclusion
ArchiMate creates real value for capability-based planning when the enterprise uses the model as a decision system rather than a static map. The point is not merely that capabilities can be drawn in the Strategy layer. The point is that they can serve as the stable reference through which strategic intent, operating design, and technology change are interpreted together.
That stability is what makes capabilities so useful. Processes, applications, and organizational structures change frequently, but the business abilities the enterprise depends on are more enduring. When those abilities are modeled consistently and linked to goals, outcomes, value streams, processes, applications, data, and technology, architecture becomes more effective at guiding investment and transformation.
In practice, mature use of ArchiMate for CBP does not mean building the most detailed repository. It means building a model that is trusted enough to shape prioritization, challenge weak investment logic, and expose hidden dependencies before commitments are made. The most effective capability models are selective, connected, and governed. They support different viewpoints for different stakeholders while preserving a single planning logic across them.
If the resulting views help executives understand where to invest, help portfolio teams see where change overlaps, and help delivery teams understand what actually needs to improve, then the architecture is doing its job. In that sense, ArchiMate supports capability-based planning not just by describing the enterprise, but by helping guide it.
Frequently Asked Questions
What is a capability map in enterprise architecture?
A capability map is a structured view of what a business must be able to do — independent of how it is currently organised or which applications support it. Capabilities are grouped by domain and linked to strategic goals, helping architects prioritise investment and identify gaps.
How do capabilities relate to applications in ArchiMate?
In ArchiMate, Application Components realise Business Capabilities through Realisation relationships. This traceability shows which systems support which capabilities, enabling portfolio analysis, rationalisation decisions, and investment planning linked directly to business outcomes.
What is capability-based planning?
Capability-based planning is a strategic approach where investment decisions are driven by the capabilities the organisation needs to develop or improve, rather than by project requests. It aligns IT investment to business strategy by making the capability gap explicit and measurable.