- SAP has proposed that Fiori makes sense to customize, that Fiori is extensible and that customization has been a major driver for R/3 and ECC acceptance. Furthermore, that R/3 was popular because it had cost efficient extensions.
- We review the accuracy of these claims.
SAP proposed in the document SAP S/4HANA Extensibility for Customers and Partners, some claims regarding S/4HANA and its customization.
In this article, we will review the accuracy of this SAP article.
“Customers using the side-by-side extensibility approach can use SAP HANA Cloud Platform to build completely new UIs based on the SAP Fiori user experience or integrate with other cloud applications from SAP.”
As we cover in the article What is Actually in the Fiori Box? Fiori is well known to be extremely difficult to customize. Projects where customization of Fiori are estimated end up being stratospheric and often get cancelled. Regardless, this document is stating that customization is a good idea.
ABAP as a Good Value?
“They can also build completely new applications and business logic that natively run on the SAP HANA platform or that are loosely coupled to the ABAP programming language back end of SAP S/4HANA.”
As we covered in the article, ABAP programming language back end of SAP S/4HANA.
ABAP is an inefficient programming language which is increasingly limited as development goes to the cloud.
Extensibility, A New Synonym for Customization?
“In SAP S/4HANA on premise, full flexibility to ABAP through ABAP in Eclipse (a development platform) is guaranteed.”
Extensibility means it can be extended, but all applications are extendable. SAP can also be extended through using any programming language that can connect to SAP function modules. It is not SAP that guarantees extensibility, is the nature of any application.
SAP R/3 Was Popular Because of Cost Efficient Extensions?
“For many years, SAP has implemented successful processes for scalable and cost-efficient extensions in all product versions.”
Has SAP cost efficient extensions? Having been on SAP projects for decades, I am unaware as to what this is. Either these extensions are a secret, or SAP is referring to customization.
Furthermore, does SAP seriously expect to leave with any credibility after proposing that customizing SAP is “cost efficient?”
That is odd. Because SAP projects are known for their excessive customization costs, some failed SAP projects have run into the billions of dollars. How did that happen without high priced customizations?
This document must be referring to another company called SAP that sold an application called R/3.
Ding Ding Ding!
This statement by SAP regarding low-cost customizations earns our Golden Pinocchio for being as false and as deliberately misleading as a statement can be.
Ease of Customization Was a Major Driver for R/3 Acceptance?
“This was a major driver of the large acceptance and adoption of SAP R/3 software, the SAP ERP application, and SAP Business Suite software (for example, by using the SAP NetWeaver technology platform for on-premise extensions of SAP Business Suite).”
SAP R/3 was adopted for many reasons, one being an arrangement between SAP and large consulting companies where the consulting companies sold out the interests of their customers so they could profit maximize at their customers. SAP was the vendor that allowed them to make the most money.
SAP is not more customizable than competing applications; it is less customizable. It has the highest cost of customization and maintenance of any vendor that we track at Brightwork. Furthermore, NetWeaver as a specific product never existed, as we covered in the article Did Netweaver Ever Exist?
SAP’s Proposal for Improved Upgradability of S/4HANA: A Whole Lot of Nothing
SAP performs a significant sleight of hand with the following few paragraphs. Now watch how the masters at SAP Marketing set up a false conclusion, without most readers ever noticing.
Step 1: SAP begins the deception by making a true statement.
“When implementing software extensions using a traditional approach, many organizations run large implementation projects with significant modifications to the standard enterprise software. At first, the high degree of flexibility may be regarded as a benefit. However, during subsequent phases of the lifecycle of the extensions, modifications may become pitfalls:”
This statement is mostly correct, but it glosses over the reason for the customizations. We won’t go into it now, let us see where SAP goes next.
“Since business experts usually do not implement extensions, interaction between the line of business (LoB) and IT often works like a waterfall model for large projects (no interconnected requirements determination and implementation phase) and thus increases time to value.”
Yes, the people writing the customizations (i.e., enhancement in SAP’s strange new vocabulary) are not the business. And writing customizations does increase the time to value, but that is true of all customizations. There is nothing new here.
“Large effort occurs for tests, validations, and adaptations necessary at every upgrade of the standard software to a new version due to (mostly) hidden dependencies between standard and extensions. The result is slow implementation of require-
ments from the LoB and delay of adoption of innovations due to the upgrade effort mentioned above.”
A bit of beating a dead horse, but also true. Once again, none of the reasons for the customization is given in this sequence. These are all negatives of customizations being listed by SAP.
“Today, this approach is taken to the next level with SAP S/4HANA: You can apply a tool-based and platform-based methodology, which is scalable for companies ranging from small startups to large enterprises and which intrinsically avoids the drawbacks mentioned above by using the following extensibility qualities:
- “End-to-end tools: Business users, experts, and implementation consultants can easily apply changes in their area of responsibility without risk.
- Pace layer IT: Custom extensions are loosely coupled with core business processes; that is, they need robust data, process, and UI integration, but the software lifecycle of extensions is decoupled from stable systems of records.
- The ecosystem of SAP partners: Customers get support to apply these principles and to implement differentiating solutions. In particular, partners often require a platform as a service (PaaS) for the development, distribution, and maintenance of their solutions.”
The problem? None of these things lead to increased upgradeability.
- SAP does not offer end to end tools that allow the entities mentioned to apply changes quickly. How would that even work? Customization must be adjusted in preparation for an upgrade. That means the code must be modified. Why is that all of a sudden easily applied “without risk” with S/4HANA in the cloud? That is just a marketing fiction.
- Pace layers IT is made up. “tight data, process, and UI integration” does not mean anything. And SAP has not had such a high cost of customization has not been because of “loose” data, process, and UI integration.
- SAP already has an ecosystem of SAP partners. This did nothing to ameliorate the high costs of customizing SAP in the past. It fed into it. That “ecosystem of SAP partners” is about billing as many hours for ABAP and possible. This would be like saying people will run faster before because now they will have legs. Yes, but they had legs before.
After all that build up the result regarding what SAP offers for S/4HANA regarding enhanced upgradeability is….nothing at all.
A Comprehensive Set of Tools, Platforms, and Methodologies?
“SAP S/4HANA extensibility provides a comprehensive set of tools, platforms, and methodologies to serve the needs of customers and partners with the qualities outlined above.”
Perhaps, but how is it different from what was offered by ECC? Furthermore, just because SAP provides something does not mean it should be used. For example, VW offers the diesel Golf, but we don’t recommend you buy one.
Again, SAP offered many tools for ECC and an SDK for iOS, but none of these items have proven to be competitive with using open tools.
“Since SAP HANA Cloud Platform is a full-fledged development platform, they can even build completely new solutions with a loose coupling to SAP back-end systems. SAP HANA Cloud Platform is designed to be 100% compliant with open standards (for example, using open source software from Eclipse and Apache).”
SAP’s development tools and related products have proven to be uncompetitive in the past and to increase the costs to customers. If SAP were in favor of open standards, they would make their applications accessible to already existing PaaS environments instead of channeling their customers to using 100% SAP items. The idea that SAP supports open standards is “fall laughing” amusing. It is a massive lie.
A Healthy Ecosystem for the HCP?
“When using SAP HANA Cloud Platform, you will therefore benefit from a healthy ecosystem of partners that contribute value to existing solutions and services. With this scenario, you can establish “best of breed” for small and large extensions. By definition, side-by-side extensions are loosely coupled with core SAP systems and therefore support a pace-layered IT.”
Does HCP have a vibrant ecosystem surrounding it? That is news to us.
Does ABAP have a vibrant ecosystem around it? Well yes, if the definition of a “vibrant ecosystem” is a massive group of consultants and employees who will charge customers to do things inefficiently. Furthermore, would anyone use HCP if the environment were not SAP? No? Then that tells you how competitive the offering is. HCP is a highly uncompetitive offering that is forced into companies through SAP’s pressure and by misinforming customers that the HCP is necessary for customizing SAP. SAP played the same tricks with ABAP for decades.
SAP’s Prescription for Continued Control
The important distinction is “not necessarily HCP (The HANA Cloud Platform – SAP’s development environment PaaS). But SAP is not describing other options in the article SAP S/4HANA Extensibility for Customers and Partners.
So what you these comments stated was true in the hypothetical sense, but our critique is what SAP is saying in this document, (which we analyze in the article How Accurate is SAP on the Use of the Term Extensible for S/4HANA?
And all SAP actions, as well as the documentation, demonstrate that they are intent on pushing everything towards SAP.
Who Will Tell SAP Customers the Truth?
Web application development, unlike ABAP, as the commenters pointed out, are filled with non-SAP development options. But who will tell SAP customers this? Deloitte and Accenture etc. will say to their customers exactly what SAP tells them to. Someone has to tell the customers that SAP’s proposals are false.
But SAP approves consulting partners is for them to serve as copy machines for SAP.
Controlling the Narrative
What SAP is doing is obvious. Get ahead of the topic, and create a structure and set of assumptions that reduce the options so that it remains controlled by SAP.
SAP wants to live in two worlds — preach the cloud (make Wall Street happy), but keep on-premises types of control.
The Word Extensibility
Regarding extensibility, SAP is creating a word that has previously not been used with SAP. Outside of SAP, the commenters are right.
I give the example of WordPress, Plugins give WordPress extensibility. But WordPress is an open system and wants companies to develop plug-ins. SAP is the opposite. It is a closed system. It has software partners, but it undermines those partners and makes their applications challenging to integrate to, in fact, puts into place legal constructs like indirect access to dissuade anyone from buying anything but SAP.
SAP is using the word extensibility because it sounds low effort and “out of the box.” They are using the word extensibility to whitewash the word customization.
SAP repeatedly use the word extensibility to refer to R/3, stating that was customization was actually “extensibility.” There is no other way of interpreting this than SAP trying to trick readers.
Upon reading the document, it is apparent that SAP plans to push companies from on-premises ABAP to using S/4HANA with the HCP. However, once again, SAP is dictating the programming environment, which hasn’t lead to good outcomes in the past.
SAP presents itself as if it has all the answers on these topics when it doesn’t. For one, S/4HANA in the cloud has a small customer base. But secondly, the terminology used by SAP must be dissected. What is “extensibility?” It seems to be a code word for custom code. What happens when an application is customized? That is right, multitenant is out the window. And multitenant is a foundational underpinning of SaaS and a primary way it leads to cost savings through improved sustainability and lower maintenance. This is why S/4HANA customers in the cloud are small — they don’t customize.
Ding Ding Ding!
SAP receives a Fake Marketing Word Alert for its creation and usage of a new mysterious IT term called extensibility.
Some are consulting companies that are trying to suck up to SAP and use an “implementation of S/4HANA” to get consulting business. That is, they barely need S/4HANA but need Quickbooks, and invoicing system and HR system, all of which they could purchase in the cloud for peanuts.
With SAP using the word “extensibility,” it makes it seem like it is not customization. Extensibility means it can be extended, but all applications are extendable. This is SAP marketing working overtime to mislead customers by coming up with more deceptive words.
There is just all manner of inaccuracies in the document from SAP.
This document receives a 1 out of 10 for accuracy. It is a work of pure marketing fluff and relied upon an enormous number of inaccurate assumptions. It won both a Golden Pinocchio as well as a Fake Marketing Word Alert.
It is a document in search of soft targets.