The Long Term Problems with SAP and Integration

Executive Summary

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

Introduction

In its history, SAP has not been successful in creating integration applications. SAP PO is not well regarded and would be a distant second to the top integration tools in the field and they do 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 scrips and other specialized integration scripts are often preferable over packaged solutions. SAP proposes that integration should be performed in ABAP, or that SAP tools should be used to create ABAP, but there are other superior languages for interface development.

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 when it comes to 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

Overall the integration market has for several decades been marked by claims around ease of integration brought by various products. Most of those claims have proven to not 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 the evolution of SAP’s integration solutions, SAP has attempted to move from programming paradigm to non-programming. This is when writing of 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 to SAP MII, that 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 in the market with PO declining in popularity further 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 remote SAP System. The Hybris Data Hub is aimed at integration the integration of SAP’s Hybris e-commerce application with a short number of functions in SAP ERP 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 C/C++ library that wrapped with Java library that wrapped with one of listed integration tool (much like an onion).

  • SAP has historically benefited from a large pool of specialized workers that are able to 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. Doing this they were able to develop a very large 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 itself.
  • 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 to most of SAP systems. However, by the end of the 2000s, we already had a massive offering of different technologies and concepts that is 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 aimed at integration with SAP ERP to extend its planning, reporting or any other abilities. There has also been the massively increased popularity of mobile and web-based solutions that also aimed to be integrated to 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,

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

SAP Contact Form

  • Interested in Our SAP Research?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch.

References

https://aiche.onlinelibrary.wiley.com/doi/epdf/10.1002/btm2.10084

How Useful is SAP API Management?

Executive Summary

  • SAP API Management is resold Apigee and is promoted to improve integration.
  • How valid are SAP’s claims around SAP API Management?

Introduction

SAP offers the following video on the SAP API Management product. We have placed our observations about the video below the video.

SAP API Management as Part of SAP Cloud?

We have already written about how SAP Cloud is primarily a mechanism for upcharging other cloud providers in the article How to Understand SAP’s Upcharge as a Service. So right off the bat, an item that is part of SAP Cloud is a problematic item to use. Secondly, beyond the very poor financial terms of SAP Cloud, SAP Cloud is a highly inefficient PaaS to use. Therefore the connection between SAP API Management and SAP Cloud is a bit of a deal breaker for us.

Sharing Mobile Data, IoT and Production Data with SAP API Management?

SAP really only has control over one of these three areas. They have nearly no IoT business, they are a nonentity in mobile. Therefore this proposed ability to share SAP data among these three areas is not persuasive. The whole “sharing real-time data” statement is very much not educational. Any interface can be scheduled to run in batch or in real time.

Real Time Analytics?

Analytics can be run real time, which is called a refresh….but what does this have to do with SAP API Management?

Manage Your Entire Ecosystem of Customers and Suppliers?

SAP has the most difficult to integrate products in enterprise software. As for collaboration, SAP’s SNC product is no longer functional. Ariba is in decline and has never extended much beyond indirect procurement. In fact, placing one’s data into SAP is one of the best ways to reduce one’s interaction with outside entities. Therefore will all of these areas be magically improved by using an API management tool like Apigee, or SAP API Management? This seems like quite a stretch.

SAP and Microservices with SAP API Management

This quote is from the Apigee website.

“Many existing and legacy services are not built for modern scale. Consequently, enterprises are adapting legacy services for modern use by breaking up monolithic applications into microservices. In most cases, however, there are already many applications taking advantage of services from the monoliths. The transition to microservices must be done in a way that makes it seamless—invisible to those other applications and developers using the monolith services.

Design and build APIs that developers love. Easily create API proxies and visually configure or code API policies as steps in the API flow. Customize API behavior using JavaScript, Python, or Node.js. Transform from or to any protocol including SOAP, REST, XML binary, and custom protocols.”

There are several problems with this quote. Let us list them.

  1. Companies are breaking monolithic applications into microservice….but not SAP customers. SAP is firmly a series of monolithic applications, and there is no movement afoot to break them into microservices. What SAP is doing is co-opting the terms around microservices without actually becoming microservice in their design. This is the same issue with using the term containers with SAP. It is not a thing that is presently done with SAP. Secondly, SAP projects have all manner of higher priority items they need to invest in, such as evaluating code prior to S/4HANA implementations. It is unlikely that microservices area true emphasis area for SAP or their customers.
  2. SAP does not use Python or Node.js. They have documentation around SOAP, REST and XML but they are not a “thing” on SAP projects. SAP uses a language called ABAP that has nothing to do with anything mentioned in this quote, along with some Java. And ABAP is distinctly not appropriate for and web development.
  3. SAP is about creating interfaces with ABAP, sometimes to IDOCS which are hierarchical files that require extensive transformation. SAP has not changed its integration much since the 1990s in a way that has meant much for projects (new products have been introduced, but none of them have been competitive with custom integration using programming rather than interfaces, which is a topic we covered in the article How Non Programming Integration Hurts SAP Projects.

Conclusion

We did not evaluate Apigee for this analysis. Apigee may be a great product. However, it does not fit with how SAP operates and its technology foundations. The fact that SAP is reselling Apigee (and combining it with SAP Cloud) really only means that SAP is offering customers the opportunity to be upcharged for a product it has nothing to do with. It never makes sense to purchase a product through SAP, because SAP will exaggerate the price and also the claims made by the actual software vendor.

By connecting Apigee/SAP API Management to the SAP Cloud, they drastically reduced the value of Apigee. Not only will SAP demand an upcharge for Apigee, but they will upcharge customers on any usage of APIs that are developed by Apigee as they will consume cloud services.

The fundamental problem is that SAP does not work anything like the environment that Apigee was designed for. Apigee is designed to manage services run from cloud service providers like AWS and GCP using modern development approaches under the construct of openness.

This is the exact opposite of how SAP environments work.

Now, we should mention that we/Brightwork is very much a supporter of the model proposed by Apigee. And we wrote two books about how to bring cloud services to SAP and Oracle environments and address the topics of microservices and containers and new development approaches taking place in the cloud in great detail. So we have no disagreement with the model presented by Apigee. However, this cannot be effectively performed within SAP’s construct. SAP had a comparative advantage in ERP systems, and it is attempting to use the account control built up from its ERP heritage to extend and insert itself into the cloud. Customers should be careful not to let SAP do this because so far, SAP has added nothing to the cloud except cloud confusion. The leaders in the cloud are far away from SAP in technology and approach. In fact, SAP should be considered an anti-cloud company. And the more customers allow SAP to insert themselves into their cloud, the more the cloud will turn into a negative ROI item that is entirely controlled by SAP.

And all of this is why we are predicting so much cloud expenditure will be wasted through SAP customers taking advice from SAP and their consulting partners on the topic of the cloud.

  • SAP is a non-starter as a cloud provider or cloud thinker. Most of what SAP states about the cloud is not correct or helpful.
  • Customers that want to use Apigee or a similar tool along with innovative cloud service providers for new development should absolutely do this and then connect this SAP independent development back to SAP. However, they should not touch SAP API Management with a ten-foot pole.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

SAP Contact Form

  • Interested in Our SAP Research?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch.

References

https://apigee.com/api-management/#/products

AWS and Google Cloud Book

How to Leverage AWS and Google Cloud for SAP and Oracle Environments

Interested in how to use AWS and Google Cloud for on-premises environments, and why this is one of the primary ways to obtain more value from SAP and Oracle? See the link for an explanation of the book. This is a book that provides an overview that no one interested in the cloud for SAP and Oracle should go without reading.

Are SAP’s REST/JSON APIs Real?

What This Article Covers

  • The Question on REST/JSON APIs
  • The Consistency of Open APIs + Indirect Access?

Introduction

SAP has been telling customers that they are bringing out a large number of REST/JSON APIs. In this article, we will review the likelihood of these APIs becoming prevalent.

The Question

“In recent discussions with SAP they have talked about web services becoming more standard and even mentioned 3000 REST/JSON APIs that are available on the platform (not sure which version?) and that is certainly a technology that my team has been ready for and would like to leverage.

That said, I’m not seeing signs of the many APIs that were reported.

Have you seen any research on SAPs ability to deliver this technology? Is it still in the works? Is there any customer adoption?”

The Analysis

This plan has not been brought to my attention. But there are several reasons to be skeptical.

SAP’s History of Restricting Integration

SAP has always made it difficult to connect to SAP. This is a premeditated strategy designed to direct companies to SAP products. SAP has made numerous statements about making integration easier over the years, but it has tended to stay the same. This is one of the reasons that companies that use SAP have such a high IT overhead. Not only is integrating to SAP difficult but simply extracting data from SAP is more difficult than any other ERP system, because SAP does not allow customers to direct access tables, as do all other ERP vendors.

The Consistency of Open APIs + Indirect Access?

If SAP is opening up technically, why are they closing down access from the legal side?

Every one of those 3000 APIs is a potential indirect access violation.

According to SAP, SAP account executives are “not trained on indirect access,” so they can introduce the APIs one month, and then an “indirect access expert” can show up a year down the line and say “these connections are all indirect access violations, and you owe us $XXX.” There is no what to know if that would actually happen. SAP applies indirect access selectively.

None of my customers are using these APIs, and SAP is always introducing new things, so if they are new, we don’t know if they will take. This is the official site/pages for the APIs

Conclusion

There are articles going back to 2013 on SAP APIs, and if they are not “a thing” by this time, they probably won’t be.

So it sounds fishy. But this can be researched to find out. If the response requests for real information is that “its coming” then its probably fake. This is yet another example of how SAP account executives tell so many lies to prospects from and from so many dimensions.

SAP Licensing Research Contact

  • Interested in Our SAP Licensing Research?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch.

References

https://help.sap.com/saphelp_smp304svr/helpdata/en/7c/0a4f017006101484238a3b00c4d5d0/frameset.htm, and it looks pretty thin.

Enterprise Software Risk Book

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Rethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model

How Accurate is SAP on SAP HANA Cloud Integration?

 What This Article Covers

  • What Does SAP Say About SAP HANA Cloud Integration?
  • Build Integration Solutions with SAP Cloud Platform Integration?
  • Does What SAP Make Any Sense?
  • Does SAP Provide Any Evidence for Its Claims
  • Does What SAP Says Accurately Reflect What is Happening on Projects?

Introduction

SAP often presents the benefits of SAP HANA Cloud integration. In this article, we will review SAP’s media output to observe its accuracy.

Connect and Integrate with SAP HANA Cloud Integration

“Easily exchange data in real-time with SAP Cloud Platform Integration. Integrate processes and data between cloud apps, 3rd party applications and on-premises solutions with this open, flexible, on-demand integration system running as a core service on SAP Cloud Platform.”

How is this accomplished? Also, why is this better than using another integration application? SAP has been guilty of making a number of exaggerated claims about its “platforms” that end up not being easier to use than competing offerings.

Obviously, any application interface can be made real time. But in many cases, it makes more sense for it to be in batch. Why is SAP including “real-time” into this description when it is well known that any interface can be made real time?

What does..

“on-demand integration”

..mean?

Any integration harness or application is on-demand for the people that use it. What does it mean that it runs as a core service as part of the SAP Cloud Platform? Isn’t it part of the SAP Cloud Platform anyway? Also is it really a platform, or just an area where integration development can be performed.

SAP goes on to to say the following:

Key benefits include:

“Access a deep catalog of integration flows.

Integrate both processes and data through unified technology engineered for the cloud.

Get an integration service that is secure, reliable and delivered and managed by SAP in SAP’s secure data centers across the globe.

Lower TCO with an affordable, pay-as-you-go subscription model and minimal up-front”

Does SAP have any independent studies that can demonstrate that the SAP HANA Cloud Platform lowers TCO, or is this just a sales statement that has nothing to back it up?

SAP Cloud Platform Smart Data Integration?

“With SAP Cloud Platform Smart Data Integration, you can replicate, virtualize and transform data from multiple sources and store it in your SAP HANA instance on SAP Cloud Platform. Smart data integration offers pre-built adapters to common data sources plus an adapter SDK that lets you get data from any source for a 360-degree view of your business. Thanks to a cloud-first architecture your data is securely transferred from on-premises applications to the cloud without putting your business at risk.”

Most SAP customers don’t have HANA. So what if the customer does not want HANA, can they use the SAP HANA Cloud Platform to store in Oracle, MongoDB, PostgreSQL, Tibero or another non-SAP database?

What is a cloud-first architecture? Are many customers using the SAP HANA Cloud Platform to do the things listed by SAP?

Build Integration Solutions with SAP Cloud Platform Integration?

“SAP Cloud Platform Integration is making process integration simple and reliable.

It is SAP’s strategic integration platform for SAP Cloud Customers and provides out-of-the-box connectivity across cloud and on-premise solutions.”

SAP, outside of its acquired applications (SuccessFactors, Ariba, Concur, etc..) has very little in the way of cloud customers. The vast majority of SAP customers are using SAP software in an on-premises delivery mode.

When SAP uses the term “out of the box” it is time to question this. Out of the box is a highly salesy term which usually translates to “a lot of work is required.” This is particularly misleading as Bill McDermott has already stated the following about integrating SAP’s cloud acquisitions with their ERP system.

“With all those new products both homegrown and acquired, building native integration has been a challenge for SAP in the past seven years. If they want customers to sign on to the whole vision, with core ERP alongside SAP-owned cloud providers, integration is a key selling point. McDermott admits to the SAP Ariba main stage crowd that it hasn’t been easy.”

Conclusion

SAP names many things that can be done in SAP Cloud Platform, but this does not necessarily mean that customers should be using SAP Cloud Platform to do these things.  Furthermore, the article does a poor job of describing what is actually happening on projects.

This article receives a Brightwork Accuracy Score of 3 out of 10, mostly for how much information it leaves out.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

SAP Contact Form

  • Interested in Our SAP Research?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch.

References

https://www.sap.com/products/hana-cloud-integration.html

https://cloudplatform.sap.com/capabilities/integration/cloud-integration.html

https://www.sapappsdevelopmentpartnercenter.com/en/build/sap-hana-cloud-integration/

https://www.asug.com/news/sap-ceo-bill-mcdermott-s-4hana-integration-is-top-r-d-priority

Enterprise Software Risk Book

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Rethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model

Enterprise Software Risk

See our free project risk estimators that are available per application. The provide a method of risk analysis that is not available from other sources.