8.1 ADM Guidelines & Techniques and Architecture Principles
Key Takeaways
- The ADM is supported by guidelines and techniques in ADM Techniques, TOGAF Series Guides, and the TOGAF Library, described separately so they can be referenced from relevant ADM points.
- TOGAF defines an Architecture Principle as a qualitative statement of intent that should be met by the architecture.
- The recommended template for an Architecture Principle has four parts: Name, Statement, Rationale, and Implications.
- Rationale highlights the business benefits of a principle, while Implications highlight the business and IT requirements in resources, costs, and activities.
- TOGAF's five criteria for a good set of principles are Understandable, Robust, Complete, Consistent, and Stable.
8.1 ADM Guidelines & Techniques and Architecture Principles
"Introduction to ADM Techniques" is worth 6 of 40 questions. This section covers four learning outcomes: briefly describe how the ADM and the supporting guidelines and techniques relate, explain the purpose of Architecture Principles, explain the recommended template, and explain what makes a good Architecture Principle.
How the ADM and Supporting Guidelines and Techniques Relate
The ADM describes what needs to be done. The application of the ADM is supported by an extended set of resources — guidelines, templates, checklists, and other detailed materials — found in:
- The TOGAF Standard — ADM Techniques (Fundamental Content)
- TOGAF Series Guides — the guidance part of the standard, on how to use and adapt the TOGAF Standard for specific needs
- White Papers and Guides published by The Open Group and classified in the TOGAF Library
The individual guidelines and techniques are described separately so they can be referenced from the relevant points in the ADM as necessary, rather than cluttering the description of the ADM itself. The Applying the ADM document separately gives guidelines for adapting the ADM to different architecture styles and practical contexts.
| ADM Techniques document chapter | Typical ADM use |
|---|---|
| Architecture Principles | Preliminary Phase and Phase A; applied throughout |
| Stakeholder Management | Phase A and ongoing communication |
| Architecture Patterns | Selecting reference models and patterns in Phases B–D |
| Gap Analysis | Phases B, C, D, and E |
| Migration Planning Techniques | Phases E and F |
| Interoperability Requirements | Phases A through F, especially E |
| Business Transformation Readiness Assessment | Phase A, E, and F |
| Risk Management | Phase A onward, monitored in Phase G |
| Architecture Alternatives and Trade-Offs | Any phase at any level |
The business scenarios technique is described in the TOGAF Series Guide: Business Scenarios (Section 8.2).
What Architecture Principles Are
The TOGAF Standard describes principles as "general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission." The glossary defines an Architecture Principle as "a qualitative statement of intent that should be met by the architecture."
Two key domains of principle inform architecture:
| Principle type | Purpose |
|---|---|
| Enterprise Principles | Provide a basis for decision-making throughout an enterprise and inform how the organization sets about fulfilling its mission; they harmonize decision-making and are a key element of a successful Architecture Governance strategy. Subsidiary principles may exist within business or organizational units, such as IT or HR |
| Architecture Principles | A set of principles that relate to architecture work. They reflect a level of consensus across the enterprise, embody the spirit and thinking of existing Enterprise Principles, and govern the architecture process — affecting the development, maintenance, and use of the Enterprise Architecture |
The hierarchy starts with Enterprise Principles; subsidiary principles must exist within the bounds of those above them. Each Architecture Principle should be clearly related back to business objectives and key architecture drivers.
The Purpose of Architecture Principles
Architecture Principles define the underlying general rules and guidelines for the use and deployment of all resources and assets across the enterprise, and form the basis for making future architecture decisions. In practice they:
- Provide a framework for making conscious decisions about the Enterprise Architecture and architecture projects
- Act as a guide to establishing relevant evaluation criteria, influencing product and solution selection
- Serve as drivers for requirements
- Provide input to assessing existing implementations and the strategic portfolio for compliance
- Support architecture governance activities, including compliance reviews and dispensations
Principles are developed in the Preliminary Phase and confirmed and elaborated in Phase A (the step "Confirm and Elaborate Architecture Principles, including Business Principles"). They are typically developed by the lead architect together with the CIO, the Architecture Board, and other key business stakeholders.
The Recommended Template for Principles
TOGAF recommends a four-part format:
| Component | Guidance from the TOGAF Standard |
|---|---|
| Name | Should both represent the essence of the rule and be easy to remember. Specific technology platforms should not be mentioned in the name or statement. Avoid ambiguous words such as "support," "open," and "consider," be careful with "manage(ment)," and look for unnecessary adjectives and adverbs |
| Statement | Should succinctly and unambiguously communicate the fundamental rule |
| Rationale | Should highlight the business benefits of adhering to the principle, using business terminology; describe the relationship to other principles and when one principle would take precedence over another |
| Implications | Should highlight the requirements, both for the business and IT, for carrying out the principle — in terms of resources, costs, and activities or tasks. The reader should be able to answer "How does this affect me?" |
What Makes a Good Principle: Five Criteria
| Criterion | Meaning in the TOGAF Standard |
|---|---|
| Understandable | The underlying tenets can be quickly grasped and understood by individuals throughout the organization; the intention is clear and unambiguous, so violations, whether intentional or not, are minimized |
| Robust | Enables good-quality decisions about architectures and plans, and enforceable policies and standards; each principle is sufficiently definitive and precise to support consistent decision-making in complex, potentially controversial situations |
| Complete | Every potentially important principle governing the management of information and technology for the organization is defined; the principles cover every situation perceived |
| Consistent | Strict adherence to one principle may require a loose interpretation of another, so the set must allow a balance of interpretations; principles should not be contradictory to the point where adhering to one would violate the spirit of another |
| Stable | Principles should be enduring, yet able to accommodate changes; an amendment process should be established for adding, removing, or altering principles after they are ratified |
A useful memory aid is "U R C C S": Understandable, Robust, Complete, Consistent, Stable.
Worked Examples
TOGAF's example principle set includes business principles (such as "Primacy of Principles," "Maximize Benefit to the Enterprise," and "Common Use Applications"), data principles (such as "Data is an Asset," "Data is Shared," and "Data Security"), application principles (such as "Technology Independence" and "Ease-of-Use"), and technology principles (such as "Requirements-Based Change," "Control Technical Diversity," and "Interoperability"). The two examples below use illustrative wording to show how the template is filled in; they are not quotations of TOGAF's sample text.
Example 1: Data is an Asset
| Template Section | Specification |
|---|---|
| Name | Data is an Asset |
| Statement | Data is a valuable enterprise asset that possesses recognized value, is owned by the enterprise rather than individual departments, and shall be managed across its entire lifecycle. |
| Rationale | Accurate, timely, and integrated data is foundational to executive decision-making, customer personalization, operational efficiency, and regulatory compliance. Managing data as an enterprise asset unifies fragmented information silos, prevents redundant data gathering, and unlocks cross-functional analytics. |
| Implications | • Business units must relinquish proprietary ownership of departmental databases.<br/>• Data stewards and formal data governance roles must be funded and appointed across all business domains.<br/>• Enterprise data standards, master data management (MDM) repositories, and common data definitions must be adopted.<br/>• Investments are required for data cleansing, automated lineage tracking, and metadata cataloging platforms. |
Example 2: Common Use Applications
| Template Section | Specification |
|---|---|
| Name | Common Use Applications |
| Statement | Application capabilities that fulfill standard business needs across multiple business units shall be shared and utilized enterprise-wide rather than duplicated within individual divisions. |
| Rationale | Deploying duplicate applications performing identical functions (e.g., multiple disparate billing engines, CRM instances, or HR portals) inflates software licensing expenditures, multiplies infrastructure footprints, and fragments user workflows. Shared applications streamline enterprise operations and lower total cost of ownership (TCO). |
| Implications | • Business units must accept common application feature roadmaps and standardized user interfaces.<br/>• Cross-charging, operational service level agreements (SLAs), and shared governance funding models must be established.<br/>• Decentralized IT budgets must be consolidated or realigned to support shared enterprise platforms.<br/>• Legacy redundant applications must be systematically scheduled for decommissioning. |
Common Exam Pitfalls
- Swapping Rationale and Implications. Rationale gives the business benefits; Implications give the requirements for business and IT in resources, costs, and activities.
- Putting technology products in the Name or Statement. TOGAF advises against naming specific technology platforms.
- Misreading "Complete." Complete means every potentially important principle is defined and every perceived situation is covered.
- Thinking principles never change. Stable principles are enduring but can be amended through an established amendment process.
Why does the TOGAF Standard describe supporting guidelines and techniques separately from the ADM?
Which part of the recommended principle template should highlight the requirements, both for the business and IT, for carrying out the principle in terms of resources, costs, and activities?
A principle set is written so that strict adherence to one principle may require loose interpretation of another, but none contradicts another to the point of violating its spirit. Which quality criterion does this describe?
Which statement best describes the purpose of Architecture Principles?