1.3 Enterprise Architecture in Practice: Context, Scope, and Architecture Domains

1.3 Enterprise Architecture in Practice: Context, Scope, and Architecture Domains

Enterprise Architecture (EA) is a strategic management discipline that translates business strategy into effective technical execution. Its primary objective is to optimize an organization's fragmented legacy of manual and automated processes into an integrated, change-responsive environment. To manage complexity across diverse organizational ecosystems, TOGAF structures architectural practice across four interconnected domains—Business, Data, Application, and Technology (BDAT)—while requiring architects to define boundaries across four essential scoping dimensions.

---

The Four Architecture Domains (BDAT)

The TOGAF Standard divides enterprise architecture into four foundational domains. These domains do not function as isolated silos; they represent integrated layers of organizational capability:

1. Business Architecture (Phase B)

Business Architecture is the anchor domain that guides all downstream technology decisions. It defines business strategy, governance, organizational structures, business capabilities, value streams, and critical business processes. In the TOGAF ADM, Business Architecture is developed first (Phase B) because technical systems cannot be meaningfully specified without first understanding the business outcomes they must deliver.

Key Business Architecture artifacts include:

• Business Capability Maps: Hierarchical catalogs of what an enterprise does to create value, independent of how or by whom it is executed.
• Value Stream Maps: End-to-end representations of how an organization delivers value to customers, from initial trigger to value realization.
• Organization Maps: Models defining business units, functional roles, and partner relationships.

2. Data Architecture (Phase C)

Data Architecture describes the structure of an organization's logical and physical data assets and data management resources. It governs how information is organized, stored, secured, and shared across systems. In modern data-driven enterprises, Data Architecture establishes master data models, metadata schemas, and data governance policies.

Key Data Architecture artifacts include:

• Conceptual, Logical, and Physical Data Models
• Data Entity / Business Function Matrices
• Data Dissemination and Data Lifecycle Diagrams

3. Application Architecture (Phase C)

Application Architecture provides a blueprint for individual applications, their interactions, and their alignment with core business processes. Rather than designing internal software code, it defines application boundaries, logical services, integration APIs, and application portfolio rationalization.

Key Application Architecture artifacts include:

• Application Portfolio Catalogs
• Application / Function Matrices
• Application Communication and Interface Diagrams

4. Technology Architecture (Phase D)

Technology Architecture defines the infrastructure platforms and technologies required to support business, data, and application services. It encompasses cloud infrastructure (IaaS/PaaS), on-premises compute, storage networks, operating environments, virtualization layers, and telecommunications networks.

Key Technology Architecture artifacts include:

• Technology Standards Catalogs
• Platform Decomposition Diagrams
• Network and Environments Diagrams

---

Interplay and Bidirectional Alignment

While the ADM follows a sequential progression from Business (Phase B) to Technology (Phase D), enterprise architecture operates bidirectionally in practice:

• Top-Down Strategic Realization: Executive business vision drives capability requirements, which dictate application services and data models, which in turn define infrastructure specifications.
• Bottom-Up Technological Enablement: Innovations in infrastructure (such as edge computing, machine learning platforms, or serverless models) create opportunities to invent new business capabilities and business models that executives previously could not conceive.

---

Defining Enterprise Context and Organizational Boundaries

A critical task in the Preliminary Phase and Phase A is establishing the precise boundaries of the enterprise undergoing architecture work. Organizations often attempt to model the entire corporation at once—a pitfall known as "boiling the ocean." The TOGAF Standard clarifies that an enterprise can be scoped down to an operating unit, a shared service department, or a supply chain network, provided it has:

• Common strategic business goals
• Clear administrative and budgetary authority to execute architecture decisions
• Defined interfaces with external systems and organizations

---

The Four Dimensions of Architecture Scoping

To ensure initiatives remain achievable and aligned with stakeholder commitments, TOGAF defines four dimensions of architecture scope, agreed in Phase A and recorded in the Statement of Architecture Work:

---

Architecture Operating Models & Team Structures

Organizations structure their enterprise architecture practices using different operating models based on size and governance maturity:

• Centralized Model: A single enterprise architecture office defines all standards, creates all architectures, and reviews all projects. While this ensures high consistency and reduces duplicative spending, it often creates bottlenecks that delay agile teams.
• Decentralized (Siloed) Model: Independent architects report exclusively to business unit managers. This provides high responsiveness to local business needs, but leads to duplicated software, fragmented data silos, and technical debt.
• Federated Model: Combines the strengths of both models. TOGAF notes that large enterprises such as governments and conglomerates typically use federated architectures, integrated through common principles for interoperability and conformance. A central Enterprise Architecture Office establishes overarching principles, core standards, repository structures, and governance rules. Embedded domain architects work directly within business units and agile teams, designing solutions within enterprise guardrails.

---

Governance Oversight: The Architecture Board

Architecture practices require governance to ensure adherence to standards. The Architecture Board is a cross-functional governing body comprising business leaders, technology executives, and lead architects. Key responsibilities include:

• Reviewing and approving Architecture Contracts
• Conducting Architecture Compliance Reviews at major delivery milestones
• Adjudicating principle conflicts between business units
• Granting formal, time-limited Architecture Dispensations when projects cannot comply with standards due to exceptional business constraints

---

Architecture Anti-Patterns in Practice

• Ivory Tower Architecture: Producing elaborate conceptual models that ignore the practical constraints of software development and operations teams.
• Boiling the Ocean: Attempting to document 100% of baseline systems before making strategic decisions. Baseline modeling should only proceed to the depth needed to identify gaps and guide target state decisions.
• Bypassing Business Architecture: Jumping directly from a technology mandate (such as cloud migration) into Phase D infrastructure design without first evaluating business capabilities, value streams, or organizational readiness.