The Real SaaS Differentiator: Cloud Native

Back in the day when cloud computing was new, simply delivering your software as a service from the cloud was a differentiator. Now that many software companies have migrated their solutions to the cloud or created SaaS versions of them, it’s gotten harder for buyers to figure out which solutions will really deliver all the benefits of SaaS—business agility, speed of implementation, ease of use, and continual innovation.

What buyers should be looking at are the differentiators between native and non-native SaaS applications.

There’s a big difference between existing applications that have been ported over to the cloud, and solutions built in the cloud from the ground up.

Tracing Paper

If you’re developing from scratch in the cloud, you have a blank sheet of paper. You have the capability to design whatever you want, taking full advantage of new techniques and mediums, learning from the works that have gone before. You have an opportunity to reconsider whatever business process you’re designing for, independently of what already exists.

If you're rewriting an application to host it and deliver it in the cloud, you're tracing. You’re putting a piece of paper over an existing drawing and recreating it. You might be able to take your pencil and eraser and make a few modifications, or add some new colors, but largely you’re going to be duplicating the same work, with the same limitations.

You have to do it that way because you have existing customers that you’re moving along with you. You could say, "Hey, now's the time to look at this differently and develop something unique." But, that’s a risk. That means your customers would have to change in a massive way, and they may not be open to it. You’re far more likely to say, “Let's not go crazy. We can add a few things, but for the most part, let's just duplicate what we have on premise using this new cloud technology." 

Built for the Power User

If you go that route, that means you’re taking something that was developed 10, 15 or 20 years ago and keeping it mostly intact. At that time, enterprise software was being built to meet the requirements of power users in the corporate office, not the average employee who only needs to log in to the application periodically. We didn’t have mobile. We barely had Google.

There wasn’t a lot of thought given to ease of use, because the plan was always for these power users to get in-depth training and support from a partner ecosystem. Everyone else who had to interact with the system either they went through one of these specially trained power users, or they found a workaround.

Business has changed a lot in the past couple of decades, and rather than having these system gatekeepers, the thinking now is to push the work to the people with a vested interest in getting it done fast and error free.

In HR, for example, the thinking today is “let's not send out paper documents for employees to fill out and then send back in, which we then have us key into the system. Let's give them a very simple electronic interface where they can go in and manage their own information.” It's like managing your personal bank account or trading on E-Trade. We don't need to go to a broker anymore. We can do it ourselves. Why? Because the solutions are simple and easy. 

As Easy As Amazon!

Today, everybody wants simple and easy. If you've heard it once, you've heard it a thousand times: Business applications should be as easy as buying something on Amazon. People expect the technology experience that they enjoy as consumers to carry over to their business world.

To accomplish that with an older product, you would have to rewrite the whole thing. So, putting it in "the cloud" usually means giving it a prettier user interface on top, but for the most part, it's the same features and functions in a different technology stack.

That’s a very different thought process from looking at modern, open source development languages, Amazon Web Services or Microsoft Azure, REST and SOAP APIs and asking "Okay, what can we do here to solve this problem?" You’re taking full advantage of the last two decades of technology innovation, and you’re also thinking differently.

Tale of Two Ferraris

The other thing about older solutions is that a lot of them are rollups. Over time, software companies expand their capabilities by merging or buying each other and integrating their technologies.

Moving these rollups to the cloud gets even trickier. You might be looking at a UI that ties everything together on the front end, but there are separate systems with different code and different databases behind the scenes. You don’t have all the benefits of an end-to-end integrated process built on a single code line.

It's like looking at two Ferraris that both look awesome from the outside, but one is all Ferrari parts. They all fit together and they all work together. 

The other one is just a Ferrari chassis. You lift the hood and you've got a Chevy carburetor, a Ford engine, and Honda spark plugs.

So, if something goes breaks and you replace the Chevy carburetor with a   carburetor, and now you've got a problem connecting to your air vent because the Chevy had a square connector and the Ford one has a circle. So, now we've got to replace that piece too. Oh, by the way, if I replace that, then I affect something else.

That increases cost and it slows down and limits innovation, which is one of the things you’re buying with SaaS. The product you buy today is not all you’re ever going to have. Every few months, there's going to be another enhancement, integration, partnership or acquisition.

It’s much easier to knit these pieces together seamlessly and roll them out in a native SaaS platform. If you think about the upgrade train that you have with Facebook or LinkedIn, or Salesforce on the enterprise side, upgrades on these platforms are rolled out literally overnight.

It’s the Data, Stupid

The other problem with rollups in the cloud is that you typically don’t have a normalized database. The reason we're putting in these systems in the first place is for data, data, data. We're digitizing the world and digitalization just means converting everything into data so we can leverage it, analyze it, group it, compare it, calculate off of it and make decisions . . . now . . . like, right now.

When you have multiple systems that support an end to end process and they're not built on one code and platform, you now have to go into different data sets and pull information and normalize it. How real time and accurate is that going to be? 

If you don't have all the data in one place, you don't get to leverage benchmarking amongst the hundreds of other organizations using the same system. You don’t get to leverage the community.

There’s a real difference between products that grew up in the cloud, versus those that moved into the neighborhood later. The only way to tell is to look under the hood, and in my next post I’ll tell you how to do just that.