Solution vs Enterprise Architecture: What's the Real Difference
Summary of the video “Solution vs Enterprise Architecture POV” by Jesper Lowgren.
Solution architecture solves defined business problems with detailed blueprints; enterprise architecture ensures the right problem is solved the right way by connecting business strategy to technology through business capability models. They are complementary, not competing—enterprise architecture prevents silos by providing the strategic context that solution architecture needs.
Core Definitions and Perspectives
Solution Architecture Solves Defined Problems
Solution architecture takes business requirements and creates a detailed blueprint with enough specificity to allow a system to be developed, implemented, or integrated. It focuses on translating what the business needs into a technical design.
Enterprise Architecture Ensures Right Problem, Right Way
Enterprise architecture ensures that organizations solve the correct business problem in the correct sequence and manner. It connects business strategy and goals through business architecture to inform application, data, and technology decisions across the organization.
Key Difference: Business Architecture
The critical distinction is that enterprise architecture uses business architecture to connect strategy with technology, while solution architecture operates within defined requirements. Business architecture prevents silos by ensuring alignment across the enterprise.
The Conceptual Framework: IT and Business Layers
Three IT-Focused Diagram Types
Directives establish IT rules and compliance levels enabling reuse through technical consistency. Landscapes describe IT structures as reference materials for technical planning. Designs specify IT requirements producing blueprints for development or implementation.
Three Business-Focused Diagram Types
Principles establish business rules creating context for IT planning and procurement. Visions align IT investment with business outcomes. Requirements translate business needs into diagrams and models that feed into the design stage.
Solution Architecture in Detail
Business Principles Guide Technical Decisions
Principles are generic rules that ensure consistency. Examples include light balance sheet (prefer operational over capital expenditure, rent before buy before build), ease of use (good employee and customer experience), maintain single source of truth (no replicated data, use APIs), and control technical diversity (reuse existing assets).
Patterns Solve Recurring Technical Problems
Patterns are granular solutions to commonly occurring problems. For example, a transaction pattern ensures that when multiple systems and data sources must be updated (like an ATM withdrawal), if one system fails all systems roll back to original state. Patterns cover transaction integrity, data transfer between environments, and other scenarios.
Three Key Solution Architecture Diagrams
Solution overview translates business requirements into use cases and conceptual architecture describing core processes and interactions. Landscape diagram shows how applications and databases integrate at high or detailed level. Solution design describes solution context including application, data, technology infrastructure, and reference architectures.
Enterprise Architecture and Business Capability Models
Business Capability: What vs How vs Where
A business capability describes what the business does, not how it does it or where it does it. This distinction makes capabilities different from organizational structures. Capabilities are grouped into hierarchies starting with level zero capabilities derived from the organization's value chain.
Capability Hierarchy Levels
Level zero capabilities are derived from the value chain (e.g., product design, marketing, sales, contract, construction, service). Level one capabilities decompose level zero into capability areas. Level two capabilities further decompose level one. Decomposition typically stops at level two when a capability can no longer be meaningfully broken down.
MECE Framework Validates Decomposition
MECE stands for Mutually Exclusive, Collectively Exhausted. This framework ensures that capability decompositions are valid by confirming that sub-capabilities do not overlap and together they completely cover the parent capability.
Current and Future State Capability Assessment
Current state assessment evaluates each capability's ability to support business operations using a classification framework: green (works well), yellow (sub-optimal), orange (problematic but non-severe), red (severe problems), blue (missing). Future state reflects capabilities needed to deliver business strategy. The gap between current and future drives capability uplift roadmaps.
Capability Uplift Roadmaps Drive Technology Decisions
Capability uplift roadmaps prioritize and group capability improvements, often by mapping dependencies. These roadmaps then drive application roadmaps, data transformation initiatives, cloud transitions, and API development prioritization—ensuring technology investments align with business strategy.
Three Key Enterprise Architecture Artifacts
Business principles establish guardrails for directives. Business capability models and capability uplift roadmaps provide guardrails for requirements. Together these three artifacts ensure the right business problem is solved in the right order across the enterprise.
How Solution and Enterprise Architecture Complement
Solution Architecture Covers Three Dimensions Fully
Solution architecture fully covers principles, visions, and requirements dimensions. It partly covers directives, landscapes, and designs. This focused scope allows solution architects to deliver detailed blueprints for specific business problems.
Enterprise Architecture Covers All Dimensions
Enterprise architecture covers all dimensions by using business architecture to connect strategy to technology. It covers principles and directives, visions and landscapes, and requirements and designs. This comprehensive view ensures alignment across the organization.
Solution Architecture Without Enterprise Creates Silos
Solution architecture focused only on business requirements creates organizational silos because it lacks the strategic context provided by business capability models and roadmaps. Enterprise architecture is essential for organizations seeking to create scale and consistency across the enterprise.
Enterprise Architecture is Superset of Solution
Solution architecture is a subset of enterprise architecture. The key difference is business architecture, which connects data, application, and technology architectures with business strategy and goals. This relationship ensures that individual solutions contribute to overall enterprise objectives.
Notable quotes
Solution architecture solves business problems defined in business or user requirements — Jesper Lowgren
Enterprise architecture ensures that the right business problem is solved in the right way — Jesper Lowgren
Solution architecture without business architecture creates silos by focusing only on business requirements — Jesper Lowgren