In my prior analyst job it was important to always make sure I was delivering analysis that was driven from a customer perspective. I was always on guard not to take short cuts and group technologies into a market that really was not a market, but just to make my job easier. When this occurs, the credibility of an entire report can be quickly undermined. Now that I am out the outside looking in at the analyst world, I can't help but look at analyst reports that get published and review them as if I was in my old job. I recently was viewing a report where the title of the report was about evaluating Public Cloud Platforms. From a Salesforce perspective in my new job, it seemed like a reasonable framework from the title that was applicable to us. However, not reading too far in, I realized that it was one of those compromised reports that somehow made it through the system.

The first thing to catch my eye was specific criteria to be able to use the platform on-premise. It was not to integrate to on premise environments, nor was it the ability to run the platform on varying cloud infrastructures, it was specifically to run the complete platform on-premise. So I stepped back and thought, "how can a report called 'public cloud platform' evaluate the ability for the platform to execute inside the firewall of a company?" I could possibly see the argument of making the title more generic and simply entitling it “Cloud Platforms,” then one could at least make the Private Cloud argument. To be clear, I am not bothered by the fact there would be a framework to evaluate technology providers on their ability to support on-premise, hybrid, or whatever term that analyst firm seems fit, but to “bait and switch” both the term and criteria is more troubling.

At Salesforce, I am obviously an advocate for Platform as a Service (PaaS) or a public cloud platform (use your analyst term of choice). As I will explain, there are good reasons why a platform in the cloud has value. Reasonable people can have a debate on the various delivery models — but what bothers me is to lead customers to believe they are evaluating one thing by saying something like Public Cloud Platform and then using evaluation criteria that considers on premise an important criteria. The minute there is one criteria that does not make sense, there is likely more. In this case there indeed were more.

Before we discuss the more extraneous criteria, it is important to revisit the reasons why customers told me they saw PaaS as an important enabler in the “Age of the Customer.” In the Age of the Customer, information and connections are rich and complex, and will require companies to rethink how they deliver customer apps. And it’s not just about the apps themselves: companies must deliver unmatched customer experiences along with every app, and they must do so in release cycles of weeks, not months.

In the spirit of full disclosure, not all customers I talked to as an analyst wanted to use PaaS, but for those that did, I offered analysis relevant for them to make their decision. It often starts with a common question I get from CIOs: “should I simply 'lift and shift' my legacy apps to cloud infrastructure or should I build new cloud apps that help better connect with my customers?” The answer is there is value in both. Both will lower operational costs due to outsourcing infrastructure, but only the second option has the “double down” effect of improving revenue and lowering costs at the same time. Which leads me to another point: if one of the benefits of a PaaS is to improve “agility” to eliminate the need to for developers to worry about underlying issues such as database tuning or memory management, why should a customer who wants to move to pure PaaS model factor those into their evaluation?

The simple answer is they should not. If a customer is worried about managing the underlying infrastructure as a service to meet their needs, they immediately lose the core values of PaaS to begin with: innovation, speed to market, and ease of on-going maintainability. This, of course, was the second consideration used in the report I read. At this point, I knew the report was just not going to provide much value to customers interested in moving to a true PaaS environment. To draw a parallel, it's almost like the evaluation of relational databases that includes a requirement to support flat-file definitions, or for an iPad to natively run a cobol program. It doesn't make sense in the context of user requirements.

The consensus industry analyst position for PaaS is not to run as an on premise environment, or require a vendor to offer low-level infrastructure as a service tooling. Instead more emphasis is being placed on providing a complete spectrum of development capabilities from code to low-code to no-code so companies can expand the pool of resources to develop and build valued applications to help better connect to the customer (see this blog post). It is also important not to forget the main tenet of PaaS which is to eliminate the need for developers to worry about low-level databases, and instead use meta-data strategies to lower upgrade and maintenance costs. My beef is not to argue with whether “lift and shift” IaaS is “better” or “worse” than PaaS, nor the relative value of on-premise, hybrid or cloud. I take issue with customers who think they are evaluating PaaS and are confused with a framework whose scope is to cast a broad net. We had a saying when I was an analyst: if you build a framework that is the “Jack of all trades,” then it will undoubtedly end up as the “Master of None.”