Software as a service? The difference between services, apps, features and functions

A post by Ajit Jaokar over at Forum Oxford (sign up if you're not a member - it's really useful) on low-cost LBS (location-based services) applications for the iPhone has chimed with something I discussed at last week's IMS 2.0 Rich Communications conference in Amsterdam.

Ajit mentions something called Vicinity:

"Vicinity (£1.79): Takes advantage of the iPhone 3G's GPS to provide one-tap access to information about local services and amenities. It will even pull in relevant Wikipedia entries and Flickr photos."

And he comments that this is essentially a one-off payment for what many might have hoped might be a subscription or per-use "Location Service". Something like "where is my nearest XXX", or "what's interesting nearby?"

This fits with my general belief that far too many communications companies think that they can somehow turn an application (or even just a feature or a function) into an ongoing, billable service. So thinking about the IMS world for a minute, I've heard various people describe "Presence" as a service. It isn't. It's a function, a basic building block of a communications platform.

In brief:

Service = something delivered as an intangible capability by a service provider, either through subscription, one-off payments, prepaid credit, or perhaps some sort of new two-sided business model. Examples include voice calls (generally), SMS, or for that matter a flight by an airline, or an audit by an accountant.

Application = a standalone piece of software, installed either on your device or used remotely on a server / the web. Usually a one-off licence payment, perhaps together with some sort of maintenance fee. May be free.

Feature = a value-added component of a technology platform. Generally not paid for separately, unless it's something that can be "unlocked" after the initial purchase. However, its presence can help the platform command a premium price.

Function = a core element of the technology platform. Included in the base purchase cost, however that is defined.

Yes, there's lots of grey areas here, especially on the web. And there's the whole move to SaaS (Software as a service) or even Hardware as a service - basically hosted applications, often paid for with a subscription fee. Salesforce.com is the obvious example, as are various managed-email offerings.

But coming back to the original LBS example, and also perhaps things like Skype, there's a counter-trend coming the other way: *Service as software* (and also, Service as Hardware).

Why pay a service provider to provide "Where is my nearest" capabilities, when you can do it yourself with a one-off payment for a capable piece of sofware? Why pay a service provider for voice connectivity when a (free) piece of software can do it for you? Why repeatedly pay a service provider to tell you where you are, when a cheap GPS chip can do it for you over and over again for a fixed price?

Clearly, there are instances in which both SaaS and "Anti-SaaS" make sense (Grammatical sidenote: palindromic acronyms are so inconvenient....). Or HaaS / SaaH.

But, thinking about it, I reckon that when it comes to services, customers tend to have an innate feeling for which things have a high fixed cost component, and which are more variable-cost based.

It feels inherently OK to pay for services with a high variable cost - flights (fuel), TV (content acquisition), 1920's telephony (manual switchboard operators) or those in which you perceive that there's a lot of hard work being done centralised components, even if they are "fixed" cost items (eg Internet access piping lots of data around from different places, or electricity from wind or nuclear facilities).

But I reckon that consumers can sense those "services" which essentially involve the provider "turning the handle" on a fixed-cost system, which has probably paid for itself already. People innately *know* when their extra service cost "goes straight to the bottom line", and feel ripped off. They'll jump at the chance of replacing that service with hardware or software.

This is a problem for many LBS offerings - they're "turn the handle" propositions: "We've got a big map & we'll charge you each time you want to look at it", or "We've got a big map and a directory, and we'll charge you each time you want to find your nearest XXX", or "We've got a big map and a set of tourist guides...." .

You get the picture.

Quite a lot of IMS "services" risk falling into the same trap - like interconnection with Internet IM systems from mobile phones, for example. Hello? This isn't a service - it's a simple feature or application. It works beautifully on PCs with very simple bits of software. Hosted IP-centrex? The same - it's attempting to replace a working product (or application like Asterisk) with a billed service.

Yes, in both those cases there are certain instances where the SaaS approach makes sense - if there's lots of maintenance involved in doing it yourself, lots of complexity involved in configuring & setting up software and so on.... then yes, it makes perfect sense to pay a service provider to deal with it for you. But replacing something easy or "plug and play" with a billed ongoing service is (often) a waste of money.

One delegate at the IMS conference also raised this, asking me a question of what phone manufacturers will put next into handsets, that would cannibalise possible service revenue streams, and what could be done about it. Nokia's put GPS and maps into phones, he complained, which had just trashed their LBS business models. I added that they also just acquired OZ Communications (it does email and IM) and launched "Comes with Music". Yet more examples of Anti-SaaS, or SaaH.

The bottom line here is that many telecom services (legacy, IMS, SDP or whatever) involve buying a standard application server from a vendor like Ericsson or BroadSoft, hooking it up, and then turning the handle. The operator is essentially taking someone else's generic application, and trying to make it look like a service. Spot the problem?

Trying to sustain long-term service revenues by reselling someone else's white-label application will always be a loser - over time, that application will become replicable on the end user's own device.

The solution lies in customising those applications, packaging them in innovative ways, blending them, managing them and so forth. Or, better still, integrating them with something you have that's unique - intelligence from your customer database, capabilities from your network (not just location, either), ability to see and manage devices and so forth.