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.
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.
- A user action in the presentation layer is sent to a dialog work process on the application layer, which runs the relevant logic…
- Presentation: the user interface (GUI/Fiori); shows screens, captures input.
- Application: executes business logic in work processes; the brain of the system.
- 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.