Author: Mahsun AK | SAP Basis Technology Consultant
Most SAP transformations fail not because of technology, but because we treat diagrams as decisions.
In meetings, what we call “architecture” is often nothing more than a picture. S/4HANA in the center, CPI/PO next to it, a few cloud systems around… When the slide looks good, everyone feels safe. But is that really the whole story?
Real life tells a different tale. Systems go down at 02:00 AM, certificates expire during public holidays, and a single poorly designed retry mechanism can stop an entire supply chain. Real architecture is not a diagram; it is a living whole of decisions, responsibilities, and operational discipline.
In this article, we would like to share what we have seen in our projects:
- Why SAP landscapes look strong but behave fragile
- What diagrams never tell us
- Which layers real architecture should include
- How a resilient SAP ecosystem can be designed
1. The Diagram Illusion – The Scene We See in Meetings
- A nice architecture presentation is opened
- Arrows flow from S/4 to CPI/PO and then to HR/SuccessFactors
- Finally someone says: “Architecture approved.”
But:
- What happens if an interface is delayed by 10 minutes?
- Who will clean CPI queues when they are full?
- Do we have a real retry and idempotency strategy?
- Is SAP customizing truly aligned with this flow?
The diagram answers none of these. It only represents boxes.
What We Show vs What We Live
[Business Process]
|
[Integration]
|
[Applications]
Invisible reality: ownership, retries, monitoring, security, operations.
2. For Us, Architecture = Decisions
The elements that determine the robustness of an SAP landscape are rarely glamorous:
- Integration patterns must be clear
- Error ownership must exist
- Data governance must be defined
- Monitoring approach must be designed
- Daily operational procedures must be established
Boxes do not create stability – decisions do.
3. Some Possible Real-Life Cases
Case 1 – The Retry Storm
In one project all IDocs were routed through CPI “for flexibility.” There was no idempotency, no back-pressure, no circuit breaker. A small functional mistake created more than 200,000 retries within minutes. SMQ2 queues were blocked and logistics stopped for hours. Everyone looked at Basis first, while the real root cause was hidden in business logic. A single pricing error caused days of disruption.
Lesson: Integrations must protect ERP. Without governance CPI/PO can turn into a weapon against its own system.
Case 2 – Certificate Crisis
The OAuth certificate of an integration expired on Friday night. There was no procedure, no alert, no owner. Critical replication did not work for days and the problem was noticed too late.
Lesson: Certificate lifecycle is not a technical detail; it is the heart of business continuity.
Case 3 – The Queue with No Owner
After a major migration inbound queues were full. Functional team said “Basis problem,” Basis said “interface logic,” integration team said “SAP standard.” Hours were lost only with ownership discussions. The responsible person was on leave and left the team unaware.
Lesson: Taking responsibility is more important than any tool.
Case 4 – The Clean Core Dream
To keep the landscape clean many validations were moved to BTP. But version alignment between CPI iFlows and S/4 releases was not designed. After the first upgrade half of the extensions became incompatible; cleaning queues took days and flows had to be stopped and adapted.
Lesson: If development is not completed with all details, integrations start a war against themselves.
The Real Battlefield
Design → Build → Go-Live → Operations
↑
real battlefield
4. Architecture from Basis & BTP Eyes
From our Basis and BTP perspective, architecture must answer concrete questions:
Transport & Lifecycle
- How are CPI iFlow versions aligned with S/4 transports?
- What happens if a transport requires new mapping?
- Is cross-system rollback defined?
Runtime Governance
- Who operates CPI/PO as real production runtime?
- What are queue thresholds and housekeeping rules?
Security Operations
- Is uninterrupted certificate rotation in place?
- Are RFC users controlled?
- Are OAuth and secrets managed and documented?
Upgrade Resilience
- Was the impact of S/4 upgrades on BTP extensions analyzed?
- Were interface regression tests executed?
- Is a decoupling strategy prepared?
Monitoring – Daily Reality
- Is end-to-end monitoring from SM58/SMQ2 to CPI active?
- Are alerts delivered to the right people?
If these are not defined, the landscape is fragile no matter how modern the diagram looks. Even a small configuration change or a new patch may create major problems.
Further Reading
Master SAP Basis projects beyond installation. Discover a strategic guide to architectural depth, risk mitigation, automation, and professional project mastery.
5. Resilient Architecture
Layered View
- Business Capability – value, impact, RPO/RTO
- Process – ownership & fallback
- Integration – contracts & idempotency
- Application – clean core boundaries
- Infrastructure – HA/DR & certificates
6. Our Recipe
Step 1 – Decision Log
For each integration:
- What is the Sync/Async justification? Was the impact tested? Is it really needed?
- Is the retry policy clear?
- Is the data owner backed up when unavailable?
- What are payload limits?
- Is there a monitoring approach?
Step 2 – Operational Scenarios
- Ready for CPI down situations?
- How fast can queue issues be detected?
- Who owns mass data errors?
- Was DR switch tested?
Step 3 – Observability
- Business logs
- Alert matrix
- KPIs
Step 4 – Clean Core
- Custom boundaries
- BTP extensions
- Upgrade impact
7. What Architecture Is – And What It Is Not
For us, architecture is not
a diagram file,
a list of CPI iFlows,
or a catalog of T-codes.
Architecture is the set of decisions that keeps the system standing when the real world hits.
If the diagram disappeared today, would the system continue to live?
If the answer is no, then what we have is not architecture, but merely a beautiful picture.
A resilient SAP landscape is only possible when backup strategies, HA/DR, security ownership, data responsibility, development scenarios, and monitoring mechanisms are considered together as a whole.
Architecture is not made of boxes, but of people, scenarios, and intervention plans.