SAP architecture, end to end, in plain English
SAP is not one product, and that is the first thing nobody tells you. It is a database, an application server, an ERP built on top of both, a cloud platform beside it and a portfolio of applications around it. This page walks all thirteen layers, follows a Fiori click all the way down to a row in HANA, and explains the save sequence that answers most of the questions people spend years being confused by. No prior SAP experience assumed.
The whole landscape in sixty seconds
A business process runs in an application, the application runs on an application server, the application server keeps its data in a database, and everything that is not the application server hangs off a platform beside it. That is SAP. Everything else on this page is detail hung off those four clauses. Once that clicks, the architecture stops feeling like a wall of three-letter names and starts feeling like layers.
Three editions, one set of ideas
SAP Cloud ERP is multi-tenant SaaS that SAP upgrades quarterly. SAP Cloud ERP Private is your own system on a hyperscaler under RISE. On-premise is your own system in your own data centre. The words differ and the extensibility ceiling differs, but HANA, ABAP, CDS views and the Universal Journal mean the same thing in all three.
Six ideas explain most of the data
Client, configuration, organisational structure, master data, transactional data and the CDS virtual data model. Almost every confusing table becomes obvious the moment you can say out loud which of those six you are looking at and which layer above it is meant to read it.
The save sequence is fixed
Authorisation, then logic on a buffer, then the enqueue lock, then COMMIT WORK and an asynchronous update task. Always that order, every time. Most SAP behaviour that looks mysterious is really a misunderstanding of that sequence, which is documented below in full.
Click any layer to jump straight into it
Five pictures that explain most of the landscape
If you only take five things away from this page, take these. Each diagram is drawn to match how SAP really behaves, not how it is usually drawn in a sales deck, and each one is explained in words underneath so you are never guessing at what a box or an arrow means.
Where your landscape actually is, in 2026
The single most useful picture in SAP architecture. Almost every scoping argument on an SAP programme is really an argument about which of these boxes exists and who is responsible for it.
Scroll the diagram sideways, or tap Enlarge for a bigger view
What is actually running inside an ABAP application server
People treat the application server as a black box for years. It is a small number of named parts, and knowing which is which turns most performance tickets into five-minute diagnoses.
Scroll the diagram sideways, or tap Enlarge for a bigger view
ICM terminates HTTP and HTTPS and is the web front door of the whole stack. The dispatcher queues requests and hands each one to a free work process. Work processes come in types, dialog, background, update and spool, and there is a finite number of them; a system that has apparently frozen is very often a system with no free dialog processes. Buffers hold table, program and number range data in the instance's own memory, and they synchronise on an interval rather than instantly, which is exactly why a configuration change can look correct on one application server and stale on another. The roll area holds user context between dialog steps. Two services exist once per system rather than once per instance: the enqueue server, which every save passes through to take its logical lock, and the message server, which the instances use to find each other. The behaviour that surprises everyone arriving from another platform is at the bottom. The dialog process usually does not write to the database itself. It runs the logic, takes the lock, hands the change to an update work process and is immediately free to answer the user. That is why a transaction can report success on screen and leave no document behind, recorded as an update termination rather than as an error the user ever saw.The thirteen layers, in order
Read it from the bottom. Each layer only makes sense once the one beneath it does, and each layer is somebody's whole job somewhere.
Scroll the diagram sideways, or tap Enlarge for a bigger view
From a click in the browser to a row in the database
Saving a record is not one step. It is a chain, and the last link in the chain is asynchronous, which is the single most misunderstood fact about the platform.
Scroll the diagram sideways, or tap Enlarge for a bigger view
Three places to put an extension, and four levels of risk
Clean core is not a slogan and it is not a purity score. It is this diagram, and it is the question you will be asked in every SAP architecture interview from now on.
Scroll the diagram sideways, or tap Enlarge for a bigger view
Where to start, depending on who you are
This page is long on purpose, because SAP architecture is not something you can learn from a single diagram. You do not have to read it top to bottom. Pick the path that matches why you are here.
I am new to SAP
Resist the urge to learn transaction codes. SAP looks arbitrary until the data model clicks, and then most of it becomes derivable. Read the model, walk one trace, and only then worry about which screen does what.
- Read L0 Deployment and Editions so you know which SAP anybody is talking about
- Read L3 the S/4HANA application and data model, especially client, organisational structure and the Universal Journal
- Walk the order to cash trace slowly, twice, until you can narrate it without looking
- Read the save sequence and understand why the update task is asynchronous
- Skim the glossary now, and come back to it after every section
I am switching from another platform
Your instincts about layering, APIs and deployment will mostly serve you. The two things that will surprise you are how much behaviour is table-driven configuration rather than code, and how seriously the platform takes the transport path.
- Start with L2 the ABAP platform, particularly work processes, the enqueue server and the update task
- Read L3 with attention to configuration as data, which is the biggest conceptual difference from most platforms
- Read L5 clean core and the extensibility tiers before you write anything
- Read L6 BTP and walk the side-by-side extension trace, which will feel familiar
- Read L11 and understand why nobody changes production directly
I build things and want to build them cleanly
The difference between a developer whose work survives upgrades and one whose work generates adjustment tickets is almost entirely a matter of which extension point they chose and why.
- Read L5 in full and learn the four clean core levels well enough to classify any object on sight
- Read L4, especially RAP, CDS and the difference between I_ and C_ views
- Read L2 on ABAP Cloud and the language version, and set it on every new package
- Walk the Fiori save trace and the side-by-side extension trace back to back
- Read L7 on integration patterns, because most extensions are integrations wearing a different hat
I am designing or reviewing a landscape
The architectural decisions that hurt are rarely technical. They are the ones about ownership, authority and boundaries, and they are made early by people who did not know they were making them.
- Read L0 and be able to state the edition, operating model and responsibility split for everything you own
- Read L6 on the global account and subaccount hierarchy, which is a boundary that is painful to change later
- Read L7 in full and inventory every interface with its pattern, guarantee and owner
- Read L12 and decide which system is authoritative for which population and which master data domain
- Read L11 and make sure one named person owns cross-product release regression
I keep it running
Most production incidents in SAP landscapes are not novel. They are one of a small number of recurring shapes, and knowing the shapes turns a two hour investigation into a two minute check.
- Read the save sequence and internalise the asynchronous update, which explains the most common false alarm there is
- Read L1 on the delta merge, memory and sizing, which explains most afternoon slowdowns
- Read L2 on work processes and locks, which explains most frozen systems
- Read L7 and make sure failed messages, blocked queues and expiring certificates have owned alerts
- Read L11 and make sure the transport path and the emergency change route are both documented and both used
All thirteen layers, one at a time
Each layer answers four questions: what it actually is, what lives inside it, how it connects to the layers above and below, and what usually goes wrong. The plain-English analogy at the top of each layer is there for anyone new to SAP. Everything below the analogy is the real detail, including where the cloud and on-premise editions diverge and where the 2026 naming has moved underneath the concepts.
Deployment & Editions
Which SAP you are actually looking at, and who runs it
As of 2026 the naming has settled into something clearer than it was. SAP Business Suite, relaunched in February 2025, is the umbrella: a modular set of cloud applications, a common data layer, and an AI layer, all built around one ERP core. Inside it, SAP S/4HANA Cloud Public Edition is now marketed as SAP Cloud ERP, and SAP S/4HANA Cloud Private Edition is now SAP Cloud ERP Private. Underneath both, and still shipped for customers who run their own data centres, is SAP S/4HANA on-premise, which follows a two-year release cadence: the 2025 release went generally available on 8 October 2025, with the next major release planned for late 2027. RISE with SAP and GROW with SAP are not products; they are commercial packages that bundle a Cloud ERP edition with infrastructure, tooling, services and a methodology. Behind all of it sits the estate SAP is trying to move, SAP ECC on NetWeaver, whose mainstream maintenance ends on 31 December 2027, with paid extended maintenance to 2030 and a narrow safe-harbour arrangement running to 2033 for customers with a committed cloud contract.
Client | The highest-level organisational and data separation unit inside one SAP system. Almost every application table carries MANDT as its first key field. Two clients in one system are two separate sets of business data. |
System ID (SID) | The three-character identifier of a single SAP system, for example DEV, QAS, PRD. It appears in hostnames, in transport routes and in every support ticket you will ever raise. |
Instance | One application server process group with its own instance number. A system can have many instances across many hosts. |
Tenant | In SAP Cloud ERP, the multi-tenant equivalent of a client. In SAP HANA multitenant database containers, a separately addressable database inside one HANA system. |
Landscape | The set of systems that form one transport path, conventionally development, quality assurance and production. |
The word 'cloud' hides three completely different contracts
In SAP Cloud ERP, SAP runs everything and you consume a standard application. In SAP Cloud ERP Private, SAP runs the infrastructure and a defined set of platform operations, and you still own Basis administration, custom code, SAP Notes and HotNews assessment, most monitoring, and the decision about when to apply a support package. The gap between what customers assume RISE covers and what the service description actually covers is the single most common source of unpleasant surprise in year one, and the answer is always in the contracted service description rather than in the sales deck. Standard availability commitments sit around 99.5 to 99.7 percent for unplanned downtime, which is materially less than the availability many large enterprises achieve in their own data centres, and it is worth knowing that before signing rather than after an outage.
Public edition is not a smaller private edition
It is tempting to describe SAP Cloud ERP as private edition with fewer features. That framing leads teams to design as though the missing pieces will arrive later. The real difference is architectural: in the public edition you have no access to the underlying ABAP stack, no classic transactions outside the released set, no ability to write directly to standard tables, and an upgrade every quarter that you cannot decline. Every extension has to be built on a released interface with a stability contract. That constraint is the product. Organisations that fight it end up with a private-edition budget and a public-edition system, which is the worst of both.
The 2027 date, and the three dates behind it
SAP ECC mainstream maintenance ends on 31 December 2027. From 1 January 2028 to 31 December 2030 there is optional extended maintenance carrying a premium on the maintenance fee. Beyond that, a narrower arrangement runs to the end of 2033 for customers who hold an active cloud ERP contract and a committed transition roadmap. Meanwhile SAP has committed to maintaining SAP S/4HANA until at least 2040, which is the commitment that actually matters when you are justifying a seven-figure programme. The practical read: 2027 is not a cliff for anyone who plans, and it is a cliff for anyone who does not.
Greenfield, brownfield, and the honest third option
A greenfield implementation builds a new system on standard processes and migrates master and open data. A brownfield conversion takes the existing ECC system, converts the database to HANA and the application to S/4HANA in place, and keeps the history and the custom code, including the parts nobody has understood since 2009. The third option, usually called selective data transition or bluefield, moves selected company codes or selected history into a new shell. The choice is rarely technical. It is a question of how much of your current process you believe is a competitive advantage, and the uncomfortable answer in most organisations is less than the business thinks and more than the consultants say.
Where the system physically sits still matters
Under RISE, your Cloud ERP Private system runs in a hyperscaler region that you select, on infrastructure SAP contracts. That choice sets your data residency position, your latency to interfaces and to users, and which SAP data centre a support engineer will connect to. It also sets your blast radius. A single-region deployment with asynchronous replication to a second region is a different availability story from an active-active design, and SAP's standard offering is closer to the former. Ask what the recovery point and recovery time objectives actually are, in numbers, and get them in the order form.
- Saying 'we are moving to the cloud' without saying which edition. SAP Cloud ERP and SAP Cloud ERP Private are as different from each other as either is from on-premise, and half of a project's scope depends on which one was meant.
- Assuming RISE with SAP means SAP operates everything. Basis administration, SAP Notes assessment, custom code, most monitoring and the upgrade decision usually stay with you unless separately contracted.
- Planning around 2027 as though it is the only date. Extended maintenance runs to 2030 and a narrower arrangement to 2033, and the commitment to maintain S/4HANA until 2040 is what actually justifies the investment.
- Choosing brownfield because it is cheaper without asking whether the point of the programme was to change how the company works. A conversion sold as a transformation disappoints everybody.
- Treating SAP Business One or Business ByDesign as small S/4HANA. They are separate products with separate architectures and almost nothing transfers.
- Signing before reading the service description. The availability commitment, the backup policy and the responsibility split are all in there, in numbers, and they are rarely what the deck implied.
SAP HANA
The database that made the rest of it possible
SAP HANA is the only database S/4HANA runs on. It stores data primarily in columns rather than rows, which means values in one column sit next to each other and compress extremely well, typically by a factor of five to ten on real business data. Because scans are cheap, HANA can answer analytical questions directly against the transactional tables instead of against pre-aggregated copies, which is the technical reason the Universal Journal could replace a dozen aggregate and index tables in Finance. Writes go into a row-oriented delta store for speed and are folded into the compressed main store by a background delta merge. Everything is also written to disk: the data volume takes a savepoint every few minutes and the redo log is written synchronously on commit, so an in-memory database is still fully durable. HANA Cloud is the managed service version of the same engine, sized in compute and storage rather than in appliance hardware, with Native Storage Extension providing a warm tier for data that must be queryable but does not deserve RAM.
M_CS_TABLES | Column store table sizes, record counts and memory consumption. The first place to look when memory is tight. |
M_EXPENSIVE_STATEMENTS | Statements that exceeded a configured threshold. The starting point for almost every performance investigation. |
M_SERVICE_MEMORY | Memory used per service, split into heap, shared and code. Distinguishes a data problem from a workload problem. |
M_DELTA_MERGE_STATISTICS | History of delta merges: which table, when, how long, and how much it reclaimed. |
M_HEARTBEATS / M_SYSTEM_OVERVIEW | Fast health checks used by monitoring and by every support engineer who opens a connection to your system. |
In-memory does not mean not on disk
This is the misconception that survives the longest. HANA is fully ACID and fully durable. Every committed transaction has its redo record written to the log volume before the commit returns, and changed pages are flushed to the data volume at each savepoint, by default every five minutes. If the server loses power, HANA restarts by loading the last savepoint and replaying the log from there. What 'in-memory' actually means is that the primary copy used for reading is the one in RAM, so the query optimiser never has to plan around disk access for the hot data. The consequence for operations is that startup time is dominated by loading columns into memory, which is why a large system does not come back in thirty seconds.
Why columns changed the application, not just the database
In a row store, summing one column across ten million records means touching all of every record. In a column store you touch one column, already compressed, already contiguous, and you can often answer from the dictionary without decompressing at all. Once that is true, maintaining a pre-aggregated total becomes an expensive way to avoid a cheap calculation. That single fact is why S/4HANA removed the aggregate tables in Finance and Materials Management and replaced them with compatibility views that compute the same numbers on the fly. Any custom code that wrote to those old tables broke; any custom code that read from them still works but is reading a view. Knowing which of the two you have is the entire content of a custom code remediation project.
The delta merge, and why it shows up as a performance mystery
Inserts and updates go to the delta store, which is optimised for writing and poor for scanning. As the delta grows, reads get slower because every query must union the main and the delta. The merge process rewrites the delta into the main store, resorts it and recompresses it, which is expensive in memory and CPU while it runs. HANA decides when to do this automatically based on delta size, memory pressure and access patterns. The symptom teams report is that a report was fast in the morning and slow at four in the afternoon on a heavy posting day. The cause is usually a delta that has not merged. It is visible in M_DELTA_MERGE_STATISTICS and it is not something to fix by hand except during a mass-load.
Code pushdown is the whole performance argument
The classic ABAP pattern was to select a large result set into an internal table and loop over it in the application server. On HANA that is close to the worst thing you can do: it moves millions of rows across a network, throws away the database's ability to parallelise, and burns application server memory. Code pushdown means expressing the aggregation, the join and the filter in the database, through Core Data Services views, ABAP Managed Database Procedures or well-written Open SQL. The rule of thumb that survives contact with reality is simple. Move the calculation to the data. If your program is transporting rows to compute a number, rewrite it.
Sizing is memory, and memory is money
HANA sizing is dominated by how much data must be resident in RAM, which is roughly the compressed table footprint plus working memory for queries, plus headroom. SAP's rule of thumb has long been that working memory should be about the same as the data footprint, which is why quoted sizes look like double what the data appears to need. The levers that actually reduce it are archiving, data ageing, Native Storage Extension for warm data, and deleting the accumulated technical debt of application logs and change documents that nobody has ever read. In a RISE contract, memory is the meter, so a data volume management strategy is a cost strategy, not a housekeeping task.
HANA Cloud is the same engine with a different operating model
SAP HANA Cloud is the managed, elastically scalable version of the database, and it is what BTP services, Datasphere and new development sit on. You provision compute and storage rather than an appliance, you scale them independently, and SAP patches the engine. The SQL surface and the modelling concepts are the same, which is why a CDS view or a calculation view moves across with modest effort. The differences that bite are administrative rather than semantic: no operating system access, a different backup and recovery interface, and a set of features that exist only in one or the other at any given moment. Check the feature scope rather than assuming parity.
- Believing in-memory means not durable. Every commit writes redo to disk and savepoints flush data pages; HANA survives power loss like any other relational database.
- Writing ABAP that pulls large result sets into internal tables and loops over them. On a column store that is the slowest possible way to answer the question.
- Sizing on raw table size. Compression reduces it, working memory adds to it, and the number that matters is the total resident footprint plus headroom.
- Ignoring the delta merge and then investigating an afternoon slowdown as an application problem.
- Assuming HANA Cloud and on-premise HANA have identical feature scope. They diverge in both directions, and the differences are administrative more often than semantic.
- Leaving application logs, change documents and idoc history to grow forever, then paying for the memory to keep them resident.
ABAP Platform
The application server that has run SAP for thirty years
AS ABAP is the application server. A dispatcher receives requests and hands them to a work process; the work process attaches to a user session, loads the program, and does the work. Work processes come in fixed types set at instance start: dialog for interactive users, background for scheduled jobs, update for the asynchronous second phase of a transaction, enqueue for the lock table, and spool for output. Each application server keeps buffers for programs, table definitions, and frequently read configuration, which is why the first execution after a transport is slow and the second is fast. The Internet Communication Manager handles HTTP, HTTPS and web service traffic, which is how Fiori, OData and REST reach the same business logic that SAP GUI reaches. In S/4HANA this is the ABAP Platform, versioned alongside the application release, and in BTP the same runtime appears as the ABAP environment, sometimes called Steampunk, with a deliberately restricted language scope called ABAP Cloud.
TADIR | The directory of every repository object: type, name, package and original system. The starting point for any custom code inventory. |
E070 / E071 | Transport request headers and object lists. What is in a transport, who owns it, and whether it has been released. |
TBTCO / TBTCP | Background job headers and job steps. The scheduling backbone of every nightly run in the estate. |
NRIV | Number range intervals. A surprisingly frequent source of production incidents when a range fills or is not extended after a copy. |
T000 | The client table. Which clients exist, what they are for, and whether changes are allowed in them. |
The three-phase transaction that surprises everyone
A classic SAP business transaction does not write to the database as you go. It collects the changes in memory, and at the commit point it hands the whole bundle to an update work process, which applies them asynchronously in a separate database transaction. This is why an order can be saved successfully from the user's point of view and still fail minutes later, and why SM13 exists. It is also why the enqueue server matters: the logical lock has to survive from the moment the user starts editing until the update finishes, which is longer than any database lock would sensibly be held. Understanding this sequence explains a whole category of production problems that otherwise look like magic.
ABAP Cloud is a different language scope, not a different language
ABAP Cloud is the development model that makes clean core possible. Syntactically it is ABAP, but the compiler only permits released APIs and released objects, forbids direct access to SAP tables that are not released, and rejects the old procedural patterns that made upgrades painful. In the BTP ABAP environment and in SAP Cloud ERP it is the only option. In S/4HANA on-premise and Cloud ERP Private you can choose it per package by setting the ABAP language version, which is the single most useful lever a development lead has: new work is written in ABAP Cloud from day one, and the old code is left in classic ABAP until it is retired. The three-tier extensibility model exists to give the escape hatches when a released API genuinely does not exist yet.
Buffers explain most 'it works on one server' problems
Table buffers, the program buffer and the nametab live in the shared memory of each individual application server. Synchronisation between servers happens through a table of pending buffer invalidations that each server reads on an interval, by default every minute or two. So a configuration change made on server A becomes visible on server B a minute later. In a busy system with a short-lived inconsistency this looks like a ghost: two users doing the same thing get different answers. The fix is almost never to disable buffering. It is to know the mechanism exists and to check it before starting a much more expensive investigation.
Transports are the reason SAP estates stay coherent
Every repository change and every client-independent customising change is recorded in a transport request with an owner, a description and an object list. Releasing the request exports it to a file on the shared transport directory; importing it into the next system applies exactly those objects. The discipline this enforces is real and worth defending: nothing reaches production that did not pass through the same crate that passed through test. The failure modes are equally consistent. Transports imported out of sequence overwrite newer objects with older ones. Objects split across two requests arrive in two waves and the system is briefly inconsistent. A change made directly in production, because someone opened the client, is invisible to the next import and gets silently reverted.
Where SAP GUI ends and the web begins
SAP GUI speaks DIAG, a proprietary protocol, to the dispatcher over port 32NN. Fiori and every modern API speak HTTP to the ICM over port 80NN or 443NN. Both end up in a dialog work process running ABAP against the same data with the same authorisation checks. This matters for two practical reasons. First, an OData service that is slow is slow for the same reasons a transaction is slow, and the same tooling diagnoses it. Second, closing SAP GUI access does not close a security surface unless you have also thought about what the OData and RFC surfaces expose, because they reach the same function modules.
- Forgetting that the update task is asynchronous, then being unable to explain how a transaction reported success and produced no document.
- Debugging a configuration inconsistency across application servers without knowing that table buffers synchronise on an interval.
- Opening the production client for a quick change. It is invisible to the transport path, it will be overwritten, and it is an audit finding.
- Treating ABAP Cloud as a different language rather than a restricted scope of the same one, and therefore not setting the ABAP language version on new packages.
- Assuming that closing SAP GUI access closes the surface. OData and RFC reach the same business logic through a different port.
- Sizing work processes by copying another system. Dialog, background and update ratios follow your workload, not somebody else's.
S/4HANA Application & Data Model
Where the business logic and the business data actually live
S/4HANA is organised into functional areas that most people still call modules: Financial Accounting and Controlling, Materials Management and Sourcing and Procurement, Sales and Distribution, Production Planning and Manufacturing, Extended Warehouse Management, Plant Maintenance and Asset Management, Project System, and Quality Management, with industry solutions layered on top. Its two structural innovations over ECC are the Universal Journal and the virtual data model. The Universal Journal, table ACDOCA, merges the general ledger, controlling, asset accounting, material ledger and profitability analysis into one line-item table, which removes reconciliation between them by construction rather than by process. The virtual data model is a hierarchy of Core Data Services views over the physical tables that gives every consumer, from a Fiori app to an analytical query to an API, the same semantically named, association-rich picture of the data. Business Partner replaces the separate customer and vendor masters, and the material number is extended to forty characters.
ACDOCA | The Universal Journal. Every financial line item, with all controlling, asset and margin dimensions on the same row. |
BKPF | Accounting document headers. Still present and still the entry point for most finance investigations. |
MARA / MARC / MBEW | Material master: general data, plant data, valuation. The classic three-table trio for anything involving stock. |
EKKO / EKPO | Purchasing document header and item. Where a purchase order actually lives. |
VBAK / VBAP | Sales document header and item. The equivalent for the order-to-cash side. |
MATDOC | The material document table in S/4HANA, which replaced MKPF, MSEG and the stock aggregate tables such as MARD and MBEW quantities. |
BUT000 | Business Partner general data. The root of the customer and supplier model in S/4HANA. |
The Universal Journal is the single biggest functional change
In ECC, finance and controlling kept their own line-item tables and their own totals, and a month-end reconciliation existed to prove they agreed. In S/4HANA there is one line-item table, ACDOCA, that carries the general ledger account, the cost centre, the profit centre, the profitability segment, the asset, the material ledger fields and the customer-defined extension fields on the same row. Reconciliation between FI and CO is not a faster process; it is a process that no longer has a reason to exist. The consequence for anyone reading data is that the answer to almost every finance question is now one selection on one table, and the consequence for anyone migrating is that the old tables are views and old custom reports must be assessed one by one.
The virtual data model has layers, and the layers have contracts
CDS views in S/4HANA are not a flat pile. Basic interface views, prefixed I_, sit directly on tables and are the stable, released surface. Composite views join and enrich them. Consumption views, prefixed C_, are shaped for a specific application or analytical query and are explicitly not stable. Restricted reuse views, prefixed R_, are released only for defined scenarios. Build on I_ views and your extension survives upgrades; build on C_ views and it will not, because the consumption layer changes whenever the app it serves changes. This distinction is the most practically useful thing a new S/4HANA developer can learn, and it is routinely skipped.
Business Partner is a data model change disguised as a master data change
In ECC, a company that was both a customer and a supplier had two unrelated master records, two numbers and two addresses that drifted apart. S/4HANA makes Business Partner the single object, with customer and supplier roles attached, and enforces this through customer-vendor integration. The migration is not a data load. It is a decision about number ranges, about which record wins when the two disagree, and about the several hundred interfaces that were built expecting KNA1 and LFA1. Programmes that treat it as a technical conversion discover in test that half the interface estate assumed a customer number and a vendor number could never collide.
Configuration is code, and it deserves the same discipline
The Implementation Guide is not a settings screen. It is a database of decisions, transported through the same landscape as programs, capable of breaking production just as thoroughly. Client-independent customising changes affect every client in the system, including the one someone is testing in. The habit that separates mature estates from painful ones is treating a configuration change like a code change: a request, a reason, a test, a documented owner. The habit that causes incidents is opening production for a quick change and forgetting to close it, which is still, in 2026, one of the most commonly reported audit findings in the SAP world.
Embedded analytics changed where reporting lives, but not entirely
Because HANA can aggregate transactional data live, S/4HANA ships analytical CDS views and Fiori analytical apps that report directly on the operational system. For operational reporting, this removed a whole extract-transform-load hop and the latency that came with it. It did not remove the data warehouse. Cross-system reporting, long history, heavy planning, non-SAP data and anything that must survive an S/4HANA data archiving policy still belongs in a warehouse or a lakehouse, which in 2026 means Datasphere and Business Data Cloud. The architectural question is not embedded versus warehouse; it is which questions belong where.
The 2025 release and what an annual conversation now looks like
S/4HANA on-premise and Cloud ERP Private follow a two-year major release cadence. The 2025 release became generally available on 8 October 2025 with roughly seven years of mainstream maintenance, and the next major release is planned for late 2027. Between major releases, feature package stacks deliver functional additions. SAP Cloud ERP, by contrast, upgrades every quarter on SAP's schedule. This asymmetry is worth stating plainly to stakeholders early: on private and on-premise you own an upgrade project every two years or so and can plan it; on public you own a regression test every quarter and cannot decline it.
- Building custom code on C_ consumption CDS views because they had the fields you wanted. They are explicitly not stable and will change under you.
- Treating the Business Partner conversion as a data load rather than as a decision about number ranges, winning records and several hundred interfaces.
- Writing to tables that are now compatibility views. Reads still work; writes do not, and the failure appears late.
- Assuming embedded analytics removes the need for a data warehouse. It removes a class of operational reporting, not cross-system history.
- Configuring in production because it is 'only customising'. Client-independent settings affect every client in the system, including the one being tested in.
- Planning an upgrade as a technical event on a two-year cadence and forgetting that the functional regression pack is the expensive part.
User Experience & Programming Model
Fiori, UI5, OData and the model that connects them to business logic
Fiori replaced the transaction-per-screen model with role-based apps launched from a launchpad. Each user sees a home page of tiles determined by their business role, and each tile opens either a Fiori app, a classic transaction rendered through the WebGUI, or an analytical view. The apps are SAPUI5 applications running in the browser, talking to the ABAP server over OData, which is a REST protocol with a machine-readable metadata document, so the client knows the shape of the data before it asks for any. Most modern apps are not hand-coded: Fiori elements generates the entire user interface from annotations on a CDS view, so the developer describes what the data means and the framework decides what the list, the object page and the filter bar look like. The ABAP RESTful Application Programming Model, RAP, is the server-side counterpart: a CDS data model, a behaviour definition that declares what can be created, updated and deleted and under what conditions, an implementation class, and a service binding that exposes it as OData V4. SAP Build sits alongside as the low-code entry point, covering application development, process automation and workzone-style portals.
Catalog | A collection of apps a user may launch. Assigned to a business role, and the reason two people with the same job title see different tiles. |
Group / Space / Page | How tiles are arranged for the user. Spaces and pages are the current model; groups are the older one. |
Target mapping | The rule that turns a semantic object and an action, for example SalesOrder-display, into an actual application to launch. |
Service binding | The RAP artefact that publishes a projection view as an OData V4 or V2 service with a versioned name. |
Annotation | Metadata on a CDS view that tells Fiori elements what to render: which fields are in the list, which are filters, what the header shows. |
Fiori is a security model wearing a user interface
The tiles a user sees are not a cosmetic preference. A business role carries both the authorisation profile, generated from PFCG, and the catalogs that determine which apps are launchable. Get the role design wrong and the symptom is a blank launchpad or, worse, a tile that appears and then fails with an authorisation error at the point the user has already committed to a task. The practical implication is that user experience design and authorisation design cannot be separate workstreams with separate schedules. In S/4HANA they are the same design, expressed twice.
Fiori elements versus freestyle, and when to break the rule
A freestyle UI5 application gives you complete control and complete responsibility: every layout decision, every accessibility behaviour, every upgrade of the framework is yours. A Fiori elements application gives you a floorplan the whole product already uses, generated from annotations, that inherits new framework capability for free. The default should be elements, and the exception should be argued. The legitimate exceptions are genuinely novel interactions that no floorplan covers. The illegitimate one, which accounts for most freestyle apps in the wild, is a developer who found annotations unfamiliar and wrote JavaScript instead, producing an app that looks subtly wrong next to every other app and needs rework at each UI5 version.
RAP is the reason extension development got predictable
Before RAP there were several competing ABAP models for building services, and each had its own transaction handling and its own idea of what a business object was. RAP settles it: the CDS view defines the data, the behaviour definition declares in a readable syntax which operations are allowed and which validations and determinations run when, the implementation class holds the code, and the service binding publishes it. Because the behaviour is declarative, the framework can enforce draft handling, optimistic locking and ETag management consistently. The learning curve is real, and the payoff is that a RAP service written correctly behaves the same way as every SAP-delivered one, including the parts developers used to get wrong.
OData V2 and V4 are not interchangeable, and the estate has both
Most Fiori apps shipped before roughly 2020 expose OData V2. RAP generates V4. They differ in the metadata format, in how they express deltas and batches, and in how annotations are carried. A UI5 application binds to one or the other, and the model class differs. In a real estate you will have both for years, and the mistake to avoid is standardising on a shared library or a shared consumption pattern that only works with one. New services should be V4; existing V2 services should be left alone until there is a reason beyond tidiness.
The launchpad in the cloud is a different animal
On S/4HANA on-premise and Cloud ERP Private, the Fiori launchpad runs in the ABAP stack, either on the same system or on a separate front-end server. On BTP, SAP Build Work Zone provides a launchpad that aggregates apps from several back ends, which is what you want when a user's day spans S/4HANA, SuccessFactors and a custom BTP app. The design decision is where the single entry point lives. Choosing the ABAP launchpad keeps things simple until the second back end arrives; choosing Work Zone costs more setup and scales to a real multi-system estate. Deciding late means migrating tile configuration, which is tedious and thankless.
- Designing the user experience and the authorisation model as separate workstreams. In Fiori the business role defines both, and they have to be designed together.
- Writing a freestyle UI5 app because annotations felt unfamiliar, then owning every layout, accessibility and framework-upgrade decision forever.
- Mixing OData V2 and V4 assumptions in a shared library, then discovering the incompatibility during integration testing.
- Deferring the decision about whether the launchpad lives in the ABAP stack or in SAP Build Work Zone until a second back end arrives.
- Building a Fiori app when a released BAdI and a standard app would have done, because building was more interesting than searching.
- Ignoring the Horizon theme and My Home defaults and shipping something that looks like it came from a different product.
Clean Core & Extensibility
How to change SAP without making it unupgradeable
SAP's current framing splits extensibility into three tiers and grades existing custom code into four levels. The three tiers are key user extensibility, where a business expert adds a field, a logic snippet in a released business add-in, or a custom CDS view through in-app tools; developer extensibility, where an ABAP developer writes ABAP Cloud inside the system against released APIs; and side-by-side extensibility, where the extension is a separate application on BTP that talks to the core over APIs and events. The four clean core levels grade what you already have. Level A is fully compliant, built only on released APIs with stability contracts, whether on-stack in ABAP Cloud or side-by-side on BTP. Level B uses classic but SAP-standardised and documented interfaces that are upgrade-stable in practice though outside the newer released framework. Level C reaches into internal, non-released SAP objects, which works until SAP changes one. Level D is the danger zone: modifications to SAP standard code, direct writes to standard tables and implicit enhancements. Clean core is broader than code, covering data, processes, integration and operations, but the code dimension is the one that shows up in an upgrade estimate.
Released API | An interface with a stability contract. In ABAP, visible through the release state on the object and enforced by the ABAP Cloud compiler. |
ABAP language version | A package-level setting: standard ABAP, ABAP for Cloud Development, or ABAP for key users. Determines what the compiler will accept. |
Extension field | A field added through key user tooling, stored in an append or extension include and automatically surfaced in the apps that support it. |
Enhancement spot / implicit enhancement | Explicit and implicit points where code can be injected into standard programs. Implicit enhancements are Level D and should be treated as debt. |
Modification | A change to SAP's own source. Requires a repair key, appears in every upgrade adjustment, and is the most expensive object type you can own. |
The point of clean core is not purity, it is upgrade cost
Clean core is often presented as an architectural ideal, which makes it easy to dismiss as consultant language. State it as an economics argument instead and it becomes hard to argue with. Every Level C and Level D object is a liability whose cost is unknown until an upgrade lands, and the amount of it you hold determines whether the next release is absorbed by the operations team or becomes a project with a business case. Organisations that measure clean core do not measure it as a percentage of purity; they measure it as the number of objects that would need touching if SAP shipped tomorrow.
The three tiers are a ladder, and you should always take the lowest rung that works
The order is not arbitrary. Key user extensibility is cheapest to build, cheapest to change, needs no transport of code and survives upgrades by construction, but it is limited to the extension points SAP has surfaced. Developer extensibility with ABAP Cloud is the next rung: full programming power, still inside the system, still constrained to released interfaces. Side-by-side on BTP is the most powerful and the most expensive, because you now own an application, its lifecycle, its identity integration, its monitoring and its bill. The failure mode in both directions is real. Teams that reach for BTP first end up operating a small software company. Teams that refuse to leave the core end up with logic in the core that had no business being there.
Level C is where the honest conversation happens
Level A and Level D are easy to talk about. Level A is fine and Level D is indefensible. Level C, code that reads or calls internal SAP objects that were never released, is where most real estates actually sit, and where the debate gets political. It works today. It has worked for years. And every one of those objects is a bet that SAP will not change something you were never promised would stay still. SAP has said it will publish changelogs for these objects so customers can detect changes earlier, which reduces the surprise but does not remove the exposure. The pragmatic policy most mature estates land on is that Level C is tolerated in place, forbidden in new development, and remediated whenever the surrounding functionality is touched anyway.
Key user extensibility is more capable than developers assume
There is a reflex among experienced ABAP developers to treat in-app extensibility as a toy. It is not. It covers custom fields propagated through the data model and into apps and reports, custom CDS views for reporting, custom business objects with their own persistence and user interface, custom logic in released BAdIs written in a restricted ABAP subset, and custom forms and email templates. A meaningful share of what used to become a development ticket can be delivered by a trained key user in an afternoon, without a transport of code, and it will still be there after the upgrade. The prerequisite is a key user who has been trained and given a governance framework, which is a change management investment rather than a technical one.
Side-by-side is a commitment, so make it deliberately
An extension on BTP is a real application. It needs a runtime, a database or a persistence service, an identity provider integration, an API management strategy, a deployment pipeline, monitoring, an on-call owner and a budget line that recurs. That is entirely appropriate for something with genuine differentiation: a customer-facing portal, a machine learning service, an application that spans several back ends. It is entirely inappropriate for a validation that could have been a BAdI. The test worth applying is whether the thing you are building would still make sense if the ERP behind it were replaced. If yes, it belongs outside. If no, it probably belongs inside, on a released interface.
- Reaching for side-by-side on BTP when a key user extension or a released BAdI would have done. You have just adopted an application with a lifecycle and a bill.
- Dismissing key user extensibility as a toy. It covers custom fields, custom CDS views, custom business objects, logic in released BAdIs, forms and templates.
- Leaving the ABAP language version unset on new packages, so new code lands in classic ABAP and joins the remediation backlog on day one.
- Measuring clean core as a purity percentage instead of as the number of objects that would need touching at the next upgrade.
- Treating Level C objects as fine because they have always worked. They are a bet that SAP will not change something it never promised to keep still.
- Implicit enhancements and modifications. They are Level D, they show up in every upgrade adjustment, and they are the most expensive objects you can own.
SAP Business Technology Platform
The platform everything that is not the ERP core runs on
The account model is the part people get wrong first. A global account is the contractual entity and holds the entitlements you have bought, expressed in service plans and capacity units. Directories group subaccounts for administration and quota. A subaccount is the actual unit of deployment: it has a region, an identity provider assignment, its own members, its own quota drawn from the global account, and it is where you enable a runtime environment. There are three current runtime environments. Cloud Foundry runs buildpack-based applications in Node.js, Java, Python and more, and is the default for CAP-based development. Kyma is a managed Kubernetes runtime for containerised and event-driven workloads and serverless functions. The ABAP environment, informally Steampunk, runs ABAP Cloud on BTP for teams that want to extend in the language they already know. The legacy Neo environment is being retired, with services on it sunsetting through 2028, and existing Neo applications need migrating to multi-cloud. On top of the runtimes sit the service groups: Integration Suite, Datasphere and Business Data Cloud, SAP Analytics Cloud, SAP Build, Cloud Identity Services, AI Core and the Generative AI Hub, and a long list of technical services from HANA Cloud to Object Store.
Service plan | A specific tier of a service, for example hana standard or integration-suite enterprise. Entitlements are granted per plan, not per service. |
Space | The Cloud Foundry subdivision inside a subaccount where applications are deployed, with its own developers and auditors. |
Role collection | The BTP unit of authorisation. Groups roles from applications and is mapped to a group or attribute from the identity provider. |
Trust configuration | The link from a subaccount to an identity provider, normally SAP Cloud Identity Services acting as a proxy to the corporate one. |
Capacity Unit | The consumption currency for the CPEA and BTPEA commercial models. Services draw from one pool at published rates. |
Get the account model right early, because it is painful to change
Subaccounts are the boundary for region, for identity provider trust, for quota and for administrative access. That makes the subaccount layout an architectural decision, not an administrative one. The pattern that ages well is one subaccount per environment per domain, so development, test and production are separate subaccounts, and a genuinely separate business domain or region gets its own set. The pattern that causes trouble is a single production subaccount holding everything, because every developer who needs to deploy anything ends up with rights in the subaccount that also runs the integration flows carrying payroll data. Splitting later means moving applications, service instances and destinations, which is a project.
Cloud Foundry, Kyma or ABAP is a team question first
The technical comparison is real but secondary. Cloud Foundry gives you the shortest path from a CAP project to a running application, with SAP-managed buildpacks and a mature service binding model. Kyma gives you Kubernetes, which is right if you already have container expertise, need fine-grained scaling, or are building event-driven services, and wrong if choosing it means one person in the organisation understands the runtime. The ABAP environment lets an existing ABAP team build cloud extensions without becoming JavaScript developers, and it integrates naturally with on-stack development, at the cost of a smaller ecosystem. The best predictor of success is which runtime your team can operate at three in the morning.
The Cloud Connector is the most misunderstood component in the platform
It is a small Java application you install inside your own network. It opens an outbound TLS connection to a specific BTP subaccount and keeps it open. Traffic from BTP to your systems flows back down that connection, which means no inbound firewall rule and no exposed endpoint. Crucially, it exposes only what you explicitly configure: a mapping of virtual host to internal host, per protocol, and per resource path, so an HTTP mapping that allows /sap/opc/odata/x does not allow /sap/bc/soap/rfc. Two common mistakes: running a single Cloud Connector with no high availability, so a patch means an integration outage, and configuring an over-broad resource path because it was quicker, which quietly turns a tightly scoped tunnel into a general-purpose door.
Neo is ending, and the migration is not a lift and shift
The Neo environment was SAP's original proprietary platform. It is being wound down, with individual services announcing sunset dates through 2028. Migration to Cloud Foundry or Kyma is not a redeployment: the identity model, the destination and connectivity services, the persistence options and the HTML5 application repository all differ. SAP publishes migration guidance per service, and the realistic planning assumption is that a Neo application of any substance is a rewrite of its infrastructure concerns with a reused business logic core. If you still have Neo in 2026, this is a dated liability with a published expiry, and it should be on a roadmap rather than in a backlog.
Entitlements are where projects stall for a week
A service is not available in a subaccount until the entitlement has been assigned from the global account, the quota is non-zero, and in some cases the service has been enabled in the subaccount's environment. Because these are three different screens administered by potentially three different people, the observed symptom is a developer saying the service does not exist in their region when in fact nobody has granted it. Add to that the fact that service availability genuinely does vary by region and by provider, and the first hour of any BTP project is well spent confirming that what the architecture assumes is actually purchasable in the region chosen.
- Designing the subaccount layout as an administrative afterthought. It is the boundary for region, identity provider trust, quota and access, and it is painful to change later.
- Choosing Kyma because Kubernetes is modern, when nobody in the organisation can operate a cluster at three in the morning.
- Running a single Cloud Connector with no high availability, so patching it is an integration outage.
- Configuring an over-broad Cloud Connector resource path because it was quicker, which turns a tightly scoped tunnel into a general-purpose door.
- Assuming a service is available because it exists. Entitlement, quota and regional availability are three separate things and any one of them blocks you.
- Still running applications on the Neo environment in 2026 without a migration plan, when services on it are sunsetting through 2028.
Integration
How SAP talks to everything else, and to itself
SAP Integration Suite is the BTP service that has replaced SAP Process Integration and Process Orchestration as the strategic middleware. Its capabilities are distinct and licensed as a bundle. Cloud Integration is the pipeline engine, formerly known as CPI, where integration flows transform and route messages across a large adapter library. API Management publishes, secures, throttles and monetises APIs through a developer portal, and Graph is a sub-capability that presents a unified business data graph across SAP applications. Event Mesh distributes events in a publish and subscribe model, with Advanced Event Mesh, built on Solace, for high-volume and high-durability event streaming. Integration Advisor uses machine learning to propose mappings for business-to-business message formats and generates runtime artefacts. Trading Partner Management handles partner onboarding and EDI, and Open Connectors provides prebuilt connectivity to more than a hundred and fifty non-SAP SaaS applications. Edge Integration Cell lets you run integration flows and API proxies inside your own Kubernetes cluster when data must not leave a jurisdiction. Underneath all of it, on the SAP side, the classic protocols persist: IDoc for asynchronous document exchange, RFC and BAPI for synchronous function calls, and the newer OData and REST APIs published in the SAP Business Accelerator Hub.
Integration flow (iFlow) | The deployable unit in Cloud Integration: one sender, a processing pipeline, one or more receivers, with its own runtime configuration. |
Message Processing Log | The per-message record in Cloud Integration. Status, attachments, custom headers, and the first place to look when someone says an interface is broken. |
Partner profile (WE20) | The on-premise configuration that determines which IDoc types go to which partner, through which port, in which mode. |
Queue (SMQ1 / SMQ2) | Outbound and inbound qRFC queues. When a queue is blocked, everything behind it stops, silently, until somebody looks. |
API proxy | The managed front door for a backend service, where policy, key validation and quota are enforced. |
Choose the pattern before choosing the tool
Most integration arguments are actually pattern arguments in disguise. Synchronous request and response is right when the caller cannot proceed without the answer and can tolerate the coupling. Asynchronous messaging is right when the caller should not wait and the receiver may be down. Events are right when the publisher genuinely does not know or care who consumes them. Replication is right when a consumer needs a local copy for performance or availability. Once the pattern is settled, the tool is usually obvious, and a great deal of expensive middleware exists because somebody chose the tool first and then bent the pattern to fit it.
IDoc is not legacy just because it is old
IDoc has an asynchronous, guaranteed-delivery, fully auditable model with tooling for reprocessing that most modern stacks still lack. It carries an immense share of real SAP traffic today and will for years. The reasons to move a specific interface off IDoc are concrete: you need synchronous behaviour, you need a payload IDoc cannot express, or the partner cannot handle it. The reason not to is equally concrete: the replacement must reproduce the delivery guarantees and the error handling, and most quick REST replacements do not, which is discovered the first time a receiver is down for an hour.
The two Event Mesh products are genuinely different
SAP Event Mesh, the standard capability, is fine for moderate volumes of small business events between SAP systems and a handful of subscribers, and it has hard ceilings on message size and throughput. Advanced Event Mesh is an OEM of Solace PubSub+, with dedicated brokers, much larger messages, large persistent storage, replay and a proper event portal. Designing an event-driven architecture against the standard capability and then discovering the limits during load testing is a common and avoidable failure. Establish the volume, message size and retention requirements first, and pick accordingly, because the migration between them is not a configuration change.
Process Orchestration is ending, and the migration is a rewrite of the middle
SAP Process Integration and Process Orchestration are on a published end-of-maintenance path, and Integration Suite is the successor. The Migration Assessment capability inventories existing interfaces and grades how mechanically they can move. The honest expectation is that simple mappings migrate with tooling assistance and complex scenarios, particularly those using Business Process Management, custom adapter modules or Java mappings, are redesigned. Programmes that budget for a conversion and discover a redesign are the norm rather than the exception, and the way to avoid it is to run the assessment early enough that the answer can still influence the plan.
Monitoring is the part everyone underfunds
An integration landscape without proactive monitoring does not fail loudly; it fails quietly and is discovered by a business user three days later. The minimum viable position is alerting on failed messages in Cloud Integration, on blocked qRFC queues, on IDocs in error status, and on certificate expiry, with each alert routed to a team that owns the interface rather than to a shared mailbox. The most common single cause of a preventable integration outage in the SAP world remains an expired certificate that somebody knew about and nobody owned.
- Choosing the tool before choosing the pattern, then bending a synchronous API into a job that needed guaranteed asynchronous delivery.
- Replacing an IDoc interface with a REST call without reproducing the delivery guarantee and the reprocessing tooling, then discovering the gap the first time a receiver is down.
- Designing an event-driven architecture against standard Event Mesh and hitting its message size and throughput ceilings during load testing.
- Budgeting a Process Orchestration migration as a conversion when anything using BPM, Java mappings or custom adapter modules is a redesign.
- Monitoring integration by waiting for a business user to complain. Failed messages, blocked queues, IDocs in error and expiring certificates all need owned alerts.
- Letting each project invent its own error handling, so the estate has fifteen different ways for a message to fail quietly.
Data & Analytics
Where the numbers go once they are more than one system's business
SAP Business Data Cloud, announced in February 2025, is the current umbrella. It bundles SAP Datasphere as the data fabric and semantic modelling layer, SAP Analytics Cloud as the analytics and planning front end, SAP BW/4HANA private cloud edition so existing BW estates can move inside without a cutover, and SAP Databricks embedded natively for lakehouse workloads, data science and generative AI. The organising concept is the data product: a governed, versioned, semantically described dataset produced by Foundation Services from an SAP application such as S/4HANA, SuccessFactors, Ariba or Concur, with lineage and metadata attached. Data products are consumed rather than copied, using Delta Sharing so that Databricks and Datasphere can read the same physical data without duplication. Insight Apps sit on top as prebuilt analytical applications for defined business areas. Alongside all of that, S/4HANA still ships embedded analytics for operational reporting on live transactional data, and the architectural discipline is knowing which questions belong to which.
Space | The Datasphere unit of isolation and governance: its own storage quota, its own members, its own connections and shared objects. |
Analytic model | The Datasphere object that exposes measures and dimensions for consumption by SAC and other clients. |
InfoProvider / ADSO | The BW modelling objects. Still central for any estate with a BW history, and now hostable inside Business Data Cloud. |
Data product | The BDC unit of exchange: a described, governed dataset with a defined producer, schema and lineage. |
Story / Model | The SAP Analytics Cloud consumption objects. A model holds the data and the planning logic; a story presents it. |
Embedded versus warehouse is not a religious question
S/4HANA can report on live transactional data, and for operational questions that is strictly better than extracting to a warehouse and answering yesterday's version. Use embedded analytics for anything where the answer must reflect the current state of the operational system and where the scope is that system. Use a warehouse or lakehouse for anything crossing systems, anything needing history beyond your archiving policy, anything needing heavy transformation, anything mixing SAP and non-SAP data, and anything where analytical load would compete with transactional load. The failure mode in both directions is familiar: teams that put everything in the warehouse rebuild reports SAP already ships, and teams that put everything in the core discover that a heavy analytical query and a month-end close do not share a system politely.
Zero copy is a strong claim, so understand what it means
Business Data Cloud's positioning rests on data products being shared rather than duplicated, using Delta Sharing between the Databricks lakehouse and Datasphere. That is real, and it removes a genuine class of pipeline and reconciliation work. What it does not mean is that no data ever moves. Foundation Services still extract from the source applications, and there is still a physical landing of data products. The accurate framing is that the copying between the analytical tools has largely gone, not that extraction from the operational systems has. Teams that hear zero copy and plan for no extraction latency are setting an expectation they will have to walk back.
BW is not dead, and the private cloud edition is the reason
A large share of SAP customers have a decade or more of BW models, transformations and reports that encode business rules nobody wrote down anywhere else. Business Data Cloud hosts BW/4HANA as a private cloud edition inside it, which extends the supported runway and, more importantly, means the migration to Datasphere can be gradual and per-model rather than a single cutover. The strategy that works is to stop building new content in BW immediately, host the existing system, and migrate models when the business asks for a change to one, so that migration effort follows business value rather than an inventory list.
The Databricks inclusion changed who can use SAP data
Historically, getting SAP data into a data science environment meant an extraction project, a licensing conversation and an argument about semantics. Embedding Databricks inside Business Data Cloud, with data products carrying their semantics with them, removes most of that friction. The consequence worth planning for is organisational rather than technical: data scientists who previously worked around SAP will now work on it, and the governance model for who can see which data product needs to exist before that happens rather than after. Spaces, data product ownership and the underlying authorisation model are the controls, and they are much easier to set up on an empty platform than on a busy one.
There are now three consumption meters to forecast
AI Units for SAP Business AI, Capacity Units for BTP services, and Business Data Cloud credits are separate pools with separate rates. Analytics workloads in particular have a habit of growing quietly, because a dashboard nobody uses still refreshes. Any serious BDC design should include a consumption model with an owner, alerting on burn rate, and a periodic review of what is actually being read. This is the same discipline that cloud infrastructure teams learned a decade ago, arriving in the SAP world through a different door.
- Hearing 'zero copy' and planning for no extraction latency. The copying between analytical tools has largely gone; extraction from the operational systems has not.
- Rebuilding in a warehouse the operational reports that S/4HANA already ships as embedded analytics.
- Running heavy analytical workloads on the transactional system during month-end close and being surprised that they compete.
- Planning a BW to Datasphere migration as one cutover instead of hosting BW in Business Data Cloud and migrating models when the business asks for a change.
- Opening a Databricks workspace over SAP data products before deciding who is allowed to see which data product.
- Leaving consumption unforecast across three separate meters: AI Units, Capacity Units and Business Data Cloud credits.
SAP Business AI
Joule, agents, and the platform underneath them
The context layer is AI Foundation on BTP. It contains the Generative AI Hub, which brokers access to external foundation models through one interface, one set of credentials and one usage meter, alongside SAP's own models such as SAP-ABAP-1 and SAP-RPT-1; the SAP Knowledge Graph, which encodes SAP process and data semantics so a model reasons about a purchase order rather than about a row; and Business Data Cloud as the grounding data layer. AI Core is the runtime that trains, deploys and serves models, with AI Launchpad as its administrative front end. The build layer is Joule Studio, generally available since June 2026, with a visual agent builder, a large library of prebuilt SAP skills, a command-line interface for pipelines, and Model Context Protocol support for connecting external tools. The governance layer is SAP AI Agent Hub, built on LeanIX, which discovers agents across SAP and non-SAP platforms and provides inventory, observability and the audit trail that the EU AI Act expects. Joule itself is the shared front end across desktop, mobile and voice, and Joule Work is the emerging workspace model where the user states an intent and agents execute it.
Skill | A discrete capability an agent can invoke, usually wrapping an API call or a defined action in an SAP application. |
Agent | A configured combination of instructions, skills, grounding data and guardrails that pursues a goal rather than answering a question. |
Scenario / Configuration / Deployment | The AI Core object chain: what to run, with which parameters, and the running instance of it. |
Grounding | Attaching enterprise content or data products to a model interaction so the answer is drawn from your data rather than from training data. |
Orchestration | The Generative AI Hub pipeline that composes templating, model call, content filtering and data masking into one governed request. |
Grounding is the entire architecture question
A model with no access to your data can write a plausible sentence about a purchase order. A model grounded in your data can tell you which purchase order is late. Everything interesting about SAP Business AI is on the grounding side: the Knowledge Graph supplying process semantics, Business Data Cloud supplying governed data products, and document grounding supplying unstructured content. It follows that an organisation whose master data is inconsistent and whose data products do not exist will get confident and useless answers, at cost. The unglamorous prerequisite for AI value in SAP is the same prerequisite as for analytics, and it is data quality.
Agents change the authorisation question, and nobody is fully ready
An assistant that answers questions inherits the user's authorisations and is comparatively easy to reason about. An agent that acts raises a harder question: does it act as the user, as a technical account, or as itself, and who is accountable for what it did. SAP's answer is developing through the AI Agent Hub, guardrails and observability, and the regulatory pressure from the EU AI Act is pushing inventory and logging requirements forward. The practical guidance for 2026 is to treat every agent as a named non-human identity with an owner, a scope, a log and a review date, and to insist on that before the first agent goes live rather than during the first audit.
The commercial model changed, and it changes designs
The RISE with SAP Premium Plus tier was discontinued in June 2025 and its capabilities redistributed. Consumption now runs through AI Units, metered by tokens and varying substantially by model choice, alongside BTP Capacity Units and Business Data Cloud credits. This has a direct architectural consequence: model selection is a cost decision as well as a quality decision, and a design that calls a frontier model for every line of a document will cost an order of magnitude more than one that filters first and calls selectively. Building a cost model at design time, and instrumenting actual consumption from day one, is now part of the architecture rather than part of procurement.
Joule Work is the direction of travel worth watching
Joule started as a copilot inside applications. Joule Work, in early adopter release through 2026, is a unified workspace that takes an intent and delegates execution to agents across business functions, with mobile and voice surfaces alongside. If that direction holds, the long-term consequence is that the launchpad stops being the primary navigation model for a large class of users, and application design shifts from screens toward capabilities that an agent can compose. It is too early to build a strategy entirely on that assumption, and it is too late to design new applications as though it will not happen.
Be specific about what is shipped and what is roadmap
SAP's AI announcements move quickly and the gap between announced, early adopter, beta and generally available is significant. As of the Q2 2026 release, the Expense Automation, Process Consulting and Enterprise Content Research agents are generally available; Order Reliability and Project Billing Price Verification are in beta; Joule Work and Voice for Joule are early adopter; and the AI Agent Hub was targeting general availability in the third quarter. Any architecture document that says SAP Business AI without qualifying which components at which status will be wrong within a quarter. Cite the status, date the statement, and design so that a beta component can be swapped.
- Expecting value from AI over data that is inconsistent. Grounding is the whole architecture, and bad master data produces confident, wrong answers at cost.
- Deploying an agent that acts without deciding whose authorisations it acts under and who is accountable for what it did.
- Ignoring model choice as a cost decision. Calling a frontier model for every line of a document costs an order of magnitude more than filtering first.
- Citing 'SAP Business AI' in an architecture document without qualifying which component at which release status, which will be wrong within a quarter.
- Building a strategy entirely on Joule Work while it is still early adopter, or designing new applications as though agentic access will never arrive.
- Treating agents as features rather than as non-human identities that need an owner, a scope, a log and a review date.
Security & Authorization
Who can do what, in a system that expresses it in unusual ways
In the ABAP world, a user has one or more roles, each role generates an authorisation profile, and the profile contains authorisation objects with concrete field values. An authorisation object such as M_BEST_BSA has fields for activity and document type, and code that wants to check a permission issues an AUTHORITY-CHECK against the object with the values in play. The role maintenance transaction, PFCG, builds these from a menu of transactions and apps, deriving the objects from the profile generator and letting the security team fill the field values. S/4HANA layers business roles on top, which combine authorisations with Fiori catalogs and spaces, so a role determines both what appears and what is permitted. Segregation of duties is the discipline of ensuring no single role, and no combination of roles held by one person, allows both sides of a sensitive process. In the cloud, SAP Cloud Identity Services provide Identity Authentication for single sign-on and multi-factor authentication, Identity Provisioning for pushing users and groups between systems over SCIM, and the Identity Directory as the user store, with Cloud Identity Access Governance adding access analysis, request and certification. SAP Identity Management, the on-premise product, reaches end of maintenance in 2027, which is why identity governance replacement projects are common right now.
USR02 | User master header: user type, lock status, password data, validity. The first table in almost every user audit. |
AGR_USERS / AGR_1251 | Role assignments to users, and the authorisation values inside roles. The pair behind almost every 'who can do what' query. |
SU24 | The proposal data linking transactions and services to authorisation objects, which is what the profile generator uses. Maintaining it well is the difference between clean roles and manual ones. |
USOBT_C / USOBX_C | The customer tables behind SU24 proposals. If your roles keep growing manual authorisations, this is usually where the neglect is. |
Emergency access (firefighter) log | Whatever your privileged access tool records. Unread firefighter logs are one of the most common audit findings in SAP estates. |
SAP authorisations are multidimensional, and that is why they are hard
In most systems a permission is a verb on a noun: read this, edit that. In SAP a permission is a verb on a noun, restricted by organisational dimensions, checked at the point in code where it matters. The same person may create purchase orders in one plant and only display them in another, and that is expressed as field values on the same authorisation object. This is genuinely more expressive than a flat model, and genuinely harder to reason about. It is also why generic identity governance tools that model SAP as a list of groups produce a picture that is technically accurate and practically useless: the group is the role, but the risk lives in the field values inside it.
SU24 is the leverage point almost nobody maintains
When you add a transaction or a Fiori app to a role menu, the profile generator proposes authorisation objects and default values based on SU24 data. If SU24 is well maintained for your custom transactions and your adjusted standard ones, roles generate cleanly and consistently. If it is not, every security administrator fills in objects by hand, differently, and the estate accumulates roles that nobody can regenerate without breaking. Investing in SU24 is unglamorous, invisible to the business, and produces a compounding return for the entire life of the system. It is the closest thing SAP security has to paying down interest.
Segregation of duties is a design problem before it is a reporting problem
Most organisations discover segregation of duties by running an analysis against an existing role landscape and receiving several thousand conflicts. That is the expensive order. The cheap order is to define the conflict ruleset first, design roles so that a single role cannot contain both sides of a conflict, and use the analysis to catch drift rather than to discover the design. Detective controls will always be needed for combinations that arise from multiple role assignments, but a role design that is conflicted internally guarantees a permanent remediation backlog. And a mitigating control is only a control if somebody actually performs it and can evidence that they did.
The cloud identity picture is a small number of pieces that people confuse
Identity Authentication is authentication: who you are, single sign-on, multi-factor, conditional access. Identity Provisioning is distribution: taking users and groups from a source and writing them into targets over SCIM. The Identity Directory is the store behind Identity Authentication. Cloud Identity Access Governance is governance: risk analysis, access request, certification. They are frequently discussed as one thing because they are sold together, and the resulting confusion produces designs where somebody expects provisioning to enforce a policy it has no knowledge of. Keep them separate in your head and the architecture becomes straightforward.
SAP IDM ends in 2027, and the replacement decision is strategic
SAP Identity Management reaches end of mainstream maintenance in 2027, with extended options into 2030 for some customers. Since SAP has not shipped a like-for-like on-premise successor, the realistic paths are the cloud identity services combined with Cloud Identity Access Governance, or a third-party identity governance platform, or a hybrid. The decision is strategic rather than technical, because it determines who owns joiner, mover and leaver for the whole estate, not just for SAP. The mistake to avoid is treating it as an SAP tooling migration, which produces a replacement for IDM's SAP scope and leaves the non-SAP scope orphaned.
Patching is a security control, and the cycle is monthly
SAP publishes security notes on Patch Day, the second Tuesday of each month, with CVSS scores, and HotNews notes are the critical subset. In on-premise and Cloud ERP Private, assessing and applying these is the customer's responsibility, and in practice it is one of the responsibilities most commonly assumed to be covered by a RISE contract when it is not. The minimum defensible position is a documented monthly process with an owner, a risk assessment per note, an application window, and evidence. Estates that skip this end up patching under incident conditions, which is the most expensive way to do it.
- Modelling SAP authorisations as a flat list of groups. The role is the group, but the risk lives in the field values inside it.
- Leaving SU24 proposals unmaintained, so every role is filled in by hand, differently, and none can be regenerated safely.
- Discovering segregation of duties by running an analysis against an existing role landscape rather than designing the roles against a ruleset in the first place.
- Counting a mitigating control as a control when nobody performs it and no evidence exists that they did.
- Confusing Identity Authentication, Identity Provisioning and Cloud Identity Access Governance, then expecting provisioning to enforce a policy it knows nothing about.
- Assuming a RISE contract covers SAP Notes and HotNews assessment. In most service descriptions it does not.
- Treating the SAP IDM end of maintenance as a tooling migration, which produces a replacement for the SAP scope and orphans everything else.
Landscape & Lifecycle
How change gets from an idea into production without breaking it
The conventional landscape is three systems: development, quality assurance and production, connected by a transport route so that changes flow in one direction only. Larger estates add sandbox and pre-production systems and sometimes a separate maintenance track for urgent fixes. The Change and Transport System moves ABAP objects and customising; git-enabled CTS, known as gCTS, brings git semantics to ABAP transports; and Cloud Transport Management on BTP moves cloud content between subaccounts. On the operations side, SAP Cloud ALM is the strategic tool for implementation and operations, covering requirements, tasks, tests, monitoring and analytics, and it is what RISE customers get; SAP Solution Manager remains in many on-premise estates with maintenance to the end of 2027, extended to 2030. Upgrades use Software Update Manager, with Database Migration Option for the combined move to HANA, planned in Maintenance Planner and assessed in advance by SAP Readiness Check. SAP Activate is the methodology wrapper: discover, prepare, explore, realise, deploy and run, built around fit-to-standard rather than blueprint-and-build.
Transport request | The unit of change: an owner, a description, tasks per developer, an object list, and a release that exports it to the transport directory. |
Transport route | The configured path from development to quality assurance to production, plus consolidation and delivery targets for multi-track landscapes. |
Import queue | What is waiting to go into a system, in order. Importing out of order is the single most common cause of self-inflicted inconsistency. |
Support Package Stack | A consistent, SAP-tested combination of support package levels across components. Always apply stacks, not individual packages. |
Readiness Check item | A finding from the pre-conversion analysis: simplification items, custom code findings, add-on compatibility, sizing and data volume. |
The transport path is a control, and shortcuts destroy it
The value of a one-directional transport path is that production contains exactly what test contained, so a successful test means something. Every shortcut erodes that. A change made directly in production is invisible and will be silently overwritten by the next import. A transport imported into production but not into the maintenance track will reappear as a regression. Two developers changing the same object in two open requests produce an overtake, where whichever imports last wins regardless of which is correct. None of these are exotic. They are the routine failure modes of every estate that treats the transport path as an obstacle.
Conversion versus implementation is the largest single decision in an S/4HANA programme
A brownfield conversion keeps the history, the configuration and the custom code, and delivers a technically new system running the old process. A greenfield implementation delivers a new process and leaves behind everything that was not deliberately carried across, including the accumulated workarounds. Conversion is faster, cheaper and lower risk to the business, and it preserves whatever debt you have. Implementation is slower, more expensive and much harder on the organisation, and it is the only route that actually changes how the company works. The honest question is not which is technically better. It is whether the organisation has the appetite for process change, and answering that honestly at the start prevents the most common programme failure, which is a conversion sold as a transformation.
Readiness Check earns its cost before the project starts
SAP Readiness Check runs against your existing system and produces the list of things that will complicate a conversion: simplification items that need functional decisions, custom code that will not compile, add-ons without a compatible version, sizing implications, data volume, and business process discovery. Running it early, when the answer can still change scope and budget, is one of the highest-return activities in the whole programme. Running it late, when the plan is fixed, converts it from a planning tool into a list of surprises. The same is true of the custom code analysis: knowing that seventy percent of your custom objects have not been executed in a year changes the remediation conversation entirely.
Cloud ALM is where the tooling is going, and the transition is real work
SAP Cloud ALM is the strategic application lifecycle management platform and is included with cloud contracts. Solution Manager remains supported to the end of 2027 with extended maintenance to 2030, and remains genuinely more capable in some areas that mature on-premise estates depend on, particularly deep technical monitoring and certain change control scenarios. The pragmatic path is to adopt Cloud ALM for new implementation and testing work now, keep Solution Manager for the operational scenarios it still does better, and re-evaluate annually as Cloud ALM closes gaps. Treating it as a one-day switch, in either direction, produces a period where neither tool is trusted.
Release cadence sets your calendar, so put it in the plan
SAP Cloud ERP upgrades quarterly on SAP's schedule, which means four regression cycles a year that you do not control the date of, and an automated test suite stops being a nice-to-have. S/4HANA on-premise and Cloud ERP Private follow a two-year major release cadence with feature package stacks in between, which means an upgrade project you can schedule but must budget for. Either way, the mistake is to treat upgrade as an unplanned event. Mature estates hold a standing regression pack, a named owner for release assessment, and a calendar entry that exists before SAP announces the date.
- Changing anything directly in production. It is invisible to the transport path, it will be overwritten, and it undermines every test result you have.
- Importing transports out of sequence, which quietly overwrites newer objects with older ones.
- Running Readiness Check late, when the plan is fixed, so it produces a list of surprises instead of an input to scope.
- Skipping the custom code usage analysis and remediating objects that nobody has executed in a year.
- Applying individual support packages instead of tested support package stacks.
- Treating an upgrade as an unplanned event, with no standing regression pack and no named owner for release assessment.
- Switching wholesale between Solution Manager and Cloud ALM in one step, producing a period where neither tool is trusted.
The Wider SAP Portfolio
Everything around the ERP that is also called SAP
SAP SuccessFactors covers human capital management, from core HR in Employee Central through recruiting, learning, performance and compensation, and is very often the authoritative source of worker identity for the whole enterprise. SAP Ariba covers sourcing, contracts, procurement and supplier management, with the Business Network connecting buyers and suppliers. SAP Concur covers travel and expense. SAP Fieldglass covers external workforce and services procurement, which matters enormously for identity because it is where contractors are managed. The customer experience portfolio covers sales, service, commerce and customer data. SAP Integrated Business Planning covers supply chain planning. SAP Signavio covers process mining and process management, and SAP LeanIX covers enterprise architecture management and now underpins the AI Agent Hub. SAP Business Network connects trading partners across procurement, logistics and asset management. Each of these has its own tenant model, its own identity integration, its own extensibility model and its own upgrade schedule, and the integration between them is a first-class architectural concern rather than a project detail.
Employee Central worker | The SuccessFactors worker record, with employment, job and personal sub-objects, and effective-dated history throughout. |
Ariba realm | The Ariba tenant identifier. Buyers and suppliers each have realms, and network transactions reference both. |
Concur expense report | The unit of travel and expense processing, with policy, approval and posting to finance. |
Fieldglass worker | The external worker record. Often the only system that knows a contractor's actual end date. |
Business Network document | Purchase orders, invoices, ship notices exchanged between trading partners across the network. |
The authoritative source question is the one to settle first
In an estate with SuccessFactors, Fieldglass, Active Directory and S/4HANA, four systems believe they know who works here. Deciding which is authoritative for which population, and for which attributes, is the single highest-leverage design decision in the whole landscape. The pattern that works is SuccessFactors as authoritative for employees, Fieldglass for external workers, and everything else downstream of one of those two, with the identity provisioning layer enforcing it. The pattern that fails is allowing each application to be maintained locally because it was quicker during implementation, after which nobody can answer the question of who has left.
Prebuilt integration content is real, and it is not free
SAP ships integration packages for the common flows between its own applications, and they genuinely reduce effort. What they do not do is make the integration free: the packages still need configuration, mapping of your organisational values, error handling that fits your operating model, monitoring, and someone who understands them when they break at month end. The failure mode is planning an integration as a configuration task because a package exists, and discovering during test that the package assumed an organisational structure you do not have.
Each application has its own release cadence, and they do not align
SuccessFactors releases twice a year on a published schedule with opt-in and universal features. Ariba, Concur and Fieldglass have their own cycles. SAP Cloud ERP is quarterly. S/4HANA on-premise is every two years. The consequence is that an estate of six SAP products has something upgrading almost every month, and each upgrade can affect an interface. Mature estates maintain a single release calendar across all products with named owners, and treat interface regression as a standing activity rather than a per-project one.
Extensibility differs per product, and the skills do not transfer cleanly
S/4HANA extensibility is key user tools, ABAP Cloud and BTP. SuccessFactors has its own metadata framework, business rules and intelligent services. Ariba has its own customisation model and its own limits. Commerce Cloud is a Java platform. A team that has learned to extend S/4HANA cleanly does not automatically know how to extend SuccessFactors safely, and the same clean core principle applies in each: use the sanctioned extension points, avoid the ones that will not survive an upgrade, and resist the temptation to solve a product's limitation by building around it in BTP unless the case is genuinely strong.
The portfolio is why BTP exists
If SAP were one product, extensions could live inside it. Because SAP is a dozen products with different runtimes, different release schedules and different extension models, there has to be one place where cross-application logic, unified user experience, shared identity and enterprise-wide integration live. That is the strategic argument for BTP, and it is a good one. It also explains why BTP feels like several unrelated things at once: it is not one platform serving one product, it is the connective tissue for a portfolio.
- Never settling which system is authoritative for which population, so four systems each believe they know who works here.
- Maintaining users locally in each application because it was quicker during implementation, after which nobody can answer who has left.
- Planning a prebuilt integration package as a configuration task and discovering in test that it assumed an organisational structure you do not have.
- Managing release calendars per product, so six products upgrade on six schedules and interface regression is always somebody else's problem.
- Assuming that a team who can extend S/4HANA cleanly knows how to extend SuccessFactors or Ariba safely. The extension models do not transfer.
- Forgetting Fieldglass in the joiner, mover and leaver design, which is how contractor access outlives contractors.
What actually happens, step by step
The fastest way to understand an architecture is to follow one thing all the way through it. These seven traces each follow a different journey across the same stack, from a user saving a change in a Fiori app to a number on a dashboard traced back to the posting that created it. Colours mark where each step actually happens.
Every layer of the modern stack appears exactly once in this path: the launchpad, the OData service, the RAP behaviour, the CDS view, the ABAP work process, the enqueue server, the update task and the HANA column store. If you can narrate it, you can debug it.
This is the integration story that made SAP what it is, and in S/4HANA it is also the clearest demonstration of what the Universal Journal changed.
Because the 2027 maintenance date makes this the single most common large SAP programme running right now, and because most of the pain in it is predictable from this list.
Because most integration incidents are not application faults, and knowing this sequence tells you exactly which of the five places to look first.
This is the trace that makes destinations, the Cloud Connector and principal propagation stop being abstract words on a slide.
Because the useful mental model is that AI is a new kind of caller of the same platform, not a new platform, and everything about accountability follows from that.
Because the question a finance director asks is always where did this number come from, and an architecture you cannot answer that question about is not finished.
The sequence that explains most of your SAP problems
When somebody says an SAP transaction failed, they usually mean it succeeded in one place and failed in another. This is what actually happens between a user pressing save and a row existing in the database, and it is the sequence that explains the majority of behaviour that otherwise looks like the system being arbitrary.
From keystroke to committed row, at a glance
The same sequence runs whether the caller was a Fiori app, an OData request from an extension, an RFC from another SAP system or an AI agent skill.
Scroll the diagram sideways, or tap Enlarge for a bigger view
In the browser, before anything is sent
Browser- Field-level checks defined in the metadata or the UI5 controller run locally, so the obvious mistakes never reach the server
- For a draft-enabled object the edits have already been persisted as a draft as the user typed, and Save is the request to make the draft active
- None of this is trusted by the server. It is convenience, not control, and an OData call from a script never sees any of it
The request arrives and takes a work process
App server- The ICM terminates the connection and the dispatcher assigns a dialog work process
- The user context is rolled in: authorisations, parameters, and whatever state belongs to this session
- There is a finite number of dialog work processes, and a long-running report holding several of them is what a frozen system usually is
- A dialog step that runs longer than the configured maximum is terminated by the runtime, which is why long work belongs in a background job and not in a screen
Authorisation, before any business logic
App server- Checks read the authorisation buffer that was built when the user logged on, not the current contents of the role tables
- This is why a newly granted role often appears not to work: the buffer is stale until the session is refreshed
- A check is against an authorisation object with specific field values, so having the object is not the same as being allowed the value
- The trace of a failed check names the object and the values that were required, which turns most access incidents into a two minute answer
Business logic runs against a buffer, not the database
App server- In RAP, determinations derive values, validations decide acceptability, and actions perform modelled operations, all inside a transactional buffer in memory
- In classic ABAP the same idea is expressed as a SAP logical unit of work: function modules registered for update, executed later
- Either way, nothing is on disk yet, and reading the database at this point will not show you what the user has just done
- This is also where custom logic in a released BAdI executes, at a point SAP has committed to keeping stable
The lock is taken
App server- A logical lock is requested from the central enqueue server before the save proceeds
- This is an SAP construct and not a database lock, and it protects a business object rather than a row
- One enqueue server serves the whole system, which is why it is a single point worth understanding and why enqueue wait time is a meaningful metric
- Locks left behind by a crashed session block the document until somebody clears the entry, which is a manual act with an audit trail
COMMIT WORK: the update task writes and commits
SAP HANA- The dialog work process hands the queued updates to an update work process and is free to answer the user
- The update work process performs the inserts and updates and issues the commit; redo is written to the log volume and the change becomes durable
- Because this is asynchronous, a transaction can report success to the user and still fail on write, which appears as an update termination and an express message rather than an error on screen
- Number ranges are drawn here, buffered per server for performance, which is exactly why document numbers have gaps and why gaps are not evidence of missing documents
Inside HANA, the write is not where you think it is
SAP HANA- Column store writes land in the delta store, which is optimised for insert, not in the compressed main store
- A delta merge later moves them into main; that merge costs memory and CPU and is a real answer to why did the system slow down at four in the afternoon
- Savepoints flush pages to the data volume so that recovery does not have to replay the entire log
- In memory does not mean not durable. Every commit is on disk before it is acknowledged
Afterwards, asynchronously
App server- Business events are raised for subscribers, which is how an extension or another system learns that something happened without polling
- Output determination may queue a document for printing, emailing or transmission to a partner
- Background jobs pick up anything deliberately deferred, and their scheduling is a design decision rather than an operational detail
- Change documents and, where configured, read access logging record what happened for the auditor who will ask about it in eleven months
The part of the model everything else depends on
SAP has tens of thousands of tables and you will never learn them. You do not need to. What you need is the handful of structural ideas that everything else is built on, because once those are clear, an unfamiliar table stops being a mystery and becomes an instance of a pattern you already recognise.
The six ideas, and how they hang together
Learn this one diagram properly and an unfamiliar SAP table stops needing to be memorised, because its role can be worked out.
Scroll the diagram sideways, or tap Enlarge for a bigger view
The client is the outermost boundary
Almost every business table in SAP begins with a client field, and almost every query is implicitly filtered by the client the user logged on to. It is a complete, self-contained set of business data inside one system: separate customers, separate documents, separate configuration for anything client-dependent. This is why a training client and a production client can share hardware and share nothing else, and why the mistake of testing in the wrong client is both easy to make and immediately obvious.
Configuration is data, not code
The thing that most distinguishes SAP from a conventional application is that its behaviour is driven by table entries rather than by programming. A company code, a document type, a pricing procedure, a movement type and an account determination rule are all rows. That is why an implementation is largely configuration, why the Implementation Guide is a structured tour of those rows, and why customising travels between systems on a transport just like code does.
Organisational structure is the skeleton
Client, company code, plant, sales organisation, distribution channel, division, purchasing organisation, controlling area. These are not labels: they are the dimensions along which the entire system posts, reports and authorises. They are also close to immutable in practice, because changing a company code after go live means touching every document ever posted against it. This is why the organisational structure workshop happens early and why experienced people take it so seriously.
Master data, then transactional data
Master data describes things that persist: materials, business partners, general ledger accounts, cost centres, assets, employees. Transactional data records events that happened: orders, deliveries, invoices, journal entries, goods movements. Transactional rows reference master data rather than repeating it, which is why bad master data is not a data quality inconvenience but a defect that reproduces itself into every document created from it.
The Universal Journal replaced the aggregates
In the older architecture, finance kept the general ledger, controlling, profitability analysis, asset accounting and the material ledger in separate tables with separate totals, and reconciling them was a real job performed by real people every month. S/4HANA writes one row per line item into ACDOCA, with all the dimensions on it, and derives the totals by aggregating on demand because a column store can do that fast enough. The reconciliation task did not get easier. It ceased to exist.
The Business Partner is the single identity
A customer and a vendor used to be separate objects with separate numbers, which meant that an organisation you both sold to and bought from was two records that did not know about each other. The Business Partner is one object that can carry multiple roles, with customer and vendor as two of them. This is mandatory in S/4HANA, and converting to it is consistently one of the most underestimated parts of a brownfield programme, because it is not a data load: it is a set of decisions about number ranges, about which record wins, and about several hundred interfaces that quote customer and vendor numbers.
CDS views are the model you should actually read
The virtual data model is a layered set of Core Data Services views over the tables. Basic interface views expose an entity cleanly. Composite views combine them into something meaningful. Consumption views serve a specific application or report. The naming matters more than it looks: I_ interface views are intended for you to build on and carry stability expectations, while C_ consumption views exist to serve a particular SAP application and are explicitly free to change. Building custom code on a C_ view because it happened to have the fields you wanted is one of the most reliable ways to break yourself at the next upgrade.
Compatibility views are a bridge, and bridges end
When S/4HANA removed or restructured a table, SAP frequently left a view behind with the old name so that existing read code kept working. Your SELECT against the old finance tables still returns data, from ACDOCA, through a view. What does not work is writing to them, and what is not guaranteed is that the view is as fast as the table used to be. Treat every compatibility view in your custom code as a remediation item with a deadline rather than as a permanent arrangement.
The wider portfolio, and why it is one landscape
S/4HANA is the centre of gravity but it is not the whole estate. Most organisations of any size run several of these, and the architecture question is never what each one does in isolation. It is which system is authoritative for which data, and what carries information between them.
Eight products around the ERP, and what each one really owns
Scroll the diagram sideways, or tap Enlarge for a bigger view
Thirteen arguments you will have, settled
Architecture is mostly choosing between two reasonable options. These are the choices that come up on nearly every SAP programme, with the rule of thumb that usually decides them.
SAP Cloud ERP or SAP Cloud ERP Private?
SAP Cloud ERP (public)
- You are willing to adopt standard processes and change the business to fit them rather than the reverse
- You want quarterly innovation without owning an upgrade project each time
- Your extension requirements fit key user tools and side-by-side applications on BTP
- You have no large body of classic ABAP that has to come with you
SAP Cloud ERP Private
- You are converting an existing system and the process footprint is genuinely differentiated rather than merely familiar
- You need the classic development environment, your own code and a controlled upgrade schedule
- Data residency, industry regulation or a specific certification constrains where and how the system runs
- Your integration estate assumes system-level access that the public edition does not expose
Brownfield conversion or greenfield implementation?
Brownfield conversion
- Your existing processes broadly work and the business case is technology, not transformation
- You need history in the system rather than in an archive
- The organisation cannot absorb a large change programme right now, and the maintenance date is approaching
- Your custom code is defensible and your master data is in reasonable condition
Greenfield implementation
- The point of the programme is to change how the company works, not where it runs
- Decades of accumulated configuration encode decisions nobody can explain or defend any more
- You are consolidating several systems, or splitting one, so the landscape shape changes anyway
- Master data is bad enough that carrying it forward would import the problem into the new system
Key user extensibility or developer extensibility?
Key user extensibility
- You need a custom field, a custom CDS view, a custom business object, a form or logic in a released BAdI
- The change belongs to the business process rather than to an engineering roadmap
- You want the change to be visible in the standard extensibility inventory rather than buried in a package
- You want the upgrade impact to be as close to zero as it can be
Developer extensibility or side-by-side
- The logic genuinely exceeds what the in-app tools express, and you can say specifically how
- You need an independent lifecycle, an independent scaling profile or a user interface the ERP does not host
- The capability is consumed by more than the ERP, so it does not belong inside the ERP
- You need libraries, languages or runtimes the ABAP environment does not offer
Cloud Foundry or Kyma on BTP?
Cloud Foundry
- You want to deploy an application and not operate a platform
- Your team's expertise is application development rather than cluster operations
- The workload is a normal business application with normal scaling needs
- You want the shortest distance between a repository and something running
Kyma
- You already run Kubernetes elsewhere and have the operational capability to prove it
- You need container-level control, service mesh behaviour, or workloads that do not fit a buildpack
- You want portability of the runtime as an explicit architectural goal
- You have serverless and event-driven patterns that Kyma expresses more naturally
Event Mesh or Advanced Event Mesh?
SAP Event Mesh
- You want SAP business events consumed by a handful of subscribers inside BTP
- Message sizes and throughput sit comfortably inside the standard service limits
- The estate is SAP-centric and the topology is simple
- You want the cheapest thing that satisfies the requirement
SAP Advanced Event Mesh
- You are building an event mesh across a hybrid, multi-cloud, multi-region estate
- You need large messages, high sustained throughput, deep queue persistence or replay
- You need dynamic message routing, event portal governance and formal event catalogues
- Events are a strategic architectural layer rather than a tactical decoupling technique
Embedded analytics or a data warehouse?
Embedded analytics in S/4HANA
- The question is operational and the answer is needed now, about current transactional data
- The user is inside the process and wants to act on what they see
- The data lives in this one system and a CDS view already exists or can reasonably be built
- No history beyond what the system holds is required
Datasphere, BW or the lakehouse
- The question spans systems, or spans time in a way the operational system does not retain
- You need harmonised definitions across sources so that revenue means one thing everywhere
- The workload is heavy enough that running it against the transactional system would compete with the business
- You need data science, machine learning or external data blended in
Integration Suite or point-to-point?
Integration Suite
- More than two systems care, or will care, about this information
- You need transformation, routing, monitoring, retry and a place errors can be seen
- The interface crosses an organisational boundary, so somebody must own it explicitly
- You want the estate to be inventoried rather than discovered by archaeology
Direct point-to-point
- It is genuinely two systems, one direction, one payload, and there is a released API for it
- Latency budget makes an extra hop unacceptable and the requirement is documented
- The connection is native, supported and covered by the same operational monitoring anyway
- Adding middleware would add a component nobody would otherwise operate
Cloud ALM or Solution Manager?
SAP Cloud ALM
- You are starting a new programme, especially a cloud or hybrid one
- You want implementation, testing, change and operations in one cloud tool with no infrastructure to run
- Your landscape is increasingly SaaS, where Solution Manager's on-premise assumptions do not apply
- You want to align with where SAP is investing rather than where it has invested
SAP Solution Manager
- You depend on deep capabilities Cloud ALM has not yet matched for your specific case
- Your estate is predominantly on-premise and your processes are built around it
- Migrating now would mean rebuilding working operational tooling in the middle of a delivery
SAP Cloud Identity Services or your existing corporate identity provider?
Cloud Identity Services in front
- You run several SAP cloud services and want one place to configure SAP-specific trust and conditional logic
- You need SAP-shaped provisioning to SAP targets, with the transformations those targets expect
- You want risk-based authentication rules applied consistently across the SAP estate
- You want a single point to change when the corporate identity provider changes
Direct trust to the corporate IdP
- The estate is small and adding a hop adds administration without adding value
- Your identity team has a firm policy of direct federation and the operational maturity to support it
- You already run a governance platform that handles SAP provisioning end to end
Business Data Cloud or keep BW and Datasphere as they are?
Business Data Cloud
- You want governed SAP data products with semantics attached rather than hand-built extractions
- You want an existing BW investment hosted and preserved while models migrate on the business's schedule
- You need a lakehouse and data science capability over SAP data without exporting copies of it
- Harmonised data is a prerequisite for the AI work you are planning
Keep the current estate
- Your analytics estate meets requirements and there is no pressing question it cannot answer
- The consumption commitment does not fit the value you can currently articulate
- You are mid-migration on another path and a change of direction would cost more than it saves
Build an AI agent or configure a rule?
Build an agent
- The work requires judgement over unstructured input that no rule expresses well
- The steps vary by case in ways that a decision table would enumerate badly or not at all
- Somebody currently does this by reading things and deciding, and can describe how
- The value is large enough to justify grounding, governance, metering and an owner
Configure standard automation
- The logic is deterministic, in which case a rule is cheaper, faster, auditable and never wrong in a new way
- The process is stable and high volume, where predictability is worth more than flexibility
- The data an agent would need is not reliable enough to ground it, which is the usual reason
- Nobody has agreed who is accountable for what the agent does
On-stack Fiori launchpad or SAP Build Work Zone?
On-stack launchpad in the ABAP system
- There is one back end and the users are ERP users doing ERP work
- You want the shortest configuration path and the fewest moving parts
- Content management sits comfortably with the team that owns the ERP
SAP Build Work Zone
- Users need one entry point across several back ends, SaaS products and custom applications
- You want a portal experience with pages, spaces, news and non-SAP content alongside the apps
- The digital workplace is owned by a team that is not the ERP team
Remediate custom code or retire it?
Remediate it
- Usage data shows it is genuinely executed, by identifiable people, for an identifiable purpose
- The functionality has no standard equivalent in the target release
- The object is small enough or valuable enough that fixing is cheaper than replacing
Retire it
- Nobody has executed it in a year and no one can explain what it was for
- Standard functionality in S/4HANA now covers it, which is true far more often than teams expect
- It is a report that exists because the old system could not aggregate quickly, a problem a column store no longer has
- It is a modification that has been generating upgrade adjustment work for a decade
Fourteen mistakes that create technical debt
Every one of these looks reasonable at the moment somebody does it. Each entry explains why it hurts later and what to do instead.
Saying we are moving to the cloud without saying which cloud
Why it hurtsSAP Cloud ERP, SAP Cloud ERP Private, a hyperscaler-hosted private system and a BTP subscription are four different things with four different operating models. Half the scope of a programme depends on which one was meant, and a surprising number of programmes get some distance in before discovering that different people meant different ones.
Do this insteadWrite the edition, the operating model and the responsibility split on one page in the first week, and make everybody who signs anything read it.
Assuming RISE means SAP runs it
Why it hurtsThe contract covers infrastructure, the database and the technical managed service. Basis work, SAP Notes assessment, custom code, most application monitoring and the decision to upgrade generally stay with you unless separately contracted. Teams sized on the assumption that all of it went away discover the gap during the first incident.
Do this insteadRead the service description, not the deck. Build a responsibility matrix from it, line by line, and staff against what it actually says.
Treating clean core as a purity score
Why it hurtsClean core is not an aesthetic. It is a prediction about how much work your next upgrade will be. Reporting it as a percentage of custom objects produces a number that makes nobody safer, because a single implicit enhancement in a critical path is worth more than a hundred harmless custom reports.
Do this insteadMeasure it as the number of objects that would need touching at the next upgrade, weighted by how bad it would be if they broke. That number changes behaviour.
Building on C_ consumption views because they had the right fields
Why it hurtsConsumption views exist to serve a specific SAP application. They are explicitly not stable, they change between releases, and they will change under your custom code without warning or apology.
Do this insteadBuild on released I_ interface views or released APIs. If nothing suitable is released, that is a real finding worth raising, not a licence to use whatever compiles.
Underestimating the Business Partner conversion
Why it hurtsIt is presented as a data model change and behaves like an enterprise programme. Number ranges, which record wins when a customer and a vendor are the same organisation, master data cleansing, and every interface that quotes a customer or vendor number are all in scope.
Do this insteadStart it before the technical conversion, treat it as a master data project with a business owner, and inventory the interfaces early.
Running Readiness Check too late
Why it hurtsRun early, it is an input to scope and the plan can still absorb what it finds. Run late, it is a list of surprises that arrives after the budget is fixed, and the only variable left to flex is quality.
Do this insteadRun it in the evaluation phase, and again periodically. It reads your real system, so it gets more useful as your system changes, not less.
Changing something directly in production
Why it hurtsIt is invisible to the transport path, so the next import silently overwrites it. It invalidates every test result you have. It is an audit finding. And it is always done under time pressure by somebody competent who intended to put it back properly.
Do this insteadClose the client, make the emergency change path a real documented route with the same gates and a shorter queue, and audit the exceptions.
Sizing on table size
Why it hurtsHANA compresses, so the raw figure overstates the storage. Working memory for queries, delta merges and temporary results adds a large amount the raw figure does not include. Sizing on either number alone produces a system that is either wasteful or that falls over at quarter end.
Do this insteadUse the sizing reports against your real data and workload, add headroom for peak, and archive aggressively. Application logs and change documents you keep forever are memory you rent forever.
Designing the authorisation model after the user experience
Why it hurtsIn Fiori the business role determines both what a user can see in the launchpad and what they can do in the back end. Designing the apps first and retrofitting authorisations produces roles that are either too broad to defend or too narrow to work, and usually both in different places.
Do this insteadDesign business roles as the shared artefact of the experience and the security workstreams, and have both teams review them together.
Leaving SU24 proposals unmaintained
Why it hurtsThe proposals are what allow a role to be generated correctly and regenerated safely after a change. Neglected, every role gets filled in by hand, differently, by whoever was on shift, and after a while no role can be regenerated without breaking somebody.
Do this insteadTreat the proposals as a maintained asset with an owner. It is dull, and it is the difference between an authorisation model that can evolve and one that can only accumulate.
Choosing the integration tool before the integration pattern
Why it hurtsSynchronous request-reply, asynchronous guaranteed delivery, event notification and bulk file transfer have genuinely different requirements. Picking the tool first means bending one pattern into another, which is how a nightly batch ends up implemented as ten thousand synchronous API calls.
Do this insteadFor each interface write down the pattern, the volume, the latency requirement and the delivery guarantee before anybody opens a tool. The tool choice becomes obvious and occasionally becomes no tool at all.
Deploying AI over data nobody trusts
Why it hurtsGrounding is the entire architecture. A model over inconsistent master data produces answers that are fluent, confident, wrong and metered. The failure is more expensive than a wrong report because people believe it more readily.
Do this insteadPick a use case where the data is already good, prove the value, and let that fund the data work for the next one. Do not start with the hardest data in the estate.
Treating agents as features rather than identities
Why it hurtsAn agent that acts has authorisations, does things that are attributed to somebody, and can be wrong at scale. An estate that has fifty of them and no inventory has a governance problem it does not know about yet.
Do this insteadEvery agent gets an owner, a defined scope, a log, a review date and an entry in an inventory, exactly like a technical user, because functionally that is what it is.
Managing each product's release calendar separately
Why it hurtsS/4HANA, SuccessFactors, Ariba, Concur, Fieldglass and the BTP services all have their own cadence. Managed separately, interface regression is always somebody else's problem, right up until the quarter where two of them change on the same weekend.
Do this insteadKeep one landscape release calendar covering every product, and name a single owner for cross-product regression.
Every term on this page, defined
Search it, or filter by the layer a term belongs to.
Practice challenge
3 questionsQ1Which statement is true of SAP architecture?
This division is why SAP can serve interactive users and heavy batch jobs on the same system without one…
Covered in the “Work processes and the dispatcher” section of this lesson.
Q2Which of these also applies to SAP architecture?
An SAP system is made of instances, each a set of work processes and memory on a server.
Covered in the “Instances and scaling” section of this lesson.
Q3Which part of the Learn SAP curriculum covers SAP architecture?
Getting started
This lesson sits in the Getting started section of the Learn SAP course.
Frequently asked questions
What actually happens in 2027?
What changed when SAP renamed the S/4HANA Cloud editions?
Is HANA really an in-memory database, and does that mean it loses data?
Why did S/4HANA delete the finance aggregate tables?
What is the difference between ABAP Cloud and classic ABAP?
What are the clean core levels, in plain terms?
Do I actually need BTP?
What happened to the Neo environment?
How is Business Data Cloud different from just having Datasphere?
Does zero copy mean my analytics are real time?
What is Joule, and what is an AI agent in SAP terms?
How is SAP Business AI charged?
What replaces SAP Identity Management?
Do I still need Solution Manager?
How often does S/4HANA release, and do I have to take every one?
Where should I start if I want to learn SAP architecture properly?
Want this taught live, with job support?
SAP Training is delivered live by working practitioners, with certification prep and placement support.
See SAP Training →