How AWS and Google Cloud Speed the Implementation of SAP and Oracle

ByShaun Snapp

Executive Summary

  • AWS and Google Cloud offer the capabilities to speed implementations for both SAP and Oracle.
  • Using external cloud services is far better for implementation speed versus methodologies.

Video Introduction: How AWS and Google Cloud Speed the Implementation of SAP and Oracle

Text Introduction (Skip if You Watched the Video)

Both SAP and Oracle rely upon an ecosystem of consulting partners to implement their software. These partners can sell both licenses and consulting services, but most only have consulting services to sell, and their consulting services are based upon billing hours. The agreement between these vendors and the consulting entities is to gain recommendations from consulting companies in return for receiving implementation work. You will learn the reality of how SAP and Oracle can be sped with AWS and Google Cloud and how SAP and Oracle consulting firms stop their customers from improving efficiency for financial reasons.

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. 

What to Consider

The following are important things to consider regarding these consulting partners.

  • As the consulting company does not use the software after it is implemented, their primary concern is the billing hours, not the software that works the best for their clients.
  • Each of the SAP and Oracle consulting companies maintain aggressive targets regarding the number of billing hours and the margin that must be sold each year for a member of these consulting companies to attain and retain their senior level status and their compensation. This is why consulting companies aren’t able to help their clients with software selection to put the client’s interests ahead of the interests of the consulting companies. The selection has already been performed before the consulting companies evaluate the requirements. This is because the consulting company has already dedicated its consultants to specific modules within a specific vendor. SAP or Oracle consulting companies will typically use the RFP process to backward engineer the RFP (regarding the RFP questions) to match the software they already consult. Any senior member who did not do this and allowed the client to choose an application the consulting company could not implement (and thus bill hours for) would lose their position in that company and the respect of their peers. This is covered in the article How to Understand the Logic of the Software RFP. For consulting companies, the RFP functions to place an aura of legitimacy over the software selection process.

The True Function of SAP and Oracle Consulting Companies

Therefore the SAP and Oracle consulting companies primarily function to funnel IT expenditures to SAP and Oracle applications and databases. This, of course, results in SAP and Oracle implementations.

Of all the vendors, SAP has the most significant partner consulting network with the top 18 consultancies employing over 250,000 consultants globally. There are many other smaller consultancies and independent consultants that increase that number significantly above 350,000 consultants. In the book SAP Nation 2.0, the global SAP ecosystem was estimated at roughly the size of Ireland or Norway’s GDP. In the book, Vinnie Mirchandani observed that he could receive no assistance from any of the well-known IT analyst firms in estimating the global yearly spend on SAP and SAP services as the IT analyst firms said that the total number was “sensitive.” Such estimation is only sensitive because the major IT analyst firms are paid by SAP to push SAP products. Therefore, SAP is a client, and hence the sensitivity, or should we say, the reluctance to offend such a well-paying customer.

The SAP Consulting Ecosystem

SAP’s consulting ecosystem has grown to be the largest in the world because SAP projects are the most remunerative in the world. That is, the consulting companies followed profit-maximizing principles when selection which vendors to push. In consulting companies with both an SAP practice and an Oracle practice, the SAP practice is larger in most cases. The remuneration obtained from SAP projects is a function of the number of consultants staffed on an SAP project multiplied by the length of each SAP project, and SAP has the most extended projects in the industry.

SAP has introduced one accelerated methodology after another for decades, beginning with ASAP in the 1990s that was proposed to increase implementation speed. We covered one such methodology in the article How to Best Understand the Faux SAP RDS. Our conclusion is that much like the SAP and Oracle consulting companies’ implementation methodologies, they are primarily written by the sales and marketing arms of these entities, and they don’t speed implementations. Neither SAP nor Oracle implementations have changed much in their implementation durations.

SAP and Oracle Implementation Timelines in Reality

How long do these implementations for SAP and Oracle take? Well, SAP’s flagship ERP application, called ECC, is typically thought not to be implemented in less than a year, with multi-year implementations being the norm. At the outer edge of the typical timeline, a recent SAP failure at the grocery chain Lidl went on for seven years until it was finally canceled. While a significant loss for Lidl, it was extremely remunerative for KPS as the consulting partner. KPS would have consumed an ample percentage of the estimated 500 million Euros spent on that project over that extended timeline. This is because the consulting company always makes a significant multiple of the funds received by SAP for the license (although recall that support is paid to SAP yearly, even after the implementation ends). Even after the failure, the project has still been declared a success on the KPS website. As we cover in the article, KPS Continues to Keep Promote HANA for Retail for Lidl After Failure.

Curiously, KPS complained that the timelines for performing customization were too short, which seems like an odd complaint for a project that went on for seven years. Still, a large number of SAP consultants leaped to KPS’s defense, declaring that in their “considered opinion,” it would have to have been the client’s fault. This is standard practice. When projects fail, the SAP consultants that comment nearly always blames either the customer or the systems integrator. And this is done ordinarily without actually reading the case study. By the time developers start work, the contract is already signed, and it’s already too late. Whenever an SAP project fails, the post-mortem is typically performed by SAP consultants (or by Oracle consultants for Oracle), which is a problem as they have a strong financial bias to blame the client, which they ordinarily do. In each case, the apologists are careful never to highlight their financial bias when they explain SAP project failures. These sources also have a habit of denying that poor quality information flows to the customer/client initially.

Both SAP and KPS told Lidl many inaccurate things. We know this because this is a feature of how SAP projects are sold and because credible sources have told us who were involved in the project. Because the duration was so long (no doubt the project became delayed from an originally shorter duration), this meant that it took Lidl a long time until they finally learned that many of the areas of information presented to them were incorrect. The eventual outcome was that Lidl preferred to stay with their previous systems rather than move on to SAP. SAP consultants see this as a “failure of leadership” at the customer.

It is well known. In the article How SAP Used and Abused the Term Legacy, we have documented that SAP nearly always overrepresents how easily SAP’s applications can take over for the prospect’s existing applications. Oracle did the same thing to the Air Force in a well-publicized case of sales overreach, proposing that Oracle’s ERP functionality could replace highly specialized military systems that had been custom developed over decades (Which we covered in the article How to Understand Overmapping Functionality to ERP). In both cases, the project’s length and eventual (mandatory?) delays pushed out the date when the customer figured out that the information given in the sales process was radically inaccurate.

How Can AWS and Google Cloud Improve This Situation?

Because AWS and Google Cloud offer ready to deploy infrastructure, it means that sales contentions can be tested far more quickly than they can in an on-premises environment. Under the on-premises model, merely the sizing exercise, which is unnecessary when one has access to a reliable IaaS environment, pushes out the date from trying out the software. Both SAP and Oracle continuously pledge their newfound allegiance to the cloud. However, they don’t run their companies as cloud vendors. They have for their entire existence operated on the on-premises sales model, where contentions are not checked until a significant amount of time has passed, and the longer the lag between the purchase the decision and learning the reality, the more likely the customer is to “stay the course” the less likely they are to admit they made a mistake.

It is essential to consider that both SAP and Oracle consulting companies operate with almost no independent verification of the information they provide to customers. We/Brightwork Research & Analysis receives details of communications from all over the world. The accuracy of the consulting company provided information turns out to be quite low, something we cover for SAP in the article A Study into The Accuracy of SAP. We have not performed such an exhaustive study for Oracle. Still, our individual analysis of Oracle, such as with the autonomous database (as covered in How Real is Oracle’s Autonomous Database?), indicates that Oracle would also not fare very well in this analysis.

As with SAP and Oracle, AWS and Google Cloud also have consulting partners. However, the orientation is entirely different from the relationship between SAP and Oracle and their consulting partners. First, AWS and Google Cloud have created such a magnet with their capabilities than AWS, and Google Cloud does not rely upon partners anywhere near the way SAP and Oracle do for lead generation. If these partners want to participate with AWS, they can, but AWS does not “need” them. Furthermore, the multiple that consulting companies have come to expect from SAP and Oracle will not fly with AWS. Therefore, the consulting companies will most likely find AWS and Google Cloud related consulting to be a poor substitute for SAP and Oracle consulting because there is no financial substitute for SAP and Oracle consulting.

One way or another, AWS and Google Cloud will grow because their offering is that good. This also extends to sales. AWS and Google Cloud’s business is mainly inbound, or the SaaS/cloud model of acquisition. AWS has hired some salespeople from Oracle and other vendors, but AWS (nor Google Cloud) will never have the number of salespeople than their revenues or customers as SAP or Oracle. SAP and Oracle are so heavy with salespeople that there are constant turf battles between the sales reps for the territory within both vendors.

AWS and Google Cloud Tools for Speeding Implementation

All three of those involved in this book are experienced implementations. As such, we are highly suspicious of accelerators promoted by vendors and consulting companies and view them more often than not as sales tools. However, when reviewing AWS and Google Cloud documentation called Quickstart, we were pleasantly surprised. Unlike with SAP or Oracle, these are not just methodologies (i.e., PowerPoint decks). They are actual components that can be leveraged within AWS. Let’s take a look at some of them.

AWS’s QuickStart covers the following categories.

  • Databases & Storage
  • Big Data & Analytics
  • Data Lake
  • Data Warehouse
  • DevOps
  • Security
  • Compliance
  • Messaging and Integration
  • Microsoft Technologies
  • SAP Technologies
  • Networking and Remote Access
  • Additional

Each one of these categories has coverage for multiple items. If we take just one, which is the first on the list, Databases & Storage, we see the following items.

  • CloudStax Cache for Redis
  • CloudStax NoSQL DB for Cassandra
  • Couchbase
  • DataStax Enterprise
  • MongoDB
  • ONTAP Cloud for NetApp
  • Oracle Database
  • SAP HANA
  • SIOS DataKeeper
  • Spectrum Scale
  • SQL Server
  • StorReduce

AWS is serious about each of these Quickstarts. Each one of them has a comprehensive guide. If we take just the first Quickstart on the list, the CloudStax Cache for Redis is 23 pages long.

Here is a graphic from the CloudStax Cache for Redis Quickstart document explaining the architecture of Redis.

Each Quickstart guide lists the prerequisites to using the Quickstart. For the CloudStax Cache for Redis, the following are listed as prerequisites:

  • Amazon EBS
  • Amazon EC2
  • Amazon ECS
  • Amazon Route 53
  • Amazon VPC
  • Redis
  • CloudStax FireCamp

The guide then explains the technical requirements, the deployment options, the deployment steps, how to launch the quick start, how to test the deployment, information around data persistence, data backup, Redis configuration, security, troubleshooting, links to GitHub to download more templates and scripts and how to share customizations with others. Finally, there is an extensive listing of additional resources.

Google Cloud also has Quickstarts. They can be found as separate documents like AWS’s Quickstarts and pop out to the right while performing tasks in the console.

Considering Quickstarts

Evaluating this documentation leaves one with the distinct impression that the Quickstarts were not merely conceived as marketing tools. Senior members didn’t write them at AWS or Google Cloud or by their sales groups (as is the case with Oracle and SAP methodology and accelerator documentation). Instead, they were written by technical resources at AWS. Once again, this makes sense. AWS and Google Cloud are not trying to sell software or to create a giant consulting ecosystem. They are trying to get customers up and working as quickly as possible. The sooner customers can begin using AWS and Google Cloud services, and the faster they can start using more services and more advanced services, the more than AWS and Google Cloud can charge them. That is, while SAP and Oracle’s revenues models are loosely based upon the usage of their products (and for SAP and Oracle’s consulting partners, their consulting services), AWS and Google Cloud’s revenues are tightly connected to the utilization of their services.

Another part of AWS’s rapid approach is the free and paid training that AWS offers. AWS offers quite a bit of good quality free training. AWS breaks its training tracks into the following:

  • Cloud Practitioner Path
  • Architect Path
  • Developer Path
  • Operations Path

While AWS offers offline courses, AWS, as is usually the case, differentiates itself by providing training online. While SAP and Oracle treat training as profit centers, AWS treats training as a way to get customers and consultants scaled up on AWS as quickly as possible.

We signed up for and tested AWS’s training ourselves while researching this book to validate its quality.

This will, of course, change, but when we filtered for Digital courses in English, we found 230 courses that we could take from AWS. They ranged from 7 hours to 5 minutes.

AWS training is quite good. Here is a slide from a video explaining the benefits of Amazon Aurora. We learned quite a bit about Aurora from the AWS training on the topic.

For example, the Aurora training did an excellent job explaining what AWS manages parts of the stack, with the EC2 service managing one level and the RDS managing essentially the entire database. This is not a slide or training that SAP or Oracle wants anyone to see. This is because neither of these vendors can offer what AWS can for the fully managed database.

Google Cloud also offers quite a bit inexpensive training options.

Google Cloud also has a wide number of training options available online. Google Cloud uses a company called Coursera.

All of this leads to how reliable SAP and Oracle consulting companies are on the subject of AWS and Google Cloud. First, these consulting companies will have a problem with AWS and Google Cloud, like AWS, and Google Cloud provides the ability to shorten implementations and bring down the time between when the sales process occurs. Therefore, when the information about the software is finally available to the customer. As so many SAP and Oracle projects have such a wide variance between what is promised and what is true, this is not a welcome development for SAP, Oracle, or their consulting partners. It does nothing but increases the likelihood their customers will confront them on inconsistencies.

The Issue with Shortening Time Fames of Implementations for Consulting Companies

Secondly, the shortened time frame reduces the potential revenues for these consulting companies. For example, consultancies like Accenture and Capgemini have begun AWS practices.

Accenture is an AWS partner. But this is not what these consulting firms actually want. Accenture and others with SAP practices will make far less money with AWS clients than they will with SAP consulting. According to the book SAP Nation 2.0, SAP consulting supports a $300+ billion ecosystem, as we covered in the article SAP Nation 2.0 on The Overall SAP Ecosystem Spend. (29% of which is consulting).

These firms’ historical behavior makes us wonder whether these are good companies to listen to or use when it comes to AWS.

  • These companies are accustomed to a high multiple between vendor or service expenditure and consulting.
  • How will they adjust to the cloud, which is supposedly about efficiency?
  • Will these firms find it as straightforward to access cloud skills as on-premises skills? Many cloud skills are based upon the open source, something big SAP and Oracle consulting firms don’t have much history working with.
  • These firms, for decades, have been very focused on specific vendor practices. How will they adjust to an environment that requires true systems integration? That is their ability to select the best tool for the job?

For this book, we reached out to Accenture and several other large consulting partners with SAP consulting practices. When we asked questions, we were met with the same overpromising that these companies are so typical on SAP projects. Everything was explained as “very easy,” and there was a desire to move us quickly to the next stage of the sales process, where we would meet with a solution architect. We are confident that these consulting firms will “lift and shift” their business practices from SAP and Oracle consulting to AWS and Google Cloud consulting.

The On Premises Model

Thus, it is not only SAP and Oracle that are “addicted” to the on-premises sales and delivery model and their consulting partners. They are all hugely successful following their current processes and have not adjusted their organization structure and staffing to succeed in the cloud. SAP and Oracle, along with their consulting partners, have fought and will continue to fight movement to the cloud as it fundamentally undermines their business model. The implications of the cloud are not only the consulting firms. As we covered in the article How Cloud Changes the Labor Needs in IT, it is not being considered by governments and policy setters.

Go to top

Conclusion

Up until this chapter, we focused primarily on the functionality offered by AWS and Google Cloud. That is why it was essential to have a chapter that just focused on development speed because this is one of the lesser discussed topics around cloud services. Services are so easy to bring up on AWS and Google Cloud that development can experiment faster than they ever could before. The introduction of “serverless” provides enhanced development speed because not only is sizing unnecessary, but server component selection is also unnecessary. The on-premises vendors were offering none of these things. Quite the contrary, SAP and Oracle were quite happy with the status quo.

However, it is not merely a matter of leveraging AWS and Google Cloud services. SAP and Oracle consulting firms are embedded at SAP and Oracle accounts, and one of their primary roles is to put the brakes on leveraging the innovation in AWS and Google Cloud. They need to push their clients to SAP and Oracle cloud to maintain their relationship with SAP and Oracle. This is why self-reliance and finding entities that are not part of the current status quo on SAP and Oracle projects are so important to leverage AWS and Google Cloud for SAP and Oracle environments.