What today’s hybrid environments mean for SAP integration | HCLTech
Digital Business

What today’s hybrid environments mean for your SAP integration strategy

Today’s hybrid environments require SAP integration strategies that ensure seamless connectivity, scalability, and performance across on-premises and cloud platforms for optimized operations.
 
5 min read
Ray Gardner

Author

Ray Gardner
Solution Director, SAP Practice, HCLTech
5 min read
Share
What today’s hybrid environments mean for your SAP integration strategy

Integration is one of the key areas of development and evolution within the IT industry. It has moved from the classical on-premise to include more open integration with richer user interfaces, supporting task-based apps, real-time analytics, and digital stream processing and capabilities for rich, intelligent insights.

To support this wide range of interactions, integration technology and tools must be updated with new designs, delivery methods, and technical patterns. The approach to integration has also gone through a similar transition and must cover a much wider range of topics.

This blog will explore the emerging integration topics that SAP users must know, including those we recommend included in any updated integration strategy or integration target operating model (TOM). Let’s dive in.

  1. Take account of today’s hybrid environments 

    Today’s integration solutions must support and on-premise solutions with lightweight cloud integration options while covering potential domains of systems, functions, or geographies. SAP itself has solution offerings in the cloud (such as SuccessFactors, Ariba, S/4, and C/4) and on-premise (such as the older ECC systems or if you decide to deploy S/4 on-premise). From an SAP perspective, data models are aligned across these domains of product offerings (a message reinforced by RISE with SAP). There may be other business, geographies, or even historic landscape domains within a corporate environment, where solutions have some common underlying principles. Yet, the variations and deviations must support these specific domains.

    Thus, your choice of integration tools becomes the key. They must cover a wide range of environments and landscapes and address a complex hybrid landscape of systems and applications on both cloud and ground (on-premise).

  2. Understand the wide range of integration

    Most companies must support cloud-first solutions, best-of-breed applications, improved user experiences, more flexible applications - and yet keep commercial off-the-shelf (COTS) standards. Hence, the integration strategies must address all of these challenges.

    Since the types of integration being addressed are now broader than the more classical process and data requirements, the integration solutions must support more real-time user demands (often via apps), requiring more functionality, flexibility, and delivery capabilities.

    To identify how your integration strategy needs to be updated, you must understand the wider range of integration technology, their typical key features, and functions – and then confirm which applies to your own business and technical needs. For example, ‘business to government’ integrations, ‘business to consumer’ or ‘open APIs’ are all now part of the wider integration styles. When companies confirm the type of integration that needs to be addressed, more detailed tools, approaches, methodology, and delivery methods can be suggested in a preferred architectural target operating model.

  3.  Review the impacts of development and support approaches such as DevOps 

    The delivery style now has to accommodate the older waterfall approach and be capable of transitioning to agile and DevOps (plus be flexible for new options, as they no doubt will emerge!). All of this can be realized within SAP, not just in the newer business technology platform (a.k.a. SAP Business Technology Platform (BTP)) - but also in the older ECC and the SAP ABAP programming approaches. There is nothing stopping SAP developers from logging requirements into ticketing systems (SAP Focused Build or others such as Remedy or ServiceNow). They can start the development work through agile delivery using daily scums, building backlogs, progressing items through iterative delivery cycles with agile dashboards, and more automated testing through deployments. As these will directly impact integration delivery, the companies must also review the development and operational approaches to ensure all aspects are considered in any updated integration strategy.

  4. Take time to consider the seismic shifts in design

    Design is possibly the most critical topic and will require a fundamental shift in thinking for many people. The design approach to integration now needs to consider a broader set of design challenges and potential architectural and integration patterns for solution delivery while also understanding the business use and application. Some items to consider are:

    • De-coupled integration – Many historical applications and the actual integration between them were tightly coupled, which have now become difficult to untangle, change, upgrade, or even extend. Realizing a more de-coupled integration solution, though, is not just about technology and tools. My view is that it is potentially more about understanding newer design options and supporting current and future business needs. Hence, the integration architect must have a wider understanding of data management, reporting, development, and user experience /user interfaces, since these are merging and have a combined impact on the integration design, delivery, and operation.
    • APIfication and API management/microservice – The approach to enable wider APIs is a good example of a new design pattern often (possibly) not fully utilized within the SAP integration landscapes. I realize that SAP has been providing APIs for many years, but the more recent shift is not about the technology but the application and use. Hence, the functional teams can be encouraged to make core API’s or microservices available for direct use, without the constraints of pre-agreeing detailed system specific-interfaces (with technical specifications and middleware setup).

    Why should this be considered? Because this can lead directly to business value. For example, if you make your product information, prices, stock, or sales available, then you can find other business areas using the information in ways not initially envisaged, which can unleash new opportunities and enable business-led differentiation and innovation.

    • User experience and user interfaces – The focus on users’ apps, interfaces, portals, and open channel and device access is established. Yet, from an SAP perspective, many companies are still heavily reliant on old-style SAP GUIs and transaction-based UIs rather than role and personalized interfaces. SAP’s recent Fiori 3 now provides a common approach across SAP’s complete product set and domains. Additionally, with low-code options, UI5 development, and extension capabilities, Fiori transforms what is possible. As such, the integration solutions must keep up with this transition and support more real-time user interface-led requirements and design options, such as orchestration, mediated integration or microservices, or generally other new integration patterns.
    • Events – Event streams lead to their own specific processing requirements. This may well not initially be an area that all companies directly deal with, as they are often positioned with IoT and information flows (from items like sensors, or where wider user sentiment or process exception handling is needed). However, it can also be simpler queue use with a move away from periodic/batch style integration and just a publish-and-subscribe solution using SAP’s event mesh. The ability to handle more complex or unstructured data events streams and processing can lead to wider opportunities; robotic process automation, bots, or to AI/ML solutions.
    • Data - I mention data here, as often it’s a fundamental underpinning of the company, either as supporting master data or as the actual business transactions and informational flows that occur across an enterprise. However, data also brings its own specific challenges. Thus, the volumes can be higher with bulk transfer options and require different solutions and options. Master Data Governance (MDG), also termed master data management (MDM), and informational reporting can often be grouped under ‘data’ but are very different topics in their own right. Any strategy review of integration must address all aspects of your company’s underlying data.

How to address these changes?

Historically, business processes are met via core on-premise applications. They synchronize any supporting master data across the landscape, enabling transactions to be passed across systems sharing this common underlying master data.

Cloud apps can directly use information from multiple systems via APIs or microservices.

However, in the cloud world, this is not the case. Cloud apps can directly use information from multiple systems via application program interfaces (APIs) or microservices, creating solutions spanning multiple systems (including partner systems!) and avoiding, or at least reducing, underlying interfaces between applications.

So while integration still covers the underlying process and data integration that many businesses require, it must also support newer areas, including cloud-based user apps and events with streams of information, to device/sensor data to support the internet of things or IoT.

To address these changes, it’s worth considering SAP’s Integration Suite. SAP’s Integration suite provides not just SAP’s core cloud-based integration solution but also (as the name suggests) a suite of solutions that can cover both cloud and ground (on-premise) integration for a hybrid integration landscape.

It’s time to reassess your strategic integration approach

It frequently strikes me just how broad the topic of integration is and how it has started to overlap with the broader development, user experience, data, and even innovation areas such as IoT and AI/ML. SAP’s RISE with SAP reinforces the fact that there is an underlying SAP solution and standard data model regardless of a company’s position from cloud to on-premise solutions. But, to maximize these benefits, a clear approach to developments and SAP cloud platform integration is also required.

The key point is that design approaches will be fundamentally different, and integration is now more than just specific interfaces. While avoiding complexity, teams will have to approach integration from a much more open and wider perspective. Overall, I suggest that integration architects dive into the new opportunities and reassess their strategic integration approach and tools in a more complex, hybrid landscape.

We are keen to talk to companies with large SAP-focused landscapes and understand how they want to transform their delivery capability and maximize cloud utilization.

There is a range of associated topics that complement the integration topic that I will cover in a series of five-minute read blogs, all aimed at enterprises with a specific SAP focus. The other blogs cover items such as; realizing a clean digital core, managing extension and developments, building your DevOps capability with SAP, intelligent enterprise solutions, service improvement (such as AIOps), and building a richer user and business experience.

Get HCLTech Insights and Updates delivered to your inbox

Share On