How Have Authorizations Changed from SAP ERP to SAP S/4HANA?

In this post, we’ll reflect on the evolution of SAP ERP into SAP S/4HANA and what this development meant for authorizations. We’ll also discuss deploying SAP S/4HANA Cloud and other cloud-based SAP solutions.

SAP ERP

In 1992, SAP released SAP R/3 as the first enterprise resource planning (ERP) system that leveraged the advantages of a distributed three-tier architecture consisting of database, application, and presentation layers. To maximize flexibility, the new architecture supported many operating systems and database management systems (DBMSs). The architecture was highly scalable and could meet the need for the larger and more complex system landscapes required by organizations that operated globally. SAP R/3 used a common client-server architecture and for the first time included a Web Application Server (Web AS). Also, SAP R/3 was the first release that enabled the seamless integration of various applications to run business processes in a single system, bringing together the areas of finance, sales, and human resources (HR).

Simultaneously, the authorization model evolved further to accommodate the demand for segregated access to business functions. For instance, the ability to post an accounting document in the finance area required access to Transaction FB01. At that time, typically, the naming convention indicated which process area the transaction belongs to. For example, most transactions starting with an “F” were typically related to a finance process. Fine-grained access within transactions was managed through authorization objects that controlled the type and extent of access. For instance, you could differentiate between display or update access (for posting an accounting document) for a particular company code.

The next major evolution step was SAP NetWeaver 2004, later renamed to SAP NetWeaver 7.0. The architecture created a stable and sustainable business technology platform that could be extended. An enhancement package (EHP) framework was delivered with SAP NetWeaver 7.0, enabling you to implement further enhancements as needed.

Another significant change was its ability to integrate with third-party technologies, like .NET, WebSphere, and Java. Particularly, SAP NetWeaver Application Server (AS) could serve an ABAP and/or Java (J2EE) stack, as shown in the figure below. The authorization model has not changed, however, and provided capabilities to integrate with Java-based SAP solutions, such as SAP Enterprise Portal.

SAP NetWeaver Components

In the past decade, changes in the IT environment—both from a legal perspective (data protection requirements or federal tax reporting obligations) and a technological perspective (digitalization, the Internet of Things [IoT], mobile devices, or connectivity)— have significantly increased demand for a capable, high-performance computing application to run business processes even more efficiently.

The next step involved the simplification of the security architecture and increasing transparency into how access is granted to critical business data and functions. Technology has become a key element in the IT strategy of many organizations to keep up or even to gain an advantage in highly competitive markets.

SAP S/4HANA

In addition, SAP Business Suite has grown consistently for many years, and thus, integration effort has increased disproportionally to the extensibility of the system (particularly with SAP NetWeaver as a central development platform and runtime environment). This growth in effort highlighted the need for a new technology, thus leading to the fourth generation of SAP Business Suite—SAP S/4HANA.

Even though SAP S/4HANA is still using ABAP for its code, its underlying database—SAP HANA—helps resolve some significant disadvantages and limitations that existed in previous SAP ERP releases, through the following capabilities:

Simplification of the data model and related processes
Integrated solution with large extensibility
Real-time data analytics
Performance improvement
Cloud computing

SAP HANA was released for the first time in 2011. Later, SAP HANA was quickly adopted for architectures with SAP Business Warehouse (SAP BW) to benefit from performance gains in real-time operational reporting and then made available to SAP ERP systems. Finally, the first release of SAP S/4HANA in 2015 used a new data model and leveraged SAP HANA’s capabilities, as shown below.

SAP’s Evolutionary Process at a Glance

Whereas technology integration has been the main focus of the SAP NetWeaver platform with SAP S/4HANA, the focus has moved to business process integration using a harmonized, fully integrated, and simplified data model. To benefit from performance improvements, real-time reporting is possible to support decision-making processes on all levels of your organization. To leverage these capabilities, a fundamental prerequisite is running SAP S/4HANA on an SAP HANA database.

SAP HANA is an in-memory relational database management system (RDBMS) that enables you to operate your systems, typically SAP ERP and SAP BW systems, with a significant performance gain over traditional RDBMS systems. As the database is column-oriented, high compression rates can be achieved. Data that is used often can be held in-memory and can thus be called up quickly, with tangible effect on program execution speed. Data is not entirely stored in the persistence layer any longer. In conclusion, SAP HANA facilitates real-time operational reporting scenarios with enhanced analytics that integrate any type of data source, such as big data, geospatial data, or social and business networks.

SAP HANA can serve as an open application development platform supporting various programming languages, such as R, SQL, or Java. SAP HANA is therefore not only a classic RDBMS. You can use SAP HANA in any scenario as a central development platform since SAP HANA can host a variety of applications of different nature. The XS engine, SAP HANA’s native application server, facilitates the efficient deployment of applications to enable end users to access complex analytics using a variety of interfaces. In this way, data can be made accessible easily regardless of the user interface (UI) technology used on the presentation layer.

For example, as shown in the figure below, SAP Fiori applications can consume data via OData services in the ABAP backend, and the data is presented based on HTML5 technology. The entire calculation logic sits on the database layer, and the data is therefore already preprocessed, thus leveraging all the advantages of SAP HANA’s in-memory data processing technology. SAP Fiori app content is hosted on an ABAP application server, the application layer. SAP Fiori apps are built using the SAPUI5 framework, which includes an HTML5 rendering library for presenting content on the client side, on the user interface (UI) layer.

Layers of the Architecture Compared

Having now multiple entry points to the system (i.e., an SAP Fiori application, an SAP GUI transaction, or a report that retrieves data directly from an SAP HANA database), you’ll need to establish an authorization concept that spans across all layers of your architecture. While both presentation and application layers still use the ABAP authorization model, SAP HANA utilizes a privilege framework on the database layer.

In previous decades, the ABAP security and authorization model had not changed significantly, even in SAP S/4HANA. Defining and implementing access controls has always been a compulsory task in the course of object development, whether developing ABAP programs or core data services (CDS) views. Authority checks must be part of the program code. Access can be granted through authorizations included in profiles assigned to a user directly or via roles.

Commonly, the infrastructure of an SAP system was located in-house or in the data center of a service provider. Eventually, this approach caused high total cost of ownership (TCO) due to high costs for system operations and maintenance. To respond to this business demand, cloud-based solutions have been developed, the next step in the evolutionary process of SAP Business Suite. A distributed system architecture in the cloud can provide resources when needed. Processes are harmonized and stay close to the standard. Simplification is a key element enabling positive effects on security by reducing the effort in otherwise time-consuming user and role management activities.

This paradigm change means suddenly IT plays an essential role in business planning and must be considered during the design of business processes. In conclusion, IT will focus less on operations and maintenance activities, including security, instead focusing more on creating business value by leveraging the advantages of technology hosted in the cloud. This shift also applies to SAP S/4HANA, also available in the cloud.

SAP S/4HANA Deployments

SAP S/4HANA can be deployed in many different ways, including using a shared infrastructure or existing infrastructure. What is considered the best fit for your company depends on multiple elements that should be taken into consideration when evaluating the various deployment options, including the following areas:

Infrastructure
Licensing
Functional scope

Other considerations may reflect on extensibility, configuration, roles and responsibilities, financial aspects, business value, and much more. The higher the degree of standardization while accepting a low degree of flexibility, the lower the TCO. In such a scenario, service providers can assume much more responsibility, particularly on the IT infrastructure and operations side, while you, as the customer, can focus on creating business value. Nonetheless, standardization requires a fit-to-standard approach with inevitable effects on business processes, as shown in this figure.

Balancing Standardization and Flexibility

Maximum flexibility is granted when SAP S/4HANA is installed on-premise on a dedicated infrastructure, which may be operated by SAP, another service provider, or in-house. When your infrastructure operations are outsourced to a third-party provider, you have adopted an infrastructure as a service (IaaS) model. In these scenarios, you will have full responsibility for managing security. In contrast to the software as a service (SaaS) model, an IaaS enables the flexibility to implement appropriate security measures tailored to your own requirements, including an enhanced authorization model that goes beyond the traditional management of read and write access in business applications. For example, data protection measures can be implemented to prevent the disclosure of sensitive information within a business application or report.

When SAP S/4HANA is hosted in the cloud, in this SaaS model, SAP is responsible for providing and maintaining the software, as shown above. Depending on the deployment option, you may have chosen SAP to serve as the cloud provider, or you’ve chosen another hyperscale cloud provider, such as Microsoft Azure, Amazon Web Services (AWS), or Google Cloud. In either case, the hyperscale cloud provider or SAP operates the infrastructure based on standardized processes, services, and service level agreements (SLAs). The more extensibility you require (for instance, in relation to addons or the implementation approach being used), the more flexibility you’ll need.

SAP offers multiple deployment options, either in the cloud or on-premise, as listed in the table below.

SAP S/4HANA Deployment Options

Standardization often impacts security. If you opt to implement SAP S/4HANA Cloud, security will always be limited to the feature scope of the relevant solution. The user access model is significantly simplified using predefined roles. In consequence, security administration efforts will shift from role design to user access provisioning. In contrast, with less standardization and more customization, options are available so you can implement a more sophisticated user access model that fits our individual needs and that is aligned to your specific system landscape.