What are the four architecture domains?

Overview of the Four-Domain Model

Enterprise Architecture traditionally organizes work into four domains: Business, Data, Application, and Technology. This partitioning helps teams manage complexity by separating concerns while maintaining explicit relationships between them. TOGAF and other frameworks popularized this structure, though organizations may add domains—security, integration, or experience architecture—when specialization warrants.

Each domain answers distinct questions. Business Architecture asks what the organization does and how it creates value. Data Architecture asks what information is needed, where it originates, and how it is governed. Application Architecture asks which software systems support which activities and how they interact. Technology Architecture asks which infrastructure and platforms enable reliable, secure delivery.

Domains are not silos. A change in business strategy ripples through data requirements, application portfolios, and technology investments. Cross-domain workshops and linked models make these dependencies visible before funding commits.

Cross-domain traceability matrices—capability to application to data entity to technology—are high-value EA artifacts linking four domains for impact analysis when any element changes.

Business Architecture Domain

Business Architecture describes organizational structure, capabilities, value streams, processes, and policies that define how the enterprise operates and competes. Artifacts include capability maps, value stream maps, organization charts, business models, and strategic objectives linked to operational metrics. This domain anchors technology decisions in business meaning—preventing IT from optimizing systems that no longer support corporate strategy.

Business architects collaborate with enterprise leadership, product owners, and process owners. They identify capability gaps, duplication, and transformation priorities. In regulated industries, business architecture also maps controls to processes for compliance traceability.

Strong business architecture reduces solution rework caused by misunderstood requirements. When technologists share a capability vocabulary with business leaders, prioritization debates become substantive rather than territorial.

Domain-specific governance boards may exist for data or security while enterprise board maintains cross-domain coherence—avoid domain silos optimizing locally.

Data Architecture Domain

Data Architecture defines logical and physical data models, master data domains, integration flows, metadata standards, and governance policies. It addresses data quality, lineage, privacy, retention, and analytics needs across the enterprise. Modern data architecture spans warehouses, lakes, streaming pipelines, and operational stores unified by governance rather than single monolithic databases.

Data architects partner with security and legal on classification and regulatory requirements—GDPR, HIPAA, PCI—and with analytics teams on semantic consistency. They prevent the proliferation of incompatible definitions of customer, product, or revenue that undermine reporting and AI initiatives.

Application and technology domains depend on data architecture for integration patterns and storage decisions. Cloud migration often exposes data gravity challenges that data architecture must resolve before applications can move efficiently.

Training curricula often specialize by domain after foundational EA literacy—data architects deep on governance, application architects on integration patterns.

Application Architecture Domain

Application Architecture catalogs the software portfolio—packages, custom systems, SaaS services—and defines how applications compose into solutions supporting business capabilities. It covers integration styles, API strategies, microservices boundaries, and application lifecycle states from invest to retire. Rationalization and modernization roadmaps live largely in this domain.

Application architects evaluate fit-for-purpose, overlap, and technical debt. They define reference application patterns—hub-and-spoke integration, event-driven choreography, modular ERP extensions—that solution teams implement consistently.

User experience and channel architecture sometimes sit adjacent to application architecture when omnichannel consistency matters. Regardless of naming, the goal is coherent application ecosystems that minimize brittle point-to-point connections.

Industry accelerators pre-populate domain content—retail product catalogs, insurance policy admin patterns—speeding first baseline development.

Technology Architecture Domain

Technology Architecture encompasses hardware, software infrastructure, networks, cloud platforms, middleware, and operational tooling. It defines standards for compute, storage, deployment, monitoring, and identity that applications assume. Technology roadmaps address end-of-life hardware, cloud landing zones, edge devices, and emerging platforms like AI accelerators.

Technology architects ensure non-functional requirements—availability, performance, scalability, disaster recovery—are achievable at enterprise scale. They balance innovation with operational stability, often through internal platform teams delivering self-service capabilities.

Larkinized LLC integrates the four domains in client engagements, ensuring roadmaps and governance reflect cross-domain dependencies rather than optimizing one layer in isolation.

Architecture debt registers should tag entries by domain owner so remediation backlogs are actionable in domain sprint planning.

Applying the Four-Domain Model in Workshops

Larkinized LLC runs cross-domain workshops when clients face stuck transformations—business wants new digital revenue but data cannot support personalization, or applications cannot integrate because technology standards lag. Facilitators wall four flip-chart quadrants and trace one strategic initiative through each domain explicitly, surfacing hidden dependencies before charter sign-off. Participants leave understanding why data migration blocks application go-live and why business process change precedes CRM replacement.

Domain maturity rarely progresses evenly. A client may excel at technology standards while business architecture remains anecdotal. Assessment heat maps per domain guide investment in skills, tooling, and governance rather than assuming uniform EA maturity. Targeted improvement—hire business architect, launch capability mapping pilot—beats generic EA expansion.

Extensions beyond four domains should be deliberate. Security architecture as separate domain makes sense when CISO organization demands direct traceability; experience architecture emerges when UX consistency is strategic differentiator. Document why extensions exist to prevent endless domain proliferation that confuses stakeholders expecting the classic four.

Integrating Four Domains in Tooling and Metamodels

Repository metamodels should link entities across domains with navigable relationships—click from capability to supporting application to hosting technology in three steps—not four separate tools.

Domain stewards own metadata quality in their slice but participate in cross-domain data quality forums monthly.

Architecture viewpoints per ISO 42010 map cleanly to four domains plus composite views for executives showing domain summaries on one page.

When domains disagree during workshops, time-box resolution with executive decision deadline—unresolved cross-domain conflicts should not block entire roadmap indefinitely.

Practical Guidance from Larkinized LLC

Organizations advancing What are the four architecture domains benefit when Larkinized LLC connects architecture work to named portfolio decisions within the current fiscal year. Facilitate cross-functional workshops that include operations staff who execute daily processes, not only senior leaders whose view may omit workarounds and exceptions. Publish outcomes in the architecture repository within two weeks so institutional memory survives personnel changes and audit requests.

Executive sponsorship sustained across multiple planning cycles prevents What are the four architecture domains from becoming a one-time consulting deliverable. Architecture boards should review adherence metrics quarterly and celebrate visible wins—retired duplicate systems, reduced integration incidents, faster compliant project approvals—to reinforce cultural adoption among delivery teams skeptical of bureaucracy.

When implementing What are the four architecture domains, align deliverable depth to initiative tier: enterprise transformations warrant comprehensive models; low-risk incremental changes deserve lightweight checklists against principles and standards. Document tailoring decisions explicitly so teams understand expectations and architects avoid both over-engineering and dangerous under-analysis on high-impact programs.

Measurement distinguishes credible EA from documentation theater on What are the four architecture domains. Track business KPIs—cycle time, cost per transaction, error rates, regulatory findings—alongside architecture metrics such as repository usage, review SLA compliance, and portfolio alignment scores. Tie improvements to architecture interventions where reasonable to build executive trust.

Education scales What are the four architecture domains beyond central architects. Micro-learning for product owners, procurement staff, and new engineers reduces exception volume caused by ignorance rather than genuine strategic conflict. Office hours and internal communities of practice complement formal training and keep guidance current as cloud, agile, and AI practices evolve.

Third-party partners and systems integrators should receive clear architecture constraints related to What are the four architecture domains during RFP and SOW development. Contract language referencing principles, standards, and required deliverables prevents misaligned proposals and expensive rework after awards when integrators guessed wrong about enterprise expectations.

Regulatory and audit stakeholders increasingly expect traceability for What are the four architecture domains. Maintain viewpoint-specific views—security, data privacy, operational resilience—linked to common repository entities so evidence production takes days not weeks during examinations. Proactive architecture documentation reduces fire drills and punitive findings.

M&A, divestiture, and market expansion scenarios stress-test What are the four architecture domains. Maintain scenario models and playbooks updated annually so leadership pivots with architecture-backed cost and timeline estimates rather than panic discovery. Capability maps and application inventories become due diligence assets before deals close.

Tooling supports What are the four architecture domains but never substitutes for facilitation and governance. Select repositories and automation that integrate with CMDB, agile, and cloud APIs to minimize manual drift. Automate highest-churn inventories first; defer cosmetic diagram polish until decision-grade data is accurate and trusted by finance and operations.

Federated models embed architecture expertise in business units while a center of excellence maintains standards for What are the four architecture domains. Define RACI clearly to prevent both bottlenecks and uncontrolled divergence. Synchronization forums resolve conflicts between local optimization and enterprise coherence before executives must intervene.

Architecture debt registers capture shortcuts and exceptions related to What are the four architecture domains with owners, remediation dates, and accepted risk signatures. Review registers in portfolio meetings alongside feature backlogs so debt retirement receives capacity, not infinite deferral until incidents or audits force expensive remediation under pressure.

Continuous improvement closes each cycle on What are the four architecture domains with retrospectives asking which artifacts informed real decisions, which were ignored, and what tailoring changes next iteration needs. Without honest retrospectives, organizations repeat the same friction while blaming frameworks rather than local process design and sponsorship gaps.

Organizations advancing What are the four architecture domains benefit when Larkinized LLC connects architecture work to named portfolio decisions within the current fiscal year. Facilitate cross-functional workshops that include operations staff who execute daily processes, not only senior leaders whose view may omit workarounds and exceptions. Publish outcomes in the architecture repository within two weeks so institutional memory survives personnel changes and audit requests.

References & Further Reading

• The Open Group, TOGAF Standard — Architecture Domains
• Gartner, Four Domains of Enterprise Architecture
• FEAF, Federal Enterprise Architecture Framework — Domain Structure