S/4HANA Architecture Decisions Every Solution Architect Needs

I once watched a project team spend three weeks designing a custom cross-module reconciliation report. In week four, someone finally pointed out that S/4HANA had already eliminated the entire problem the report was solving. The team was still designing for ECC’s world, inside a system that had quietly made that world obsolete.

S/4HANA’s architecture is not a features list you read once and move on from. It is a set of hard constraints — what data lives where, what a deployment option locks in and what it rules out — and those constraints shape almost every solution decision that comes after them.

This post covers the two architectural decisions that matter most for a solution architect: the data model behind the Universal Journal, and the deployment option. Get either one wrong in your head, and you will end up designing something that fights the platform instead of using it.

🔗 Foundation for this post

If you have not read What Does an SAP Solution Architect Actually Do?, start there for the accountability model this post builds on. If the difference between S/4HANA and ECC is still fuzzy, S/4HANA vs ECC — The Real Difference is the right prerequisite.

The one-sentence version

S/4HANA’s architecture is a set of constraints — what changes are cheap, what changes are expensive, and what simply is not possible — and understanding those constraints is most of what “knowing the architecture” actually means for a solution architect.

📌 Key takeaway

If someone describes S/4HANA’s architecture to you as a list of capabilities — in-memory database, embedded analytics, Fiori — they are describing marketing material, not the thing you actually need to know to design against it.

The Universal Journal — one table changes everything

In SAP ECC, financial and controlling data lived in separate tables that had to be reconciled against each other, sometimes manually, at period close — general ledger data in one place, controlling data in another, asset accounting and material ledger data in others still.

S/4HANA replaced all of that with a single line-item table, ACDOCA — the Universal Journal — that general ledger, controlling, asset accounting and material ledger all write into directly. This is not a UI change or a performance tweak. It is a structural decision that removes an entire category of problem by making cross-ledger reconciliation architecturally unnecessary.

📝 Note

This is why “no more FI-CO reconciliation” shows up in so much SAP marketing material. It is not a feature someone built on top of the system. It is a side effect of putting everything in one table in the first place.

What the Universal Journal means for solution design

Three consequences matter more to a solution architect than the table structure itself.

Custom fields ripple. Adding a custom field to ACDOCA usually means it needs to appear consistently across general ledger, profitability analysis and reporting — because these are now views into the same table, not three tables you can extend independently the way you could in ECC.

Data volume becomes an architecture decision, not just a Basis one. ACDOCA carries far richer dimensional detail per line item than the tables it replaced, and it grows faster as a result. Deciding on a partitioning, archiving and retention strategy is now a solution design decision, because it shapes how every downstream report and profitability analysis performs — not something to leave to the Basis team after go-live.

Reporting design changes. Real-time drill-down reporting straight from posted documents is now the standard, not a stretch goal. A solution that still routes reporting through a batch extraction layer “just in case” is solving a problem the architecture already solved, and adding unnecessary complexity in the process.

⚠️ Warning

I have seen migration projects carry ECC-era custom reconciliation reports into S/4HANA “for safety.” Six months later, nobody can explain why they still exist, because the problem they solved no longer does. Auditing custom reports against the new data model should be an explicit step in every conversion project — not an afterthought discovered by accident.

The deployment decision, and what SAP calls it now

A naming note first, because it trips people up: in mid-2025 SAP rebranded what was SAP S/4HANA Cloud, Public Edition to SAP Cloud ERP, and what was SAP S/4HANA Cloud, Private Edition to SAP Cloud ERP Private. The underlying products and licensing did not change — only the marketing name did — and both the old and new names are still in everyday use across SAP’s own documentation and the wider ecosystem. This post uses both names together so it stays useful either way.

Looked at architecturally rather than commercially, there are three real options.

Option	Architectural reality	Best fit
SAP Cloud ERP (Public Edition)	Multi-tenant, standardised, direct core modification is technically blocked, not just discouraged	Standardised processes, fast time to value, limited need for deep customisation
SAP Cloud ERP Private (Private Edition)	Single-tenant, deeper in-core customisation possible, customer or partner controls upgrade timing	Complex or heavily customised landscapes, brownfield conversion from ECC
On-premise	Full infrastructure control, but SAP is steadily steering customers toward the cloud editions	Strict data residency needs, existing infrastructure investment, ECC extended maintenance to 2030

💡 Practical tip

Do not let the commercial conversation — RISE, GROW, pricing — drive the architecture conversation. Decide what your solution genuinely needs to be able to do, deep core customisation or standardised fit-to-standard, and let that decision point you to the deployment option. Not the other way round.

How deployment choice and extensibility interact

SAP’s current clean core model classifies every extension on a maturity scale from Level A to Level D. Level A means fully compliant — built on released APIs, either on-stack with ABAP Cloud or side-by-side on BTP using the Cloud Application Programming Model. Level D means direct modification of the core, and SAP does not recommend it under any circumstance.

In SAP Cloud ERP (Public Edition), only Level A and Level B extensibility are technically possible — the system enforces this, it is not a matter of following a policy. In Private Edition and on-premise, deeper levels remain technically possible, but they carry real upgrade risk and accumulate as technical debt over time.

This is the actual architectural consequence of the deployment decision. Choosing Public Edition does not just mean “a less flexible ERP.” It means splitting the architecture into two systems that must be governed together from day one — the standardised core, and a BTP extension layer that carries its own security, lifecycle and integration governance.

📌 Key takeaway

Choosing SAP Cloud ERP over SAP Cloud ERP Private is not a flexibility trade-off you make once. It is choosing to run two systems that must be architected and governed together — whether or not anyone planned for that split at the start of the project.

Where modules fit into this picture

Modules are not separate systems in the way people sometimes still picture them from the ECC days. FI, CO, MM and SD all write into and read from the same Universal Journal, and they share the same master data — business partners, material master, and the rest.

Scoping a project module by module, the way ECC-era projects often did, can hide the fact that a “finance change” and a “logistics change” now touch the same underlying table. Catching that overlap before build starts is exactly the cross-module blind spot the solution architect exists to catch, and it is a direct consequence of the architecture covered in this post — not a separate skill.

Architecture decisions to lock down early

Three decisions are expensive to reverse once a project is underway, and cheap to get right at the start.

The deployment option, because it determines which extensibility levels are even technically possible for the life of the system. The extensibility strategy, because retrofitting a clean core approach onto a system already full of Level C and D extensions is a multi-year remediation project, not a setting you flip. And the data retention and archiving approach for ACDOCA, because deciding this after the table has grown for two years is a far harder conversation than deciding it before go-live.

✅ Best practice

Write these three decisions down explicitly during blueprint or design phase, with the trade-offs stated in plain language for business sponsors — not buried in a technical design document that nobody outside IT ever reads.

At a glance — the mental model

Concept	One-line summary
Universal Journal (ACDOCA)	Single table combining GL, controlling, asset accounting and material ledger — eliminates reconciliation by design, not by feature
Data model impact	Custom fields ripple across financial areas; data volume and retention become architecture decisions, not just Basis ones
SAP Cloud ERP (Public Edition)	Multi-tenant, standardised, core modification technically blocked — extensibility pushed to BTP and key user tools
SAP Cloud ERP Private (Private Edition)	Single-tenant, deeper in-core customisation possible, customer-controlled upgrade timing
On-premise	Full infrastructure control, but SAP is steering customers toward the cloud editions; ECC mainstream maintenance ends 2027
Clean core extensibility levels	A to D maturity model; Public Edition technically enforces roughly Level A/B only
Decisions to lock down early	Deployment option, extensibility strategy and data retention approach — cheap now, expensive to reverse later

What to take away

S/4HANA’s architecture is not neutral. Every deployment option and every data model decision removes possibilities as much as it adds them, and knowing which ones you are giving up before you commit is most of the actual job.

A solution architect who treats the Universal Journal as “just where finance data lives now,” or the deployment choice as “just a hosting decision,” will design something that technically works and architecturally fights itself for years afterward.

Understand the constraints first. The feature list takes care of itself.

🔗 Related reading — the rest of this series

SAP S/4HANA Migration: Greenfield, Brownfield, Bluefield — the implementation path you choose interacts directly with the deployment decision covered here.

RISE with SAP — What’s Actually in the Bundle — the commercial vehicle behind the Private Edition path, and what it actually includes.

GROW with SAP vs RISE with SAP — Which Is Right for You — how the commercial model maps onto the Public vs Private architecture decision.

SAP Clean Core — Strategy Behind Every S/4HANA Build Decision — a deeper dive into the extensibility levels touched on in this post.

Published on rakeshnarayan.com — Articles

URL: https://rakeshnarayan.com/articles/s4hana-architecture-decisions-every-solution-architect-needs/