Why SAP and Oracle Have Such Problem Building their Clouds

Executive Summary

Oracle and SAP have built virtually nothing in their cloud services.
We cover why Oracle and SAP appear incapable of creating competitive clouds.

Introduction

While currently, both vendors cannot talk enough about the cloud, both vendors fought against the cloud for many years (and we have the evidence in this book). These vendors behaved this way as they knew that the cloud cut against their on-premises business model. Moreover, once they embraced the cloud (not that they wanted to, but Wall Street told them they did not have an alternative), their approach to the cloud has not been to improve IT efficiency or to reduce prices. Instead, it has been merely to lift and shift their business model to the cloud and then to deceive their customers and prospects as much as possible about the cloud.

See our references for this article and related articles at this link.

For instance, for years, Oracle has been crediting cloud sales to customers who use the same on-premises version of the application. Information from actual projects as well as Oracle sales reps is that the cloud version of the Oracle application is not implemented (but booked as revenue) while the on-premises version is not booked as revenue, but is used.

Seeking Alpha also explains this.

“Oracle management likes to talk a lot about new customers and competitive wins. I get that. I am sure that there are workloads new to Oracle on the cloud. How much these are I cannot say. But the fact is that core IT applications are simply not growing by all that much-they have long since been saturated. Most of the time when Oracle sells a cloud application, it is selling it to someone who has the selfsame application running on-prem.”

Thus the customers of both of these vendors are prime candidates to harness AWS and Google Cloud to improve their value.

The following quotation on this topic comes from Ahmed Azmi.

“Why does AWS, Google, and Alibaba have a good cloud product while SAP, Oracle, and IBM don’t? Because AWS, Google, and other cloud-natives had to build global scale infrastructure to support their internal workloads for e-commerce, search, and ads. They are now offering surplus capacity and a subset of their own tools to “external” customers. They understand the problem domain better than anyone else and they’re a decade ahead. Oracle, SAP, and IBM never had to operate a global e-commerce platform or host software at scale. They’re software houses who built (mostly acquired) then sold packaged software to customers and customers did the hosting on-premises. The institutional knowledge is not there.”

Ahmed’s point about SAP and Oracle’s lack of experience in implementing software internally is a good one. SAP and Oracle have only ever talked about and sold technology to others.

What are Oracle and SAP Investing in Cloud?

Both Oracle and SAP have tried to argue that they have made major investments in the cloud. Let us take a closer look at these claims. SAP’s lack of investment in the cloud has been well documented, one source being the book SAP Nation 2.0.

SAP’s Steve Lucas stated that they were not going to open their application to the cloud as it would be a “race to the bottom.” But then SAP introduced their multi-cloud strategy as covered in the article SAP’s Multicloud Announcement, where they fundamentally changed strategy from proposing that they would not open their solutions to the other cloud providers. To doing a 180 and stating their solutions would be to being complimentary with AWS, Google Cloud and Azure. Currently, SAP Cloud connects to AWS, Google Cloud, and Azure.
Oracle, on the other hand, has promoted its investment into the cloud and to directly challenging AWS. As we will discuss further in detail, Oracle has had to answer pointed questions as to why for a company which such enormous resources their investment in the cloud has been so small compared to the major cloud providers.

We conclude that neither Oracle nor SAP has any particular technology interest in the cloud. (Of course, they have a genuine monetary interest in the cloud, but this is to defend their on-premises ecosystems.) Instead they rightly viewed the cloud as a threat to their account control within their enormous respective account bases. And this is why both companies have a history of being so dismissive to the cloud, particularly in the cloud’s early period.

This video from 2009 shows Larry Ellison getting a lot of laughs applying a straw horse logical fallacy where he implies cloud merely is hosting.

In this amusing rant, it is difficult to critique the performance. However, he misses on the shared resource aspect of the cloud, the multi-tenancy of cloud, the sever-ability of cloud terms. Instead, Larry prefers to focus on arguments that were not particularly prevalent at time-related to the cloud having “no hardware”.

Moreover, nine years later, the Oracle Cloud is a non-factor on Oracle accounts. At the time of this video is 2009, while Oracle and SAP were “running down” (a bit of deliberate FUD perhaps?) cloud, AWS, and Google Cloud were investing in their offerings. Larry thought he and Oracle could ride the on-premises model forever. Now, after doing little aside from cranking up the cloud marketing machine for over a decade, Oracle is lost in making progress in its cloud. In September 2018, Thomas Kurian, the head of Oracle Cloud, stepped down. Thomas Kurian’s exit from Oracle (it is at least strongly rumored) was due to his view that existing Oracle customers should be able to choose which IaaS they wanted to run their software on, which conflicted with Larry Ellison’s vision. After all this time, and so little progress, Oracle is still trying to figure out its strategy, and appears headed in an unsustainable direction concerning the cloud.

The Threat to SAP and Oracle from the Cloud

How is cloud a threat to both Oracle and SAP? Well, cloud naturally undermines the on-premises assumptions around which both these vendors developed their business model. That is everything from their internal skills to their contracts and internal incentives. Cloud companies are not configured like Oracle or SAP and would impose a great deal of unwanted change if they had to adapt. Change, mainly when one is so financially successful doing things for decades one way, is historically put off as long as possible.

Cloud also threatens their consulting partners that are also based around the on-premises model. Once the cloud is employed, the number of consulting resources drops and hence consulting revenues. This is the primary reason why SAP and Oracle partners fought the cloud. Behind closed doors, they still fight the cloud, although they can’t admit it publicly. SAP and Oracle and their consulting partners would like to move with the times. Still, the problem is they want to move with the times while keeping their inefficient and dated methods of operation, and their margins, perhaps even increasing them as we will see later in the book. We have reviewed the internal SAP consulting company slides that promoted the idea that the cloud would help them increase their revenues. Perhaps this consulting company does not fully appreciate how the cloud works, but the cloud reduces the number of resources required for a project. Moreover, consulting companies function with the following formula.

Deloitte Revenues = The Number of Resources on the Project x The Number of Weeks on the Project

Cloud reduces both of the inputs.

Fewer resources are required, and they are required for a shorter period. This is not good news for consulting companies. Senior members of SAP and Oracle consulting partners have stated to the authors that they would never “recommend the cloud.”

Why?

Because if they did, they would not be able to staff a sufficient number of resources, to bring in enough money, to maintain their position in their companies.

The marketing these same companies do around the cloud looks much different. In public communications, SAP, Oracle, Accenture, Deloitte, etc.. are “all in on the cloud.”

However, what do all of these entities really want, and how do they plan to react to the cloud?

It is all straightforward. They will superficially promote the cloud while keeping everything else the same, which means defending their on-premises revenue model. If a customer is utilizing entities that only have a history in on-premises software, the likelihood that they will benefit from real cloud efficiency rapidly shrinks. There are no precedents where entities passively accept lower revenues without fighting that change. As we will discuss, the fact that so many people are still employed in IT consulting is evidence that we are still early in the cloud transformation of IT.

SAP and Oracle can only slow the process, and they must do what they can to either co-opt cloud (i.e., pretend they are more involved in it than they are) or adopt it. So far, they have chosen to co-opt the cloud rather than become true cloud vendors.

What is the Difference Between Real Cloud and Faux Cloud?

While SAP and Oracle and their partners dislike the arrival of the cloud, they are financially incentivized to “pretend to move to the cloud.” They have spent most of their efforts trying to cloud wash or to co-opt the cloud, which means to miscommunicate either their on-premises revenues or support revenues as the cloud. SAP and Oracle will tell Wall Street anything they want to hear if cats are popular on Wall Street, SAP, and Oracle loooove cats. If its dogs….well, you get the picture. The fact is that most of what SAP and Oracle offer customers is a faux cloud, as we covered in the article How to Understand Oracle as Faux Cloud Versus AWS.

We have investigated true cloud versus faux cloud in-depth for several clients. What we discovered was shocking to us. The vast majority of notably more prominent companies that say they are cloud/SaaS are not the cloud. Salesforce, a company that started as cloud, now has restrictive cancellation clauses and other account control terms & conditions. Cloud computing has a specific meaning and a particular set of requirements. While reviewing all the marketing literature, it is very tempting to forget what the actual definition of cloud, which is why we always refer back to earlier research we performed on this exact topic.

Cloud is frequently diluted to mean the service is merely off-premises. So, let us take this opportunity to get clear on what the cloud is, and what features are necessary for an offering to be considered cloud.

The following eight conditions must be met for a service to be the cloud.

One codebase
No customization
The vendor provides the hosting (i.e., the vendor provides and maintains all infrastructure for the application)
Flexible cancellation
Published and transparent pricing
Using a cloud salesforce
Using self-guided demo systems
Vendor-provided Software maintenance

Multitenancy

One codebase is what allows for multi-tenancy. This means that multiple customers use the application logic and, in some cases, the same database. Multi-tenancy flows directly into the topic of no customizations. No customization is necessary because if different customers were allowed to make customizations, then the application could no longer be multitenant.

To provide IaaS capabilities, vendors invest in their own data centers. However, as we will cover further on in the book, only a few companies are interested in making these investments. If we look at SAP, while they tout cloud, in many cases, they have other entities hosting their applications and databases. In the past, this was more commonly a consulting partner like CapGemini. Also, if your hosting is with Deloitte or Accenture, which has shown no true cloud capabilities, even to manage multitenancy, one has to wonder about the effectiveness of this strategy.

Definition of Multitenancy

This is the first time we have used the term multitenancy. Multitenancy means more than one “tenant,” the tenant, in this case, being a customer. Multitenancy is critical to the understanding cloud. Multitenancy can be considered the core characteristic of the cloud. It allows resources and costs to be shared across a pool of users. It means that in the case of database multitenancy, the data from many customers can be kept in a single database instance, and the database can be maintained at very low overhead and high economies of scale. At the application level, it means that updates can be implemented for all users at once. We will discuss multitenancy in depth further in the book.

Objectivity on the Cloud

Think about it in these terms, does anyone go to Deloitte or Accenture or CapGemini for cloud IaaS if they are not pushed there by SAP? This appears more geared toward giving business to partners rather than doing something that is in the customer’s best interests.

In summary, it seems that SAP is not all that interested in investing in data centers. This raises questions about how a vendor like SAP deals with third parties hosting their software.

SAP’s marketing materials show many cloud acquired applications. SAP’s marketing investment in the cloud is undoubtedly substantial. However, SAP maintains what has been described by others as a “puny” data center investment and capability. SAP’s acquired application typically suffer from chronic data center underinvestment.

This is explained in the following quotation.

“There is another concern about SAP’s S/4 public cloud. The data center in Sankt LeonRot Germany, while close to SAP’s impressive Walldorf headquarters, does not itself inspire much confidence. It has been called puny and primitive compared to the data centers of infrastructure as a service providers like Amazon, Microsoft Azure and Rackspace. Indeed competitors like Info and Unit4 are using infrastructure-as-a-service (using data centers from Amazon and Microsoft respectively) rather than trying to compete with their scale.”

“Even where SAP offers public cloud options-for example with its SuccessFactors and Concur customers– the individual data centers are undersized and often supported by co-location vendors around the globe. SAP’s about 82 million cloud users are fragmented across products and across geographies. Little attempt appears to have been made to date, to consolidate data centers that support them. While compliance requirements dictate regional diversity in such facilities, they are further reminders of Balkanization in the SAP economy.”

The Truth Around S/4HANA

Most of SAP’s database and applications revenue is from on-premises applications. S/4HANA is an internally developed application. There is an on-premises and a cloud version of S/4HANA. Yet out of 1500 “live” implementations, we estimate around 10% are S/4HANA Cloud. On quarterly calls, SAP does everything it can to distract from this reality. The reality is that outside of the acquired applications, SAP does not have a cloud application business of any significance.

The cloud customer should have a month-to-month contract with the software vendor or service provider, which allows for flexible cancellation. This relates to preventing lock-in, although it should also be acknowledged that some applications have more lock-in than others. ERP systems, by their nature, have more lock-in than other applications, like CRM applications, which are far easier to switch between. Although regardless of the application, there is some stickiness factor that reduces the actualized flexibility in changing to a different system.

AWS and Google Cloud offer highly flexible cancellation terms. It is the ability to bring up and bring down services and to pause services. For example, we can close down any one of our AWS or Google Cloud services at any time. The services are billed in hours or minutes or second or millisecond. When the service is turned off, the billing no longer runs. This is not a “month-to-month” cancellation capability, but an immediate canceling capacity. The account stays active at AWS and Google Cloud, but that is separate from the services that are billing or not billing as the case may be. We have become used to this type of flexibility, but it is easy to forget how unusual this is in the history of enterprise software.

SAP and Oracle are not experienced in working with this type of business model.

SAP has only very recently begun to offer month to month subscriptions to their products. We reviewed this same pricing page in June of 2018, and at that time, the price was listed as monthly, but it had a yearly term. The vast majority of SAP’s products have secretive pricing. We were not able to verify if a monthly term applied to S/4HANA Cloud if a discount was applied. SAP responded that they would only answer that question if we provided a customer name.

Being Forced to Adjust to the Cloud

SAP has to respond to market pressures. SAP could have done this years ago, but they didn’t. SAP is being forced to adjust to the cloud, and these changes are being fought tooth and nail by SAP (and by Oracle). And, as our example of SAP’s unwillingness to verify the interaction between a discounted price and the monthly cancellation term, often when one gets into the details, it turns out that the promised cloud terms are not a cloud at all.

Even now, SAP and Oracle operate on the on-premises model where projects are made about software capabilities, usage, implementation difficulty, product maturity, and other product features without testing the item. Some might respond to this by contradicting the statement and pointing to proof of concepts. However, evidence of concepts is run by the vendors. Vendors run the POC to “prove the concept” not to “test the concept.” The POC intends to convince the customer to purchase the software. It is not at all, like when the customer tests the software themselves. By contrast, the cloud puts the customer in the “driver’s seat” rather than trying to control the process of evaluation.

On the topic of the necessity for a self-guided demo system, generally, on-premises application sales teams tightly control exposure to the application. The prospect is only allowed to see a demo of the system for short periods. Specialized resources called presales consultants to walk prospects through a demo. This approach does not provide or allow a thorough evaluation of the usability of the system. Demonstration consultants, who are very familiar with the application, can do many things that average users often cannot. Alternatively, when cloud vendors provide access to a cloud demo environment, the experience becomes self-guided. This gives the prospect more control and allows them to understand whether the application is a good fit for them in a shorter period.

Published Versus Secret Pricing

Published pricing is a fundamental feature of cloud providers. For AWS and Google Cloud, they chose to outsource much of the presales effort to its customers. They do this by doing what was in the past unthinkable; that is, by publishing their pricing and making it virtually non-negotiable. In doing so, AWS and Google Cloud remove an enormous obstacle for customers to adopt their services. Also, then customers can begin testing the capabilities and the cost without even needing to, in many cases, interact with AWS or Google Cloud representatives.

As any reader of this book will likely know, SAP and Oracle have unpublished pricing. Just a few pages ago, we showed an example of published pricing for SAP’s S/4HANA, but this is new, in part faux cloud pricing, and most of SAP’s product catalog is still secret. The same applies to Oracle. And when we say secret, we don’t just mean unpublished. We mean secret. On the first page of SAP’s pricing page, it states that sharing the pricing spreadsheet could expose the person sharing the pricing sheet to legal jeopardy.

“All rights reserved. The contents of this work are confidential and proprietary information of SAP AG. Improper and/or unauthorized reproduction in whole or in part of the information contained in this work is a violation of SAP’s proprietary rights and could cause irreparable damage. No part of this work may be reproduced or copied in whole or in part in any form or by any means (including without limitation graphic, electronic, or mechanical, including photocopying, recording, taping or information storage and retrieval systems) without the prior written permission of the publisher.”

Interesting isn’t it? According to SAP, its pricing is protected information. Furthermore, if one is in possession of this pricing spreadsheet, the recipient has specific responsibilities.

“This SAP Software Price List may only be distributed by an employee, agent, or representative of SAP AG / SAP subsidiary. If you have received it by any other means, you are hereby notified to return it to SAP AG to the attention of the Contracts Manager.”

Oh yes, a company that writes these types of clauses around its price list is TRULY ready for the cloud!

Complicated Pricing

Both SAP and Oracle’s pricing is so complicated that sales reps for each company seem to spend at least as much time working out pricing as focusing on technology. For example, we had to completely revamp the SAP pricing sheet before we were able to use it because, as it is given initially to salespeople and pricing consultants, it is tough to use. Secondly, even if the pricing sheet is obtained, there are so many discounts that the pricing can’t be known with certainty. This applies equally to Oracle.

It even goes even beyond this. If you go through an official SAP representative, there are still frequent problems getting a firm price. At clients that we advise, SAP sales often postpone giving out pricing even when the customer specifically asks for a price. For some reason, the pricing has to be a run-up to the higher levels in SAP….or at least that is what customers are told. It is quite odd when you can’t even get a price for weeks because of a large number of behind the scenes mechanizations and scheming that has to take place. However, this is the world that SAP and Oracle have created for their customers. And these are the type of things people outside of the field don’t find out because it is not the sort of thing that is published.

AWS and Google Cloud have estimates per configuration. The example we have in this screenshot is for SAP HANA, express edition. This for the HANA database that can be run without a base edition, platform edition, or enterprise edition license. SAP does this to encourage development on HANA. Because the only change here is from Google Cloud, the pricing is transparent. However, as soon as one makes the switch to the SAP HANA “Bring-Your-Own-License,” while the hosting costs are the same, the overall pricing immediately becomes secret. In that case, neither AWS or Google Cloud has anything to do with the pricing of the license. That license pricing is set by SAP, and now “the games begin,” as one must work through an archaic and time-consuming process called the on-premises sales model.

The Low-Cost Distribution and Sales Model

The original cloud vendors followed a low-cost distribution and sales model. This means employing fewer salespeople, focusing less on relationships, and on manipulating relationships. It says cloud salespeople are closer in many ways to presales resources than sales resources. This dramatically lowers the cost of sale, and it also reduces the amount of inaccurate information being communicated to customers. This also happens to be how AWS and Google Cloud operate.

When considering this context, while SAP and Oracle declared they were moving more to the cloud, they did not reduce their sales force.

SAP and Oracle are both highly aggressive sales cultures with vast numbers of salespeople. Oracle employs 35,000 at last count. That should tell anyone who is paying attention that SAP and Oracle are not migrating to the cloud anywhere near as fast as they are saying. If a company is following a cloud model, the need for salespeople steeply declines, as the primary means of interaction is through the website, not through phone calls and on-site visits. (And the skills of the salespeople also change.) If one compares the revenue to employees in AWS and Google Cloud versus SAP and Oracle, AWS and Google have a higher ratio of revenues to employees.

Cloud Service Providers and Support

Cloud began with the cloud vendors providing the maintenance. This means that this is taken off of the customer’s plate. Under SaaS, the customer only uses the application; they don’t worry about the infrastructure, database, updates, etc. The updates are supposed to be so automatic and well managed that the customer does not notice the update being made. An excellent example of this is Gmail, which is a cloud application that most people use. Gmail has gone through many updates, but Gmail users do not observe the changes occurring. The story with AWS and Google Cloud is a bit more complicated because customers are not using AWS and Google Cloud just for applications (SaaS), but for their development and infrastructure (PaaS, IaaS). But this applies very readily to AWS RDS and Google Cloud SQL, where much of the maintenance of these databases is managed for the customer, and the customer can focus on using the database.

The following quotation explains this from Google.

“Let Google manage your database, so you can focus on your applications. Cloud SQL is perfect for WordPress sites, e-commerce applications, CRM tools, geospatial applications, and any other application that is compatible with MySQL or PostgreSQL.”

SAP and Oracle Sell Technology Rather than Use Technology

Neither SAP or Oracle ever built anything themselves. Internally they have roughly the same technological accomplishments of a large consulting company.

Say a Deloitte or Accenture. They have an HR system, systems for recording sales and expenses, invoicing, etc… Anything of any significance that is accomplished with SAP and Oracle products is accomplished in their customers.

SAP’s Underinvestment in Cloud Infrastructure

The underinvestment in SAP cloud infrastructure is covered in the following quotation.

“There is another concern about SAP’s S/4 public cloud. The data center in Sankt LeonRot Germany, while close to SAP’s impressive Walldorf headquarters, does not itself inspire much confidence. It has been called puny and primitive compared to the data centers of infrastructure as a service providers like Amazon, Microsoft Azure and Rackspace. Indeed competitors like Info and Unit4 are using infrastructre-as-a-service (using data centers from Amazon and Microsoft respectively) rather than trying to compete with their scale.”

The next quote gets into how the SAP data centers are undersized.

“Even where SAP offers public cloud options-for example with its SuccessFactors and Concur customers– the individual data centers are undersized and often supported by co-location vendors around the globe. SAP’s about 82 million cloud users are fragmented across products and across geographies. Little attempt appears to have been made to date, to consolidate data centers that support them. While compliance requirements dicate regional diversity in such facilities, they are further reminders of Balkanization in the SAP economy.”

The following quote covers the enormous costs of the SAP cloud.

“Customers also report that SAP’s recent software economics (as against business network economics described above) are uncompetitive whether it is proposing on-premise or its cloud solutions. For example, in a recent deal, its five-year software cost was three times as much as the winning competitor cloud bid. SAP’s annual maintenance cloud by itself exceeding the subscription cost of the competition, which also included hosting, apps management and upgrades in its price.”

Did SAP Successfully Implement its Learning from SuccessFactors on the Cloud?

The following is a quote from a paid placement by SAP into Fortune.

But it has put some of the right pieces in place—the CEO of recently-acquired SuccessFactors, Lars Dalgaard, has joined the company’s executive board and is now tasked with running all of its cloud efforts. Cloud revenue is small but growing at a much faster rate than traditional software sales: SAP reported that the SuccessFactors business grew bookings by 69% compared to the first quarter of 2011. And the company is pouring marketing muscle and manpower into HANA and other innovative efforts like mobile apps.

The idea was that SAP would learn a lot about cloud from SuccessFactors, and talking to those inside of SAP, they did. Yet, the exposure has not translated into any of the expected improvements in SAP’s cloud offerings, which is very much lagging the market.

Next month, at a conference in Florida, SAP is expected to unveil more details on its cloud strategy. It’s sure to talk up HANA, mobile and analytics as well. But what about its core business, enterprise resource planning software? It’s long-overdue for a serious overhaul on its less-exciting core product, which accounts for the bulk of current revenue. Of course, redesigning complex software isn’t easy and takes time. But it’s a necessary step for SAP to truly become the innovation leader in the enterprise.

Whatever SAP announced, it has not resulted in anything of substance over five years later.

Coercing Companies into the Cloud

SAP and Oracle have been in the position of having to force companies into the cloud as we cover in the article How SAP and Oracle Coerce Customers into the Cloud.

Upcharging for Private Clouds

SAP has a minimal cloud capacity and relies upon very low-quality partners that work under their HEC brand, which we cover in the article Our Comparison of SAP HEC with Virtustream Versus AWS Analysis. SAP really marks up the cloud services of these companies, as we cover in the article How to Understand SAP’s Upcharge as a Service Cloud. As with Oracle, none of these private cloud offerings are multitenant, as we cover in the article Why Oracle Cloud is Not Multitenant.

SAP and Oracle and Consulting Partner Information Quality

Migrating from SAP and Oracle, or portions of SAP and Oracle to AWS has many implications. Some of them are related to corporate strategy, contracts, and related factors. We will cover as many of these as we can.

Customers have, for decades, chosen SAP and Oracle applications and databases. In some cases, the selections made sense. However, in many cases, when there was no logical reason to select the options presented by SAP or Oracle, except they felt like safe choices. This is buying on the basis of a brand rather than an actual analysis of the pros and cons of the purchased items. SAP and Oracle have not only extensive sales and marketing budgets, but an army of consultants built up that both implement, but also serve to promote more and more SAP and Oracle sales.

Brightwork Research & Analysis frequently performs analysis of statements by SAP and Oracle consultancies to their clients is that the average information quality provided by them is low. As it happens, right now, we are aware of Oracle partners who are lying to companies about Oracle Cloud. They are falsifying the customers they have live on Oracle Cloud. They are doing this so they can sell Oracle Cloud and get experience in Oracle Cloud.

SAP and Oracle spend mightily to influence people, and it works, which we cover in How SAP Controls IT Media. The vast majority of SAP sales reps and SAP consulting firms spend their time talking about how SAP “could be used” (according to a brochure), not how it is used. Brightwork Research & Analysis is one of the only entities that discuss how it is used in reality. Moreover, discussing this topic is very bad for sales, which could cause you to “lose the deal” and then get fired as a sales rep for these companies.

The problem is financial bias.

Implementation companies don’t implement things from many vendors. They implement software from a few vendors. If the consulting company has a financial bias, it is logical and is borne out by observations that they will recommend what is best for them financially. SAP and Oracle consulting companies are not fiduciaries as we cover in Do Consulting Companies Have a Fiduciary Duty. They are under no obligation to place their client’s financial interests ahead of their own.

While they may be safe politically, they are, in many cases, not safe in reality. Here are several examples of why this is the case.

Immature Products: SAP has a history of bringing out immature applications that have major implementation failures and have to be written off. SAP implementations have so undermined some companies that they were sufficiently weakened to become acquisition targets.
High Cost and Maintenance Database: The Oracle database (Oracle 18, 12, 11) has many upper-end features, but it also historically has the highest maintenance overhead of any database in its class (until SAP released HANA that is, which took the crown). Furthermore, many of the Oracle DB’s more advanced features go unused by customers. Like SAP, Oracle accounts suffer from high TCO. SAP and Oracle’s high TCO is how they can pay at the top of the market for sales reps.
A History of Overpromising: Both SAP and Oracle have a long-established history of overpromising what their applications and databases can do. They often promote the upper level of functionality that is very rarely reached by customers because of the effort and maintenance overhead in getting their offerings tuned. The result is the “average usage” is far below the potential theoretical usage. So what customers see in the sales phase is not anywhere close to what customers get.

All of this is possible because, under the on-premises model, the application or database is purchased first and then tested after. Customers buy cloud services by the SLA, not by the sales pitch.

Go to top

Conclusion

Both Oracle and SAP’s clouds are based upon smoke and mirrors and not long term investment. They significantly lag other cloud service providers, and they provide false information to customers about their clouds.