Light Reading analysts latest report is about Telco Mash-Ups and the threat or opportunity of this mode of service creation to Telcos. As some of you know, I set up the “Mashing Room” within Motorola some time back in order to explore the possibilities, so the report grabbed my interest. My approach towards technology (and most other stuff) is to examine claims carefully, try things out and see where the real issues are, thus separating the chaff from the wheat, or the hype from the reality.

The mash-up idea in Telco is not new. It is essentially part of the Parlay vision, although trendy words like mash-up don’t tend to flow from such projects. Moreover, the viscous world of Telco-IT convergence has meant that this pathway to service creation has remained very steep and winding. By the way, a good introductory text for Parlay/OSA is the book by Bennett et al.

There are a number of possible architectures for Telco mash-ups, most of which I have proposed to various operators in workshops. In general, whilst most operators will understand the new frontier that might be open to them, there is usually resistance to the idea. This is based on the usual suspicions, such as dangers of “opening the network”, quality of service across multiple platforms, lack of coherent business models and blurring of customer support accountability. Some of these are excuses and some are very real, but overall the usual lack of creativity is often the underlying problem. These days in operators there are a good deal of people tasked with being innovative and creative, which they might well be and often are. However, the culture of innovation must embrace risk, which is the part most difficult to find in traditional businesses.

One approach to Telco mash-ups is to take some service that the operator has on its portal, such as an address-book back-up service, and to open it up with an API. “What for?” You might ask. Well, this is often the problem. There is no answer other than to create attraction, which isn’t a parameter so easily entered into a Telco biz plan or spreadsheet. However, it is useful to understand what might happen. A lot of clever Web programmers will start to come up with their own uses for the API and start building new services - mash-ups. Some of these might be useful, like merging phonebook data into webmail contacts, which is easily done.

Going in the other direction, the operator could do something like mash-up the address book with your LinkedIn contacts. A common problem we all face is who to call about X, where X might be a job heard about on the grapevine or any of the other reasons that LinkedIn users have when requesting introductions via a 3rd, 4th or even 5th party. I could tap in a search word on my mobile, like “Acme” and my address book would highlight all my contacts with friends at Acme. I select a contact to see who he or she knows. If it looks useful, I ask the intermediary for a phone introduction, which they get on their mobile. If they accept, then the person from Acme appears as a new contact in my address book. I don’t have their details, but I can place a call or text them without them having to reveal their number, if they prefer to retain privacy. There are many variations on this theme and many ways of implementing such a service.

The extent of mash-up possibilities is much wider in the Telco system. If the operator is also running an all-IP core network, most likely IMS, the service can access telephony and messaging services within the same programming environment. So, if the operator is running SIP/SIMPLE instant messaging (or “super-texting”, depending on how they’ve marketed it) then it is easy to update presence and use IM within the same mash-up, place 3rd-party calls and so on. An early mash-up attempt I worked with was kicking-off conference calls via SIP based on what’s happening in a Google Calendar. This is just one example of telephony/web mash-ups. Another is my famous push-to-taxi example, which mashes location, presence and push-to-talk.

IMS itself is more than capable of supporting mash-ups across SIP services. These tend to be called combinatorial services, which is a dull name for mash-ups, but telco types can be forgiven for their lack of imaginative names, although this is the era of colourful wordplay like Lucent and not AT&T, or just Bell.

Business models and business advantages can be posited for various mash-up scenarios, I am confident of this. However, it’s not as if the next texting success can be so easily conjured up and positioned as a sure thing. Eventually operators have to stand back and ask what is the best pathway to the next area of growth and then take a bet. The promise of mash-ups and agile release-as-you-go programming techniques so well rehearsed on the Web is potentially significant. Mobile applications development continues to be a relatively niche activity and needs to become more mainstream. Opening up to the world of mash-ups and the plethora of motivated programmers who simply like to do interesting stuff is, in my opinion, well worth pursuing.

In terms of technical challenges, then the remaining hurdle is the handset. Early IMS applications were hampered by a lack of handsets with SIP/IMS connectivity. The IMS ecosystem has often been compared to the Web. In principle, the all-IP client-server approach of SIP is very similar to HTTP, which was, after all, the inspiration for pursuing the SIP model. However, the analogy quickly breaks down because Web is essentially all about the browser/HTTP pairing as a universal client. There is currently no such thing in SIP/IMS. I have discussed many times before the potential for bringing SIP into the browser and remain convinced that a hybrid programming model is possible in the handset as well as in the server (e.g. JAIN SLEE). Various approaches are possible, but the recent release of Google Gears is an interesting development, not because it has anything to do with SIP, but because the idea of intermediate logic between the browser and the server has entered into the mainstream. It is an old idea, but as we all know, the tipping point for an idea can come a lot later, usually after a lot more people start scratching their heads and ask “why can’t we do that?” Usually, the answer is “we can - we did it already”….”really? let’s do that then” and so the idea is reborn and takes hold in our imaginations.

As the Rage Against the Machine song goes…”not long, not long…” (is that band name apt? - often feels like it!)

Technorati Tags: mash-up, Parlay, Telco, LinkedIn, IMS, SIP, Google Gears