Parting the Clouds

In the last few decades, technology has advanced at such a rapid pace that anyone not closely involved in its design and implementation may see little reason to acquaint themselves with the ‘tech terminology du jour’. After all, these terms and phrases often emerge or become extinct as quickly as the technology they are used to describe.

Procurement software is no exception. It has evolved from on-premises (or behind the firewall) solutions to SaaS and cloud computing — apparently the minimum expectation for keeping pace with technology evolution today. In many ways, a growing distance between procurement and the technology used to automate its processes makes sense. After all, isn’t the advancement being seen supposed to alleviate the need for companies to understand each solution down to the code level? While, generally speaking, making procurement technology more user friendly offers great strategic advantages, in some cases our peripheral relationship with how it actually works causes us to be overly casual when we characterize its capabilities. Broadly describing procurement technology in the cloud as SaaS/cloud technology belies the difference between the two, unintentionally watering down the differences between the options available today.

To understand the difference between cloud-native software and Software as a Service, one has to understand the architecture behind them.

The Evolution of Cloud Computing

Some new technologies can be thought of as solutions waiting for the right problem to come along. Cloud computing is not one of those. The advent of true cloud systems has come about as a very direct result of a very real problem for businesses. It is because of this that cloud computing can be genuinely given the label that is so often used euphemistically in the software industry — it is a “solution”.

The problem can be thought of in fairly simple terms. The fewer things you need to worry about that aren’t your core business, the more you can focus on actually doing business.

This is quite true when it comes to business software systems. In the past, a corporate software program would be 100 percent an IT concern. Your sourcing or purchasing package would need machines, hardware, power, operating systems, end-user terminals and maintenance. As the world changed and networks grew, you needed telecommunications, security, firewalls, databases and virtual machines. With the advent of the Internet you needed always-on, always-available systems and every single one of this ever-growing list of components has required that you have the expertise to go with it.

And that’s just for what you had at that time. Planning for the future was always at best a bet.

Specify a system too far in advance of you current needs and it was hard to reach an ROI. Go “lite” and cheap, and your business systems might run out of steam before you reach full user capacity. So upgrades, maintenance, keeping pace and reacting to change all needed to be built in to the plans. And you haven’t even thought about doing any business yet.

So, it’s no surprise that the maturing of the data center saw service providers rushing to meet the demand of businesses looking to offload as many of those concerns as possible to a contracted service provider. Initially, that was a matter of outsourcing IT — let someone else be responsible for the situation as it is. This in turn evolved into the Software as a Service model that also included a physical relocation of the components, leaving the business just concerned with using the software tools — in theory.

The fact is, the concerns for all those components in the list — from hardware and operating system, to security and telecoms, haven’t gone away; they’ve simply become someone else’s problem. Someone still has to maintain, upgrade, secure and otherwise watch over the system and there is cost and risk associated with every component. Certainly, the business need only concern itself with SLAs but the underlying issues are still the same and scaling, performance and other reactions to changing circumstances have to be accommodated.

Enter the Cloud. The cloud decouples many of those system concerns from the application provider and the business completely. Need more processing power? It can now be “dialed in” and not physically installed, tested and brought on-line. Need massive redundancy across a global footprint? That too can be a matter of configuration instead of a matter of planning, construction and the enforced time-lag that goes with such things.

The application provider can focus on delivering you a solution instead of just some software, the cloud provider in turn does what they do best — running the infrastructure.

Cloud therefore changes the nature of the relationship between your business and the technology that you need to support it. But why should you care if your SLAs within the outsourced of SaaS model were good enough?

If the Internet age has taught us anything, it is that what is good enough today can become completely unacceptable tomorrow. Flexibility and agility — the ability to change direction in web-time — is undoubtedly going to be a strategic advantage in the years to come.

Why SaaS and Cloud-Native are Not the Same

It is true that cloud technology is managed ‘as a service’, but the two terms actually have little in common. Software that is delivered ‘as a service’ — which includes the vast majority of enterprise software in use today — allows the purchasing company access to the solution provider’s intellectual property on a subscription-based cost model. The purchasing company does not own the software outright or has a unique installation, instead it pays for access to the software’s functionality. Because of this delivery model, companies do not have to administer the infrastructure or maintenance in house that they did using onpremises software. This includes facilities, staffing, upgrades, communications, and updates.

Cloud technology, on the other hand, is characterized by its architecture rather than by a commercial model. Technology hosted in the cloud decouples the application from the infrastructure (i.e. memory, databases), and is often described as Platform as a Service (PaaS). While this may seem like just another term du jour, the distinction is one that procurement and supply chain professionals should be able to relate to: while SaaS subscriptions involve a solution provider and the company that will use the software, PaaS subscriptions involve a solution provider and a hosting platform, such as the Microsoft Azure Cloud Platform.

Each solution provider’s Microsoft Azure (i.e.) account benefits the end users subscribed to their SaaS solution, and the platform (along with its flexible demand or elastic pools of resources) is scaled and consumed across all of the solution provider’s clients. The resulting chain of relationships — you might even call it a supply chain – puts the platform to use for solution providers who in turn sell software subscriptions to a number of clients.

Even once the differences between SaaS and Cloud have been delineated, confusion may remain because even the cloud is not always the cloud.

• Cloud-native: Thinking back to the example of Microsoft Azure serving as the PaaS of choice for a SaaS solution provider, it is critical to point out that cloud-native solutions must be built upon one specific platform. The deep level requirements of the cloud separate the application from the architecture. Solution providers working through this model are able to focus entirely on workflow patterns and user interface, leaving the messaging, security, and database balancing to their PaaS provider. Directionally speaking, cloud-native solutions are built ‘up’ from one specific platform.
• Cloud-based: When SaaS solutions are not designed for one specific platform, but are instead migrated from a legacy SaaS model to Cloud-hosted infrastructure, they are described as cloud-based or hybrid cloud. In a cloud-based scenario, less responsibility is handed off to the platform provider, resulting in a division of labor that more closely resembles residency in a shared space than a full third party relationship. If cloudnative software is built ‘up’ from a platform, Cloud-based software is moved ‘over’, taking advantage of the increased hosting performance without actually changing the software’s architecture.

Why It’s Important to Make a Distinction Between the Two

Despite all of the changes discussed thus far, the mindset around B2B software hasn’t changed much — particularly in companies that have a legacy driven by ERP systems, many of which may have been designed for their own unique and particular use.

While this fact may seem as though it could be relegated to a small handful of companies still running home-grown solutions, it continues to play an influential role in how decision makers regard the differences between customization and configuration, and what is possible with cloud software. Because cloudhosted solutions are multi-tenant, meaning that more than one company is accessing a single code base, it cannot be customized. It can, however, be configured along the lines laid out by the solution provider. For this to accommodate the needs of a broad range of companies, the solution provider must have a solid understanding of the range of requirements likely to be seen in its user base.

While this may seem confining at first pass, a configured versus customized approach is a good match for the needs of procurement processes — particularly those that understand their true role is to manage the information flow central to effective spend management rather than dictating a lengthy series of keystrokes that constrict how purchases are made throughout the organization. When considered through this view, the majority of procurement’s software requirements are shared across industries, making it a key target for cloud software.

While it is entirely possible that in time there will be something beyond SaaS, PaaS, and cloud-native that procurement technology will have to accommodate, procurement professionals owe it to themselves to separate the commercial model from a platform-driven approach to architecture design — both for the sake of understanding what kind of software they have in house today and what kind of software they want to have in place to meet the opportunities presented in the future.

Does it Really Matter Which Solution You Use?

Fundamentally, it shouldn’t matter whether your business software is SaaS or cloud by the definitions proposed in this paper. From an operational and legal perspective, the concern should be with the SLA offered by your service provider and adherence to the same. But the reality is more complex as we have seen.

As things stand at any given moment, a software system provided “as a service” should be straightforward to access and robust, offering no management issues to the customer at all. It should be of no consequence how the underlying delivery mechanism is structured or defined.

What does make a difference, however, is what happens at moments of upheaval or steady change. Growth in user load – whether organic or step-change – can see demand quickly outpacing capacity for any system. Mitigating the impact becomes dependent on how quickly and seamlessly the system can be resized to fit. If the change is in the opposite direction, it may be due to a massively over-specced system.

Between steady growth and sudden shrinkage there is the more commonplace reality of variable demand and unpredictability. And this is where the details of the underlying model really can become important. What is important is not whether you have the right SLAs today but whether the service can change with you. Tomorrow’s required SLAs could be quite different and the fact is that the way the “as a service” system is built fundamentally determines whether it can meet the SLAs today and tomorrow.