2.2 Scope of the Enterprise and Defining the Architecture Footprint

A frequent stumbling block for enterprise architecture initiatives is the ambiguity surrounding the term 'enterprise'. In everyday business parlance, an enterprise is assumed to denote an entire legal corporation or holding company. However, the TOGAF Standard 10th Edition provides a much more flexible and pragmatic definition:

Enterprise: Any collection of organizations that has a common set of goals.

Under this definition, an enterprise can be:

• An entire multinational corporation or conglomerate spanning diverse operating companies.
• A specific division, subsidiary, or line of business within a larger corporate structure (such as the wealth management division of a diversified financial institution).
• A single government department, municipal authority, or public sector agency.
• A joint venture, consortium, or public-private partnership operating toward a collective commercial objective.
• An extended enterprise, which encompasses the core company along with its critical suppliers, distribution partners, third-party logistics providers, and cloud service vendors.

The Four Architecture Scope Dimensions

When establishing the EA capability during the Preliminary Phase, the lead architect must explicitly calibrate boundaries across four interdependent dimensions. Failure to calibrate these dimensions will inevitably lead to architectural sprawl or irrelevance:

1. Breadth (Organizational Scope): Specifies which organizations, business units, and geographical entities fall within the capability's mandate. Does the architecture team govern all global operations, or is it initially restricted to North American retail operations and shared human resource platforms? Explicit breadth boundaries prevent scope creep and clarify which executive leaders hold stakeholder authority.

2. Depth (Level of Detail): Determines how detailed architectural descriptions must be. Does the team produce broad executive capability roadmaps, segment-level business integration architectures, or granular application interface and data schema specifications? Establishing depth limits prevents architects from drowning in low-level implementation details that are better left to engineering and delivery squads.

3. Time Period (Planning Horizons): Defines the planning windows governed by architecture artifacts. Typically, an architecture capability models three temporal perspectives: the Current Baseline Architecture (the present-day operating reality), the Target Architecture (the intended future state, often several years out), and intermediate Transition Architectures (stable plateaus that each deliver business value). Broader, less detailed architectures usually stay valid for longer periods than detailed ones.

4. Architecture Domains (BDAT Scope): Identifies which of the four core TOGAF architecture domains—Business Architecture, Data Architecture, Application Architecture, and Technology Architecture—are in scope. While mature practices address all four domains in an integrated manner, an initial EA capability may deliberately focus on Business and Technology domains to drive an executive cloud rationalization mandate, or Data and Application domains to support a customer relationship consolidation program.

Defining the Architecture Footprint

The architecture footprint represents the active boundary of business capabilities, applications, data entities, and infrastructure environments that fall under formal enterprise architecture governance. Defining this footprint is one of the most consequential decisions made in the Preliminary Phase.

Attempting to govern every system, database, spreadsheet, and business process across a global organization from day one is the most frequent cause of EA capability collapse—a failure mode universally recognized as 'boiling the ocean'. When an architecture team attempts universal coverage without adequate staffing or maturity, it generates massive delays, bureaucratic friction, and little actionable value.

Conversely, confining the architecture capability to a single, isolated software project creates an 'island of excellence'. While that individual project may succeed, the organization fails to achieve cross-departmental integration, technology rationalization, or strategic alignment.

To establish a viable architecture footprint, architects evaluate:

• Strategic Value and Criticality: Focus on core value streams and high-margin capabilities.
• Volume and Rate of Change: Prioritize business domains undergoing digital transformation or major market disruption.
• Architectural Maturity and Capacity: Align the footprint with the available skills, tooling, and governance bandwidth of the EA team.

Operating Models: Centralized, Federated, and Autonomous

How architectural authority is distributed across an organization dictates the structure of the EA capability:

For large, diversified organizations, the federated model is widely considered the industry best practice, allowing corporate architects to protect enterprise integrity while domain architects accelerate business delivery.

Levels and Partitions: Two Different Organizing Ideas

TOGAF uses two distinct concepts to keep a large Architecture Landscape manageable. Exam questions often test whether you can tell them apart.

Levels divide the landscape by granularity:

1. Strategic Architecture: an organizing framework for operational and change activity that supports direction setting at an executive level.
2. Segment Architecture: an organizing framework that supports direction setting and effective architecture roadmaps at a program or portfolio level.
3. Capability Architecture: an organizing framework for change activity and roadmaps that realize capability increments.

Broad, summary architectures set direction for narrower, more detailed ones. TOGAF describes two ways to develop architectures at different levels: iterate within a single ADM cycle, or run a hierarchy of ADM cycles concurrently. In practice architects blend the two.

Partitions divide the landscape into separately owned architectures. TOGAF gives three reasons to partition: organizational unit architectures conflict with one another; different teams need to work on different parts at the same time; and effective reuse needs modular architecture segments. Partitions are distinct from levels and from the Architecture Continuum, and TOGAF states that there is no definitive partitioning model: each enterprise adopts one that reflects its own operating model.

The classification criteria used to partition are:

In the Preliminary Phase the enterprise determines the organization structure for architecture, assigns responsibilities to each standing architecture team, and defines the relationships between architectures. The aim is for each partitioned architecture to have one owning team. Federated architectures are common in governments and conglomerates. Each is developed and governed separately and then integrated through agreed principles for interoperability, migration, and conformance, and through standards for content integration such as a shared process catalog.

Complex Scenarios: M&A, Subsidiaries, and Multinational Realities

Practitioners frequently encounter complex operating environments on the OGEA-103 examination:

• Mergers and Acquisitions (M&A): When two enterprises merge, the lead architect must rapidly establish an interim architecture footprint. The team categorizes acquired assets into three distinct postures: Immediate Absorption (migrating quickly onto parent platforms to capture synergies), Ring-Fenced Containment (allowing acquired systems to operate independently while building API bridges), or Selective Adoption (replacing parent legacy systems with superior acquired platforms as new enterprise standards).
• Multinational Subsidiaries & Regulatory Divergence: Global organizations must satisfy conflicting regional legal mandates—such as GDPR in the European Union, CCPA in California, and strict data residency laws in Switzerland or Singapore. In these contexts, the architecture footprint cannot enforce a monolithic data storage model. Instead, the federated EA model establishes a unified logical data architecture while permitting regional physical partitioning to maintain strict compliance.