ArchiMate Strategy Layer Explained with Real Architecture

⏱ 25 min read

ArchiMate Strategy Layer Explained with Real Architecture Examples ArchiMate training

Learn the ArchiMate Strategy Layer with clear explanations and real architecture examples. Explore capabilities, resources, value streams, and strategic modeling best practices. ArchiMate tutorial for enterprise architects

ArchiMate Strategy Layer, ArchiMate examples, enterprise architecture, ArchiMate tutorial, strategy layer explained, ArchiMate capabilities, ArchiMate resources, ArchiMate value streams, TOGAF ArchiMate, architecture modeling, enterprise strategy modeling, ArchiMate business architecture ArchiMate layers explained

Introduction

The ArchiMate Strategy Layer gives enterprise architects a way to model how an organization intends to create advantage before that intent is translated into operating models, processes, applications, and technology. In many organizations, architecture discussions start too late—once teams are already debating platforms, target operating models, or delivery plans. Strategy starts earlier. It is about direction, deliberate choice, and the enterprise abilities that must be strengthened to compete, adapt, or transform. ArchiMate relationship types

That is where the Strategy Layer earns its place. It helps architects represent not only what the enterprise does, but why it is investing in change and how that change is expected to create value. In ArchiMate, this is expressed primarily through three concepts: capability, resource, and course of action. A capability describes what the enterprise is able to do. A resource describes what it can draw on, such as data, platforms, expertise, relationships, or brand. A course of action describes the strategic approach leadership has chosen, such as expanding through digital self-service, standardizing operations, or building a partner ecosystem.

Together, these concepts bridge business motivation and execution design. Motivation explains what stakeholders want and why. The Strategy Layer adds the enterprise response: which abilities must improve, which assets can be leveraged, and which strategic path the organization intends to follow. That makes the layer particularly useful in portfolio planning, investment prioritization, and transformation roadmapping.

Consider a retailer pursuing click-and-collect growth. The strategy is not simply to launch a new customer feature. It depends on capabilities such as inventory visibility, local fulfillment coordination, customer communication, and partner logistics integration. It also relies on resources such as store networks, product data, integration services, and operational teams. Modeling those relationships at the strategy level helps leaders see that success depends on coordinated capability uplift across several domains, not just a new front-end application.

The same pattern appears across industries. A bank responding to fintech pressure may need stronger product configuration agility and more personalized engagement. A healthcare provider expanding hybrid care may need remote patient engagement and secure clinical data exchange. A government agency modernizing identity and access management may define a course of action around centralized identity services and risk-based access, rather than treating IAM as only a tooling upgrade. In each case, the Strategy Layer helps architects turn broad ambitions into a structured model that can later be traced into business, application, and technology architecture.

This article explains how the ArchiMate Strategy Layer works, why it matters in enterprise practice, and how to apply it using realistic architecture examples. It begins with the role of the layer in strategy modeling, then introduces the core concepts of capability, resource, and course of action. From there, it shows how these concepts connect business goals to architecture decisions before exploring practical examples. The article closes with modeling patterns, common pitfalls, and practices that make Strategy Layer views useful in real decision-making. ArchiMate modeling best practices

What the ArchiMate Strategy Layer Is and Why It Matters

The ArchiMate Strategy Layer is the part of the language used to describe how an enterprise intends to respond, compete, or reposition before those intentions are translated into operating models, projects, and solution designs. It captures strategic structure in a form that is explicit enough for analysis, yet abstract enough to remain useful across business units, portfolios, and transformation programs.

Its concern is not implementation detail. Instead, it models the enterprise’s strategic means: the capabilities it must possess, the resources it can use, and the courses of action it chooses to pursue. Those three concepts make the layer effective as a bridge between ambition and execution.

This matters because strategy is often documented in forms that are difficult to connect to architecture. Board papers, annual plans, and investment themes may refer to growth, efficiency, resilience, sustainability, or innovation, but they rarely spell out the architectural implications clearly enough to guide change. The Strategy Layer fills that gap by giving architects a vocabulary for turning strategic intent into enterprise design concerns.

One of its main strengths is that it reduces solution bias. In many organizations, transformation conversations jump too quickly to platform selection, application modernization, or organization redesign. The result is predictable: the enterprise commits to initiatives before clarifying what strategic advantage those initiatives are meant to create. Strategy-layer modeling slows the conversation down in a useful way. It pushes stakeholders to ask:

• What capability must improve?
• What resource can be leveraged, or is currently constraining progress?
• What course of action gives the enterprise the best path forward?

A healthcare provider offers a simple illustration. If leadership decides that future competitiveness depends on hybrid care delivery, the strategic issue is not yet the choice of a telemedicine platform. At this level, the real question is which capabilities are required—remote patient engagement, digital triage, care coordination, and secure clinical data exchange, for example. It is also necessary to identify the supporting resources, including clinician expertise, patient trust, regulatory knowledge, and interoperable health records. Only when those strategic elements are clear does it make sense to design business services and supporting applications.

The Strategy Layer is equally valuable when comparing investment options. Enterprises rarely have the capacity to fund every worthwhile initiative. Architects therefore need a way to assess whether separate proposals reinforce the same strategic capabilities or pull the organization in different directions. A strategy model makes those dependencies visible. If several programs all claim to improve customer experience, the model can show whether they strengthen shared capabilities such as customer insight, personalization, and channel integration—or whether they are isolated efforts with limited strategic effect.

This is where architecture governance becomes more disciplined. An architecture board may reject three separate customer master initiatives and instead approve one enterprise customer data capability uplift because the strategy model shows all three proposals are addressing the same constraint. In the same way, a technology lifecycle board may decide to retire an aging integration product only after confirming that the replacement supports the target course of action, rather than a local technical preference.

The layer also improves sequencing. Some capabilities are foundational and enable many later changes. Others create value only when resources, governance, or organizational conditions are already in place. By modeling these relationships, architects can identify where early investment creates leverage. In practice, that is often the difference between a coherent transformation and a collection of disconnected projects.

Put simply, the Strategy Layer matters because it gives enterprise architecture a credible role in strategic decision-making. It allows architects to engage not only with delivery teams, but also with executives and portfolio leaders, using models that clarify choices, expose assumptions, and connect ambition to enterprise change.

Core Strategy Layer Concepts: Capability, Resource, and Course of Action

At the center of the ArchiMate Strategy Layer are three concepts: capability, resource, and course of action. Used together, they provide a disciplined way to model strategic change without drifting into implementation detail too early.

Capability

A capability represents an ability that the enterprise possesses or must develop. It is not a process, application, or team, although all of those may contribute to it. A capability is expressed at a higher level—as something the organization can reliably do.

Examples include:

• Customer analytics
• Partner onboarding
• Regulatory compliance management
• Digital product delivery
• Demand forecasting

This distinction matters because capabilities are more stable than the operating structures that realize them. A bank may replace its lending platform, reorganize operations, or outsource part of service delivery, but the capability of credit risk assessment remains strategically important. That relative stability is one reason capabilities are often the best starting point for strategic analysis.

In practice, capability maps help architects answer questions such as:

• Which abilities are strategically differentiating?
• Which are underdeveloped relative to business ambition?
• Which initiatives are strengthening the same capability?
• Which proposed changes depend on capabilities that do not yet exist at the required maturity?

A useful micro-example is subscription billing in a software company. Teams may debate CRM workflows, invoice engines, or finance ownership, but the strategy concern is broader: does the enterprise have the capability to manage recurring revenue, pricing changes, and entitlement control at scale? That capability remains relevant even if the underlying systems change.

Resource

A resource is an asset the enterprise can use to realize capabilities or support strategic action. Resources may be tangible or intangible, including:

• Data
• Platforms
• Intellectual property
• Specialist staff
• Supplier relationships
• Brand reputation
• Physical infrastructure
• Access to distribution channels

If capability describes what the enterprise can do, resource describes what it can draw upon. That makes resources especially important when assessing strategic feasibility. An organization may aspire to advanced personalization, but without high-quality customer data, consent management, and analytical talent, the capability will remain weak regardless of leadership intent.

Resource modeling adds realism. It shows where strategic plans depend on assets that are fragmented, missing, or hard to scale. For example, an IAM modernization program may identify directory services, identity data quality, access policies, and security expertise as critical resources. If those resources are inconsistent across business units, the target capability of federated access management will remain weak even if a new platform is purchased.

Another simple example comes from higher education. A university may want to expand online executive learning, but if course content is scattered across faculties, learner data is inconsistent, and partner channels are managed informally, the institution lacks the resources needed to scale that ambition.

Course of Action

A course of action represents the chosen approach for configuring capabilities and resources in pursuit of strategic outcomes. It captures deliberate strategic choice, such as:

• Expanding through digital self-service
• Standardizing shared operations
• Entering a partner ecosystem
• Shifting from product sales to subscription services

This concept matters because two organizations with similar capabilities and resources may still choose very different paths. The element captures intent and positioning, not simply what the enterprise possesses.

In practice, courses of action help architects compare alternatives. A manufacturer seeking resilience might consider dual sourcing, regionalized production, or increased inventory buffers. Each option places different demands on capabilities and resources. Modeling these alternatives clarifies trade-offs before they become expensive programs.

An event-driven architecture example makes this concrete. A company may decide that its course of action is to improve operational responsiveness through real-time event sharing. That does not yet mean “implement Kafka everywhere.” It means strengthening capabilities such as event governance, near-real-time integration, and consumer decoupling, while evaluating whether platforms like Kafka are the right resources to support that strategy.

How the Three Work Together

Used together, these concepts create a practical structure for strategy:

• Capabilities identify what must be strong.
• Resources show what is available, constrained, or missing.
• Courses of action define how leadership intends to combine them.

A concise example is a utility pursuing smart meter growth. The course of action may be to scale digital field operations and remote service activation. The capabilities involved include device lifecycle management and outage response coordination. The resources include field workforce expertise, network telemetry, and integration with meter vendors. Without all three elements, the strategy remains incomplete.

The next section builds on this by showing how these concepts translate business goals into architecture decisions.

How the Strategy Layer Connects Business Goals to Architecture Decisions

Most enterprises are not short of goals. They want faster growth, lower operating costs, stronger compliance, better retention, higher resilience, or more innovation. The problem is that goals are usually expressed in the language of outcomes, while architecture decisions have to be made in the language of design. The Strategy Layer provides the intermediate structure that makes that translation possible.

A goal such as “improve customer retention” does not, on its own, tell architects what to change. It could point to better service responsiveness, more personalized engagement, improved product fit, or reduced onboarding friction. Without the strategic structure described earlier, different teams may interpret the same goal in different ways and launch disconnected initiatives.

The Strategy Layer forces greater specificity. Using capabilities, resources, and courses of action, the enterprise must define how the goal will actually be pursued. In one organization, retention may depend on customer insight and proactive service recovery. In another, it may depend on loyalty partnerships and channel consistency. The architectural implications are very different.

That makes the Strategy Layer a decision filter. Architects can test whether proposed changes genuinely support strategic intent or simply sound attractive in isolation. If an insurer adopts a course of action centered on digital self-service at scale, architecture decisions should favor reusable identity services, policy data accessibility, workflow automation, and channel integration. A proposal that increases manual back-office customization may still have local value, but it is weaker strategically unless it clearly strengthens the same target capabilities.

The layer also helps derive architecture principles. Once strategic priorities are modeled, architects can define design implications that guide downstream decisions. For example:

• A strategy centered on operational standardization may lead to principles such as:

- adopt common platforms over local variants

- harmonize processes before automating them

• A strategy centered on rapid experimentation may lead to principles such as:

- design modular applications

- use API-first integration

- prefer cloud-native deployment patterns

These are not merely technical preferences. They become traceable responses to enterprise direction.

The Strategy Layer is equally important for portfolio coherence. Large organizations often fund projects one by one, with each business case justified independently. The result is a landscape of initiatives that are individually sensible but collectively fragmented. Strategy-layer modeling helps portfolio teams see whether multiple investments reinforce the same capability uplift or compete for scarce resources without improving strategic position.

Consider a telecom company trying to reduce churn through a better service experience. CRM modernization, field service scheduling, and customer communication redesign may at first appear to be separate projects. Through the Strategy Layer, they can be assessed as contributors to shared capabilities such as customer insight, service responsiveness, and omnichannel coordination. That makes prioritization more coherent.

The layer also gives context to trade-offs. Architecture decisions always involve balancing speed and control, reuse and specialization, or centralization and autonomy. Strategy provides the frame for making those trade-offs explicit. A company pursuing regional market adaptation may accept more variation than one pursuing global efficiency. An enterprise focused on ecosystem expansion may prioritize external integration over internal optimization. The strategic model does not remove trade-offs, but it makes them easier to explain and defend.

A university provides another useful example. Suppose it wants to grow lifelong learning revenue. At the strategy level, it may identify capabilities such as rapid course packaging, learner analytics, partner channel management, and digital enrollment. That framing then informs business architecture decisions about service design, application architecture decisions about learning platforms and CRM integration, and data architecture decisions about unified learner profiles.

The same logic applies in governance decisions. A technology lifecycle review may conclude that a legacy ETL tool should move from tolerated to phase-out status because the enterprise course of action favors event-driven integration and reusable data products. The tool is not retired simply because it is old, but because it no longer supports the strategic direction.

Real Example 1: Using the Strategy Layer in a Digital Banking Transformation

Digital banking transformation is a strong example of Strategy Layer modeling because banks rarely change for a single reason. More often, they are responding to several pressures at once: fintech competition, rising customer expectations, cost-to-serve concerns, regulatory scrutiny, and the need to launch products faster. Without a strategic model, those pressures tend to produce fragmented programs rather than coordinated change.

Consider a mid-sized retail bank with a three-year ambition to become a digital-first relationship bank. Leadership wants to reduce branch dependency, increase mobile adoption, improve cross-sell conversion, and shorten time-to-market for new savings and lending products.

Using the concepts defined earlier, the bank can express this ambition through a set of target capabilities:

• Digital customer onboarding
• Personalized engagement
• Product configuration agility
• Fraud and risk intelligence
• Omnichannel service orchestration

These are not projects. They are the enterprise abilities that must be strengthened if the strategy is to succeed.

Resource Analysis

The next step is to identify the resources that make those capabilities realistic. The bank already has several strengths:

• A trusted brand
• A large customer base
• Strong compliance expertise
• A stable core banking platform

It also has significant constraints:

• Fragmented customer data
• Separate mobile and web teams
• Product rules embedded in legacy systems
• Slow change cycles around core product logic

This resource view reveals an important truth: the bank is not starting from zero, but its main digital constraints are structural, not merely technical.

A realistic micro-example here is onboarding identity proofing. The bank may discover that each product line uses a different vendor and a different evidence standard for KYC checks. That is not just a delivery nuisance; it weakens the broader capability of digital onboarding and makes channel consistency harder to achieve.

Course of Action

A useful course of action for this bank might be:

Digitize acquisition, modularize product delivery, and centralize customer insight.

That is far more useful than a generic statement such as “modernize banking systems.” It implies real choices. It suggests that the bank intends to compete through lower-friction onboarding, faster product innovation, and more relevant customer interaction. It also helps prioritize investment.

For example, the architecture board may decide to fund identity and onboarding modernization before a full mobile redesign, because the strategy model shows onboarding capability is foundational. In practice, this could mean introducing reusable IAM services such as customer identity proofing, step-up authentication, and consent capture that support both acquisition and ongoing service.

Strategy-Led Sequencing

The Strategy Layer is particularly helpful for sequencing. The bank may be tempted to launch a new mobile app first because it is visible to customers. The strategy model shows why that would be incomplete. Customer-facing improvements will stall unless foundational capabilities are addressed.

For example:

• Digital onboarding depends on identity verification, document handling, workflow orchestration, and customer data integration.
• Personalized engagement depends on consent management, event data capture, segmentation models, and campaign execution.
• Product agility depends on decoupling product parameters from hard-coded legacy logic.

This view supports a roadmap that starts with capability enablers rather than cosmetic digital change.

Portfolio Governance

The model also improves investment governance. Suppose three programs seek funding:

• A chatbot initiative
• A loan origination redesign
• A customer data platform

Without strategy modeling, they may look like unrelated proposals. In the Strategy Layer, architects can show which target capabilities each one strengthens and where overlap exists.

• The chatbot may contribute to omnichannel service orchestration, but only marginally if customer context remains fragmented.
• The loan origination redesign may improve onboarding and product delivery, depending on scope.
• The customer data platform may seem less visible, but it is foundational for both personalized engagement and service consistency.

That creates a stronger basis for prioritization.

Why the Example Matters

The main lesson is simple: a bank does not become digital-first merely because customers can open accounts on a phone. It becomes digital-first when its strategic capabilities, resources, and chosen course of action align to support faster adaptation, lower friction, and more intelligent service across the enterprise. The Strategy Layer makes that alignment visible.

Real Example 2: Applying the Strategy Layer to Manufacturing Supply Chain Modernization

Manufacturing supply chain modernization is another strong use case because supply chains are shaped by strategic trade-offs, not just operational inefficiencies. A manufacturer may want lower cost, shorter lead times, greater resilience, better service levels, and reduced environmental impact at the same time. The Strategy Layer helps clarify which of those priorities actually define the enterprise response.

Consider a global industrial equipment manufacturer that has experienced disruption from supplier concentration, transport volatility, and limited visibility across contract manufacturers and regional distribution centers. Leadership decides that future competitiveness depends less on pure cost optimization and more on resilient, data-informed fulfillment.

That strategic shift changes the architecture conversation. The issue is no longer simply how to upgrade ERP modules or add dashboards. The question becomes which enterprise abilities must be strengthened to sense disruption early, adapt sourcing and production decisions quickly, and maintain customer commitments under changing conditions.

Target Capabilities

At the strategy level, the manufacturer identifies several target capabilities:

• Multi-tier supply visibility
• Scenario-based planning
• Supplier risk management
• Adaptive production allocation
• Logistics coordination across regions

Resource Analysis

The manufacturer already has useful resources:

• Long-standing supplier relationships
• Regional planning teams
• Engineering knowledge
• Warehouse infrastructure
• Large volumes of operational data

Those resources, however, are uneven in quality and accessibility:

• Supplier data is inconsistent across business units
• Plant scheduling relies on local tools
• Transport events are visible only for selected carriers
• Risk knowledge resides mainly in experienced planners rather than shared models

Representing these as resources exposes an important constraint: strategic ambition depends as much on information quality, governance, and decision rights as it does on new software.

A small but telling example is supplier substitution. If part equivalence rules exist only in spreadsheets maintained by individual plants, the enterprise cannot respond quickly to disruption even if it buys a sophisticated planning suite. The strategic weakness sits in the resource base, not only in the application estate.

Course of Action

A suitable course of action might be:

Increase resilience through diversified sourcing, end-to-end planning visibility, and regional response flexibility.

This clarifies which architectural choices are preferred. It may justify investment in supplier network mapping, planning data harmonization, and event-driven integration before broad deployment of advanced forecasting tools.

A realistic architecture example here is Kafka-based event architecture. Rather than integrating each plant and logistics provider point-to-point, the enterprise may choose Kafka as a shared event backbone for shipment updates, inventory movements, and production exceptions. In Strategy Layer terms, Kafka is not the strategy itself; it is a resource that supports capabilities such as multi-tier visibility and coordinated response.

Strategy-Led Roadmapping

As with the banking example, the Strategy Layer improves sequencing. A common mistake is to treat supply chain modernization as a single system replacement. In reality, the target capabilities cut across multiple architecture layers.

For example:

• Multi-tier visibility may require supplier collaboration processes, master data improvement, and integration with external logistics feeds.
• Scenario-based planning may require common planning models, simulation tooling, and governance for decision escalation.
• Adaptive production allocation may require tighter linkage between demand signals, plant capacity data, and sourcing constraints.

A strategy-led roadmap might therefore begin with foundational resources such as supplier master data, inventory event capture, and common planning definitions. It can then progress toward risk analytics, response playbooks, and regional orchestration services.

Portfolio Implications

The model also helps leadership assess whether programs in procurement, manufacturing operations, logistics, and analytics are converging on shared strategic capabilities or merely optimizing isolated functions. That is especially valuable in global manufacturing environments, where local improvements often fail to add up to enterprise resilience.

Why the Example Matters

The lesson here is similar to the banking case. Supply chain modernization is not just about digitizing existing processes. It is about aligning capabilities, resources, and strategic choices so that the enterprise can respond effectively under uncertainty. The Strategy Layer gives architects a way to model that alignment before investments become locked into technology programs.

Common Modeling Patterns, Pitfalls, and Best Practices for Strategy Layer Views

Strategy Layer views are most useful when they are created for a specific decision, not as abstract diagrams of “the strategy.” In practice, a small number of repeatable patterns tend to work well.

Common Modeling Patterns

1. Capability Uplift View

This view shows current and target capabilities alongside the resources and courses of action that will strengthen them. It is especially useful in investment planning because it reveals whether funding is going toward foundational capabilities or isolated initiatives.

2. Strategic Options View

This view models two or three alternative courses of action and the different capability and resource implications of each. It is valuable in early transformation design, market entry, or merger planning.

For example, a telecom provider considering digital services expansion might compare:

• a platform-partnership approach
• a build-and-own approach

Both may support growth, but they require different resources, risk tolerances, and capability profiles.

3. Strategy-to-Execution Traceability View

This view links the Strategy Layer downward into business processes, value streams, application services, or work packages. The purpose is not to overload the strategy diagram with implementation detail, but to show that strategic intent is grounded in executable change.

This is often the view that gives the Strategy Layer credibility with both executives and delivery teams.

4. Technology Lifecycle Governance View

This view connects strategic direction to technology standards and lifecycle states. For example, if the enterprise strategy favors shared digital identity, event-driven integration, and platform reuse, the model can justify moving custom authentication components to retirement, promoting Kafka as a strategic integration resource, or restricting new deployments on end-of-life middleware.

Common Pitfalls

Confusing Capabilities with Processes or Organizational Units

Teams often label departments such as “Customer Operations” or workflows such as “Order Handling” as capabilities. That weakens the model because it ties strategy to the current operating design rather than to underlying enterprise abilities.

A simple test helps: if the concept would still exist after a reorganization or process redesign, it is more likely to be a capability.

Using Courses of Action as Slogans

Statements such as “be more digital,” “improve innovation,” or “transform customer experience” are too vague to guide architecture. A good course of action should imply choices about how the enterprise will compete, adapt, or allocate effort.

Ignoring Constraints

Strategy views are far more useful when they acknowledge resource limitations, maturity gaps, and dependencies. A model that shows only target capabilities without exposing what is fragmented, missing, or difficult to scale will have limited planning value.

Overloading the Diagram

If every capability in the enterprise appears in one view, the strategy disappears into cataloging. Strategy diagrams should be selective and decision-oriented.

Best Practices

Several practices help keep Strategy Layer views effective:

• Model for one decision at a time. A portfolio prioritization view should look different from an executive discussion view.
• Keep the number of strategic elements intentionally small. Focus on what matters most.
• Show constraints as well as ambition. Resource gaps and maturity weaknesses make the model actionable.
• Use heat mapping where useful. This helps stakeholders see not only what matters strategically, but also where weakness or investment concentration exists.
• Maintain traceability. The Strategy Layer becomes most powerful when it can be connected to lower-layer architecture and roadmap artifacts.
• Review models as strategy changes. Capabilities may remain stable, but courses of action and resource priorities often shift.

Used well, Strategy Layer views do more than describe ambition. They help enterprises compare options, expose assumptions, and organize change around the few capabilities that truly matter.

Conclusion

The ArchiMate Strategy Layer is most valuable when it changes how architecture decisions are made, not simply how they are documented. Its strength lies in making strategic direction explicit before organizations commit to delivery choices that are expensive to reverse.

As this article has shown, the layer works by structuring strategy through three core concepts: capability, resource, and course of action. Capabilities identify what the enterprise must be able to do. Resources reveal what it can leverage—or where it is constrained. Courses of action capture the chosen path for creating value. Together, they form the bridge between business ambition and execution design.

That bridge is what makes the Strategy Layer so useful in enterprise practice. It helps architects translate goals into architecture implications, compare investment options, sequence transformation work, and maintain coherence across portfolios. In the banking example, it exposed why customer-facing digital improvements depended on foundational capabilities such as customer insight and product agility. In the manufacturing example, it showed why supply chain modernization required more than system replacement and had to be framed around resilience, visibility, and coordinated response.

It also strengthens the architect’s role. Instead of entering the conversation only after priorities have been fixed, architects can contribute earlier by clarifying which capabilities create leverage, which resources limit ambition, and which strategic choices create conflicting demands across the enterprise. That makes architecture more relevant to executives, portfolio leaders, and transformation teams.

Ultimately, the Strategy Layer is not abstraction for its own sake. It is a practical way to move from ambition to coordinated change. Used well, it helps organizations focus investment where it matters most, align programs around shared strategic outcomes, and build roadmaps that are both realistic and purposeful.

Frequently Asked Questions

What are the three core ArchiMate layers?

The three core ArchiMate layers are the Business layer (processes, roles, services), the Application layer (software components and data), and the Technology layer (infrastructure, platforms, networks). Together they provide a complete cross-domain view of the enterprise.

How do ArchiMate layers connect to each other?

ArchiMate layers connect through Serving and Realisation relationships. The Application layer serves the Business layer by providing application services that support business processes. The Technology layer serves the Application layer by providing hosting, networking and runtime infrastructure.

Why are layers important in enterprise architecture modeling?

Layers separate concerns so each audience sees the right level of detail. Business stakeholders focus on the Business layer, solution architects work with the Application layer, and infrastructure teams use the Technology layer. All three layers remain traceable in one coherent model.