1.4 The Context for Enterprise Architecture: Purpose, Capability, Security, and the Digital Enterprise

1.4 The Context for Enterprise Architecture: Purpose, Capability, Security, and the Digital Enterprise

"The Context for Enterprise Architecture" is the first Level 2 topic area for Part 2 of OGEA-103, and it frames how almost every scenario should be read. The Level 2 learning outcomes expect you to explain why Enterprise Architecture (EA) exists, what an EA actually looks like, what an Architecture Capability is, why several architecture states must be managed at once, why security is a cross-cutting concern, and how the Enterprise Architect's role changes in a digital enterprise. The main sources are the TOGAF Fundamental Content and two Series Guides in the Practitioner Body of Knowledge: A Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM and Using the TOGAF Standard in the Digital Enterprise.

---

Why Enterprise Architecture Exists: Guiding Effective Change

The Practitioner material puts it plainly: the purpose of Enterprise Architecture is to guide effective change. The Introduction and Core Concepts document adds that EA optimizes a fragmented legacy of manual and automated processes into an integrated environment that responds to change and supports the business strategy.

That framing matters in Part 2. An answer that produces impressive models but does not help a decision-maker choose, sequence, or govern change is weaker than one that delivers just enough architecture to support the decision at hand.

Four Purposes an Architecture Can Serve

The Practitioners' Approach guide describes developing architecture to support Strategy, Portfolio, Project, and Solution Delivery. Each purpose changes the breadth, depth, and timing of the work:

When a scenario tells you why the architecture is being developed, choose the answer whose depth matches that purpose. Detailed solution design in a strategy engagement is as wrong as a vague vision for a solution delivery team.

---

What an Enterprise Architecture Looks Like

An Enterprise Architecture is not one document. It is a landscape of related architecture descriptions, held in the Architecture Repository and organized by:

• Levels: Strategic, Segment, and Capability Architectures, each giving direction to the more detailed ones beneath it.
• Partitions: separately owned slices of the landscape, such as a business unit or a shared platform.
• States: the same scope described at different points in time.

Managing Multiple Architecture States

Practitioners must manage several states at once: candidate architectures still under discussion, the current (baseline) state, one or more transition states, and the target state. A Part 2 scenario might show a project designing against an out-of-date baseline, or two teams working from different targets. The better answers bring the states back under governance, by updating the Architecture Landscape and resolving which target is authoritative, before more design work proceeds.

The ADM Is Iterative

The ADM graphic reads like a waterfall, but the Practitioners' Approach guide uses a Gantt-chart example to show that ADM phases overlap, that many steps run at the same time, and that phases are revisited as information emerges. Expect scenario answers that "finish Phase B completely before starting anything else" to rank below answers that iterate sensibly.

---

The Architecture Capability and the Enterprise Architect

The Architecture Capability is the enterprise's ability to perform EA work: the organization, people, processes, governance, tools, and repository that the Preliminary Phase establishes. The TOGAF Standard's structure deliberately mirrors this capability, and the TOGAF Leader's Guide gives a path for establishing and evolving it.

The Introduction and Core Concepts document lists the kinds of EA services a capability can provide:

• Enterprise support services
• Design support services
• Development support services
• Requirements elicitation and understanding services
• Architecture planning services
• EA practice development support services

Architecture Governance keeps this capability effective: it ensures that architectures are developed, approved, and used to steer change. The Enterprise Architect leads and facilitates that work. The architect's job is to make sure decisions are informed by the architecture and governed against it, not to make every decision personally.

---

Security as a Cross-Cutting Concern

The Series Guide Integrating Risk and Security within a TOGAF Enterprise Architecture treats Enterprise Security Architecture as a concern that runs through every phase rather than a separate domain bolted on in Phase D. In practice:

• Security and risk appetite are considered when the Architecture Capability and principles are set in the Preliminary Phase.
• Phase A determines whether a security-specific architecture design is needed and how much is sufficient.
• Phases B to D address security in business processes, information classification, applications, and technology.
• Phases E to G carry security risks into migration planning and implementation governance.

A related Level 2 outcome is creating an environment in which the uncertainty of a change's success can be managed, to maximize business benefit and minimize business loss. That is the role of risk management, transition architectures that deliver value in steps, and governance checkpoints.

---

Enterprise Architecture in the Digital Enterprise

Using the TOGAF Standard in the Digital Enterprise draws on The Open Group's Digital Practitioner Body of Knowledge (DPBoK) Standard, which describes four contexts through which an organization evolves:

1. Individual/Founder: one person or a very small group delivering digital value.
2. Team: a single product team with shared practices.
3. Team of Teams: several teams whose work must be coordinated, partitioned, and kept coherent.
4. Enduring Enterprise: a large, long-lived organization that must steer, manage risk, and assure performance at scale.

The Enterprise Architect's role grows with each context. Formal EA adds little for a founder or a single team. It becomes essential once coordination across teams is needed, and in the Enduring Enterprise it underpins governance, portfolio decisions, and long-term coherence.

Architecture and Agile Delivery

The same guidance shows how architecture keeps agile work aligned with organizational objectives. The architecture supplies the context: the target, principles, constraints, and dependencies. Agile teams then make detailed decisions within that context and feed back what they learn. The strongest Part 2 answers rarely tell agile teams to stop and wait for a full architecture. They also rarely abandon architecture to let each team decide independently.

---

Applying the Context in Part 2

• Identify the purpose (strategy, portfolio, project, or solution delivery) and the level of the architecture before judging any answer.
• Prefer answers that keep candidate, baseline, transition, and target states governed and consistent.
• Treat security and risk as part of every phase, not as a final technical review.
• Match the amount of architecture to the enterprise's context, as the DPBoK contexts illustrate.