Diagram illustrating the balance between TOGAF continuums and SAP S/4HANA digital core platform
In SAP S/4HANA programs, architects constantly face the tension between “staying as close as possible to standard” and “not ignoring real-world business requirements.” This tension makes or breaks the long-term health of your S/4HANA landscape.
If you fail to strike the right balance, even a brand-new S/4HANA system can easily degenerate into “yet another heavily customized legacy ERP,” with high upgrade costs and low agility. Practices such as SAP’s clean core strategy and BTP-based extensibility exist precisely to avoid this situation.
Two TOGAF® concepts are especially useful to bridge this gap between design and implementation: the Architecture Continuum and the Solution Continuum.
In this article, I will look at these continuums from the perspective of an enterprise architect leading an S/4HANA program and describe how to apply them in a practical way.
The Architecture Continuum is, in simple terms, an “organized shelf for architecture assets.”
This continuum holds Architecture Building Blocks (ABBs) such as business capability models, reference process models, information object definitions, architecture principles, and reusable design patterns.
In an S/4HANA context, you can use the Architecture Continuum at multiple levels:
The critical point is to make explicit, on the Architecture Continuum, which levels of standard you will rely on and where you deliberately allow organization-specific variation in this S/4HANA program.
Once this is explicit, you can evaluate individual requirements and customization requests against clear architecture principles instead of debating each one from scratch.
While the Architecture Continuum manages design-level assets, the Solution Continuum is the “organized shelf for implemented solutions.”
Here you place Solution Building Blocks (SBBs) such as the SAP S/4HANA product itself, industry solutions, cloud services, configuration templates, and custom extensions built during your projects.
For S/4HANA, examples of SBBs on the Solution Continuum include:
The key is to treat these not as one-off project deliverables but as reusable solution components positioned along a continuum.
If you do this well, global rollouts, carve-outs, and future upgrades become much easier to handle by recombining proven building blocks instead of rebuilding everything from scratch.
The Architecture Continuum and Solution Continuum are not one-way streets; they connect design and implementation in both directions.
For example, consider the principle “Maintain a clean core in S/4HANA, and realize business differentiation through extensions on SAP BTP.”
On the Architecture Continuum, you define this as a core architecture principle.
On the Solution Continuum, you prepare corresponding SBBs such as “S/4HANA standard functionality plus side-by-side extensions on SAP BTP,” with clear patterns and templates for those extensions.
If a project team claims they “must create Z-tables or classic on-stack enhancements in S/4HANA,” that SBB is then reviewed against the clean core principle in the Architecture Continuum.
By tracing ABBs from the Architecture Continuum into SBBs on the Solution Continuum, you gain a systematic way to verify that implementation decisions respect design intent.
Conversely, you can feed lessons learned from actual implementations back into the Architecture Continuum so that future S/4HANA programs start with more realistic and effective principles and reference models.
To make this more concrete, let’s walk through a typical S/4HANA rollout scenario using SAP Activate phases.
During the early phases, the enterprise architecture (EA) team curates industry-standard process models and SAP reference architectures into the Architecture Continuum and presents them as “candidate standards” for the program.
In parallel, the team structures candidate S/4HANA editions (Cloud vs. on-premise), SAP BTP services, and integration platforms on the Solution Continuum and uses this to present solution options to stakeholders.
In Fit-to-Standard workshops, teams compare “industry standard processes (ABBs)” with the company’s current processes to identify where customization is truly justified.
Based on these decisions, they design SBBs such as “covered by standard configuration,” “implemented as BTP extension,” or “handled via integration with another system,” and then register these SBBs on the Solution Continuum as reusable patterns.
During realization and deployment, the project team builds S/4HANA templates, rollout configuration packages for different sites or countries, interface templates, and data migration objects, and refines them into mature SBBs for reuse.
At the same time, the project documents “forbidden customizations” and “recommended extension patterns” as architecture guidelines and anchors them in the Architecture Continuum.
SAP has committed to supporting S/4HANA until at least 2040, which means organizations must plan for continuous upgrades and transformation over a long horizon.crescenseinc+1
Each time new business requirements, M&A events, or organizational restructurings occur, architects update the Architecture Continuum and add or refine SBBs in the Solution Continuum, thereby institutionalizing a “change-by-design” operating model rather than treating transformation as a one-off program.
Through this lifecycle, consciously using TOGAF’s continuums turns design and implementation assets from “project artifacts” into enterprise-wide architecture assets that can be reused across future rollouts, cloud transitions, and peripheral system modernizations.
To reconcile a clean S/4HANA core with real-world business requirements, you must go beyond debating each customization and instead clarify, via the Architecture Continuum, which standards you rely on and where you explicitly allow organization-specific solutions.
On top of that, by organizing standard S/4HANA functionality, industry templates, and your own configurations, extensions, and interfaces as SBBs on the Solution Continuum, you can drastically reduce the waste of re-opening the same design debates in every project.sap+1
If you establish an operating model that traces principles and reference models from the Architecture Continuum into concrete templates and extension patterns on the Solution Continuum, you can reliably enforce strategies like “keep the core clean and realize differentiation on BTP” at implementation level.
Finally, by continuously feeding project lessons back into both continuums, you evolve a “transformation-ready operating model” in which S/4HANA rollouts, future cloud migrations, and surrounding system renewals can all be governed using the same coherent framework.
Please refer to this article for topics related to Enterprise Architecture (EA).
Enterprise Architecture – Insight Arc | SAP, Enterprise Architecture & Supply Chain Strategy
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.
A practical guide to using the TOGAF Content Framework in S/4HANA projects to organize deliverables,…
This article explains how SAP Enterprise Architects can use TOGAF Architecture Building Blocks (ABBs) and…
This post explains how to turn slogans like “Fit‑to‑Standard” and “Clean Core” into actionable architecture…
Many SAP programs fail due to weak requirements definition and uncontrolled scope creep. This article…
SAP go‑live is not the finish line but the start of a new enterprise architecture…
Learn how TOGAF ADM Phase G strengthens SAP Implementation Governance and drives successful enterprise SAP…