Architecture For Extending SAP S/4HANA: Cloud Application Pattern

Many customers have already done implementing S/4HANA systems and many are doing projects/waiting to jump into the train with green/brownfield implementations.

?

Whatever your S/4HANA strategy is, SAP recommends keeping your core S/4HANA implementation/processes as standard as possible in order to implement current and future best practices, modifications easier, now and in the future.

Keeping the core simple doesn't mean that you cannot do "custom stuff". In fact you have more options than before and they are more flexible and reusable than ever. (thinking of the traditional extension approaches).

The most important question here is not how to extend but what is the requirement(business needs) and where I want to reach (strategy); then the architecture needs to be formulized with technical & solution architects.

SAP has best practices and recommendations in their roadmaps, guides and whitepapers for finding the best "path(s)" for architecting the S/4HANA extension strategy. One of these are the key architectural design patterns for extending SAP S/4HANA where they are describing 5 patterns from small key user / developer(on-stack) extensions to hybrid & cloud applications. The choice depends on who to use it, how it is used and how flexible it should be.?In fact you can mix and merge these patterns like some of your extensions may be in-app while developing and integrating your own cloud extensions with third parties and your on premise solutions.?

As a believer for effective cloud based landscapes, I would like to write about cloud application pattern which I think most of the enterprise customers will benefit from.

?The Cloud Application Pattern for Extending S/4HANA

In cloud application pattern, while their S/4HANA systems doing the regular work, customers create extension-applications in the cloud (SAP BTP); they have additional options to use cloud services such as API management, workflows, business rules and publish the information from their systems to the outside world via controlled APIs. In the mean time these applications use & merge the data coming from the on premise systems via OData APIs and through business events. (For instance you can easily build a scenario where a new sales order in S/4HANA system will trigger your extension cloud application, then it will notify (a) third party application(s) expecting the order & product details through integrated services)

This information can be served to the end-users via Mobile or Web UI technologies. One example would be Fiori / SAPUI5 but it's not the only one. For another option, custom applications may use the data through secure APIs controlled by SAP BTP's API Management Services. (you can control how, when, what amount through policies to keep your data and apps tidy and secure).

Coming to the human resources capabilities for generating these applications, your developers do not have to be ABAP profiles only, you can generate services with Java or Node.js and SAPUI5 which is another advantage.

There are many other advantages for this pattern such as;

• You can focus on end users outside your organization easier and vice versa as they can use your controlled data and build their own apps, and use standards' based APIs - where they do not need your human resources in order to integrate these apps.
• You can automate your development cycles and make them flexible as the backend system is not tied to these extensions, and Cloud DevOps services offer many automations making the cycle faster. In the meantime as you seperate your backend from custom logic, these two can be operated-upgraded seperately. One example of these DevOps services is project Piper which I will write about afterwards.
• You can create quick Proof-of-Concept and Pilot Applications. For instance you can create a mobile application with SAP's new low code no code platform #AppGyver and integrate your services within the same platform.
• You can also benefit from other cloud and #BTP services. Such examples would be where you can centrally manage your user authentication via identity authentication services or use cloud eventing (Event Mesh) for triggering applications after business and technical events. No need to keep on premise services, applications and databases for these requirements.
• You can use modern technologies to integrate with other SAP and non-SAP solutions. For instance you can get a change in the data from SuccessFactors system and immediately trigger a business event-use and enhance the data within on premise SAP system. This cycle can also be triggered via third party application which gives you more data that is not available in your SAP Landscape such as information coming from a 3rd party project management or time & attendance system. The architecture here would be designed so that cloud system will be a hub to send this information to on premise S/4HANA system at the same time to SuccessFactors to trigger other business processes.

?

There are many other benefits, supporting technical applications and services for this pattern, which requires detailed discussions and arguments. However above summary and the technical overview below -which is from one of SAP's examples- should give you the picture of the architecture.?

I am planning to write about new improvements in this area as they occur (solution and architecture based), but in the meantime please feel free to contact me about your recommendations / questions.?

You can reach my other articles regarding cloud & technical architecture from here