Core Concepts

Enterprise

In TOGAF, an enterprise is the scope being considered. It may be:

• an entire company;
• a government department;
• a business unit;
• a partnership or ecosystem;
• a product line;
• a transformation program; or
• any collection of organizations sharing goals.

Do not assume “enterprise” always means the whole legal organization. State the boundary explicitly.

Architecture

Architecture describes the fundamental organization of a subject, its elements and relationships, and the principles governing its design and evolution.

In practice, architecture is both:

• a description of a baseline, target, or transition state; and
• a discipline for making and governing consequential design decisions.

Enterprise Architecture

Enterprise Architecture connects goals and strategy to coordinated change across operating models, capabilities, people, information, applications, and technology.

It operates at several levels:

These levels should connect. Strategic architecture without delivery evidence becomes aspirational; solution architecture without strategic context becomes local optimization.

Stakeholders, concerns, views, and viewpoints

These four concepts prevent architecture from becoming a diagram collection:

• A stakeholder is a person, group, or organization with interests in the architecture.
• A concern is an issue important to one or more stakeholders, such as cost, resilience, compliance, usability, or time to market.
• A viewpoint defines the conventions for constructing and using a view. It says what the view should address and how.
• A view is the actual representation of a specific architecture from a viewpoint, created to address stakeholder concerns.

Example:

The rule is simple: create a view because it answers a decision-relevant question, not because a framework lists it.

Architecture description

An Architecture Description is the collection of work products used to express an architecture. It may contain models, principles, requirements, standards, decisions, roadmaps, and other content.

No single model describes the whole enterprise. Different views intentionally show different concerns.

Baseline, target, transition, and gap

• Baseline Architecture: the relevant current state, including already approved or in-flight change when appropriate.
• Target Architecture: the future state required to meet agreed objectives.
• Transition Architecture: a meaningful intermediate state between baseline and target.
• Gap: something present in one state but missing, changed, or retired in another.

Avoid documenting every current-state detail. Capture only what is needed to understand the change, risk, and decisions.

Requirements

Architecture requirements express what the architecture must enable, constrain, or satisfy. Good requirements are:

• linked to drivers, goals, stakeholders, and outcomes;
• testable or otherwise verifiable;
• prioritized;
• assigned an owner;
• traceable to architecture and implementation; and
• governed through change.

Requirements Management interacts with every ADM phase. New findings may create requirements; requirement changes may force architecture work to be revisited.

Principles

An architecture principle is a durable rule or guideline used to make consistent decisions. A useful format is:

1. Name — memorable and specific.
2. Statement — the rule.
3. Rationale — why the enterprise adopts it.
4. Implications — consequences, costs, and required behavior.

Principles should guide trade-offs. “Use best practices” is too vague to be a principle.

Building blocks

A building block is a potentially reusable component of business, architecture, or solution content.

• An Architecture Building Block (ABB) describes required capability or behavior without committing to a specific implementation.
• A Solution Building Block (SBB) describes an implementation that realizes one or more ABBs.

Example:

Keep the problem and required behavior separate from the chosen product long enough to evaluate alternatives.

Deliverables, artifacts, and building blocks

These terms are related but not interchangeable:

flowchart TD
    D[Deliverable<br/>reviewable contractual work product]
    A[Artifact<br/>catalog, matrix, or diagram]
    B[Building block<br/>reusable capability or component]
    D -->|contains| A
    A -->|describes| B

• A deliverable is a formally reviewed work product.
• An artifact is a representation of architecture information.
• A building block is the reusable subject represented by artifacts.

Architecture landscape

The Architecture Landscape gives an organized view of architecture assets at different levels and states. It commonly includes strategic, segment, and capability-level descriptions of baseline, transition, and target architectures.

Reference models and patterns

• A reference model supplies reusable concepts and relationships for a domain.
• A reference architecture applies patterns and principles to a recurring class of problem.
• A pattern is a reusable response to a recurring problem in context.

Use these as accelerators, not unquestioned answers.

Architecture debt

Architecture debt is the future cost or constraint created when implementation diverges from intended architecture or when the architecture itself becomes outdated. Record debt explicitly with:

• rationale;
• business impact;
• risk;
• owner;
• remediation trigger or due date; and
• accepted decision authority.

Fitness for purpose

TOGAF should be tailored. A fit-for-purpose architecture has enough detail to support the next important decisions—no more and no less. The appropriate depth depends on uncertainty, blast radius, reversibility, regulatory exposure, and investment size.

Next: Architecture Development Method