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

Larkinized LLC facilitates cross-domain workshops tracing one strategic initiative through business, data, application, and technology quadrants so sponsors see hidden dependencies before funding locks. These workshops prevent CRM replacement programs that ignore master data remediation until go-live crises.

Domain stewards own metadata quality with monthly cross-domain forums resolving conflicts—data definitions versus application interfaces versus platform constraints. Without forums, domains optimize locally and enterprise incoherence returns within two planning cycles.

Heat maps per domain guide investment: business architecture maturity may lag while technology standards excel—targeted hiring and tooling follow assessment rather than generic EA expansion. Executives prefer honest uneven maturity over uniform maturity claims unsupported by evidence.

Traceability matrices linking capability to application to data entity to hosting platform are high-value deliverables—click three times in repository to answer impact questions. Larkinized LLC automates matrix generation where possible to avoid manual spreadsheet decay.

Extensions beyond four domains—security, experience—require documented rationale so stakeholders understand why classic taxonomy expanded. Prevent domain proliferation that confuses executives expecting business-data-application-technology language.

Training paths specialize after foundational literacy—data architects deep on governance, application architects on integration patterns—while enterprise architects maintain cross-domain coherence in boards and roadmaps.

Larkinized LLC connects guidance on what are the four architecture domains to named portfolio decisions within the current fiscal year so architecture work is legible in funding systems executives already use. Workshop outputs publish to the repository within two weeks with owners assigned, preventing loss of context when facilitators rotate or consultants depart after initial engagement.

Cross-functional participation includes operations staff who execute daily processes—not only senior leaders whose high-level views omit workarounds that define real performance. Their input grounds models in operational truth and reduces downstream rejection when delivery teams claim architecture ignored how work actually happens.

Education scales beyond central architects through micro-learning for product owners, procurement staff, and engineers, reducing exceptions driven by ignorance rather than genuine strategic conflict. Office hours and internal communities of practice keep guidance current as cloud, agile, and AI practices evolve faster than annual training cycles.

Measurement pairs business KPIs—cycle time, cost per transaction, error rates, regulatory findings—with architecture metrics such as repository usage, review SLA compliance, and portfolio alignment scores. Improvements tied to architecture interventions build executive trust more reliably than model counts alone.

Regulatory and audit stakeholders increasingly expect traceability; viewpoint-specific views linked to repository entities produce evidence in days rather than weeks during examinations. Proactive documentation reduces fire drills, punitive findings, and leadership distraction from core transformation priorities.

M&A, divestiture, and market expansion stress-test architecture assets—scenario playbooks updated annually let leadership pivot with cost and timeline estimates instead of panic discovery after announcements. Capability maps and application inventories become due diligence assets before deals close, not afterthought spreadsheets.

Governance forums for what are the four architecture domains should meet on a predictable cadence tied to portfolio and release planning—not ad hoc when crises force attention. Larkinized LLC recommends standing architecture review slots with published intake criteria, SLA targets, and escalation paths so delivery teams know how to engage without treating architecture as unpredictable gatekeeping that rewards political access over merit of design.

Traceability from strategy statements to capability or architecture elements to funded initiatives to deployed solutions closes the loop executives expect when they approve EA funding. Without traceability, architecture remains a parallel documentation universe. Link charters, requirements, design records, and operational inventories in one searchable repository so auditors, product managers, and engineers retrieve consistent answers instead of conflicting spreadsheets maintained in silos.

Risk management benefits when what are the four architecture domains practices identify concentration risks—single vendor platforms, fragile integrations, key-person dependencies, regions without failover—and map mitigations into migration plans with owners and dates. Risk registers integrated with architecture repositories beat oral tradition during incidents when leadership demands answers within hours and teams cannot afford heroic manual discovery across dozens of systems.

Innovation programs need explicit guardrails within what are the four architecture domains so experiments proceed safely: sandbox environments, data masking rules, time-boxed pilots, and kill criteria before production commitments. Architecture enables innovation velocity by stating what teams may try without enterprise approval versus what requires board-level review because customer data, financial reporting, or safety-critical operations are affected.

Global enterprises localizing what are the four architecture domains should tier standards: mandatory worldwide, recommended regional, optional local—documented in governance charters to prevent both harmful divergence and rejection of valid regional regulatory requirements. Regional architects on a council synchronize proposals before they become de facto standards that conflict with enterprise principles approved by executive sponsors accountable to the board.

Quality assurance for architecture artifacts includes peer review, automated validation where schemas exist, and executive readability checks before publication. Larkinized LLC teaches teams to reject diagrams that look complete but lack definitions, owners, and measures—hallmarks of documentation theater that erodes trust faster than publishing fewer, higher-quality views updated on schedule.

Stakeholder onboarding for what are the four architecture domains never ends; annual refreshers for new leaders, rotating product managers, and engineers hired from acquisitions prevent repeated violations caused by ignorance rather than defiance. Micro-learning, office hours, and annotated examples in repositories scale literacy without requiring week-long courses that busy executives and engineers will not attend consistently.

Ultimately what are the four architecture domains succeeds when leaders reference architecture evidence in routine decisions—funding, hiring, vendor selection, incident response—not only during transformations. Larkinized LLC measures cultural adoption through decision log sampling: what percentage of major investments cited architecture assets in approval packets last quarter? Rising percentages indicate durability; flat or falling percentages signal sponsorship or relevance problems requiring honest retrospective, not additional templates.

References & Further Reading

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