SAP Three-tier architecture
The three-tier architecture, presentation, application and database, is the defining structural model of SAP, introduced with R/3 and still the way to reason about any SAP system. Each tier has a distinct job, and separating them gives SAP its scalability and flexibility.
SAP's three tiers each have one job: presentation, SAP GUI or Fiori, shows screens and captures input; application runs the business logic in work processes; the database stores all data. A user action goes to a dialog work process, which reads or writes the database and returns the result. Each tier scales and evolves on its own.
- Watch out: Collapsing the tiers mentally, they are distinct for good reasons.
The three tiers and their jobs
- Presentation: the user interface (GUI/Fiori); shows screens, captures input.
- Application: executes business logic in work processes; the brain of the system.
- Database: stores and retrieves all data; the single source of truth.
How a request flows
A user action in the presentation layer is sent to a dialog work process on the application layer, which runs the relevant logic, reads or writes data in the database layer, and returns the result to the screen. Understanding this flow makes performance analysis and troubleshooting far more logical.
Why three tiers
Separation lets each tier scale and evolve independently: add application servers for more users, upgrade the UI without touching logic, and manage the database on its own terms. It also isolates concerns, keeping the system maintainable at enterprise scale.
Common pitfalls
- Collapsing the tiers mentally, they are distinct for good reasons.
- Scaling the wrong tier for a given bottleneck.
- Ignoring the request flow when troubleshooting.