Introduction: The real challenge of S/4HANA is the gap between design and implementation
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.
Architecture Continuum: Building the “design backbone” of your S/4HANA program
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:
- Generic level: Define ERP-wide business capability hierarchies and standard information models that are agnostic of a specific product.
- Industry level: Adopt SAP Best Practices and industry reference process models as “the standard we rely on” for your sector.
- Organization-specific level: Define your target business architecture, target KPI model, roles and responsibilities, and target system landscape that reflect your company’s strategy.
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.
Solution Continuum: Managing S/4HANA templates and extensions as reusable implementation assets
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:
- Generic SBBs: Standard SAP S/4HANA Cloud and on-premise editions, SAP BTP services, SAP Integration Suite, and standard Fiori apps.
- Industry SBBs: Scope items from SAP Best Practices, industry add-ons, and industry rollout templates.
- Organization-specific SBBs: Configuration templates confirmed during Fit-to-Standard, custom BTP side-by-side apps, standardized interface packages, and data migration templates.
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.
Connecting both continuums: Tracing architecture principles into S/4HANA configuration and extensions
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.
Example: Applying the continuums across a typical S/4HANA implementation lifecycle
To make this more concrete, let’s walk through a typical S/4HANA rollout scenario using SAP Activate phases.
1. Discover / Prepare: From vision to candidate standards
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.
2. Explore (Fit-to-Standard): Deciding where to deviate
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.
3. Realize / Deploy: Industrializing templates and rollout assets
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.
4. Run / Continuous transformation: Operating for change, not for stability-only
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.
Conclusion: Making clean core and local requirements coexist by design
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
Reference Links
- TOGAF / Enterprise Continuum / ADM
- Understanding TOGAF’s Continuums – Architecture and Solutions Continuum (Visual Paradigm)
- TOGAF Enterprise Continuum (Sparx Systems)
- Introduction to TOGAF Architecture Development Method (ADM) (Cybermedian)
- TOGAF® – The Definitive Guide (LeanIX)
- Understanding the Enterprise Continuum in TOGAF – explained simply (LinkedIn Article)
- SAP S/4HANA / SAP Activate / BTP
- SAP S/4HANA Best Practices Explorer
- SAP Activate Methodology for SAP S/4HANA Cloud (SAP Help Portal)
- Accelerating S/4HANA Migrations through Strategic Enterprise Architecture (International Journal paper PDF)
- Why SAP S/4HANA Demands a Continuous Operating Model (ERP Today)
- SAP S/4HANA support through 2040 and extended maintenance announcement (Crescense summary of SAP statement)
- Extending SAP S/4HANA with SAP Business Technology Platform – extension patterns and best practices
- SAP BTP – Extensibility Overview & Clean Core
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