How to Understand AWS’s Multibase Versus SAP’s Singbase Approach

Executive Summary

  • SAP has been proposing that all companies should use a single database type and that they should buy HANA.
  • AWS’s CTO explains the benefits of the multi-base approach.

Introduction to Multibase

What is often left out of the analysis of database advice from commercial software vendors is how biased it and self-centered it is. Commercial database vendors don’t provide any information to a customer that is not in some way designed to get the customer to invest more deeply in the vendor’s commercial products. As bad as Oracle’s “advice” to companies has been, Oracle at least has respected, although highly self-centered, knowledge of databases. SAP’s rather insane advice to their customers has been far worse, and far more self-centered. For years SAP has been telling customers that they need to perform multiple

For years SAP has been telling customers that they need to perform multiple types of database processing from a single database. This is wholly false but has not stopped either SAP or their partner network for saying its true. We have covered in detail how SAP’s proposals about HANA have ended up being proven incorrect in article ranging from What is HANA’s Actual Performance?, A Study into HANA’s TCO, to How Accurate Was Bloor on Oracle In-Memory.

In this article, we will expand into a topic which shows how wrong SAP is. This perspective we will address is not brought forward by either SAP, Oracle, IBM or Microsoft, but by the entity providing thought leadership on the future of how databases being used…which is AWS.

Verner Vogels on Multiple Database Types

In an excellent article by Verner Vogels who is the CTO of AWS. Let us begin with how he starts the article.

“A common question that I get is why do we offer so many database products? The answer for me is simple: Developers want their applications to be well architected and scale effectively. To do this, they need to be able to use multiple databases and data models within the same application.”

Notice the last part of this paragraph, where Verner describes using “multiple databases and data models within the same application.” Wait what was that? We all know that applications have a single database right? How does a single application use multiple databases? What is Verner talking about?

Well, it turns out Verner is describing software development that is different than the monolithic environment. Verner goes on to say this..

“developers are now building highly distributed applications using a multitude of purpose-built databases.”

That is the application that we think of is one way of developing, but this is giving way to distributed applications that can access multiple databases. It is an unusual way of thinking about applications, for those of us who came up under the monolithic model.

The Limitations of the Relational Database

Verner goes on to describe the limitations of the relational database.

“For decades because the only database choice was a relational database, no matter the shape or function of the data in the application, the data was modeled as relational. Is a relational database purpose-built for a denormalized schema and to enforce referential integrity in the database? Absolutely, but the key point here is that not all application data models or use cases match the relational model.”

This we have seen in the rapid growth of databases like MongoDB and Hadoop that specialize in either unstructured data or data with lower levels of normalization. Verner describes how Amazon ran into the limitations of using the relational database.

“We found that about 70 percent of our operations were key-value lookups, where only a primary key was used, and a single row would be returned. With no need for referential integrity and transactions, we realized these access patterns could be better served by a different type of database (emphasis added). This ultimately led to DynamoDB, a nonrelational database service built to scale out beyond the limits of relational databases.”

Let us remember, AWS has a very fast growing relational database service in RDS. However, they also have fast-growing non-relational databases like DynamoDB.

The Different Database Types According to Verner

Below we have provided a synopsis of the different database types, their intended usage, and the database that reflects them by Verner.

  • Relational: Web and Mobile Applications, Enterprise Applications, Online Gaming (e.g., MySQL)
  • Key Value: Gaming, Ad Tech, IoT (DynamoDB)
  • Document: When data is to be presented as a JSON document (DynamoDB)
  • Graph: For applications that work with highly connected datasets (Amazon Neptune)
  • In Memory: Financial Services, Ecommerce, Web, Mobile Applications (Elasticache)
  • Search: Real-time visualizations and analytics generated by indexing, aggregating, and searching semi-structured logs and metrics. (Elastisearch Service)

And actually, it is a bit more complex than even Verner is letting on. This is because some databases that AWS releases or releases access to, end up being used differently than first intended. This is described in a comment on Verner’s article.

“It turns out that your products are so good that people do end up using them for a different purpose. Take Amazon Redshift. I remember when Amazon Redshift was launched, a question came from the audience if you can use Redshift as an OLTP database, even though it’s OLAP. Turns out using Redshift in an OLTP scenario is one of the major use cases, to build analytical applications. We are one of those use cases, we’ve built an analytical app on top of Redshift. The OLTP use case stretches Redshift once you start putting a serious number of users on it. Even with the best WLM configuration.

To solve for that, we’ve used a combination of Amazon RDS, Amazon Redshift and dblink plus Lambda and Elasticsearch. Detailed write-up on how we did it here:”

The Multi-Application Nature of Solutions Distributed by AWS

The multi application nature of solutions is explained as follows by Verner.

“Though to a customer, the Expedia website looks like a single application, behind the scenes Expedia.com is composed of many components, each with a specific function. By breaking an application such as Expedia.com into multiple components that have specific jobs (such as microservices, containers, and AWS Lambda functions), developers can be more productive by increasing scale and performance, reducing operations, increasing deployment agility, and enabling different components to evolve independently. When building applications, developers can pair each use case with the database that best suits the need.”

But what are packaged solutions offering? Well, monolithic applications that are the exact opposite of this. And as SAP is a perfect example of a monolithic application provider, SAP wants customers to use a single database, and further, they want customers to use “their” single database as in HANA. Which according to SAP can do all the processing as well as all the different database types described by Verner above? The one problem being, HANA can’t.

The AWS Customers Using Multibase Offerings

  • Airbnb: DynamoDB, ElastiCache, MySQL
  • Capital One: RDS, Redshift, DynamoDB
  • Expedia: Aurora, Redshift, ElastiCache, Aurora MySQL
  • Zynga: DynamoDB, ElastiCache, Aurora
  • Johnson and Johnson: RDS, DynamoDB, Redshift

Verner goes on to say.

“purpose-built databases for key-value, document, graph, in-memory, and search uses cases can help you optimize for functionality, performance, and scale and—more importantly—your customers’ experience. Build on.”

The Problem with SAP and Oracle Cloud and Leveraging the Multibase Approach

SAP and Oracle have been touting their cloud. However, with SAP and Oracle, the cloud is only a pathway to lead to SAP and Oracle’s products. This is as much true of databases. SAP and Oracle are closed systems. They dabble in connecting to non-SAP and non-Oracle, but only to co-opt an area so they can access markets. AWS and Google Cloud are quite different. Notice the variety of databases available at Google Cloud.

There are over 94 databases out at Google Cloud, and far more out at AWS. These databases can be brought up and tested very quickly. Selecting one of the databases brings up the configuration screen. Furthermore, the number of database and database types is only increasing with AWS and Google Cloud. 

Right after this is launched, one can bring up a different database type, (say NoSQL, or Graphic) and immediately begin testing. Under the on-premises model, this would not be possible. Instead of testing, one would go through a sales process, a commitment would be made, the customer would be stuck with (and feel the need to defend) whatever purchase had been made. We have entered a period of multi-base capabilities, and AWS and Google Cloud are the leaders in offering these options. This will transform or is transforming how databases are utilized. And the more open source databases are accessed, the worse commercial databases look by contrast. 

Conclusion

Packaged solutions ruled the day for decades. After the 1980s, custom coded solutions were for losers. They were to be replaced by “fantastic ERP” systems that would make your dreams come true. And who agreed to this? Well vendors and consulting companies with packaged software and packaged services to sell. Consulting companies became partners with packaged software companies, parroting everything they said, without evidence. Even to the point where almost no one in IT is even aware that packaged ERP systems have a negative ROI as we cover in the book The Real Story on ERP. ERP proved to be a false God and delivering both a negative ROI (but a positive ROI for vendors and consulting firms) while saddling companies with systems that put the ERP vendors in the driver’s seat of account control to extract more and more out of their “customers.”

Now as I read about distributed applications accessing multiple databases, are we entering a period where the pendulum switches to custom coding again. Under the SAP or Oracle paradigm, you accepted the databases that were “approved” by SAP and Oracle. All competition was driven out of the process. Oracle applications worked with the Oracle database. SAP finally decided to introduce HANA to push the Oracle DB out of their accounts. SAP now thinks that all SAP applications should sit on a SAP HANA database.

Verner is describing a combination of components that are selected and stitched together. Most of these databases are open source. And one can choose from a wide variety offered by AWS. This is inherently contradictory to packaged applications, because the packaged application uses one DB, and works in a particular and defined way.

While this is little-discussed AWS/GCP can be viewed as opposed to packaged applications. Sure, leveraging AWS/GCP will start with the migration of packaged applications, but once companies get a taste of freedom, it will begin breaking down the rules enforced by the packaged software vendors. And who will tell this story? Will it be Gartner? No. Gartner receives 1/3 of it is multi-billion dollar per year revenues from packaged software vendors, and it is doubtful that AWS or GCP will pay Gartner to sing their praises the way that the package software vendors have. Gartner presents SAP Cloud, Oracle Cloud, AWS and GCP as if they offer basically the same thing, but that AWS is simply “ahead” of SAP Cloud and Oracle Cloud. Gartner has no interest in educating their customers as to the reality of AWS and Google Cloud, as it cuts against their own corrupt revenue model.

AWS / GCS Question Box

  • Have Questions About Using AWS for SAP & Oracle?

    Our unbiased experts can provide you with honest answers and advice about how you can use Amazon Web Services with SAP and Oracle.

    Just fill out the form below and we'll be in touch.

References

https://www.allthingsdistributed.com/2018/06/purpose-built-databases-in-aws.html

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.

AWS Further Eases Database Migration Away From Oracle

Executive Summary

  • How AWS’s new heterogeneous migration targets Oracle.
  • Understanding how AWS’s Managed Services reduces a company’s reliance on Oracle support.

Introduction

Oracle has based its database business around lock-in. As I have covered in previous articles, there is an immense opportunity to reduce costs by migrating away from Oracle databases to databases like PostgreSQL or MariaDB or others. However, something that is required is a managed DB. There is no point in migrating away from Oracle DBAs if something else cannot take its place.

Well, something did.

AWS’s Managed Services

AWS came up with the managed DB through its managed services, which manages overall infrastructure, databases being one component of this. This AWS has had for a while. However, migration has been performed by consulting firms with expertise in AWS. But recently AWS has “greased the skids” for companies with the desire to migrate databases to AWS, and also to migrate away from the database to different databases. Let us see the following quotation from the AWS website.

“The service supports homogenous migrations such as Oracle to Oracle, and also heterogeneous migrations between different database platforms, such as Oracle to Amazon Aurora or Microsoft SQL Server to MySQL. You can also use AWS DMS to stream data to Amazon Redshift, Amazon DynamoDB, and Amazon S3 from any of the supported sources, including Aurora, PostgreSQL, MySQL, MariaDB, Oracle, SAP ASE, SQL Server, and MongoDB. In addition, you can use AWS DMS for continuous data replication with high availability.” – AWS Website

“Options” But a Target on Oracle’s Back

AWS presents this as a bunch of “options” but there is one database vendor that is burning a hole in company’s pockets with its expense and overhead and this database is Oracle.

In this quotation, it explains the details of how this is accomplished.

“With this launch, AWS DMS enables customers to use the same mechanic that the database uses for commit sequencing, which is the log sequence number (LSN). The launch also opens more integration use cases. For example, now you can use Oracle Data Pump or SQL Server BCP to do the initial data load into a target database and then use the DMS log sequence numbers to start change data capture (CDC). With the checkpoint feature.. you can replicate changes once a day from the last checkpoint.” – AWS Website

This conversion setup can be seen in the following screenshot from AWS.

Notice the options under the migration type. 

Conclusion

Companies can avail themselves of this new capability to migrate away from Oracle. Of course, many companies have customizations in Oracle, stored procedure, etc, that reduce the ability to migrate. However, for those databases that can, (other databases can be migrated by moving the stored procedures out of the database and into the application layer) it enables one to migrate to an open source database, which in the vast majority of cases can handle the workload just fine, and with AWS’s Managed Services, it means that Oracle support can be dropped. This can be a boon to companies. It takes what amounts to what is widely considered to be close to no value, and puts back in the company’s pocket to spend on things that do add value.

Brightwork 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.

AWS / GCS Question Box

  • Have Questions About Using AWS for SAP & Oracle?

    Our unbiased experts can provide you with honest answers and advice about how you can use Amazon Web Services with SAP and Oracle.

    Just fill out the form below and we'll be in touch.

References

https://aws.amazon.com/blogs/database/aws-dms-now-supports-native-cdc-support/https://aws.amazon.com/managed-services/faqs/

The Risk Estimation Book

 

Software RiskRethinking 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

Do RDSs Speed SAP HANA Implementations?

Executive Summary

  • The SAP RDS has been proposed to improve the speed of implementations. However, we cover if RDSs are anything more than simply marketing and sales construct in order to make companies think they can implement SAP faster than is possible.

Introduction

In this article, we will cover what is the real impact of RDS on HANA implementations.

What is the RDS?

The RDS is SAP’s Rapid Deployment Solutions are ostensibly things that speed the implementation of SAP products. SAP products will normally take longer to implement than those from any other vendor. And this fact has persisted with SAP no matter how many items SAP has introduced to supposedly alleviate this issue (the most prominent being the ASAP implementation methodology).

RDSs are one of the newer things that SAP will use during the sales stage to make the prospect think that the history of SAP’s implementation duration can be ignored because there is something SAP can offer them to speed the overall process.

The RDSs are really two things.

  1. One is what SAP claims that they are.
  2. The second is what they actually are.

The following are some of SAP’s claims regarding RDSs.

SAP’s RDS Claims

  1. “Build your roadmap with multiple RDS packages that leverage the latest innovations in SAP HANA.
  2. Low TCO, faster speed to market, low custom code, easy usability, and agile implementation.
  3. Best practices content to harmonize your processes
  4. Quick ROI
  5. Need to improve business process NOW!
  6. At least 40% time and effort reduction compared to similar scope of traditional project.” – *ASUG

*ASUG – These bullet points were published by ASUG, but ASUG is just a media outlet for SAP. Like SAP Press they do nothing and publishing nothing without checking with SAP, and/or often being sent the material from SAP. These bullet points came from and should be considered straight from SAP.

These claims are made in rapid sequence, but let us step back and analyze each of them.

Multiple RDSs and Innovation?

Curiously, after analyzing RDSs we can say only the first claim has any validity, and only partially, as only half of the claim is true. That is it is possible to use multiple RDS packages, but this does not lead to leveraging any innovation that you would not leverage without the RDS.

Lower TCO/Faster to Market?

SAP does not have evidence, at least that they have published, that shows RDSs lower TCO of either HANA or any other SAP product.

  • There is also no evidence that RDS lead to faster implementation.
  • There is no evidence the resulting implementing is more usable.
  • There is no evidence that it is agiler.

Best Practices and Process Harmony?

RDSs do not contain best practices, except to the degree that the RDSs contain previously published best practice documentation. Yet the SAP best practice documentation that SAP is referring to is not best practices in the conventional sense of the word.

SAP calls what would normally be called configuration documentation “best practice documentation.” But here are some important features of his documentation.

  • Anything Useful in the RDSs?: In the areas that I configure, I would never use this documentation.
  • What Did SAP do to Create the RDSs?: What SAP actually did is take a configuration document from a project and called that particular configuration best practices. And again, every one of these documents was already published before the RDS was introduced.

Quick ROI?

SAP does not perform TCO estimations, so it is not in a position to perform ROI calculations.

We have written the only book on enterprise software TCO and have the only online TCO calculators and have extensively evaluated all of SAP’s claims and evidence around TCO.

And in our analysis, there is nothing to any of SAP’s statements regarding TCO. Furthermore, like other software vendors SAP does not want customers to know or to perform TCO calculations of their applications. This is no different from automobile companies preferring their customers not know the TCO of cars, or real estate agents not wanting house buyers to know the TCO of house ownership. The more the customer knows the full long-term costs of what they purchase, the less they will purchase.

  • Do people and companies that are trying to sell things want the buyer to consider the TCO of their purchases, or would they prefer they focus on the initial purchase price?
  • How can an entity that seeks to underestimate TCO (or have prospects not focus on it) be able to make any claims regarding ROI, as the ROI using the TCO as the starting point?  

Need to Improve Process NOW?

There is no evidence that RDS improves business processes or improves them faster.

40% Reduction in Implementation Time?

The 40% that SAP throws out is entirely made up, most likely by marketing. The point of that number is to offer a specific number to customers and prospects. When people see a specific number, they tend to think of it as more credible.

Here is another explanation by SAP of why RDSs are desirable.

“Top 6 Reasons Why Companies Choose SAP RDS

  1. Simplicity: Incremental approach, complete solution.
  2. Innovation: More benefits, less risk!
  3. Growth: Think big, and start small!
  4. Differentiation: Solution addresses unique business need
  5. Speed: Faster time to value
  6. Value: Align Business with IT” – ASUG (that is from SAP through ASUG)

Once again, none of these items line up with what is actually offered within the RDSs.

SAP provides no evidence for any of the claims for RDS.

What Really Happens on RDS Sold SAP Projects?

What happens on projects that are sold under the construct of using RDSs stop using RDSs very quickly into the project, once the customer figures out what is in them. The projects that use RDS are invariably reset and extended.

What the RDSs (Actually) Are

We cover this in more detail in the article How to Best Understand the Faux RDS, however, we can provide a synopsis of that analysis here.

The best-generalized description of RDSs would be the following:

  • SAP Basis notes
  • Process flow documentation
  • Configuration guides (the same as those that are referred to in SAP Best Practices)
  • Basic Demos (assumed to be data and accompanying documentation) (in only some cases, but not all RDSs have them)
  • An implementation approach which assumes a small and simple solution, with very little requirement gathering as the standard – simple configuration is accepted in all areas. (although this point is not generally emphasized)

As a long time SAP implementer, who was hired to evaluate the RDS’s value, I can say that the hastily cobbled together RDS packages do not have any value to implementation. It actually takes longer to understand what is in each RDS that the RDS gives back in value.

After analyzing many RDSs and reflecting on them, I could not think of any use I would have for the items as part of the RDS package.

The Real Outcome of Introducing and RDS

The unfortunate outcome of the analysis of RDSs is that it took time evaluate quite a few of them, and then to explain to people who did not know what was in them why was SAP was telling them was incorrect and that not only would RDSs not add value, they would result in an unrealistic timeline being created that would never be met. 

It is difficult to see the RDSs as anything more than a dishonest attempt on the part of both SAP and their consulting partners to mislead customers into thinking that the implementation duration will be shorter than it will turn out being. 

Who Developed the Idea of the RDS and Why?

The important thing to remember is that RDSs were not developed by SAP consulting. SAP consulting most likely had a part in categorizing the already existing documents into “RDS” packages, but the idea most certainly did not come from them.

They were created by SAP marketing and promoted by SAP sales, two groups that normally have a habit of attempting to downplay the duration of projects to customers: Spoiler Alert: so they can sell more.

RDSs were the absolute minimum amount of work that SAP could do (by grabbing pre-existing items that had been around for years) and put them into an RDS so that marketing could say that they had “something.” And there is no marketing or salesperson who can tell a consulting resource what will speed implementation as they have never implemented software before. The RDSs has the distinct odor of SAP marketing first creating all of the claims (based on what they knew prospects would want to hear) and then issuing the task of finding pre-existing documentation to put into the RDS.

Who Told the Truth on RDSs?

And at the risk of being a broken record, there was not a single SAP consulting company we could find that contradicted the story of the SAP RDS in any published form we could find. Quite the contrary, SAP consulting companies have routinely promoted RDSs. Although in their defense, most of the senior people in these consulting companies do not have any idea what is actually in an RDS.

Making RDSs “A Thing”

SAP has a relationship with a publishing company called SAP Press. SAP does not outright own SAP Press, but they remotely control them. When SAP is trying to push a new application or concept, they rely upon SAP Press to publish a book in the area. Some of these books are written by outside consultants. For example, I wrote a book for SAP Press. But a book like this, which deals with a marketing construct, will ordinarily be written by a person who works for SAP.

And there is a book on RDS by SAP Press.

Now the SAP consultant or SAP employee will ordinarily not care if anything in an SAP Press book is true. Many of these books are simply designed to get excitement around an area that SAP is introducing. A book like this one will be basically straight material that SAP would like customers to think is true. The more they buy into the RDS the more software SAP can sell. People reading an SAP Press book may think they are getting real information, but they aren’t. They are getting information that SAP approves of being published. Much of it is straight from SAP marketing. 

Curiously, with SAP Press books buyers actually pay what is normally around $70 for the right to be propagandized. I have read many SAP Press books in my life. I read them more as media criticism. Some of the things in them are true, but any unflattering information or information that contradicts the official SAP position would never be published in a book by SAP Press.

As I was told by an editor at SAP Press, “our job is to make SAP look good!” (Her exclamation point, not added in). Replay that in your mind for a moment. Is that the actual job of a publication? Are we talking about something identified as a marketing literature here, or something that is masquerading as an independent book?

RDS and HANA

As with other products, HANA also has an RDS. Below you can see a typical slide from SAP on RDSs for HANA.

However, data points coming in from many locations are not showing quickly implemented HANA projects. The reason for this is that HANA is still immature as a product and uses both components below it that must be mastered as well as other databases that are sold with HANA, like ASE and IQ that perform tasks that are necessary to even use HANA.

Due to HANA’s high complexity and immaturity, it takes longer than other databases to implement, whether an RDS is used or not. At some point the information about HANA’s long implementation duration will get out, in those cases SAP will respond to those concerns by pointing to the RDS.

Again, the RDS is useful for telling the customer not to observe the actual implementation history of HANA.

The Real Project Duration of HANA

A typical HANA implementation will take between 1 year and 1.5 years to finally migrate. This means that the customer has to run the HANA sidecar this period of time and absorb the cost of doing so. This is a longer duration than is pitching by SAP account executives, and it is one reason why HANA’s TCO is so high. This is where the RDS comes in. It has no value for the project, its “value” is in the sales process. That is the RDS is valuable for SAP sales not for the customer.

We cover HANA’s TCO in the first and only independent TCO analysis of HANA.

Conclusion

The RDS does little to speed HANA. The RDS was developed by sales and marketing to sell HANA into accounts by getting customers to ignore the historical duration of HANA.

Brightwork 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.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

https://archive.sap.com/discussions/thread/3376303

https://events.asug.com/2013AC/Business%20Intelligence/4011%20Leverage%20SAP%20HANA%20Analytics%20Foundation%20to%20Bring%20Operational%20Reporting%20to%20the%20Next%20Level%20Using%20SAPs%20Suite%20Content.pdf

*https://www.slideshare.net/NPFPMO/rds-supporting-sap-hana

The Risk Estimation Book

 

Software RiskRethinking 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

Is Oracle in Trouble (Longer Term) for Oracle Cloud vs AWS?

Executive Summary

  • Oracle is a dominant database vendor, but Oracle is set to lose out in database growth as well as IaaS growth in the future.
  • How AWS threatens Oracle’s account control and how AWS dramatically differs from Oracle in using products themselves
  • Our prediction of what will happen versus AWS (Oracle Cloud vs AWS)

Introduction

This blog focuses on SAP HANA and related topics, and of course, Oracle database is a related topic. SAP HANA was designed not to benefit customers, not to bring anything particularly advantageous to the market, but to grab the high margin database business from Oracle. Oracle is the dominant database that SAP customers use. SAP thought that if they used enough false claims about HANA they could claim a large share of the database market. Bill McDermott predicted that by this time, 7 years after HANA was introduced, SAP would be the number two database vendor in the world.

SAP made all manner of exaggerations in order to promote its customers to drop Oracle in favor of HANA. All of these claims have been researched by Brightwork Research & Analysis and have been proven to be untrue. Oracle’s future database dominance will be challenged, but not by SAP. 

In this article, we will observe something quite interesting about their popularity in databases and what it might mean for the company’s future.

Understanding the DB-Engines Ranking  forOracle Cloud vs AWS

DB-Engines ranking is a site that uses a method that combines a series of factors to result in a rank of how widely a particular database is used. So what factors do they use? Well, I have listed their description of their method below:

“Number of mentions of the system on websites, measured as number of results in search engines queries. At the moment, we use Google, Bing and Yandex for this measurement. In order to count only relevant results, we are searching for <system name> together with the term database, e.g. “Oracle” and “database”.

General interest in the system. For this measurement, we use the frequency of searches in Google Trends.

Frequency of technical discussions about the system. We use the number of related questions and the number of interested users on the well-known IT-related Q&A sites Stack Overflow and DBA Stack Exchange.

Number of job offers, in which the system is mentioned. We use the number of offers on the leading job search engines Indeed and Simply Hired.

Number of profiles in professional networks, in which the system is mentioned. We use the internationally most popular professional networks LinkedIn and Upwork.

Relevance in social networks. We count the number of Twitter tweets, in which the system is mentioned.” – DB-Engines

This seems like a reasonable way to perform a ranking.

Oracle’s Growth Rate

To begin, let us review the usage/popularity list from DB-Engines.

DB-Engine rankings can go up and down over time, so when we refreshed this article we took a second data point.

Oracle’s decline has continued, but interestingly, MySQL and SQL Server have turned significantly negative. This does not track what we will discuss, which is Oracle databases which are switched from being on premises to being hosted with AWS or Azure or other — reducing Oracle’s support revenue. 

Oracle’s DB-Engines Ranking for Oracle Cloud vs AWS

Oracle has two of the fastest declining databases in terms of popularity on the entire list of databases. MySQL is less of a concern as Oracle makes little money on MySQL as it is open source. However, Oracle’s proprietary databases are steeply declining in popularity. Now the overall database market is not growing very fast. In fact, the top 2 databases have an average growth rate of 4.2%. Although it should be mentioned DB-Engines is not measuring revenues, but rather popularity.

  • Clearly, databases that are growing very rapidly such as PostgreSQL and MariaDB are simply taking market share that Oracle is losing. Of all the open source databases, PostgreSQL has probably the best overlap with Oracle in terms of higher-level functions. However, it is also true that many companies that use Oracle don’t take advantage of Oracle higher level functions. That is they purchased Oracle on the basis of brand recognition and defensibility if something were to go wrong (i.e. the IBM argument “no one ever got fired for buying IBM”)
  • This means lower cost databases are eroding the market share of a high-cost database, with high maintenance costs (but with more ability to be tuned).

Oracle’s Long-Term Growth

DB Engines also shows the long-term trend of Oracle.

This is a rather shocking and severe decline. What is curious is how little this is commented upon. Oracle’s databases have not declined, but open source alternatives are eating away at Oracle’s market share, as well as lower priced databases like Microsoft’s SQL Server. Let us look at SQL Server’s growth. 

This graphic is misleading, however. It makes Oracle’s decline look more much severe than it actually is. This is because the base is set to 1.3, instead of zero. If we look at the actual percentage decline from Jan 2013 to July 2017 it is 1.5k – 1.35k or .15. .15/1.5 = 10%.

However, if we look at the graph, it looks like a decline of over 50%. This is the problem with graphs that do not have the x axis set to zero.

Also, this does not seem to match the 97% decline year over year presented in the table. July 2016 shows Oracle with a popularity of roughly 14.2. A decline from 14.2 to 13.7 is .5/14.2 = 3.5%. So how does that comport with DB-Engine’s estimate of 97% decline year over year?

After a significant period of decline in 2014, 2015, SQL Server is regaining its popularity. But is not indicative of long-term growth. 

PostgreSQL is a highly technically competent open source database. After 2014, PostgreSQL has grown consistently. This is exactly the type of database that it taking market share from Oracle, and looks ready to do so in the future. 

Oracle and the Cloud (Oracle Cloud vs AWS)

Oracle is like SAP, a vendor that flourish and is completely designed for the on-premises model. Oracle has two major problems with the cloud.

  1. SaaS vendors tend to not choose Oracle. And prominent SaaS vendors like Salesforce that do use Oracle are trying to move away from them.
  2. Oracle’s applications are not substantially used in the cloud. Oracle sells cloud licenses (because this is how Oracle compensates salespeople) but Oracle sells both the on-premises license and the cloud license bundled. However the cloud license is far less frequently used, and it becomes shelfware — all of this is an attempt to cloud wash Oracle’s earnings for Wall Street.

This following point is brought up by Ahmed Azmi.

“Oracle is obsessed with AWS. Over the past couple of years, Oracle’s marketing machine has been completely fixated on Amazon’s cloud business. I knew something was up when Larry used most of his hour-long keynote at Open World ’16 in San Francisco to trash AWS’ slow first-generation cloud infrastructure.

By October 2017, AWS migrated over 40,000 databases to their cloud. The majority of which are Oracle instances. Why’s this a threat? Because these are AWS fully managed instances. This means AWS takes care of the full range of database administration work including upgrading, patching, and security.”

How AWS Explains This Topic

This is explained in the AWS page on the benefits of managed databases like AWS RDS.

“Many customers prefer to use Amazon RDS for Oracle because it frees them to focus on application development. Amazon RDS automates time-consuming database
administration tasks, including provisioning, backups, software patching, monitoring, and hardware scaling. Amazon RDS simplifies the task of running a database by eliminating the need to plan and provision the infrastructure as well as install, configure, and maintain the database software.”Strategies for Migrating Oracle Databases to AWS

As we are currently doing application development ourselves for our application the Brightwork Explorer, this resonates with us. We want the database to just work, and don’t want to worry about all the database maintenance, which is why we are going with AWS ourselves.

Ahmed continues….

“The AWS threat is so serious, Oracle resorted to the most desperate anti-competitive measure the industry has seen in decades. In January 2017, Oracle quietly doubled its database license for instances hosted on AWS cloud!”

How AWS is Changing How Customers Staff Database Management

This next quote from Ahmed gets into how AWS is changing how customers staff database management, essentially outsourcing it to AWS.

“This is irresistible to many customers because they no longer need to keep as many DBA’s on their payroll. The savings are really quite significant. The operational agility is even better. This model is a no-brainer not only for small businesses, but also for large companies trying to do more with less.

But that’s just an appetizer. Here’s the main course: A fully managed database is a trouble-free database. In other words, customers can easily drop the annual 22% maintenance and support fee they pay Oracle and save really BIG. That’s the existential threat because nearly 50% of Oracle’s annual revenue is generated from install base M&S. The cash cow is moving to greener pastures.”

But familiarity becomes less of a concern if someone else is managing it — providing the DBA, etc… And to Ahmed’s point, AWS has a history of proving managed DBs; Oracle never had this background. (They are an on-premises vendor in their heritage — and as Ahmed points out in their actual revenues).

The customer buys the database and hires their own DBA. That has been their model.

How AWS Threatens Oracle Account Control

Oracle (overall) is vulnerable to database maintenance loss because everything Oracle does is based upon its account control which is based upon its monopolistic control over the database.

If AWS threatens that, it threatens everything else that Oracle does — including their account control.

Ahmed’s quote regarding commoditization of the database layer is as follows.

“Cloud computing commoditized hardware. Now, it’s commoditizing software starting with database. The database, a back-end process by definition, is the perfect candidate for automation.

What happens when a database is commoditized? Just like compute and storage, customers only care about the SLA not the manufacturer. They no longer care HOW you deliver 99% availability because that’s no longer their concern. In this case, why keep paying millions for M&S? You no longer maintain the database and you loathe tech support.”

How Oracle Cloud vs AWS Differs in How the Companies Go To Market

And this shows a difference in how Oracle and AWS go to market.

“AWS and Google are developer-focused. They sell to developers. When your buyer is a developer, you really need credentials. You get credentials from building not buying and reselling.

You may be surprised to learn that AWS hired so many seasoned Oracle salespeople. They hire them because they own the account relationships at many organizations and know how to open doors. Long years of experience also gives you a deep understanding of the local market.

AWS goes to market primarily by gaining grass root mindshare for their developer centric tools. You can call it B2D2B where developers use the services to build solutions then they (the developers) do the selling internally on behalf of AWS. They showcase their work to management as social proof. Much of the process, as you said, is self-service. You don’t need nearly as many sales people. The products do much of the “talking”.”

This gets into the topic of the prominence of the database as it becomes a service.

“The database trajectory is a micro-service. Apps and developers only need to know the API/SQL. If the service provider switched overnight to another SLA-compatible micro-service that happens to run say RedShift, who cares?”

Migrating Oracle to AWS (Lo0king Easier and Easier)

As pointed out by Ahmed, AWS has hired ex-Oracle sales to get Oracle accounts transfer to AWS hosting. A major part of Oracle keeping its customers is inertia. AWS’s hiring to sales reps (many who were let go by Oracle in an effort to go younger and cut its sales costs, explained by Ahmed in the following quotation).

“The idea is to replace as many highly experienced (expensive) account reps with much cheaper fresh grads to lower operating cost enough to report a net profit for product lines where sales growth has stalled.

The justification is that in such accounts, experienced reps add no value since the customer is already locked into long-term contracts and account control is already established via lock-in and the prohibitively high switching cost.

The problem, as Mark Dalton noted, is that those high-profile reps joined competitors like AWS, Google, Salesforce, and Workday. They took with them the account relationships, deep industry insights customers want more than anything else, and some pretty persuasive, time-tested, competitive tactics.

It’s dangerous to think that the credentials of an enterprise sales rep is a replaceable commodity.”

This is clear evidence that AWS is becoming more aggressive in going after Oracle’s maintenance business. AWS did not have to do this. They could have sat back and continued to receive inbound business and continued to grow very well. However, out guess is that AWS saw the opportunity to seriously cut into Oracle’s maintenance business, and by selectively hiring ex-Oracle sales reps decided to alter their normal sales strategy. How can we put this, AWS essentially said to Oracle “For you, we will make an exception.”

But AWS also has online educational material that explains how to migrate Oracle DBs to AWS as well as Oracle DB to AWS’s DBs like Aurora.

They also offer a migration service. 

We have always found that AWS has some of the best technical documentation, and all of it available on the web. 

Oracle Database Migration Options

 ApproachTool Provider
For Smaller Databases < 200 MB (Even with numerous objects)SQL Database CopyOracle
Greater than 200 MB but Smaller than 500 MB.Materialized ViewsOracle (Oracle Database Enterprise Edition)
Greater than 500 MB, Less than 10 GBSQL Loader (Process repeated per schema)Oracle
Greater than 10 GBData PumpOracle

In AWS’s documentation, it shows different approaches for exporting databases from Oracle.

 This is the SQL Database Copy, (for smaller databases).

...which changes depending upon the size of the database. SQL Loader for databases smaller than 10 GB. 

The more customers have customized the Oracle database, the more they have followed Oracle’s advice and placed stored procedures in the database, the more difficult it will be for them to migrate their data to AWS, and also to other non-Oracle databases.

A big part of AWS’s strategy for grabbing Oracle support business is by having customers help themselves as much as possible.

How Oracle Really Sees the Cloud (Oracle Cloud vs AWS)

Oracle appears to have a weak commitment to the cloud as anything more than a mechanism to extract more income from companies and to get a higher multiple from Wall Street. This following quotation is the problem that companies run into when they both try to message to customers and to Wall Street, you end up with inconsistencies.

“And healthy margins are what Oracle’s cloud strategy is all about. “When a customer who is on-prem paying us support moved to the cloud, they pay us more money,” Hurd explained on the most recent earnings call. “They don’t pay us one to one, they don’t pay us two to one, they pay us more like three to one. In some cases more than three to one.”Forbes

How is a customer supposed to interpret this statement from Mark Hurd?

More reality regarding Oracle’s true commitment to the cloud is offered by Mark Dalton, CEO of AutoDeploy.

“Oracle has cloud marketing, AWS has the real deal. The capabilities that AWS has so far outpaces anything Oracle talks about, it is astonishing. I would urge everyone to watch Werner Vogels and Andy Jassey’s talks at Reinvent, last year. Vogels is particularly good.

On Oracle sales front, I used to think the biggest threat to Oracle was not having a fully baked cloud roadmap. I’ve come around to think that it’s the massive sales force that Oracle has alienated, and now have huge upside to go work with Google, Amazon, SFDC etc….Oracle is losing the institutional knowledge of their sales teams. They just push cloud cloud cloud regardless of customer needs. It’s a problem.”

What is the Value of Oracle Support?

Oracle support is as little in value-add as SAP’s, and Rimini Street was essentially originated as an idea to go after this 90%+ margin business that Oracle has in its support. As with SAP support, it is one of the great areas of waste in IT budgets for companies that use SAP or Oracle.

“As a recent Rimini Street survey showed, as much as 74 percent of Oracle customers are running unsupported, with half of Oracle’s customers not sure what they’re paying for. These customers are likely paying full-fat maintenance fees for no-fat support (meaning they get no updates, fixes, or security alerts for that money).” NZ Reseller

This article brings up the question of whether you should be hosting with Oracle. That is, is IaaS and managed DBs a core thing for Oracle? Oracle has immense resources and can cut the price on its IaaS BDs, but the price is not the only factor, but other probably more important features are selected and options for one. So what if a customer want to migrate some of my current Oracle DBs to Redshift or try out other DBs, is Oracle a good choice for my IaaS provider? No. Oracle will, of course, lock them into Oracle.

How about proven managed DB capability. Is this an Oracle core “thing?” No. Oracle is doing this defensively.

Again Oracle seems to be transitioning to managed DBs rather than it being something they have normally done.

How AWS Differs Dramatically from Oracle in Using Products Themselves

Have you noticed how little AWS talks or makes announcements or talks about how much they are investing in A or B? Amazon is huge but very quiet. They don’t have to make big pronouncements; they don’t need expensive sales reps — they just quietly grow market share by being more efficient and offering more choice.

If you don’t actually use your own stuff, you are much more likely just to create trendy stuff that sounds cool. SAP does this. They sell software on the basis of things that sound cool, and they don’t care if any of the cool things end up being true.

Oracle has made announcements that they are investing mightily in data centers as the following quotation attests.

“The future of IT is autonomous. With our expanded, modern data centers, Oracle is uniquely suited to deliver the most autonomous technologies in the world,” said Oracle CEO Mark Hurd. “As we invest, our margins will continue to expand. And with our global datacenter expansion, we are able to help customers lower IT costs, mitigate risks and compete like they never have before.”

First, Oracle has actually very little to show for the “autonomous database” which is a response to AWS’s managed service. The vast majority of Oracle instances globally are managed the old fashioned way, inefficiently, on-premises and with little in the way of automation.

Second Oracle seems to think the only thing that separates them from AWS that will make the difference between Oracle Cloud vs AWS is more servers and more sysadmins. But if customers are looking to have someone manage their databases why would they want to be locked into one database vendor?

  • If possible, (which it is) it is preferable to choose an entity that is database agnostic.
  • An entity that can offer scale economies in Oracle’s database that even Oracle can’t seem to offer?
  • And if the database becomes managed, then the preference for Oracle DB will decline, as much of Oracle’s market share in DBs currently is due to familiarity with IT departments.

A Prediction of What Will Happen Versus AWS  (Oracle Cloud vs AWS)

Sounds like Oracle is going to lose a lot of maintenance to AWS in the coming years.

This whole thing with Oracle being able to charge so much for their database for such long periods of time so long is odd.

Normally customers say Oracle is their least liked vendor, and yet they have this leverage over their customers for so long while there are so many good options available. The old argument was MySQL was not heavy duty enough, but now PostgresSQL brings scale and performance. MariaDB has built-in cloud features that 12c does not have.

AWS sees a big fat margin in Oracle maintenance and they are going after it.

Oracle’s Attempt to Respond to AWS with Pricing

Oracle has claimed that customers that switch from AWS to Oracle for managed DBs will see their costs decrease.

Ahmed Azmi has the following observation on this.

“Larry doubles Oracle DB license on AWS then claims he can halve the cost on Oracle cloud. When Larry’s gone, I’m going to miss his funny antics. Ethics aside.

Nobody can compete with Amazon or AWS on price leadership. Google’s the only exception because of their monstrous scale and pervasive automation. Everyone else, in comparison, has enormous cost inefficiencies. If you have any lingering doubts, ask Verizon, HP, Cisco, Rackspace, and VMware.”

Oracle as a Highly Expensive Offering with High TCO

Oracle has always been a very expensive offering — literally, customers constantly complain about Oracle’s pricing. I have heard these stories for decades now. But all of a sudden Oracle is going to cut the cost in half. Its difficult to believe because its antithetical to what Oracle has been about. That history does not get wiped away because Hurd or Ellison make some statement about pricing at a presentation.

The standard argument offered by Oracle has been their database is better than all other databases. That is a different topic. But it has not been the price argument.

Here is another story that makes the Oracle price declaration seem unrealistic.

“According to that story, Oracle, which would not comment, is calling lawyers in faster to invoke “breach notices.” These contractual notices mandate that non-compliant customers stop using the relevant software within 30 days. If the software in question happens to be the company’s lifeblood database, that is a potentially lethal threat. But guess how the customer can avoid all that unpleasantness? By buying cloud! Cha-ching for Oracle.” – Fortune

And in this quote.

“The secret: tricking customers into using features they haven’t licensed. “Oracle’s licensing policies are notoriously vague and confusing,” said Robert Sheldon, technical consultant writing for TechTarget’s SearchOracle. “One misstep and you can end up owing thousands of dollars in audit fees. Yet Oracle software, with its dazzling array of management packs and pre-installed options, is easy to misuse.”

This is the same technique used by SAP, but for indirect access. Both SAP and Oracle use confusion in order to charge more from customers than would ordinarily be possible. This can be viewed as the attorney approach to extraction.

“The challenge with Oracle software, in particular, is that product options and management packs are installed with the main products and enabled by default.” Once a customer has fallen into this trap, Oracle sends it a breach notice, and then sends in a team to conduct a software license audit. Bringing a customer into compliance, however, isn’t Oracle’s primary goal – selling them services they may not want or need is. “These days, to make the breach notice go away — or to reduce an outrageously high out-of-compliance fine — an Oracle sales rep often wants the customer to add cloud ‘credits’ to the contract,” Bort said.

Once again, it almost seems as if this is undifferentiated from SAP’s use of indirect access. Under indirect access, SAP brings what are phony claims in order to push companies into buying more SAP.

“Customers are buying cloud services to make the Oracle issue go away, not because they have any intention of using cloud services,” according to Craig Guarente, CEO of Palisade Compliance.

Why Is Oracle Used?

Oracle has several different businesses. They have hardware, applications and databases. But their core advantage lies in their database. However, the options for both the database itself as well as the hosting now put Oracle’s database in a weak value proposition. A case can be made for Oracle 11 and 12’s differentiation in the market, but the differentiation is for a narrow number of applications. If a reset button were hit, and companies were able to select any database they wanted, Oracle’s database dominance would change very quickly. This brings up the following quotation.

“For many of its existing customers, however, sticking with Oracle in spite of its anti-customer policies is preferable to switching to another vendor – not because Oracle’s products are necessarily any better, but because Oracle has done such a good job putting up roadblocks for any company considering such a move.” – Forbes

The Problem for Oracle for Oracle Cloud vs AWS

The problem with this for Oracle is that databases are really Oracle’s core strength.

Oracle used its database revenue to make an enormous number of acquisitions in applications.

However, none of those acquisitions were as differentiated as their database. As Oracle’s database decline continues, it reduces their power over their customers. And that leads to Oracle’s application sales also declining. Not immediately of course. Applications in the enterprise space have a stickiness. For example, DB-Engines shows Oracle declining in popularity over the long term, but a rapid decline.

The original purpose of making such acquisitions in the first place was, at least in part, to concentrate the account management and sales effort. Therefore, an Oracle rep would not only offer databases but applications as well. Enterprise accounts tend to like to concentrate their purchases from as few vendors as possible. That is rather than evaluate each offering on its own merits, IT pushes the business to make their lives as easy as possible and to manage fewer vendors.

Therefore, the thought goes that the more that any one rep can offer, the higher the ability to crossover sales for various products.

Historically, vendors that have made the most money, have used a strong capability in one area to sell more product in another area. This is how vendors grow from stronger offerings to progressively weaker offerings.

Conclusion

The trend in databases is clear — most of the growth is coming from open source databases versus proprietary databases. This will have a major impact on Oralce Cloud vs AWS. What this shows us is that the original promoters of open source are being proven correct.

  • The Relational Market: This is still dominated by Oracle in both its proprietary databases and in MySQL, is giving way to open source databases.
  • The Rise of AWS: The usage of AWS’s open source databases continues to grow rapidly. This is bad for Oracle Cloud vs AWS because AWS primarily offers open source databases on its PaaS. It exposes more customers to non-Oracle databases. And the more they do, the more customers will realize they often have Oracle databases that could be migrated to open source options.

These activities in the popularity of databases bode poorly for Oracle at least in the long term and is something that they will need to address with some strategy.

As a side note. It is important to look over long periods of time for database increases or decreases in popularity. If we look at the example of SQL Server, it has grown quite a bit over the past few quarters. However, has yet to recapture the popularity that it maintained back in 2013. This may indicate some change in policy, price change etc..

Brightwork 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.

AWS / GCS Question Box

  • Have Questions About Using AWS for SAP & Oracle?

    Our unbiased experts can provide you with honest answers and advice about how you can use Amazon Web Services with SAP and Oracle.

    Just fill out the form below and we'll be in touch.

References

Ahmed Azmi is a Developer Advocate and Community Builder at the Dubai Technology Entrepreneur Center

https://d0.awsstatic.com/whitepapers/strategies-for-migrating-oracle-database-to-aws.pdf

https://www.reseller.co.nz/article/633023/why-oracle-cloud-bravado-masks-deep-database-despair/

https://www.linkedin.com/pulse/why-aws-bigger-threat-oracle-than-sap-microsoft-ahmed-azmi

– https://fortune.com/2015/07/10/oracle-sales-cloud-hard/

https://db-engines.com/en/ranking_definition

https://www.forbes.com/sites/jasonbloomberg/2017/07/11/oracles-cloud-strategy-ruthless-or-byzantine/#5fae6e1662d9

https://www.techrepublic.com/article/oracle-prepares-for-war-with-amazon-adds-12-new-data-centers-for-cloud-business/

*https://www.dbms2.com/2015/12/31/oracle-as-the-new-ibm-has-a-long-decline-started/

The Risk Estimation Book

 

Software RiskRethinking 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

Risk Estimation and Calculation

Risk Estimation and Calculation

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.

project_software_risk