As we all know by now, diversity matters. We need to ensure that we approach all aspects of life with an inherently open approach to diversity from a human, ethical and wider behavioral and operational perspective at all times. A key part of that process on a human level is making sure we expose ourselves to other things, other experiences and to other places and people.
If enterprise technology is capable of imitating life (or art) in any significant way, then it is through its need to be architected with interoperability to and from other systems, not all of which will necessarily share the same shape, form factor, conduits, protocols and device outputs.
Extend, expose, exchange
When we think about how SAP systems need to be able to extend securely outwards to interconnect with non-SAP systems, we should first realize why we are performing such an action. One of the central rationales for planning to connect non-SAP systems in an SAP landscape are the business opportunities created by extending, exposing and exchanging data and application resources. Additional rationales could be, for example, legal requirements like Electronic Invoicing for Brazil (Nota Fiscal Electronica – NFE).
As we move to start integrating and connecting data, applications and all forms of IT services, we need to remember that not all forms of data are necessarily equal. We could be thinking about taking raw data from SAP and exposing it to another IT service, in which case it may need deduplication, parsing and other forms of data preparation.
Organizations also need to be able to shoulder the challenges that come from connecting not just different types of data, but also data that runs at a different cadence i.e. we might be talking about real-time data, asynchronous data streams or data that is generated on a more ad hoc basis. It’s important to know not just what, but also when.
The push & pull of data
There is a working push and pull effect on data caused by any number of factors. This might range from regulatory requirements to strategic business decisions and even perhaps onwards for some form of prototyped experimentation as new business services are created.
Because every data integration needs to have a validated business case behind it, a business should work to a formalized integration diagram and document. This is of acute importance in scenarios where the data engineers and business people who initiated integration of any kind have left an organization. Laying down and documenting the architectural requirements that govern the journey data takes into and out of SAP systems is of fundamental importance, and even more so in a Cloud-based SAP scenario.
Businesses looking to perform this level of data should be aware of middle-tier interfacing systems that will further impact the data’s journey.
As organisations direct their SAP S4/HANA deployment release and ingest data, they will need to consider where the master records of data are held for any given use. Keeping sight of the ‘single source of truth’ inside any organisation is a core mission here, so let’s also remember that the central point of information may not always be an SAP system. Sometimes data ground zero could be an SAP system given the platform’s widespread use as a system of record, but it could equally be an enterprise inventory system that holds the kernel of a firm’s information store.
Possibilities of incompatibilities
Inevitably we come to the point in this analysis when we need to stop and think about error handling, exceptions, syntax incompatibilities, parsing mismatches and all the other areas where two systems may come together. This challenge can create various forms of system clash, crash or possibly some higher-level compromise.
This is a big challenge for many organizations, especially ones that have a narrow time window within their SAP systems in terms of their Recovery Point Objective (RPO) parameters, which should ideally be set to zero but are sometimes longer. The business will need to have established procedures for reprocessing the operations that have experienced mismatch or corruption.
Organizations should of course pay attention to their live Production systems first and perform mandatory testing of procedures in Development or Quality Assurance systems before making any changes in Production. This is especially true where any type of patching is going on.
As analyst house IDC reminds us, data integration and intelligence have been a key consideration for businesses across all verticals throughout the Covid-19 pandemic. According to Stewart Bond, research director for data integration and intelligence software research at IDC, “Data and analytics initiatives have been identified as a high priority for organizations that need to continue their digital transformation and plan for digital resiliency.”
Algorithmic engine power
A central technology proof point for SAP S/4HANA is its ability to turn data into actionable insights and predictive foresight. It does this through algorithm-led principles, rather than by human intuition. But achieving this in the real world is only possible when data has been integrated in a secure and managed way.
There is no universal adapter kit or guide available to shoulder the challenge of data integration into and out of SAP, or across any other enterprise software platform, suite or product. Working with a partner who has experience at the coalface of these tasks is essential unless a business wants to risk having to learn from too many of its own mistakes. Data does have an inherent ability to connect to other data, but knowing where the seams are is essential if organizations want to weave a stronger final fabric.
