12.4 Architecture Principles, the Decision Log, and Resolving Principle Conflicts

12.4 Architecture Principles, the Decision Log, and Resolving Principle Conflicts

Architecture Principles are the first technique in TOGAF's ADM Techniques document, and they recur across the exam. They are established in the Preliminary Phase, confirmed and elaborated in Phase A, used to guide design in Phases B to D, and applied as criteria in compliance reviews and change decisions. Part 2 scenarios often present two stakeholders who each cite a valid principle. You need to know how TOGAF expects principles to be written, applied, traded off, and recorded.

---

What Principles Are

TOGAF describes principles as general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way an organization fulfills its mission. Principles can exist at different levels:

• Enterprise principles provide a basis for decision-making throughout the enterprise and inform how the organization sets about fulfilling its mission.
• Architecture principles govern the architecture process and the implementation of the architecture. They should be consistent with, and build on, the enterprise principles.

The TOGAF Enterprise Metamodel defines a Principle as a qualitative statement of intent that should be met by the architecture, with at least a supporting rationale and a measure of importance.

The Standard Template

Every TOGAF principle has four components:

A principle without its implications is incomplete: the implications show what following the principle will cost and what has to change.

Qualities of Good Principles

TOGAF lists five criteria for a good set of principles:

1. Understandable: quickly grasped by people across the organization, with the intent clear and unambiguous.
2. Robust: support good-quality decisions about architectures and plans, and enforceable policies and standards; each principle is precise enough for consistent decisions in complex situations.
3. Complete: every potentially important principle governing the management of information and technology is defined; the set covers every situation perceived.
4. Consistent: strict adherence to one principle may require loose interpretation of another; the set must be expressed so that a balance of interpretations is possible, and principles should not be contradictory.
5. Stable: enduring, yet able to accommodate changes through an amendment process established when the principles are first approved.

TOGAF's Example Principles

TOGAF provides 21 example principles that organizations adapt:

• Business principles (1 to 9): Primacy of Principles; Maximize Benefit to the Enterprise; Information Management is Everybody's Business; Business Continuity; Common Use Applications; Service Orientation; Compliance with Law; IT Responsibility; Protection of Intellectual Property.
• Data principles (10 to 15): Data is an Asset; Data is Shared; Data is Accessible; Data Trustee; Common Vocabulary and Data Definitions; Data Security.
• Application principles (16 to 17): Technology Independence; Ease-of-Use.
• Technology principles (18 to 21): Requirements-Based Change; Responsive Change Management; Control Technical Diversity; Interoperability.

Primacy of Principles states that the principles apply to all organizations within the enterprise. It is what gives the rest of the set its force.

---

Developing and Governing Principles

Principles are typically developed by the Enterprise Architects together with key stakeholders and are approved by the Architecture Board. In the Preliminary Phase the enterprise defines its Architecture Principles as part of establishing the Architecture Capability. In Phase A, step 7 confirms and elaborates them for the engagement, including business principles. If they are missing or ambiguous, the team goes back to the body responsible for governance to define and endorse them. TOGAF notes that one of three key elements of an effective governance strategy is "a comprehensive set of Architecture Principles", alongside a cross-organizational Architecture Board and an Architecture Compliance strategy.

---

When Principles Compete

TOGAF expects principles to be applied as a set, and it acknowledges that they will sometimes compete: accessibility and security, for example, tend toward conflicting decisions. Its guidance is that:

• Each principle is considered in the context of "all other things being equal".
• At times a decision is needed about which principle takes precedence on a particular issue.
• The rationale for such decisions should always be documented.

In practice, a sound resolution sequence is:

1. Re-read both principles' rationale and implications. The rationale often shows which business outcome is really at stake in this context.
2. Look for an alternative that honors both, using the Architecture Alternatives and Trade-offs technique (Section 8.4). For example, tiered authentication can give low-risk transactions an easy path and high-risk ones strong controls.
3. Escalate through governance if stakeholders cannot agree. The Architecture Board provides a visible escalation route for out-of-bounds decisions and resolves escalated conflicts.
4. Record the decision and its rationale so later teams understand the precedent.
5. If the same conflict keeps recurring, review the principle itself through the amendment process rather than granting endless exceptions.

Numbering does not settle conflicts. Principle 1 does not automatically outrank Principle 18; precedence is decided per issue, and the reasoning is recorded.

---

Recording Decisions in the Governance Repository

In the TOGAF 10 Architecture Repository, the Governance Repository holds shared information about the ongoing governance of projects. TOGAF explains why: decisions such as standards deviations, or the rationale for a particular architectural approach, are important to retain. If a system is later replaced, the key decisions that shaped it reveal constraints that might otherwise be obscured.

Its first component is the Decision Log, a log of all architecturally significant decisions, typically including:

• Product selections
• Justification for major architectural features of projects
• Standards deviations
• Standards lifecycle changes
• Change Request evaluations and approvals
• Re-use assessments

The Governance Repository also holds Compliance Assessments, Capability Assessments, a Calendar of projects and reviews, the Project Portfolio under governance, and Performance Measurement for the architecture function. TOGAF notes that Architecture Board minutes are often kept in separate documentation archives, outside the repository, for legal or regulatory reasons.

Architecture Decision Records as a Format

Many teams write decision log entries as Architecture Decision Records (ADRs). This is a lightweight format popularized outside TOGAF that records the context, the decision, and its consequences. An ADR is never edited after acceptance; it is superseded by a new one. ADRs fit well as entries in TOGAF's decision log, but TOGAF itself does not define them. On the exam, the TOGAF terms are the Decision Log and the Governance Repository.