SAP S/4HANA: New Architectural Blueprint for In-House Software

Many companies want to move to SAP S/4HANA but are put off by having to migrate anything up to several hundred applications they have built in-house. A new architectural blueprint is about to make that migration easier.

Capgemini’s Roman Bartlog turns to a medical analogy to help him explain how companies’ IT architecture might look in the near future. The heart, he says, pumps blood into the arteries and round the body, right to the very tips of the fingers. Arms and hands are nimble and flexible. They can perform lots of different tasks: type a Whatsapp message, draw a bow across a violin, unlock doors.

In Bartlog’s analogy, the heart is SAP S/4HANA, a standard that stays stable. The arms and hands are a microservices-based architecture that enables extra functions to be added flexibly to those of SAP S/4HANA. Under the new architecture, all custom applications run on common programming languages such as Java and JavaScript on the SAP HANA extended application services, advanced model, technology without any changes to SAP S/4HANA (see the graphic).

Image via Capgemini

SAP S/4HANA Plus Microservices: the Benefits

1. Keeping Custom Applications

Over time, companies’ processes evolve and become increasingly specialized. Some simply cannot be mapped in a standard ERP system. It is not unusual for companies to have several hundred custom applications, many of which will need adapting when migrating to SAP S/4HANA.

“This is a good opportunity to separate custom applications from the core and convert them to a modern programming language like Java,” says Bartlog. That way, because the application runs on SAP HANA extended application services, it is independent of the core and therefore more agile. Besides, the applications on SAP HANA extended application services and on SAP S/4HANA run on the same database technology, which makes it easier to exchange and access data.

“At database level, the SAP HANA smart data integration technology can be used to access data without having to copy it first,” says Bartlog. At application level, the open format means that Open Data Protocol, or OData, can be used to exchange data.

2. On Premise as an Additional Option

Migrating to SAP S/4HANA is a major step for many companies because their IT strategy often prevents them from adopting SAP Cloud Platform technology and moving their in-house applications to the cloud at the same time. For instance, applications they have built themselves are viewed as business-critical.

SAP HANA extended application services allow them not only to deploy their existing custom applications but also to build new ones and get them ready for the cloud as well. That way, companies gain the time they need to decide on a cloud strategy and when to move to SAP Cloud Platform.

3. Trialing SAP S/4HANA Updates

SAP brings out annual new releases for SAP S/4HANA, which are installed on-premise and operated at the customer’s site. But not all customers need all the new features SAP delivers. For a year, they can test new functions using SAP HANA extended application services. When they are satisfied that the features are stable and add value, they can import them, risk-free, into SAP S/4 HANA.

4. Innovation When You Need It

Innovation cycles for SAP S/4HANA follow a fixed timetable that is not necessarily in sync with business needs. Yet business departments know when demand for products has changed and need their IT experts to create flexible solutions fast. SAP S/4HANA is the stable core that is always the standard.

Microservices, mapped in SAP HANA extended application services, can be created and adapted at any time to meet the changing needs of the business. Since SAP HANA is the central database for SAP S/4HANA and offers the microservices, this architecture makes it possible to use data stored in the “heart” and build fast new solutions.

5. The Microservice Architecture Pattern Can Be Used

According to technology writer Martin Fowler, microservices are best created by autonomous teams that build them with the user interface, middleware, and data storage in mind. Such agility is possible in this approach as well, but there is a difference: SAP HANA is the central database.

6. Migration to SAP Cloud Platform

SAP HANA extended application services help users learn how to build their own microservices and run them on SAP HANA. Once they have their first major SAP S/4HANA transformation project behind them, they can take what they have learned about microservices from the agile part of the architecture and apply it to the cloud by way of SAP Cloud Platform.

“First building microservices using SAP HANA extended application services helps prepare companies for migrating to SAP Cloud Platform,” says Bartlog.

7. Not Just for SAP Systems

Besides SAP S/4HANA and microservices on SAP HANA extended application services, a third pillar for non-SAP applications is possible. That way, the architectural model enables companies to establish a single source of truth (read more in this article: Why SAP HANA Also Fits Java Environments).