How to Differentiate TOGAF® Architecture Definition Document (ADD) and Architecture Requirements Specification (ARS) in Practice

Why This Distinction Matters in SAP and PLM Programs

For Enterprise Architects implementing SAP and PLM, proceeding without a clear distinction between the Architecture Definition Document (ADD) and the Architecture Requirements Specification (ARS) often leads to failure in implementation decisions and governance—even if the conceptual vision appears solid.

In TOGAF®, the ADD is positioned as the core document that expresses architectural intent and structure, while the ARS defines measurable requirements that must be satisfied during implementation.
Source: https://pubs.opengroup.org/architecture/togaf90-doc/epf/TOGAF9/workproducts/Architecture%20Requirements%20Specification_FCE52369.html

This separation becomes especially critical in Tier 1 automotive suppliers integrating SAP and PLM. In areas such as product change management, BOM alignment, engineering change control, production ramp-up, and cost visibility, mixing “vision” and “acceptance criteria” leads to misaligned expectations across departments.

---

Key Differences Between ADD and ARS

According to TOGAF®, the Architecture Definition Document is described as a deliverable container that consolidates core architectural artifacts produced during a project. It provides a qualitative view of the solution and communicates the architects’ intent.
Source: https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf

In contrast, the Architecture Requirements Specification provides a quantitative view, defining measurable criteria that must be met during implementation.

Put simply:

• ADD describes what the architecture should look like (business, data, application, technology).
• ARS defines what conditions must be met for the implementation to be accepted.

In practice:

• ADD alone enables shared understanding but leaves ambiguity in execution.
• ARS alone provides detailed requirements but lacks context and rationale.

Both are essential, and neither is sufficient on its own.

---

Relationship Between ADD and ARS

ADD and ARS are not competing documents—they are complementary.

• ADD defines architecture vision, scope, baseline, target, transitions, and cross-domain consistency.
• ARS translates these into testable and verifiable requirements for implementation, migration, and operations.

A practical way to understand this is:

• ADD = Blueprint
• ARS = Acceptance Criteria

Example:

If ADD states:
“PLM will be the system of record for product design data, and SAP will serve as the core execution ERP.”

Then ARS must specify:

• Which attributes belong to which system of record
• Acceptable synchronization latency (e.g., within X hours)
• Audit trail retention requirements
• Data consistency thresholds

Without ARS, the principle remains abstract and unenforceable.

---

How They Are Used in the ADM

Within TOGAF® ADM:

• ADD evolves across phases starting from Architecture Vision, accumulating outputs from:
  • Business Architecture
  • Information Systems Architecture
  • Technology Architecture

It becomes the foundation for:

• Opportunities & Solutions
• Migration Planning
• Governance decisions

Source: https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf

ARS operates across Requirements Management and all ADM phases:

• Captures and refines requirements in measurable form
• Supports:
  • Phases B–D: Architecture definition
  • Phases E–F: Work packages and migration planning
  • Phase G: Implementation governance and compliance

ARS serves as a continuous decision baseline throughout the lifecycle.

From an Enterprise Architect’s perspective:

• ADD is strong for stakeholder alignment
• ARS is strong for project control, procurement, acceptance, and governance

Maintaining both separately ensures flexibility in design while eliminating ambiguity in execution.

---

Tier 1 Automotive Supplier Example (SAP + PLM)

In a Tier 1 automotive context, ADD should define scope and principles such as:

• PLM as the origin of engineering changes
• SAP as the execution platform for procurement, production, inventory, costing, and finance
• Controlled transformation from Engineering BOM to Manufacturing BOM

ADD also captures:

• Business capabilities: ECR/ECO management, prototype-to-mass transition, customer-specific configuration, supplier collaboration, quality traceability
• Application roles: PLM, SAP, MES, EDI, quality systems
• Data ownership: material master, BOM, routing, drawings, change history, supplier data

Source: https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf

ARS then translates these into measurable requirements, such as:

• ECO changes reflected in SAP within 48 hours
• Master data consistency ≥ 98%
• PLM-SAP integration availability ≥ 99.5%
• Audit logs retained for 7 years
• Controls to prevent obsolete BOM usage during production transition

This structure ensures:

• ADD explains why the architecture is designed this way
• ARS defines how to verify that it works

This is particularly critical in global deployments and OEM-specific requirements.

---

Key TOGAF® Quotes to Remember

The following three statements capture the essence of ADD vs ARS:

• “The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project and for important related information.”
• “The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architects.”
• “The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture.”

Together, they clearly define the division of responsibility.

---

Design Review Checklist

When reviewing ADD and ARS in SAP and PLM programs, ensure:

• ADD includes scope, principles, baseline, target, transition, and clear responsibility boundaries
• ARS defines measurable criteria for performance, availability, data quality, auditability, security, integration, and operations
• Traceability exists from ADD design intent to ARS requirements
• Change management processes update both ADD and ARS consistently

This approach shifts focus from “document creation” to improving translation accuracy from architecture to implementation.

---

Conclusion

In TOGAF-based enterprise architecture, separating ADD and ARS is not just a documentation practice—it is a governance strategy.

• ADD ensures architectural coherence and shared vision
• ARS ensures implementation clarity and enforceability

For SAP and PLM programs in complex manufacturing environments, managing both in tandem significantly increases the probability of success.

---

Reference Links

Official TOGAF® Sources

• Architecture Definition Document
  TOGAF® Standard — Deliverable: Architecture Definition Document[pubs.opengroup]
• Architecture Requirements Specification
  TOGAF® Standard — Deliverable: Architecture Requirements Specification[pubs.opengroup]
• ADM Overview
  TOGAF® ADM Phase Overview[togaf]

English Reference Links

• TOGAF Architecture Content Framework overview
  Visual Paradigm: Understanding the Architecture Content Framework in TOGAF[guides.visual-paradigm]
• TOGAF requirements specification article
  CyberMedian: TOGAF ADM Phase B — Architecture Requirements Specification[cybermedian]
• TOGAF overview
  LeanIX: What is TOGAF?[leanix]

---

Disclaimer

Parts of this article were developed with reference to generative AI suggestions and were reviewed, refined, and supplemented based on the author’s professional expertise and judgment.

---

Back to Top