From Enterprise Architecture to Solution Architecture

What This Guide Covers

Enterprise Architecture defines the strategic intent, guardrails, and structural models of the enterprise. Solution Architecture turns that intent into concrete, implementable designs. This guide explains how to bridge the gap — ensuring that solutions are aligned with strategy, compliant with architecture principles, and grounded in real-world delivery constraints.

The goal is to provide a practical, repeatable approach for moving from capabilities, value streams, and reference models to solution views, integration flows, data contracts, and deployment architectures.

1. The EA → SA Continuum

Enterprise Architecture and Solution Architecture are often treated as separate disciplines, but in practice they form a continuum:

Enterprise Architecture: Defines the “what” and “why” — capabilities, principles, standards, target states, and reference models.
Solution Architecture: Defines the “how” — solution components, integration flows, data structures, deployment topologies, and implementation decisions.

Effective organizations ensure traceability between the two — from strategy to capabilities to architecture to solution to implementation.

2. Translating EA Artifacts into Solution Designs

Solution Architecture becomes significantly easier when EA artifacts are used as inputs. This section outlines how each EA artifact maps to solution-level outputs.

Capabilities → Services, Modules, Components

Capabilities define the functional boundaries of the solution.
They guide modularization and service decomposition.
They help identify ownership and domain boundaries.

Value Streams → Workflows and Orchestration

Value stream stages map to solution workflows.
They identify integration points and handoffs.
They highlight where automation or orchestration is needed.

Data Architecture → Schemas, APIs, Events

Information concepts become data models and contracts.
Data flows become APIs, events, or pipelines.
Data ownership informs domain boundaries and governance.

Integration Architecture → Flows and Patterns

Integration patterns guide solution interactions.
API-led, event-driven, or batch patterns are selected based on context.
Integration principles ensure consistency and reuse.

Technical Architecture → Deployment and Infrastructure

Cloud services, compute, storage, and networking choices.
Security and identity integration.
DevOps pipelines and operational considerations.

3. Solution Architecture Viewpoints

TOGAF and other frameworks recommend using multiple viewpoints to describe a solution. The following viewpoints are the most practical and widely used.

Logical Architecture

Major components and their responsibilities.
Logical grouping aligned to capabilities or domains.

Physical Architecture

Actual systems, services, and infrastructure components.
Cloud services, containers, databases, and integrations.

Integration View

APIs, events, messaging, and data flows.
Patterns used and rationale for selection.

Data View

Data models, contracts, and ownership.
Data lineage and transformation logic.

Security View

Identity and access management.
Threat modeling and security controls.

Deployment View

Environments, clusters, and cloud regions.
CI/CD pipelines and operational considerations.

4. Architecture Decision Records (ADRs)

ADRs capture key decisions that shape the solution. They ensure transparency, traceability, and alignment with EA principles.

Document the context, options, and rationale.
Link decisions to EA principles and standards.
Use ADRs to guide implementation and future changes.

5. Patterns and Anti‑Patterns

Solution Patterns

API-led solution patterns
Event-driven solution patterns
Microservices decomposition patterns
Modular monolith patterns
Cloud-native solution patterns