What a year! 2020 was like one of these Sci-Fi movies becoming reality...
From my IT-Job-perspective, it felt like a "kick in the ant-hill": suddenly, everyone realised the importance of digitalisation, especially for B2C use-cases. Whilst the companies already having a clear online retail strategy (Amazon, Zalando, Otto, Globus...) saw their results grow - others struggled to keep the lights on. And this is exactly where Platform-as-a-Services, like the SAP Business Technology Platform, can help execute a modern, scalable and omnichannel B2C strategy.
Through services like the "Integration Suite", our customers can build integrations for B2B purposes but also engagement platforms for their customers. A great example is "Globus", a German Retailer, who duplicated the blueprint of their "customer engagement platform" for retail-partners and employees.
The issue is very often, that our customer's systems of record are not meant to scale for the foreseen usage, nor are they technologically capable to communicate in internet-based standards. Changing these core systems would also be a critical operation - which is sometimes not feasible at-all or at least not in the required timeframe.
What Gartner talked about in their "Digital Integration Hub" (DIH) 2018 became a reality at some customers: an API-platform to decouple you systems of record from the pace and requirements of modern applications. Over the last years, Gartner has refined the architectural paradigm and refreshed that concept in 2020.
This blog will assume you are familiar with the DIH concepts and will explain how SAP Business Technology Platform can be used as implementation environment for it.
As you may have seen from our Integration Solution Advisor Methodology, we have provided an architecture based on SAP Business Technology Platform that implements the DIH-blueprint.
It is important to keep in mind that the picture above shows an illustrative example that needs to be adapted to the specific customer context and requirements. It serves as a starting point for customers to model their hybrid integration use cases.
As a Customer Advisor at SAP, I am interested in both concepts and details. So let's have a look under the hood to see how the SAP Business Technology Platform implements the DIH blueprint.
These are the applications "fueled" by the APIs. In an interconnected world where APIs are the de-facto standard for communication, a multi-experience application could be a web-portal, a smartphone app, a giant touch-screen kiosk, a chat-bot, a smart-watch, etc.. But it could also be a SaaS application you want to do synchronous, near real-time integration with.
The SAP Business Technology Platform provides many tools and frameworks to build or configure such applications, be it Business Application Studio, SAPUI5, mobile SDKs (Android and Apple), Conversational AI, .... This is one of the reasons we are seen as one of the leaders in that space.
This is where we typically find the "SAP Business Technology Platform Integration Suite". The dedicated and specialised services work together to model, adapt and manage APIs, and to perform modern application integration.
The front-end API Services need to be fully managed from both a security, performance and analytical point of view- typically in an API Gateway. But they may also need to be modelled first, if you want to implement a new API.
All this can be achieved using the "SAP Business Technology Platform API Management" service that lets you:
The front-end APIs may be implemented in different places, depending on the use case:
Obviously there are more ways to implement front-end APIs but these are the main ones.
You may rightfully ask yourself: "What about eventing?". This is also where the hybrid integration layer comes into play. One functional aspect of Eventing should be to have the integration layer been notified by changes in the backend. Through the usage of "SAP Business Technology Platform Event Mesh" this becomes perfectly possible.
The aforementioned "systems of record" can be anything really. However, you may want to make a mental separation between databases and applications: on one hand you will handle communication with a database though typical Data Integration concepts (high volume, batch, table-level, ETL, ...) whereas the communication with applications is based on Process Integration concepts (object-level, near real-time, ...).
Here is how the Integration Solution Advisor Methodology (ISA-M) compares the 2 integration styles:
In case you want to learn more about the ISA-M, you may want to look-up the upcoming (or current, or past - depending your temporal location) on OpenSAP.
With this in mind, there are multiple ways to implement communication with the systems of record:
Obviously, it is possible to use other tools and services to perform the synchronisation of data between the in-memory database and the system of records. For instance, one could use "SAP Data Intelligence" to perform data integration.
In a nutshell we can say that the "Digital Integration Hub" pattern is a very good guidance for companies looking at executing a digitalisation strategy, especially in regards to lessons learned over the past years.
The DIH can fully be implemented with SAP solutions: the illustration above is only an example of the implementation - and should be refined and adapted to specific requirements.
One thing is for sure: every company will - one day or another - run into the requirement of providing omnichannel access to its functions and data from systems of records. The question is only "How will they do it?".
From my IT-Job-perspective, it felt like a "kick in the ant-hill": suddenly, everyone realised the importance of digitalisation, especially for B2C use-cases. Whilst the companies already having a clear online retail strategy (Amazon, Zalando, Otto, Globus...) saw their results grow - others struggled to keep the lights on. And this is exactly where Platform-as-a-Services, like the SAP Business Technology Platform, can help execute a modern, scalable and omnichannel B2C strategy.
Through services like the "Integration Suite", our customers can build integrations for B2B purposes but also engagement platforms for their customers. A great example is "Globus", a German Retailer, who duplicated the blueprint of their "customer engagement platform" for retail-partners and employees.
The issue is very often, that our customer's systems of record are not meant to scale for the foreseen usage, nor are they technologically capable to communicate in internet-based standards. Changing these core systems would also be a critical operation - which is sometimes not feasible at-all or at least not in the required timeframe.
A solution blueprint
What Gartner talked about in their "Digital Integration Hub" (DIH) 2018 became a reality at some customers: an API-platform to decouple you systems of record from the pace and requirements of modern applications. Over the last years, Gartner has refined the architectural paradigm and refreshed that concept in 2020.
This blog will assume you are familiar with the DIH concepts and will explain how SAP Business Technology Platform can be used as implementation environment for it.
An implementation blueprint
As you may have seen from our Integration Solution Advisor Methodology, we have provided an architecture based on SAP Business Technology Platform that implements the DIH-blueprint.
It is important to keep in mind that the picture above shows an illustrative example that needs to be adapted to the specific customer context and requirements. It serves as a starting point for customers to model their hybrid integration use cases.
As a Customer Advisor at SAP, I am interested in both concepts and details. So let's have a look under the hood to see how the SAP Business Technology Platform implements the DIH blueprint.
Multi-experience applications
These are the applications "fueled" by the APIs. In an interconnected world where APIs are the de-facto standard for communication, a multi-experience application could be a web-portal, a smartphone app, a giant touch-screen kiosk, a chat-bot, a smart-watch, etc.. But it could also be a SaaS application you want to do synchronous, near real-time integration with.
The SAP Business Technology Platform provides many tools and frameworks to build or configure such applications, be it Business Application Studio, SAPUI5, mobile SDKs (Android and Apple), Conversational AI, .... This is one of the reasons we are seen as one of the leaders in that space.
Hybrid integration platform
This is where we typically find the "SAP Business Technology Platform Integration Suite". The dedicated and specialised services work together to model, adapt and manage APIs, and to perform modern application integration.
The front-end API Services need to be fully managed from both a security, performance and analytical point of view- typically in an API Gateway. But they may also need to be modelled first, if you want to implement a new API.
All this can be achieved using the "SAP Business Technology Platform API Management" service that lets you:
- model APIs first: define a contract between the API-Consumer and the API-Implementation, based on open standards like OpenAPI or OData.
- secure APIs: especially mediating internet-oriented security concepts with on-premises security concepts is important. But also protecting back-end systems from unforeseeable traffic is an important task.
- increase performance of APIs: through concepts like caching and purpose-oriented refactoring (lightweight), the responsiveness can be greatly increased.
- steer your API platform: monitoring - ie. analytics - is an important aspect of a digital strategy so you can define project-priorities based on API adoption.
The front-end APIs may be implemented in different places, depending on the use case:
- in the "SAP API Management" service: this is where mash-ups and filtering can occur, to do lightweigt API composition.
- in the "SAP Business Technology Platform Integration" service: this is where REST APIs can be graphically implemented in order to orchestrate complex logic and connect to heterogenous systems.
- in a headless microservice that can be developed with the "SAP Cloud Application Programming Model" (CAP) and run on various services of the SAP Business Technology Platform such as Kyma or Cloud Foundry runtime.
- in the Hana in-memory database: Hana features native capabilities to expose its data through OData REST APIs and provides lightening fast response times.
Obviously there are more ways to implement front-end APIs but these are the main ones.
You may rightfully ask yourself: "What about eventing?". This is also where the hybrid integration layer comes into play. One functional aspect of Eventing should be to have the integration layer been notified by changes in the backend. Through the usage of "SAP Business Technology Platform Event Mesh" this becomes perfectly possible.
Systems of records
The aforementioned "systems of record" can be anything really. However, you may want to make a mental separation between databases and applications: on one hand you will handle communication with a database though typical Data Integration concepts (high volume, batch, table-level, ETL, ...) whereas the communication with applications is based on Process Integration concepts (object-level, near real-time, ...).
Here is how the Integration Solution Advisor Methodology (ISA-M) compares the 2 integration styles:
In case you want to learn more about the ISA-M, you may want to look-up the upcoming (or current, or past - depending your temporal location) on OpenSAP.
With this in mind, there are multiple ways to implement communication with the systems of record:
- Applications - Process Integration: through the "SAP Business Technology Platform Cloud Connector", the SAP Business Technology Platform establishes a secure tunnel to on-premises systems. This connection is then available to any of the services, including the "Integration Service" (aka. CPI or fka. HCI, part of the Integration Suite). The integration service enables connectivity to virtually any application.
Typically, the integration service is used for executing real-time transactions against systems, or to update the central in-memory data store due to changes. - Database - Data Integration: through the "SAP Smart Data Integration" (SDI), the Hana Database is capable of communicating and synchronising with many different, non-SAP databases.
Typically, SDI is used to transfer relevant - or virtualise - data between the DIH in-memory database and the on-premises databases.
Obviously, it is possible to use other tools and services to perform the synchronisation of data between the in-memory database and the system of records. For instance, one could use "SAP Data Intelligence" to perform data integration.
Conclusion
In a nutshell we can say that the "Digital Integration Hub" pattern is a very good guidance for companies looking at executing a digitalisation strategy, especially in regards to lessons learned over the past years.
The DIH can fully be implemented with SAP solutions: the illustration above is only an example of the implementation - and should be refined and adapted to specific requirements.
One thing is for sure: every company will - one day or another - run into the requirement of providing omnichannel access to its functions and data from systems of records. The question is only "How will they do it?".
- SAP Managed Tags:
1 Comment
