SAP Implementation Risk: Why Skipping the Statement of Architecture Work Is Dangerous

Introduction

In SAP implementation projects such as SAP S/4HANA, attention often centers on requirements definition and Fit-to-Standard workshops.

However, from an enterprise architect’s perspective, it is critically important to formally agree—before all that—on how far and in what way architecture work will be carried out in the project.

In TOGAF®, this role is fulfilled by the “Statement of Architecture Work (SoAW).”

This article explains what SoAW is, where it is created in the ADM, and how it can be effectively used in SAP implementation projects.

---

What Is SoAW? The “Contract” for Architecture Work

According to TOGAF®, the Statement of Architecture Work defines the scope and approach used to complete an architecture project. It also serves as a basis for success criteria and contractual agreement.

In simple terms, SoAW clarifies:

• What is in scope
• How deep the work goes
• What approach will be used
• Who is responsible for what
• What deliverables will be produced
• What defines “completion”

Rather than just a descriptive document, SoAW functions as a formal agreement that authorizes architecture work at an organizational level.

Reference:
https://www.linkedin.com/posts/clicksavvy4results_enterprise-architecture-domain-knowledge-activity-7379442575952232448-6q73

---

Where SoAW Fits in ADM: Locking Scope in Phase A

SoAW is created and agreed upon in Phase A (Architecture Vision) of the TOGAF ADM.

After setting up EA capabilities in the Preliminary Phase (principles, metamodels, repositories), Phase A begins when a concrete SAP project is initiated. Key activities include:

• Defining the transformation vision
• Identifying stakeholders and concerns
• Assessing risks and constraints
• Consolidating all of the above into the SoAW

Once SoAW is agreed, it defines the boundaries for subsequent phases (Business, Information Systems, Technology Architecture).

This prevents a common issue: architecture work expanding uncontrollably without clear limits.

---

Where SoAW Adds Value in SAP Projects

From an enterprise architect’s perspective, SoAW is particularly effective in three areas:

1. Clarifying Scope in SAP Terms

Define scope in SAP-relevant language:

• Target systems: SAP S/4HANA core, BW/4HANA, BTP, Ariba, non-SAP systems, data lakes, audit systems
• Domains and depth:
  • Business processes: how far to standardize (e.g., Order-to-Cash, Procure-to-Pay)
  • Data: enterprise-level structure for master and transaction data
  • Applications/integration: level of EA review (interface method vs message structure)
  • Technology: inclusion of cloud, network, security zoning principles

Without this clarity, projects often swing between extremes—either overloading EA teams or excluding them from critical decisions.

---

2. Embedding EA Governance into the Project Plan

SoAW should include governance elements such as:

• Framework alignment: SAP Activate with TOGAF ADM
• Standards alignment: SAP best practices vs enterprise architecture principles
• Review gates:
  • Post Fit-to-Standard solution review
  • Architecture compliance checks
  • Pre-cutover validation
• Decision-making structure:
  • Who approves exceptions
  • How trade-offs between cost, schedule, and architecture quality are handled

This ensures EA is part of the project—not an afterthought.

---

3. Visualizing Roles and Deliverables with RACI

SoAW should clearly define responsibilities and deliverables.

Example:

• Enterprise Architect: To-be process architecture, system landscape principles
• SAP Solution Architect: S/4HANA configuration and GAP design
• Integration Architect: Interface patterns, API strategy
• Security Architect: Roles, authorization, audit compliance

Use RACI (Responsible, Accountable, Consulted, Informed) to define ownership.

This prevents ambiguity and reduces burnout by separating ownership from review responsibilities.

---

A Practical First Step: Start Small

Introducing SoAW doesn’t require a full TOGAF rollout.

A minimal version can include:

• Project background and objectives
• Architecture scope (domain, depth, timeline)
• Key deliverables and RACI
• Review gates and approval process

Even this lightweight version significantly reduces risk and clarifies expectations.

Over time, it can evolve into a full TOGAF-aligned SoAW.

---

Conclusion: Architects Should Own the Entry Point

The value of enterprise architects in SAP projects is not just reviewing designs.

It lies in defining how the transformation will be governed and executed—and aligning stakeholders upfront.

The Statement of Architecture Work is a simple yet powerful tool to achieve this.

Next time you join an SAP project, consider proposing:
“Shall we create a SoAW together before we begin?”

Please refer to this article for topics related to Enterprise Architecture (EA).
Enterprise Architecture – Insight Arc | SAP, Enterprise Architecture & Supply Chain Strategy

---

Reference Links

1. Official / quasi‑official TOGAF and ADM references

• The Open Group – ADM Phase Overview
  • Overview of all ADM phases. Phase A explicitly mentions “create the Statement of Architecture Work”.
  • http://www.togaf.com/admref/welcome.htmltogaf
• The Open Group – TOGAF Standard (Architecture Content)
  • Explains the Architecture Content Framework and the role of deliverables and artifacts. Good background when positioning Statement of Architecture Work as a deliverable.
  • https://pubs.opengroup.org/togaf-standard/architecture-content/chap04.htmlpubs.opengroup

2. Statement of Architecture Work – definition and typical contents

• Cybermedian: TOGAF ADM Phase A (Part 4 of 4) – Statement of Architecture Work
  • Provides a clear definition: “The ‘Statement of Architecture Work’ defines the scope and approach that will be used to complete an architecture project… measured and may form the basis for a contractual agreement…”, and lists typical contents (title, background, scope, roles, acceptance criteria, plan, approvals).
  • https://www.cybermedian.com/togaf-adm-phase-a-part-4-of-4-statement-of-architecture-work/cybermedian
• Visual Paradigm: How to Develop ADM Statement of Architecture Work (Phase A)
  • Step‑by‑step guidance on creating the Statement of Architecture Work at the end of Phase A; reiterates that it defines scope and approach and is used to secure approval from sponsors.
  • https://circle.visual-paradigm.com/docs/togaf-adm-guide-through/phase-a-architecture-vision/how-to-develop-statement-of-architecture-work/circle.visual-paradigm
• TAYLLORCOX: Statement of Architecture Work (glossary)
  • Short glossary entry describing Statement of Architecture Work as a document that defines the scope and approach of architecture work and may serve as a basis for a contract.
  • https://www.tx.cz/en/terms/togaf-standard/statement-of-architecture-worktx

3. General TOGAF / EA background (for contextual links)

• Visual Paradigm: TOGAF ADM Tutorial
  • High‑level tutorial on ADM and key concepts, useful as a general background link when explaining how SoAW fits into the broader ADM cycle.
  • https://www.visual-paradigm.com/guide/togaf/togaf-adm-tutorial/visual-paradigm
• LeanIX: What is TOGAF?
  • Overview of TOGAF and Enterprise Architecture in business language, good for readers who are less familiar with EA.
  • https://www.leanix.net/en/wiki/ea/togaf

---

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