Telco 2.0 event: Technology Insiders' Workshop summary
Most of the Telco 2.0 event is aimed at folk from the commercial side of the business. But we also run a workstream for senior technologists who are increasingly looked upon by the business to help provide strategic direction and product ideation. The world of IP offers fewer natural boundaries than that of traditional telephony, and many of those employees most plugged into Internet culture won't sit in marketing, business development or product management. So the second of our event summaries is from the Technology Insiders' Workshop on the third day.
Our kick-off presenter was Steve Devo, the lead architect of Vodafone's global web services platform initiative. In a way I wish Steve had been given the opportunity to present to the 250 people from the commercial side on day one of the event. We've been talking about partnering and platforms for a long time; to Steve this is the everyday reality of doing business in the future.
His core themes were:
- The immediate future is in "mashups" of core telco network capabilities and IT/data resources with 3rd party applications.
- At the very least you must reduce fragmentation and partner complexity within your own operator group (e.g. Vodafone's global operator portfolio) with a single partnership agreement and common technology. This includes the business processes around the partnership (signup, payments, etc.) as well as APIs themselves.
- User privacy and anonymity are core to your offering. (An area where Internet players fare poorly, especially as they lack access and control to device or billing identity data.) This means building sophisticated controls that prevent different bits of information being handed out and then assembled to form a profile of user location or behaviour that the user would not approve of.
- You need to build a common operator-specified external interface to protect the network, provide vendor independence, and hide the multiple implementations between different networks and network subsystems.
- Don't sit around waiting for a single common industry solution to everything. Just work with what you've got and learn what's useful.
Steve is treading the part I followed (and fell off down a cliff) five years ago at Sprint, so I'd dare to add more key requirements: get senior business sponsorship for your platform/partner initiative; conquer the IT/network cultural divide of who owns the APIs; and treat the partners as your customers and involve them in driving the requirements (so the business hears their voice, not yours). Otherwise, you'll be crushed between the budgetary needs of the next billing system and network upgrades.
After this message, let's talk about money
So, do we really have good commercial requirements for the core voice and messaging roadmap? Judging by the presentations and feedback at the previous Telco 2.0 event, vendors and operators alike have been accused of running a technology-led vision that is weakly aligned to user needs.
I reprised some of STL Partners' research findings on Voice & Messaging which will be appearing in our forthcoming report. Briefly:
- It's about the user experience and meeting that -- not VoIP, FMC, or the acronym of the week.
- We don't have a good idea of what the real user needs are, despite the two core products of voice and SMS generating most of the industry's profits.
- The top three rated features by industry insiders were presence data (i.e. user control over the timing of calls), ease of use (think: Apple iPhone visual voicemail) and enhanced directory services ("address book 2.0").
- When you map the top dozen features as to whether an IMS or new service platform is needed (beyond existing IN platforms), the answer about half the time is "maybe not" or "no".
- A similar story applies to fixed-mobile convergence features.
Several people commented on Martine Lapierre's market statistics based on Alcatel-Lucent's forecasts, and how large they see the IMS market becoming. The smell of obsolescence hangs over much of the 1990s era mobile telco infrastructure. She laid out a number of case studies that showed how the vendors have to play various roles from supplier to business partner. Whilst these network upgrades may not yet be enabling revolutionary user experiences, the flow of sustaining innovation and spending is likely to increase for some time regardless of the telco/IT/Internet collision.
Thomas Welzel of T-Mobile International really stirred things up with his implicit declaration of war on the Internet players who would steal away telecom revenue. He defended the services approach, which is about putting together the end-to-end user experience and proposition: sales, provisioning, application, seamless connectivity, payment, and support. The Internet players are long on application ideas, but short in all other domains. Thomas is ready for the fight - but wishes other operators would have more stomach, as he declares:
...we need to understand that "Collaboration on the back end" is for the benefit of every market participant. A non-optimal joined-up approach is still far way better than the best possible individual solution.
First rule of architecture: make the entrance obvious
Our service architects had no shortage of things to say. It's always fun to have sponsors with diametrically opposed views, and Keiran Dalton of Aepona sure did deliver a contrasting opinion to those of larger established competitors. He's tired of over-complex telecom-specific service delivery platforms that cost a fortune to deploy, require rare skill sets, and often fail to deliver. It says "SDP" on the tin, but inside is a multi-year integration project.
He foresees a revolution in progress whereby off-the-shelf, cheap commodity IT applications servers, message buses, and hardware take over. Integration costs decline, as everything looks like an IT system. What's a "network element" anyway, if they're all just managed boxes of electronics?
We think we heard it out loud: "Every large SDP project we've tried has failed."
Colin Pons of KPN is no stranger to "cheaper, faster, better" in the Darwinian world of Dutch telecoms. Colin's metaphor for the current approach to IMS is this: just because you can hit a nail with a wrench, it doesn't mean it's a good idea. KPN sees its job in a complex, fragmented world of multiple access methods, devices and competing services as just being the guy in the middle who pulls it all together for the user and just makes it work. To this end, SIP and IMS and just possible tools in the bag for smoothing over the many differences between the elements of a real-time environment.
He had some pretty harsh things to say about IMS: fragmented incompatible implementations, poor wholesale services support, barely able to support all the functions of the telephony business model, and pretty hopeless at reaching out to other business models. (Ever had the feeling we're stuck with SS7 and TDM networks for some time to come ... as they're the only thing that really works in the real world?)
Given his message, you half expected Shane O'Flynn from Openet to come both dressed for a funeral, as well as bearing christening gifts. He implicitly spelt out death rites for the traditional network equipment provider. Unless you're blasting photons down glass or through the ether, you're out of business. The world doesn't need you and more. His message - and the birth of a new breed: "new ways of enabling huge volumes of real-time services, at low-cost" again through working to make commodity IT hardware work in the real-time telco environment. (Somehow, I suspect this won't be news to Google. Five nines? Millisecond responses? No sweat.) Shane's recipe:
- Run on standard HW & OS (Sun/HP Unix, Opteron/Itanium, Linux)
- Run on off-the-shelf SW (Oracle/SQL Server, Veritas)
- Exploit the HW & SW properly (Multi-threading model, Multi-core chipsets, Grid Architectures, Virtualisation to reduce footprints)
- Stop being allergic to Open Source software
As a former Oracle tech consultant, I can appreciate that you don't want your system to take a 60 second tea break just because you've switched some backup recovery or logging setting over. The promise to deliver answers from an enterprise database has always been "whenever I'm ready...", which is the space that gave companies like TimesTen (now owned by Oracle) room to grow.
Still, a showdown between the vendor Davids and Goliaths is going to be good for pundits, if not for shareholders.
Who is that at the front presenting? Are you sure? Can you prove it?
We had two presentation on the sunken rock of telecom on which many large projects founder: user identity. It's not glamorous, the technology is either utterly mundane (formatting names and addresses consistently) or incomprehensible (got a PhD in crypto?). Nobody in the commercial side of the business will love you for fixing it, but they'll damn you for all the data quality issues and integration costs as customers try to cross application and divisional silos. I still have recurring nightmares from a digital identity project that involved putting about 2000 post-it notes around a massive conference room to try to match the customer databases of several dozen disparate systems.
Aude Pichelin of France Telecom detailed just a few of the challenges in scaling her Mont Blanc of identity crevasses and treacherous icy cornices. Her message is that you need to scale the mountain by planning to get to the top when you're standing at the bottom, which means looking at identity as an end-to-end issue (with presumably organisational structures and processes to prevent each project going its own way). For example (one I'm making up), in the multi-party multi-service world, anonymity is important. But if you shared the IP address of a user with a 3rd party (maybe just accidentally in a SIP header) then you've exposed that user to being tracked across requests and sessions and personal data being correlated.
Also, from the user's point of view they want a single place to manage their relationship and identity profile, permissions and preferences with the operator. After all, if it's all fragmented, what's the operator's value-add? You might as well sign up for a whole bunch of disparate services from web portal operators and organise your own connectivity and devices.
Telcos are in the identity supply business to internal and partner applications, but they hardly know it. Which is a shame, because messy unglamorous businesses are often rather profitable.
Aude finished with an appeal for operators to get their standards sorted out in this space. Which nearly teed up John Storrie of Nortel, who gave us a briefing on the ITU's new working group on identity standards. This isn't a technology standards effort, as the IT industry has provided us with no shortage of standards to choose from. Rather, the focus is more on common choices of interface and process to enable operators to create interoperable services. (And before you chuckle, remember we can be talking about mundane stuff like roaming.) Maybe Google are right and we'll never pay another bill in our lives as all our needs will be serviced gratis (if you don't mind viewing this short message from our sponsors. And this one, and maybe one more.) The audience was sceptical in the questions and feedback of the ITU's relevance and authority in the area. However, in the real world of billing, mobility and legal accountability sorting out some basic customer data exchange standards and principles could take a lot of friction out of the world of telecoms commerce for operators and their services partners.
If we build it, will they come?
My wife told me to take down the BT posters from our bedroom wall and on the ceiling, but let's face it, BT are tops in our STL surveys of who is getting it right, and remain somewhat of a Telco 2.0 poster child. Rory McKenna gave an extended review of BT's open API experiments. BT are working to package up all that developers need to build applications with just a few lines of code. You, a free tool, a $1000 PC and a $10bn network to play with. They support a wide range of interface standards, making It easy for everyone - and have signed up far more developer partners than they ever planned for. BT is very much "walking the walk" of opening up and becoming a platform enabler for 3rd party services.
We should be hearing more from Rory soon on the blog.
Thomas Magadanz from the Fraunhofer Institute was our final speaker of the day, and detailed the test labs they have built from trialling IMS implementations. What's important about Thomas's work is the incredibly low barriers their environment put between you and building a real-world IMS-based application. The most critical part is OpenIMS - and open source IMS implementation (proprietary vendors please look away now) that covers all the defined IMS nodes and also offers a hosted test bed. You can also just download and compile away your own IMS application server environment.
Unless the average telco engineer and web developer can get his hands on this technology, it's doomed. Not because of anything wrong with it, but because to succeed technologies need to be adopted and integrated with the Web 2.0 world. Does a technology really exist before there's an O'Reilly book on it in your local bookstore?
If they come, will we have built anything?
We rounded off the day with a quick survey. How important are combinatorial services to quad-play operators? These services are ones that cross the divides between fixed and mobile telephony, TV and the Internet. We gave three examples:
- Using the TV to see the caller ID of a caller and the remote control to reject the call if unwanted.
- A virtual secretary application that handles inbound and scheduled calls based on your activities and context
- Escalating instant messaging to voice calling, but using the landline or mobile phones and not PC telephony.
The outcome - our network engineers, whose jobs may somewhat be at stake depending one the answer, unanimously agreed: the users want this, and we're going to deliver it.
How important are combinatorial services to quad-play operators?
Again, thanks all the speakers, analysts-in-residence and participants for coming and taking part.