The IaaS Model vs Traditional Enterprise Software

Executive Summary

  • IaaS offers elastic databases in the cloud. Lock-in generalizes outside of databases.
  • AWS offers a way around the on-premises software sales workflow which focuses on getting the customer pregnant.
  • AWS offers so much choice for Oracle, SQL Server, MariaDB, PostgreSQL, Redis, etc…
  • Understanding the business model AWS, Azure and Google.
  • Why so many media entities has a problem contradicting billionaires.

Introduction AWS IaaS Options

Enterprise software is slowly and haltingly moving towards an environment with more choice than has existed previously. As much as it has been proposed that the major participants are helping to drive this forward, in fact, most enterprise software entities only have an interest in moving towards this new environment on their terms.

In this article, you will learn about change and distinguish between the force-feeding of apps and DBs into customers versus the choice model.

Elastic Databases in the Cloud

Under the on-premises model, databases were not and are not elastic. You had to size the database, and then after that, you were stuck with that size. You could, of course, adjust it upward, but when you made a purchase, you were locked in.

This brings up the topic of the new flexibility and choice that has become available, as explained in this quotation by Ahmed Azmi.

“It’s not always possible to distribute read and write activity evenly all the time. When data access is imbalanced, a “hot” partition can receive such a high amount of read and write traffic compared to other partitions that throttling occurs.

To avoid this situation, DynamoDB adaptive capacity enables your application to continue to perform read and write operations in a hot partition without being throttled, provided that your table’s total provisioned capacity is not exceeded. With adaptive capacity, DynamoDB becomes more tolerant of imbalanced workloads.”

Something I really like is the elastic nature of the memory. So I wrote the following article on the problem with HANA sizing.

In that article, I explained that SAP was actively deceiving customers as to the sizing of HANA to bring down the anticipated price (and setting up a big surprised down the road). As I propose, SAP learned that people thought HANA was too expensive, so they engineered this fake sizing with Hasso telling everyone the database will compress by 98.5%. Those same tricks aren’t going to work with open source on AWS because the customer can simply shut the instance down.

But with DynamoDB, there is no commitment and no standard sizing exercise. (correct me if I am wrong). A company can start a test instance, and size from there.

How Lock In Generalizes Outside of Cloud

This lock-in generalizes outside of databases. On-premises, ERP systems lock companies into using ERP, and ERP vendors use the ERP system to penetrate accounts and radiate from that penetration point to selling what are often mediocre non-ERP applications to the account. In fact, a very large percentage of the overall enterprise software market is based on force-feeding applications and databases into customers. The most financially successful software vendors (vendors like Microsoft, SAP & Oracle) also happen to be the most accomplished at force-feeding applications.

Ahmed Azmi also explains how a database like DynamoDB at AWS can be scaled and its elastic nature.

“Appliances scale vertically. If you need to add capacity, you buy and install more memory, processors, and storage. But initially, you must do a capacity estimate as you say. If you over-provision, you’re paying for resources you don’t need and wasting money.

With a cloud service like DynamoDB, none of this is needed. The database can be started at any minimal configuration, and it automatically adds capacity when needed. More importantly, it removes capacity when demand drops. You pay for what you use, and you don’t have to manage any of this.

It’s a completely different IT strategy suited for TCO aware competitive businesses. “

The Importance of Justifying Past Purchases

Under the “no backout” model of SAP and Oracle the objective is to “lie you into a buy,” but then once in, you are trapped. It’s like a fish trap; fish swim in, they don’t swim out.

A major part of enterprise software is IT departments justifying previous purchases and previous investments into software. On several occasions, I have been brought in to improve an SAP module where the primary objective of IT was for me to make their previous purchase look good. On the occasions where I found that SAP had ripped off the customer by selling them add-ons that did nothing, or where the research showed that the company spent a year or more configuring SAP in a way that would never work properly, I was told to shelve that research as it would be bad for morale. On one account after I left, the company spent another 6 years trying to get an approach in SAP software to work that was impossible to get to work because the functionality was defective. I wrote the report that explained this, and it sat unread in the company. Six years later they removed that component and brought in a different software vendor. 

I see this at all of my clients.

Their IT department is littered with underutilized and or broken applications that were forced into the company because of exaggerated claims and the salesperson’s quota. I only really get to see SAP environments, and for SAP environments the situation is extreme. But I have the feeling that if I had access to non-SAP environments that I would find a similar situation, although to a lesser degree. I believe the situation is the worst with SAP because it has so many partners in crime, which are the consulting companies, force-feeding inappropriate applications into customers for profitability reasons.

If these systems were objectively analyzed for what they are contributing to the customers, many of the applications would be decommissioned. But no one wants to admit they made a mistake.

The On-Premises Software Sales Workflow

Therefore a primary workflow of on-premises software is…

  1. Makes Sure Your Marketing Department Lies: Hire unprincipled marketing individuals who will write anything, as long as it sounds good. As one head of marketing for a vendor once told me “I need you to tell me what I can get away with saying.
  2. Motive the Quick Score: Incentivize your salesforce so that they just get paid on the license and so they don’t care about implementation success. As one salesperson told me “I don’t like services sales. I like software sales. I want to sell the software and get paid.” 
  3. Coffee is for Closers: Let the salesforce know that they will either meet aggressive quotas or be fired, thus creating a perfect environment for providing false information to customers.
  4. Castigate Consulting or the Client: Once the software has been sold, allow the issues of unmet promises to be managed by the consulting team. Castigate the consulting team when they can’t meet the expectations of the sales process by telling them they are “losing the account.”
  5. Build Relationships: Co-opt the IT organization by treating them to conferences, potential future jobs, i.e. create “strong relationships,” that insulate the software vendor from judgments related to the discrepancy between the sales promises and the actual outcomes.

How AWS Promotes Choice

In a recent criticism of AWS, Larry Ellison stated that Oracle 18c was better than AWS’s database because it was automated. I address Oracle’s claims about automation in this article.

However, even if the claims about automation were true, this lays down a false comparison. First, because AWS allows one to host just about any database. And second AWS is not charging a license for its database. AWS prices its databases as open source databases.

Ahmed explains AWS’s pricing approach of its databases versus open sources database.

“AWS pricing for DBaaS is all based on actual consumption and the instance types/sizes you choose. No premiums. AWS tries to reduce prices not increase them. That’s their business model. High volume, low margin. It’s the exact opposite of say Oracle which has fewer customers but charges premium margins.”

Therefore Oracle is comparing itself to AWS databases that while not open source are priced as an open source database. Oracle and AWS are saying two very different things. Oracle is saying, “You must use our database because it is better than all the other databases.” 

AWS is saying something quite different. “We just want to host your business — you can use our Aurora database, or choose from any of the others — we don’t care.”

AWS for Aurora, or Oracle or SQL Server, or MariaDB, or PostgreSQL or Redis, or…..

If you look at AWS’s RDS service, they don’t push Aurora over the others — its an option. Oracle Cloud exists to host Oracle software. That is it is a combination of Oracle’s IaaS with Oracle’s database. The entire premise is based upon Oracle having the best of both. And it goes beyond the topic of “best.” This is because AWS is offering many specialized open source databases in addition to the compensated license databases. Oracle is trying to set up the scenario as if the competition is between Oracle’s “database” and AWS’s “database.”

But it isn’t.

It is between Oracle’s database + Oracle’s IaaS versus AWS’s IaaS + AWS’s database + all other databases, including Oracle. This is how IaaS is different from SaaS. With SaaS you engage with the vendor for the application, and the vendors “provides” the IaaS along with SaaS, with the IaaS being something you don’t see. SaaS is great for consumers. No single consumer wants to get into the IaaS decision to sign up for a DropBox account. I use DropBox, an invoicing application, a research search engine, Gmail + another email service, Google Suite, a web host (for this site), etc.. And I am not interested in setting up an IaaS for these applications. But for companies that have a lot of users and have to integrate new applications with old applications, IaaS is for some (not all) applications actually more appropriate.

All of this gets to the topic of choice.

The Preferred On-Premises Vendor Relationship

According to the vast majority of on-premise vendors, this is a depiction of the perfect vendor/customer relationship dynamic. If I am SAP, I am going to tell my customer that my database runs 100,000 times faster than any other database. If I am Oracle, I will tell the customer the database is entirely automated and does not have humans operating it.

Getting The Customer Pregnant

Under the on-premises the model, the intent is to get the customer “pregnant.” After that point then, they are trapped by your promises, because the IT department will not go back and say “we got bamboozled, we don’t know how to do research. 

As we will note further on in this article, even some SaaS vendors like Salesforce now seek to have the above on-premises relationship with customers described above.

Who is Changing Enterprise Software?

If you approach a vendor, you normally get pushed down a pathway where you have to use everything or as much of what they have as possible. Our present software system is based on pushing people down pathways.

  • Smaller vendors that lack the ability to lock customers in, still push strongly that their solution is the best.
  • Larger vendors combine the promotion of the smaller vendors with lock-in. The large consulting companies push customers down pathways where the consulting company can make the most money — which happens to be with the vendors that engage in the most lock-in.

AWS has people like Ahmed and myself thinking about how the entire enterprise software business should be configured.

What is so curious about all of this is that the entity which is causing the most competitive pressure in enterprise software (Azure is also causing pressure, but without AWS, Azure would not exist.), is a company that created computing capability to support its own business, and then branched into the enterprise software market. That is it is was not a company that started off as software vendors.

What Type of Business Model is AWS, Azure and GCP Following

With respect to AWS no charging companies for its own databases versus open source databases, Ahmed explained it this way.

“The fundamental difference is that AWS, Azure, and GCP are platform companies NOT product companies. Think about a mobile network operator versus a mobile phone manufacturer.

The phone manufacturer wants you only to buy their brand. The network operator wants you to use their network regardless of your mobile set.

Very different business models.”

The Force Feeding Software Model

And this gets to something very important in that model because it’s the IaaS, not the application or the database. Deloitte wants to drive you to Oracle or SAP.

This brings up an interesting question.

The original premise was that you needed to use SaaS. Access our SaaS application the vendors said. A lot of money was raised. SaaS was going to take over the world, but it is looking less like that.

These are the top SaaS vendors according to Datamation.

The List Coding

I have comments and some coding next to each vendor. I have commentary next to some of the vendors, but also a coding. The coding is colored to differentiate it from the comments. The coding is as follows:

  • Glue Vendor
  • Traditional Vendor

The Top SaaS Vendor Listing

  1. Salesforce (Traditional Applications)
  2. Microsoft (I question this ranking. I bought the Office 365 Suite and paid online, but it is not a SaaS application)
  3. Adobe Creative Cloud (Design)
  4. Box (glue vendor)
  5. Amazon Web Services SaaS
  6. Google G Suite (Office Suite)(BTW, I am increasingly collaborating with clients on forecasting with G Suite, and it is showing me new things all the time. No forecasting application has the ability to collaborate the way G Suite allows. The ability to add and see notes means G Suite allows for long-distance teaching. Watch out Microsoft!)
  7. Slack (glue vendor)
  8. Zendesk (glue vendor)
  9. ADP (glue vendor)
  10. Oracle (But a smaller percentage of overall revenues and tons of cloud fakery)
  11. DocuSign (glue vendor)
  12. Cisco (WebEx, Spark) (glue vendor)
  13. ServiceNow (IT service support)
  14. GoToMeeting (glue vendor)
  15. GitHub (Online software dev)
  16. Workday (Traditional Application)
  17. HubSpot (Web Marketing)
  18. Twilio (glue vendor)
  19. Coupa Software (Traditional Application)

Categorizing the Cloud Vendors

When I look at this list, what pops out immediately is the number of  “glue” vendors. I classify a glue vendor as a vendor whose application is really about connectivity and could not exist without that connectivity. Things like WebEx that have to be SaaS. The same is true for you can’t have an “on premises” file sharing service, or at least one than works outside of a company.

What is apparent is that the majority of these vendors did not migrate from to the cloud, they originated in the cloud. 

Of the top 19 vendors, I have classified 8 as glue vendors. Google Suite and Hubspot aren’t glue applications, but they did not exist “off of the web.” In fact, of the top 19 SaaS vendors, only 3 are traditional vendors. Oracle, SAP, and Microsoft are cloud washing their cloud revenues. A lot of licenses sold by Oracle as SaaS are shelfware. The only reason Oracle, SAP and Microsoft’s cloud washing acts are accepted is that of the money they use to flood the IT media. Oracle, SAP and Microsoft are on premises when it comes to customers, but cloud when it comes to Wall Street.

This is the common explanation of software vendors moving to the cloud. However looking at the list above for customers that fit this narrative, only a few companies that began as on-premises vendors can be found to have substantially moved to the cloud. And this is not the early stages of the cloud/SaaS. I first became introduced to the cloud with Arena Solutions back in 2008. All of the capabilities to offer cloud applications existed back in 2008. Yet we have seen very little actual migration.

There has been lots and lots of smoke, but little actual migration. 

Cloud Vendors in the Traditional Enterprise Software Space

The three vendors that are in the traditional space are Workday, Coupa & Salesforce. All of these vendors could be on-premises, but they chose not to be. Salesforce has slowed and is calcifying, acting more like an on-premises vendor. They are pivoting to the force-feeding model in terms of conditions, cutting off choice while retaining the cloud model for delivery. The hype that used to surround Salesforce has dissipated and Salesforce CRM is now far behind the other CRM systems but continues to be used because it is “the standard.”

Long story short, the majority of software vendors that have risen in the cloud, began there. Those that are migrating to the cloud are moving far more slowly than is being explained. The most interesting thing happening right now is happening in IaaS rather than SaaS.


Choice is coming to enterprise software that did not exist before. It’s not coming from the largest software vendors. It has been forced from the outside by AWS and to a far smaller degree Google. Azure is a reaction to AWS on the part of one of the top vendors.

The level of options offered by AWS or Azure or GCP, therefore in IaaS, is far more than is found in any other area of enterprise software. But there is still far more control than is generally being proposed.

Postscript: A Problem Contradicting Billionaire Advertisers?

As a side note when Larry Ellison’s comments I listed above were published, I found no explanation of this point that Ellison was creating a false equivalency. That is media entities carried forwards Oracle’s message without questioning the message, even though it was a false comparison.

This returns us to a repeating observation that the way to make money in IT media is through repeating the messaging of the most powerful and wealthy entities, not questioning it. Furthermore, if you repeat whatever the entity says, you can accept advertising from them, make a lot of friends in within those software vendors and get invited to conferences where you can hobnob with them and gain more access where you can get even more false information. Therefore not only to massive software vendors pay salespeople to repeat what are often false statements, they pay IT media to do the same.

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 Question Box

  • Have Questions About Using AWS or Google for SAP & Oracle?

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

    This article is free, we do not answer questions for free. Filling out this form is for those that have a budget. If that describes you, just fill out the form below and we'll be in touch asap.


Enterprise Software Risk 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.


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