Evolution of SAP ERP Architecture

Understanding SAP ERP Architecture can be a very hard job for a beginner. An easy way to learn is to begin from the beginning and see how the architecture evolved.

Computerization of Business Processes

With the advent of computing technology, companies looked for opportunities to automate various business tasks, instead of relying on slow and error-prone manual work. They would hire software developers (or outsource) to write applications that would help them achieve this requirement.

The applications were specific to the business needs of the organization, but they were not so easy to maintain (poor documentation, bad practices, people who knew how it worked left, fear of changing anything tied them down to the same old technology, each department had their own application and they never integrated to form an ERP system etc.)

Worlds’s most powerful ERP was right under IBM’s Nose

Dietmar Hopp, Hans-Werner Hector, Hasso Plattner, Klaus Tschira, and Claus Wellenreuther – five (former) IBM employees noticed the similarities in the business applications that were being developed and used independently by several companies.

They proposed the idea of creating a standard software that would avoid this rework and address the weaknesses of software built in-house. This ERP solution could be used by many organizations and thereby reduce the cost of developing and maintaining such a software solution.

IBM didn’t buy the idea.

They started their own company in 1972 as Systemanalyse und Programmentwicklung (System Analysis and Program Development) and later renamed it to Systeme, Anwendungen und Produkte in der Datenverarbeitung (Systems, Applications and Products in Data Processing).

Real-time Systems: Hello World

SAP developed their first accounting software -R/1 system- that runs on DOS, in 1972, followed by SAP R/2 system in 1979, which was based on mainframe computing. SAP R/2 included most enterprise functions such supply chain, manufacturing processes, accounting and HR. R/2 also supported multiple languages and currencies which helped it become popular with multinational organizations.

Three Layer Client-Server Architecture

In 1992, SAP redesigned their solution to SAP R/3 which is based on client-server architecture. Several PCs could be used to connect with the one or more application instances which would process the data on one or more instances of the database.

Division of the solutions into three layers (presentation, application and database) and client-server architecture allowed organizations to run each of the layers on separate specialized hardware.

  1. Presentation layer (SAP GUI) runs on each user’s computer; they don’t have to worry about time-sharing the GUI on a server.
  2. The application layer executes the business logic, accessing data only when it is necessary.
  3. The database layer persists the business transactions.

The presentation layer is client and application layer is the server; similarly application layer is client and database is server. This turned out to be a very successful architecture.

SAP Functional Modules, Industry Solutions and Technology Layer

The application layer consists of the core modules such as Materials Management (MM), Sales & Distribution (SD), Human Resources (HR), Production Planning (PP), Financials & Controlling (FICO) etc.


Industry specific solutions are provided as add-ons. Organizations would be able to use specialized business processes relevant to their industry by deploying Industry Solution Add-on suitable to them. The Industry Solution add-ons (slightly) modify the standard core functional modules to make it relevant to the industry.

The application is built on technology platform called as SAP Basis (which will take many other names – Web Application Server and NetWeaver Application Server). SAP Basis allows SAP to run on different combinations of operating systems and databases.

SAP R/3 up to 4.6c, EnjoySAP and what happened to “SAP R/3 4.6D”

Using SAP R/3 as the reference, let’s see how the SAP ERP architecture evolved.

The SAP R/3 architecture until the release 4.6c consists of:

  1. A technology layer (Basis and ABAP)
  2. Core application (SAP_APPL and SAP_HR – the functional modules)
  3. Add-ons (industry specific add-ons and plugins like Y2K check)


While the architecture was evolving, SAP also reinvented the way users interacted with SAP application.

Collaborating with Frog Design, SAP introduced EnjoySAP. The tree structure in the left pane, reduced screen changes, non-Windows look etc. are the features of EnjoySAP (SAP usage being more enjoyable). EnjoySAP is the standard used by the current SAP GUI.

Before Basis 4.6D, SAP Basis was an integral part of SAP R/3 only. This was reflected by the Basis and R/3 having identical release numbers, or by joint Support Packages, for example.

With mySAP.com (in 1999), SAP started delivering several application components, like SAP R/3 or the SAP New Dimension Products which are all based upon SAP Basis.

As Basis disintegrated from SAP R/3, its development was dependent on mySAP.com’s application components and their technical requirements.

SAP Basis Release 4.6D, which is used by mySAP.com components, like the Workplace, BW, KW, CRM, and other SAP products, was not used by any R/3 release. Therefore, although Basis 4.6D existed, “SAP R/3 4.6D” never did, nor did any R/3 release that used Basis 4.6D.

Enterprise Extensions and SAP R/3 Enterprise

In the late 90’s, two core technologies gained prominence: Unicode and Web (dotcom bubble) thanks to JAVA.

SAP changed the basis layer to move in the direction of the latest trend in technology. SAP renamed Basis to Web Application Server to indicate adaption of these technologies. The name Basis never died, so these terms are used interchangeably.

With the introduction of new features, introduction of Enterprise Extensions, and thereby the architecture changes, SAP R/3 started being called as SAP R/3 Enterprise.


A very important architectural change of the application is the introduction of Enterprise Extensions.

The Enterprise Extensions, which are essentially smaller packages on top of the core application, contain new functionalities avoiding the need to change the core application. If an enhancement finds its place in more than one enterprise extension, it would instead be part of the core application. This way changes and enhancements are first introduced as extensions.


Check Also

Determining the Number of Work Processes

Procedure The context change for processes on Windows is more time-consuming compared to UNIX. Therefore, …