Three-tier architecture, or how the application server ate the fat client
The floppy disk arrives at the accounts-payable clerk’s desk on a Tuesday in January 1991 — not for her, but for her machine. A technician has been working his way through the building since Monday with the same errand: the tax rate changed on New Year’s Day, the business rules changed with it, and the fat-client billing software has to be reinstalled on every machine that runs it. There are 300 machines. The technician has 298 to go.
This was not considered a crisis. It was considered Tuesday.
Two-tier client-server had been the dominant architecture since the mid-1980s, when cheap networked PCs made it sensible to put display and processing power on every desk. A client machine ran the application; a server ran the database; a network connected them. Elegant in principle, and for a while sufficient. The trouble arrived when “the application” expanded to mean business rules — pricing tiers, tax schedules, approval workflows — and business rules turned out to be the thing that changed most often. Every change was a distribution campaign. Every new policy meant another technician with another bag of disks.
SAP R/3 shipped on 6 July 1992, and the number in the name was explicit: three tiers. A presentation layer — the SAPgui client — handled only what appeared on screen. An application layer, powered by the ABAP-based application server, held all the business logic. A database layer held the data. When a tax rate changed, one tier was updated. The 300 clients on those desks rendered screens; they held no logic; they required no visit. The pattern was codified in print by Wayne Eckerson in a January 1995 paper in Open Information Systems, titled “Three Tier Client/Server Architecture: Achieving Scalability, Performance, and Efficiency in Client/Server Applications” — by which point enough practitioners had shipped it to have opinions about naming it.
By 1999, SAP’s co-chairman Henning Kagermann had grown comfortable with an expansive claim. Interviewed at SAPphire '99 in Singapore, he said: “We invented the three-tier client server architecture. We are the only ones with this architecture and this is one of the key success factors of SAP.” His competitors — Oracle, PeopleSoft — were still defending fat-client products. When the web browser arrived and everyone needed a presentation layer that ran in a browser rather than an installed application, SAP already had a presentation tier that could simply be swapped. The architecture had anticipated the problem seven years before it became urgent.
The deeper contribution was a principle about software organisation: separate the layers by what changes at what rate. Presentation changes fastest — users want new screens, new workflows. Business logic changes with the business. Data changes slowest, constrained by schema and migration costs. Put each layer on its own tier, maintained by teams with no need to understand each other’s internals, and the whole system can evolve without the whole system being redeployed. That premise — separation by rate of change — is the load-bearing idea under every application server, every web framework, and eventually every microservice that followed.
The technician with the floppy disks did not disappear immediately. But his territory shrank, tier by tier, until there was almost nothing left for him to carry.
Sources
- SAP R/3 — Wikipedia — Launch date of 6 July 1992, three-tier structure (presentation, application, database), the meaning of “R/3”, and market reception.
- Multitier architecture — Wikipedia — Wayne Eckerson’s January 1995 paper in Open Information Systems, the architectural definition and separation of tiers.
- Kagermann interview, DQ India (February 2000) — “We invented the three-tier client server architecture” quote, Kagermann’s contrast of SAP’s architecture with Oracle’s and PeopleSoft’s fat-client products, and the web browser transition advantage.