Speaking Engagements & Private Workshops - Get Dean Bubley to present or chair your event

Need an experienced, provocative & influential telecoms keynote speaker, moderator/chair or workshop facilitator?
To see recent presentations, and discuss Dean Bubley's appearance at a specific event, click here

Monday, October 06, 2008

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.

4 comments:

Sean said...

Sorry I missed you at the IMS RCS event Dean. Always enjoy your thoughtful perspective on things.

Just wanted to say: I entirely agree. I think you clarification in here is very useful. On the positive side (for operators) I especially agree with your last sentence. I said something similar the day before at the event (to operators): try to think about things you have that are really unique and possibly useful:
- could I have an alert the first time someone I know/care about uses their phone each day (with their permission)?
- could you mine my call and SMS data and extract my social graph (with my permission) - before SkyDeck does it all for me?
- mine the text data for a city or town and extract a real-time "social zeitgeist" (permission-based) ("Tonight Dublin is mostly discussing Strictly Come Dancing")

And so on.

Operators have lots and lots of great data - activity-based, real-time, and often social. There are several ways to make that data come alive and use it either for defensive purposes (stickiness) or find actual ways to make money around it, without trying to charge repeatedly for something that as you say, people innately have a feel for being wrong.

Cheers, Sean (sos "at" dial2do "dot" com)

Anonymous said...

Hi Dean,

A couple of years ago (2003) we talked to a certain Telco about an "LBS" idea we had.

We had a simple idea of telling the user where they were, using LBS. Nothing fancy, but this was when LBS just got installed in their networks. We suggested to them to offer it for free as part of the service and thus differentiate themselves in terms of not being "just a bitpipe".

They liked the idea but informed us that it was not possible because the model they had from the Hardware vendor was actually a pay-per-use model. They implied that they could not offer this service because they would lose money on every query to the "LBS box".

Do you have any data suggesting this model has changed? and that now it is simply:" involve buying a standard application server from a vendor like Ericsson or BroadSoft, hooking it up, and then turning the handle."?

My perception, back in 2003, was that the purchase model of the MNO, was stopping them from offering a friendly model to the end-user. Any thoughts?

Dean Bubley said...

Sean - thanks for your comments. Making the data "come alive" is an excellent way of phrasing it.

Edsard - I think that comes down to the particular revenue model chosen for the particular "box". I picked Ericsson & Broadsoft because of their involvement in IMS & VoIP rather than LBS - I don't think most carrier voice switches are charged by vendors on a pay-per-use basis.

I suspect that LBS may have been purchased on that basis because the operator wasn't sure exactly how much it might be used... and therefore chose a payment method which didn't scale very well.

Anonymous said...

A ot of that "unique" data isn't that useful. Social graphs, for example, are total boll**ks. You find out you call girlfriend and your mates most often. Wow.