The Long Term Problems with SAP and Integration - Brightwork Research & Analysis

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

SAP makes bold statements about application integration that assumes SAP’s integration competence.
We review SAP’s history with integration.

Video Introduction: The Long Term Problems with SAP and Integration

Text Introduction (Skip if You Watched the Video)

In its history, SAP has not been successful in creating integration applications. SAP integration is generally difficult. SAP PO is not well regarded. SAP does not sell integration applications like SAP PO to anyone but pre-existing SAP accounts, usually under the concept that SAP PO is naturally designed to integrate to SAP. And for many types of integration work, using data transformation scripts and other specialized integration scripts is often preferable over packaged solutions. SAP proposes that integration should be performed in ABAP or that SAP tools should create ABAP. You will learn how there are other superior languages for interface development.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem.
Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers.

Yet, nowhere is this observed in any of the SAP documentation. As an example, ABAP is not used outside of SAP customers for interface development. Languages like AWK are quite frequently used for transformation because they are naturally designed for this task.

Following SAP’s Integration Advice?

If SAP’s applications are not used in an area, and the area is programming intensive (which integration is), there is little reason to follow SAP’s advice regarding what language to use or what tools to use. The entire logic for following SAP’s directives is if one is using their packaged applications.

Previous Claims Made in the Application Integration Market

For several decades, the integration market has been marked by claims around ease of integration brought by various products. Most of those claims have proven not to be true. That is, the movement has been from using programming to using applications to perform the integration.

In more cases than not, this has proven to be negative for integration productivity and even transparency. It is apparent from SAP’s documentation and other marketing literature that SAP is not interpreting their attempts to productize integration in a way that allows them to understand why they are not making progress in the integration space. This gets into the topic of the non-programming integration paradigm.

The Non-Programming Integration Paradigm

If we follow SAP’s integration solutions’ evolution, SAP has attempted to move from a programming paradigm to a non-programming. This was when writing explicit code was replaced with some transactions for customization.

A few examples are as follows:

2005: SAP renamed XI to PI (Process Integration) due to modification of licensing policy, so that clients paid for traffic, but not per instance. Also, SAP extended the number of use cases in marketing materials. In the same year, SAP acquired LightHammer. LightHammer had and their integration solution aimed at the manufacturing domain. Later this solution was renamed SAP MII, which was delivered with SAP PCo (Plant Connectivity). An additional service aimed at industrial support interfaces of data exchange like OPC. SAP MII was also built as a wrapper on top of C/C++ libraries.
2011: SAP PI was renamed to SAP PO (Process Orchestration). However, it was more marketing rebranding than a technology update. This rename did not change SAP PO’s prospects globally, with PO declining in popularity since 2011.
2016: SAP presents its Cloud Platform Integration & Hybris Data Hub. The SAP Cloud Platform (renamed from SAP HCP) is designed to perform integration with a remote SAP System. The Hybris Data Hub aims to integrate SAP’s Hybris e-commerce application with a small number of SAP ERP functions, like material master data, stock value, and prices.

Document Note *This is a truncated history, but it should be sufficient to illustrate the pattern we are describing.

All of the technologies listed in the previous section are based on the C/C++ library that wrapped with Java library that wrapped with one of the listed integration tools (much like an onion).

SAP has historically benefited from a large pool of specialized workers that can configure systems without knowing how to code. This is the standard SAP “functional consultant” as opposed to a “technical consultant.”
Meanwhile, vendors ranging from Oracle to Axapta to Baan frequently struggle with a shortage of well-qualified IT resources to build their ecosystems. SAP easily attracted non-technical resources and converted them to consultants. They developed a vast number of resources who were ready to set up all business logic in SPRO/configuration. Without writing a single line of code with most of these resources working in SAP consulting partners or as independent consultants rather than working for SAP.
The approach to making the configuration available within an application reduced the learning curve for configuring SAP and opened the area to more resources.

Issues with The Non-Programming Approach for Integration

In the mid-2000s, this might be proposed to be a reasonable trade-off (although we would have disagreed with it even then). However, at that point, there was little to integrate into most of the SAP systems. However, by the end of the 2000s, we already had a large offering of different technologies and concepts that are still growing. And these are becoming more available due to cloud service providers. This allows companies to experiment at low effort in a way that was previously not possible.
In recent years, we see the growth of solutions to integrate with SAP ERP to extend its planning, reporting, or other abilities. There has also been the massively increased popularity of mobile and web-based solutions that also aimed to be integrated into SAP.

Getting to the Heart of the Problem with SAP’s Integration Strategy

The biggest problem of current integration products from SAP is that SAP provides an inappropriate model of integration.
Features that made SAP XI/PI/PO accessible to SAP consultants are now doing them a disservice.
SAP PO was not designed to work with most of the contemporary technologies and protocols.

We put AIF and BRF in a similar category with SAP PO, which is why, in addition to the products not matching the SAP pronouncements about them.

I am frequently asked how difficult it is to connect various best-of-breed planning solutions to SAP. I typically answer that integration between planning systems and SAP is greatly overrated in terms of difficulty. I often comment that planning systems benefit from having only a few interactions with ERP execution systems. I also tell people that I have integrated planning systems to SAP roughly five times (both serving as the integration application engineer and managing the integration). I have never run into a major complication or missed deadline (unlike my experience with implementing supply chain application modules).

Sales Orders and Forecast Consumption

Furthermore, the documentation on this issue was slight, and we had to raise a note to SAP. The lesson from this experience is that the transactions that flow from SAP ERP control essential functions within APO. However, is this desirable?

SAP would clearly say this is desirable. However, my experience is that it isn’t. SAP developed from an execution system and entered into the planning market in my view, primarily at the nudging of analysts who very shortsightedly declared ERP “dead” back in the late 1990s (which brings up the topic of the accuracy level of software analyst firm’s projections). SAP brought their extreme complexity and detail-oriented approach, which they had developed from their experience in execution systems to APO, not an execution system. Unfortunately, this has not been a good match.

Planning systems deal at a more aggregated level than execution systems. Having three quantities associated with a Sales Order is unnecessary. Having a configuration in the ERP system that controls essential functions such as forecast consumption in APO is more of a liability. As a planning consultant, I want to control the consumption within APO entirely, and I don’t want to be surprised like this that I then have to sort out with the ERP team. This glitch prevented the client from using the consumption logic for several months. The issue is that SAP has never seemed to understand that planning systems are different from execution systems, and this has resulted in a difficult to implement software suite in APO vs. best of breed vendors.

For those that don’t think this one setting is that big of an issue, one should understand that this is just one setting (and a not well-documented setting). There are hundreds of settings like this, and every time I arrive on a project, because the project documentation is not well maintained in 90% of the instances, I have to check everyone one of these settings. This is why it takes so long to troubleshoot APO vs. other planning software. The importance of not documenting everything in APO was highlighted by the experience described here.

Conclusion

In the cases that I have created custom integration harnesses, I never ran into these problems because I could control the meaning of the transported objects (Sales Orders, On Hand, Stock Transfers, Purchase Orders, etc..) more easily than with the CIF. However, with the CIF, you end up getting unwelcome surprises precisely like this. SAP has taken the approach that there should be tremendous complexity in the logic of the integration between their ERP system and APO. I don’t think this has been a correct decision.