Many SAP project managers still see TOGAF® as “an architect’s framework” that is far removed from the day‑to‑day realities of S/4HANA implementations or RISE with SAP transitions. Yet in real global template programs, the same pain points keep appearing:
- Sprints deliver quickly, but the solution ends up full of custom code and point‑to‑point interfaces that are hard to change.
- Each country or plant rollout introduces more deviations from the global standard.
- New digital initiatives such as BTP extensions, AI, or process mining cannot be scaled because the underlying landscape is fragmented.news.
TOGAF® exists precisely to prevent this pattern of “local agile success, enterprise‑level failure.” TOGAF® in particular is written with digital enterprises in mind and speaks explicitly about agility, technical debt, and the need to govern complex core platforms like SAP S/4HANA.
Agile SAP Delivery Does Not Automatically Create an Agile Enterprise
Scrum, SAFe, and other agile methods are increasingly common in SAP programs, especially for greenfield S/4HANA and global template rollouts. Sprint‑based Fit‑to‑Standard workshops make it possible to deliver visible results in short cycles.
However, TOGAF® warns that “agile delivery” does not automatically translate into an agile product or an agile enterprise. In SAP initiatives, this shows up as:
- Each sprint designs add‑ons and interfaces in isolation to satisfy immediate business requests.
- Local rollout teams accept more deviations from the template under pressure from country‑specific requirements.
- After go‑live, no one can clearly explain the overall enterprise landscape, its dependencies, or its long‑term roadmap.
This is exactly the kind of agile‑without‑enterprise‑view that TOGAF® cautions against. For a PM, success is not only “delivering the sprint” but also “protecting the coherence of the enterprise,” and TOGAF® provides the common language and process to design and maintain those connections.
Technical Debt in SAP: The Invisible Cost Every PM Must Manage
TOGAF® defines technical debt as the additional future cost created when we choose a quick, simple solution instead of a more sustainable one, and it recognizes that agile delivery can never eliminate such debt entirely. In SAP programs, this debt appears in very concrete forms:
- Implementing Z‑tables and custom logic instead of leveraging S/4HANA standard capabilities.
- Building integrations through file exchanges or direct database access instead of APIs and events.
- Designing master data such as business partners, materials, and G/L accounts per site instead of defining global ownership and standards.
- Allowing each team to choose its own BTP services, integration patterns, or infrastructure standards without central guidance.
In the short term, these decisions may look like project “wins” because they keep scope and timelines under control. Over several years, however, they turn into serious constraints:
- Every major upgrade or RISE with SAP migration requires large rework efforts.
- Data analytics and process mining demand massive cleansing and interface redesign.
- Each new digital initiative incurs different additional investment per country or plant because the landscape is inconsistent.
The Digital Practitioner Body of Knowledge (DPBoK) reinforces this view by highlighting the “Cost of Delay” that accumulates when organizations postpone repaying technical debt. From a PM perspective, the role is not only to hit this year’s go‑live date but also to facilitate decisions with a clear view of future debt costs and their business impact.
Using TOGAF® ADM to Assess and Reduce Existing SAP Debt
Even when the SAP landscape is already heavily customized and fragmented, TOGAF® is still useful. Its Architecture Development Method (ADM) provides a structured cycle to describe the current state, define a target state, and expose the gaps—many of which correspond directly to accumulated technical debt.
1. Visualizing the As‑Is: Where Is the Debt?
A PM can use ADM thinking to drive a cross‑project assessment:
- Map which business functions (order‑to‑cash, plan‑to‑produce, record‑to‑report, etc.) run on which systems (S/4, legacy, satellite applications).
- Clarify where master and transactional data are created, maintained, and replicated across the landscape.
- Catalogue which interfaces exist, what technologies they use, and which teams are responsible for them.
In TOGAF®, these perspectives appear as business, application, data, and technology architectures; for program management purposes, the key is to see the distribution of debt patterns such as “master data fragmentation,” “interface sprawl,” and “add‑on bloat” by domain and system.
2. Defining the Target: What Should the SAP Template Really Look Like?
Next, the program needs a clearly articulated target architecture—essentially the “ideal” SAP global template:
- Decide which business capabilities should be delivered by S/4HANA standard.
- Specify which capabilities should be provided by BTP extensions or cloud solutions such as SuccessFactors or Ariba.
- Define ownership boundaries for master and transactional data: who owns what, where, and under which governance.
- Establish integration principles such as “API and events by default” and clarify where file‑based mechanisms are still acceptable.
In TOGAF® terminology, this is the target architecture; in SAP terms, it is the reference template that anchors every local rollout and subsequent transformation.
3. Turning Gaps into a Roadmap
The differences between the current and target landscapes can then be structured as architecture gaps, which the PM translates into a multi‑release roadmap:
- Items to address in the next S/4HANA release (e.g., removal of certain add‑ons, consolidation of key interfaces).
- Changes that should be aligned with BTP platform build‑out or modernization of critical satellite systems.
- Items to be coordinated with other enterprise programs such as PLM refresh or data platform transformation.
DPBoK’s Cost of Delay concept is especially useful here to prioritize which debts must be repaid immediately and which can be temporarily tolerated with explicit business agreement. The PM becomes the facilitator who mediates between “teams that want to fix everything” and “executives who must optimize budget and resources,” using TOGAF® as a transparent decision framework.
Proactive Guardrails: What PMs Must Lock In Early
Managing debt only after it appears keeps the organization in a perpetual firefighting mode. TOGAF® therefore emphasizes reusable standards, architectural building blocks, and an architecture repository to prevent unnecessary debt from arising. In SAP projects, PMs should at least establish the following guardrails.
1. Make Clean Core and Extension Strategy a Project Principle
Key principles should include:
- Protect the S/4HANA core by default, using BTP side‑by‑side extensions or standard in‑app extensibility options first.
- Document the criteria under which custom add‑ons are allowed, including impact analysis and an explicit explanation of their future debt cost.
- Define clear template deviation criteria for rollouts, typically limited to genuine legal, regulatory, or non‑negotiable commercial requirements.
In TOGAF® terms, these are architecture principles, but in practice they must be written into the project charter and formally endorsed by the steering committee to give the PM a strong mandate.
2. Run the Architecture Board as a Partner, Not a Gatekeeper
TOGAF’s architecture board should be operated in an agile‑friendly way: a forum that offers guardrails and support rather than a slow approval gate. For SAP programs, this can look like:
- Quick, focused reviews with PMs, product owners, enterprise architects, and SAP architects before major extensions or template deviations are confirmed.
- Collaborative problem‑solving to propose alternatives that minimize technical debt instead of simply rejecting proposals.
- When debt is unavoidable, recording the agreed “repayment plan” and expected timeline in the architecture repository.
If the PM positions this board as “insurance against future surprises” rather than a bureaucratic hurdle, delivery teams are more likely to engage with it constructively.
Architecture Repository: Turning SAP Knowledge into a Strategic Asset
TOGAF’s concepts of an architecture repository and an enterprise continuum encourage organizations to treat past designs, standards, and patterns as reusable assets rather than one‑off project artifacts. In SAP environments, this repository can contain:
- Global process models such as order‑to‑cash and plan‑to‑produce linked to S/4HANA standard functions and approved extension patterns.
- Standard interface templates for PLM, MES, data warehouses, tax engines, and other key systems.
- A maintained view of template deviations by site, including their justification and planned retirement dates.
- Security and compliance patterns for requirements such as SOX, GDPR, and country‑specific regulations.news.
When PMs actively use and contribute to this repository, several benefits appear:
- New rollouts and projects can start from proven templates instead of rebuilding specifications from scratch.
- Local “best practices” are captured once and reused across the enterprise instead of staying as tacit knowledge.
- Even when vendors or implementation partners change, the organization retains a consistent architectural direction.
Three Practical Takeaways for SAP PMs Using TOGAF®
For PMs leading SAP‑centric digital enterprises, TOGAF® is less a theoretical framework and more a toolbox to balance short‑term delivery success with long‑term sustainability. Three practical points stand out:
- Decide up front who will own technical debt and complexity management, rather than assuming agile ceremonies alone will keep the landscape healthy.
- Use Cost of Delay thinking to jointly evaluate with executives the trade‑offs between “this release” and “future debt” when prioritizing scope and investment.
- Regularly revisit the current SAP landscape, the desired template, and the gap‑based roadmap with an ADM mindset, so that the enterprise‑wide view remains visible beyond individual projects.
By codifying principles for clean core, extension strategy, and template deviations, and supporting them with an active architecture board and repository, PMs can explain not only what is standard and what is an exception, but also why a specific exception exists and when it should be retired. In that sense, TOGAF® becomes a practical means for SAP program managers to deliver both rapid transformation today and a maintainable, future‑proof digital core for tomorrow.
Please refer to this article for topics related to Enterprise Architecture (EA).
Enterprise Architecture – Insight Arc | SAP, Enterprise Architecture & Supply Chain Strategy
Reference Links
•TOGAF® Standard, 10th Edition – Official overview (The Open Group)
https://www.opengroup.org/togaf
•What is New in the TOGAF® Standard, 10th Edition?
https://www.opengroup.org/togaf/new-version
•What is TOGAF®? | The Definitive Guide to TOGAF® (LeanIX)
https://www.leanix.net/en/wiki/ea/togaf
•Comprehensive Guide to TOGAF 10 for Enterprise Architecture (EA)
https://togaf.visual-paradigm.com/2025/02/18/comprehensive-guide-to-togaf-10-for-enterprise-architecture-ea/
•How to Master Enterprise Architecture Using TOGAF® 10 (Avolution)
https://www.avolutionsoftware.com/our-resources/how-to-guide-enterprise-architecture-togaf-10/
•SAP: RISE with SAP – ERP Clean Core Strategys
https://www.sap.com/products/erp/rise/methodology/clean-core.html
•Clean core strategy: How to keep your SAP S/4HANA system clean
https://www.ibsolution.com/academy/blog_en/smart-enterprise/platform/clean-core-strategy-how-to-keep-your-sap-s4hana-system-clean
•Describing Implementation Types and Clean Core – SAP Learning
https://learning.sap.com/courses/managing-clean-core-for-SAP-Cloud-ERP/describing-implementation-types-and-clean-core-1
•How SAP Activate Supports Clean Core Implementations
https://itp.biz/sap-activate-supports-clean-core-implementation/
•Embracing Enterprise Architecture in SAP S/4HANA Transformation Programs
https://blogs.infosys.com/sap/enterprise-architecture/embracing-enterprise-architecture-in-sap-s-4hana-transformation-program.html
•SAP Enterprise Architecture Framework: A Practical Knowledge Base
https://www.linkedin.com/pulse/sap-enterprise-architecture-framework-practical-base-arun-obilisetty-w8znc
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.
Leave a Reply