Cloud … SaaS...what’s the difference and why does SaaS make economic sense?
When Commercial people start talking to Technology people, very often what happens is that they got lost in TLAs (Three Letter Acronyms) that mean SFA to them. To be fair, the same often happens in reverse.
In the old days, the Technology person and the Commercial person would get together over a lunch, or maybe even a beer, to translate each other’s jargon and have a meeting of minds, but as we are only slowly emerging from lockdown let’s have a virtual lunch. And yes, we realize SaaS is a Four-Letter Acronym, but let’s start with the Commercial person.
First off what is SaaS?
It’s Software as a Service and it’s a way of allowing everyone to have access to sophisticated software that otherwise would be unaffordable for most.
I’m told that SaaS significantly reduces costs and increases speed of business execution. But why is this the case?
Well, lets start with costs and introduce the Cloud. The Cloud is essentially large volumes of computer equipment that is accessible by way of a telecoms link. It allows everyone to have access to sophisticated hardware that otherwise would unaffordable for most.
Software as a Service (SaaS) is business application software that is installed in the cloud, delivered through a web browser and charged per user per month. Good examples are Salesforce.com, arguably the original of the species, and Workday. When you combine sophisticated hardware and sophisticated software you are also reducing the cost of delivering more value.
So why does using SaaS make economic sense – for all parties?
What’s rarely understood is that writing lines of code is the most expensive part of delivering a business application. While the fully loaded costs of hardware have reduced, the cost of writing software is increasing as demand for talent spirals because more businesses transform and trade digitally.
So, if the cost of writing lines of code is increasing, how can we sell it more cheaply as a service?
Essentially it comes down to good old-fashioned economies of scale.
Earlier generations of software were provided by a craftsperson who built bespoke software to exactly fit a clients business. It was a thing of beauty but alas the craftsperson cannot compete with the industrialised edition of the same set of functions.
At the heart of what has happened to drive SaaS economics are;
1. An industrial revolution in the production of software
2. A sea change in how software is delivered.
Much like car production software is now built on automated assembly lines. It’s more reliable, secure, and lines of code can be produced more quickly and with higher quality. This automation is an aspect of DevOps.
The sea change in how software is delivered is where lines of code are now spread across thousands of customers. Quite literally customers are sharing the same lines of code but with unique data sets. But there is one additional piece of magic – the code is designed to be configurable. In much the same was as a car can be configured for trim etc so can software.
How does that concept apply to something simple like Accounts Receivable (A/R)?
Accounts Receivable is broadly similar for every business, so we can agree that A/R does not generally have any unique aspects, but, how it is applied can change from business to business, so let’s look at treating some aspects as configurable parameters.
Standard payment terms are 30 days but some services business will only allow 14 days. Same lines of code – different parameters, different customer data sets. The customer set up will allow them to specify the number of days for payment – it’s not hard coded or baked into how the process works.Our SaaS provider has now written the code just once but hundreds of thousands of customers can use it simultaneously by tweaking a parameter.
But why does this increase speed of business execution?
When a SaaS company decides to build application software they deliberately make the software incomplete. They can never match a craftspersons tender loving care and attention, nor do they aspire to do so.
They write their software and provide craftsmen access to their lines of code so that the core functions can be extended to meet demands that are niche. These are labelled ‘add-ons’ i.e. the add-on to the core code. You may hear the acronym API in this context. This means Application Programming Interface and this is the means by which the craftspeople and the SaaS providers write their separate lines of code to interact with one another in a way that is invisible to the end user.
And this is why the speed of business execution has accelerated. When a business acquires a SaaS it comes with a ‘platform’ fully loaded with all of the ‘add-ons’ businesses need so they can move with urgency rather than wait for the craftsperson to get around to thinking about how to design and implement some small set of features which they cannot sell to anyone else. Examples of a platform are the Apple and Android Store. Returning to our Accounts Receivable SaaS provider they might have a partner that builds an add-on to run a credit check.
The good news for the craftspeople is that they now have a wider marketplace for their wares. Their ability to focus on a small niche product and innovate the hell out if it is their new raison d’etre, while Customers have lower costs and acceleration of business value.
That sounds great, so what could possibly go wrong?
The obvious, and very topical one is Security. Business logic should tell you that the armies of security experts in Amazon, Google and Microsoft will be able to repel bad actors far faster than craftspeople ever could.
Another obvious issue is Regulatory and Legal Compliance? And guess what,the answer is the same as for security.
What about Data integrity?
With a bespoke system, you can build it so that everything is under one roof, but If data is spread across multiple SaaS how do you know if you have one version of the truth? Data in SaaS is easily replicated on a real time basis between SaaS products. Quite frequently these data connectors are sold as low cost’add-ons’.
SaaS software architectures (the logical design for how your business processes will work in software) allows customers to group their business functions around the most relevant SaaS provider and synchronise them. Salesforce for CRM and Workday for HR.
There is also an added advantage of having data spread across multiple systems which means no single point of failure. And SaaS vendors will guarantee uptime through legally binding Service Level Agreements and pay a penalty for breach of contract.
All this sounds good, but it also sounds like I am giving these SaaS people access to my data and I may end up locked in with them?
Many businesses will assess that the life length of their SaaS is sufficiently short that it’s acceptable to be locked in. Others will design their SaaS implementation so as to ensure portability. The upside to being locked in is that you access ‘out-of-the-box’ functionality that includes optimised and codified processes.
So, SaaS allows me to access high quality software, running on high quality hardware, in a secure, reliable manner at low cost and with access to add-ons that I pay for monthly….
Now you’ve got it, and the bill for lunch!
SaaS is well proven. There are no laggards. There are companies with older systems planning to phase them out and replace them with SaaS for two reasons. First to inject urgency into their business operations thereby outpacing the competition. Second to reduce cost.
In general, we advise our clients to start with out of the box processes rather than attempt to adjust the product to fit with your unique and often quirky ways of doing business.
For customer facing processes or those that include your secret sauce – ignore what comes out of the box and consider not using a SaaS in the first instance.
Daysha DevOps is partnered with Atlassian, a leading SaaS provider to improve team collaboration. The Atlassian platform is the craftspeoples market place where our customers search through 3,000 add-ons to meet their niche requirements.