Service as a Service
In this blog post, Richard Develyn CTO, explores what true service looks like with a software solution and if the SaaS model is truly all it’s cracked up to be.
If you went into a high-class restaurant and ordered yourself a meal, you wouldn’t expect to be directed into the kitchen and presented with the recipe and ingredients and then told to get on with the cooking, even in these COVID-troubled times.
This would, however, be the culinary equivalent of Software as a Service (SaaS).
Take away the recipe and ingredients and you would have Platform as a Service (PaaS). If you were also told that you were in charge of maintaining the cooker and keeping the fridge stocked up, you would now be in the realms of Infrastructure as a Service (IaaS).
So, what do you call it when all that you want is to have the meal of your choice presented to you, on a plate, with knives and forks, and simply be allowed to get on and eat it?
There doesn’t seem to be anything in the IT “as a Service” world to describe such a thing. Personally, I would call it “Service as a Service”. Never mind how it gets to you. Never mind who does the cooking, or where they get the recipe, or what make of water bath they used when they produced that sous-vide steak that still seems to be well done on the outside but raw on the inside. What you want is to satiate your hunger, preferably with something of high quality, and you have neither the time, nor expertise nor inclination to satisfy that requirement yourself.
A big problem for vendors with Service as a Service is that if, say, the steak was undercooked, and the customer was unhappy with it, then the customer would be perfectly entitled to send it back or get their money back or get another steak or refuse to pay. Vendors of Software as a Service are free of this sort of problem because, following the restaurant example above, the customers are basically responsible for cooking the thing themselves and it’s up to them to get it right.
SaaS, therefore, favours the vendor, whilst Service as a Service favours the customer.
Unfortunately, SaaS vendors all too frequently claim that they deliver their solution as a service. This is misleading. What SaaS vendors are actually doing is delivering a toolset for their solution as a service, not the actual solution. The correct implementation of that toolset is left entirely to the customer. SaaS vendors can’t even guarantee that their toolset will suit the customers’ needs. In a sense, they can’t, because the success of that solution will be dependent on the customer using their toolset in the right way, and they have no control over that. Sure, if the software being provided “as a service” is easy to use then everyone is going to be pretty much on safe ground, but if it’s complicated, or requires skill or expertise, then all bets are off.
CloudTrade delivers Service as a Service. Customers don’t operate our software – we do. We take responsibility for it being fit for purpose and for making sure that it works well to our customers’ requirements. Our customers don’t have to worry about the difficulties or idiosyncrasies of extracting data from their documents. We do all that. Furthermore, we do it for a fixed price, regardless of how complicated or weird any of these documents might turn out to be.
Sometimes you don’t mind cooking the food in a restaurant yourself. Fondues are like that, but then they’re not exactly difficult to do – prod a piece of bread with a fork, stick it in the bubbling cheese, swirl it around a little bit and then eat it with a nice glass of wine. Identifying meaningful data from human-readable documents is not the data-extraction equivalent of a fondue, I’m afraid, at least not in the general sense. Project Grandalf (and perhaps we should rename it Project Fondue) is where we’re making inroads in this direction for simpler documents, but our main service remains one where the customers receive their dinners ready-to-eat, and where we look after the kitchen. CloudTrade is, indeed, a true Service as a Service provider.