.comment-link {margin-left:.6em;}

Thursday, June 29, 2006

Report from Intel/BEA IMS seminar

Martin Geddes (master blogger, Chief Analyst at STL and contributor to the Telco 2.0 Report) went to Intel and BEA's IMS Application Delivery seminar at 'The Brewery' in London today. This is his report:

Today’s penance is being conducted via “Death by Powerpoint” in a dungeon at the edge of the City of London, coincidentally not a million miles from the infamous old Newgate prison. The seminar is being hosted and sponsored by Intel and BEA. Their respective jobs are to sell you expensive processors in cheap metal boxes, and very expensive application server software in cheap cardboard boxes.

There’s no 2G, 3G, WiFi, Ethernet or any other form of network connectivity in this seminar room, no power sockets, and it’s hidden down the end of a long underground set of passages. Perfect telecom territory – maybe I’m supposed to be giving my undivided attention to the front. I’m beginning wonder when the dungeon doors will be closed and the IMS community locked away only to be discovered by some future archaeologists.

Anyhow, what we’re looking for are signs that IMS is able to exploit chinks in the armour of the Internet. Are there indeed functions that the operator of the network has an unfair advantage in performing? Does it make sense to locate those functions in a heavyweight IT architecture embedded in that same network? If it didn’t exist today, would we invent it anyway?

I was late to the meeting, but a colleague told me that Intel started out with a sensible presentation describing their focus on the PC (‘ultra mobile PC’) as the key service client. Their over-riding aim is to ‘simplify the user experience’ (for entertainment, communications and information) at home, on the road, at work. And they believe that a hardware platform and strategy built bottom up on ‘Moore’s Law’ is the best way of supporting this at the lowest cost. I’ll come back to this in a future posting…

What is still missing of course, in this seminar and all vendor (and indeed all telco) discussions of IMS, is a clear description of 1.) what is the telcos’ path to growth, 2.) what services are needed to deliver it…and 3.) therefore the spec for supporting technology. (Hence the reason I’m involved in the IMS Services Forum brainstorm in October, and the just-released Telco 2.0 Report which, I hope, for the first time answers points 1-3).

On to BEA. What’s the big value-add of the BEA stack? It looks like they want to buffer the IT developer from the mess of different vendor network implementations. So it’s a hedge against future IP application standards being universally understood in the same way as SS7. I’ll buy that.

They also want a framework to deploy latency-sensitive applications. I’ll definitely buy this one. If you’re running 24x7, and you want to run a backup or extract some management or operations stats, the normal environment doesn’t do this well. If you’re a UNIX hacker, you’ll know you can “nice” a process to a different priority level; but the control is very crude. You can’t “nice” its network load at all.

Next up is they want to protect the resources of the network from being subjected to an accidental denial-of-service attack by the services. This means defining SLAs and policy between the applications, their servers in which they’re embedded, and the network. To the extent that networks define services that are resource constrained (rather than suffer from packet congestion), this makes sense.

If there’s any “convergence” going on here, it’s really the usual story of “displacement”. BEA is an IT vendor, with IT channels and IT values. They say they’re moving into telecom solutions, but really they’re cutting the air supply to the Alcatels and Nortels of the world anywhere up the stack beyond bit transport.

I can believe that a multi-modal application of the future does indeed follow a hybrid P2P and application server approach. Some signalling and session control via the application server and some going direct between the end points (“His mute button is on and he can’t hear you!”). But this will all be done by application service providers outside of the network operator, even if they choose to co-locate in NOCs to reduce latency between the components.

IMS solutions in the end may be deployed more by non-operators than operators. BEA has a better chance of success in this scenario because of their experience with Java virtual machines (theirs runs direct on raw iron with no OS in the way), developer programs, career trajectory of their staff, relationships of their sales staff, alliances, etc.

IMS looks increasingly like relatively sensible technology being badly positioned. The traditional telco vendors want to make $50m sales of kit to operators. BEA are probably more used to $5m sales to corporations. How much will the market for “telecom equipment” shift from operators to systems integrators and enterprises?

One observation: I also don’t believe a lot of the examples they keep giving. Not because it isn’t technically compelling, but because it’s solving the wrong *business* problem. The assets of a telco that are hard to replicate are often “asynchronous” – customer support, retail, billing, provisioning. The real-time services like directory and profile are easily accessible via long-established protocols like LDAP and vanilla web services. No HSS, IMS, HLR, TLA, or Old MacDonald’s EI-EI-O required.

I really like the idea of turning the OSS/BSS into a service rather than being a screen in an application in some dimly-lit operations centre. (Vitamin D deficiency is the key personnel heath risk in telecom.) There’s probably more gold here for the telcos than under most other stones. Even if intelligence is at the edge, without actionable data about the state and nature of the network, endpoints and environment it’s hard to make smart decisions when you start to reach technical and make choices about allocating resources.

I wonder if P2P is a threat to BEA and Intel’s big iron business. Skype hosts 100m accounts and over 5m concurrent users constantly exchanging presence information and making audio and video “calls”. I suspect that their operational infrastructure for their e-commerce store and PSTN interconnect is way bigger than the on-net directory servers. BEA and Intel are making a big deal here on scalability and extracting value from centralised hardware.

Intel are praising their lab efforts on building reference hardware platforms. Yes, there’s a real unresolved issue of what goes “in the network”, but it’s by no means clear that the IMS architecture reflects the P2P reality of most Internet traffic. Even services like YouTube are having to throw vast amounts of money at interconnect because the PC browser and OS has no integration with BitTorrent etc.

Furthermore, we need some terminology that differentiates from vertically integrated “owned and operated” services from the network provider, “externally owned but internally hosted” (“Akamai for streams not files”) and the more traditional Web model of Amazon and eBay where it’s remotely hosted and ‘just deliver our damn bits’. It’s not clear to me what the long-term balance will be between these different deployment architectures.

A lot of people here seem concerned about the handsets and how open they may be. Perhaps there’s an operator opportunity to go a “next-gen unlock code” where you buy back the openness of the device. I suspect the handset vendors I consult to would shudder at the thought!

An interesting little point was that your device turns up on some network and wants to interrogate what services are available (e.g. PSTN-VoIP, push-to-talk, etc.) There are two problems: nobody can quite agree on the semantics of these applications any more (because surely you want to differentiate yours in some way!) and everything is shoe-horned into SIP headers, which aren’t always the most natural way of carrying this data. A by-product of SS7 was that it limited what your PSTN service could do. Even with the constraints of SIP (as opposed to P2P IP) you’ve a lot of scope to invest ways to break interoperability.

Comverse, who typically provide carrier voicemail solutions, are doing a Powerpoint demo (remember: no connectivity in this room, this is telecom) of a premium rate video call as part of a dating service. I suspect my friends at leading dating company Lavasoft (who produce Lavalife and a huge legacy base of traditional phone shag hunting) might have a few things to say on this, having recently announced Skype integration. What value-add from IMS would they perceive? Outside of IMS, what could and should carriers be doing to create win-win models that exploit those marketing, distribution, support etc. assets?

(Actually there’s probably a whole lot in managing privacy, billing and identity that could go on here, but IMS isn’t necessarily the architecture to implement it. Also, the chances of an operator getting a dating app right themselves is very small. So this whole app platform would be bought and hosted by someone like Lavasoft without a carrier getting a look in.)

Do you want to have the network call you with a video call as soon as your kids get home? Comverse think so. In fact, there’s a wonderful history of canonical service examples from vendors (the Starbucks location-based coupon, and onwards) never turning into compelling user-adopted solutions.

And BOOM on cue: A cold snowball question from the floor right in the face – what does IMS add to the two examples? Answer: “Reliability…” (although what he describes is more an interoperability) “…and time-to-market and development effort...” There’s a clear disconnect even in the language and concepts between the two sides of the fence. Comverse grant that IMS isn’t adding much value here because there’s no real application integration. The IMS value-add comes from the management side, maybe?

Is there ever going to be a “PSTN 2.0” or “Universal Operator Push-to-Talk” app application that requires horizontal integration between operators? Probably not on current trends, because anyone on the Net can achieve the same user outcome by not inviting any operators to the application party. If you’re an operator you might use IMS as a toolkit to deploy more stovepipe solutions.

Ericsson are saying some sensible things about trying to hunt for new business models. Ads? Transactions? Subscriptions? Interactions? They define a middle space between “walled garden” and “bit pipe” as “channel provider”. We (in Telco 2.0 Report) frame this as “platform”, which tends to conjure up APIs, but I do really like the more business-centric framing.

Horizontal network model (hybrid during transition from circuit/SMSC world) + vertically integrated distribution model. That means you go to the Vodafone store and all the kit is compatible, supported via one number with no buck passing, and offers some level of service integration (just as Apple do across their product line).

The Ericsson presenter sees that the operator role is in co-ordinating value chains (e.g. preventing fragmentation of handset base – are you listening, Vodafone, Orange, Verizon?), not extraction of the value of all bits passing over the network. I guess that means you move more towards a membership fee: what’s the American Express of network operation?

Clearly he’s struggling, as is everyone, to name any compelling services. Perhaps it’s time to take the hint that operators aren’t cut out to do this, and they’re ultimately selling to the wrong audience. Wouldn’t you see those who’ve been living in an all-IP world for a decade and more as your most natural leads?

Netwise are pitching their hosted PBX and IP centrex solution. Two years ago, I’d probably have been less favourably inclined to these solutions. Now I feel there’s yet another chink in the “intelligence at the edge” armour: that there’s no cost in deploying, managing and maintaining that intelligence. Whilst I see Peerio-like technologies (pure P2P) ultimately prevailing, the transition period is likely to be two decades – plenty long enough to fill your pension fund with intermediate centralised (but not network-integrated) solutions.

A hint to all vendors: the demo the Netwise guy gave was short, sweet and showed managing a call both on the web and mobile handset at the same time. (This is clearly differentiated, say, from what Skype does). No endless powerpoint: show what you do for users if your business is user-facing! Finally someone’s shown me something that is powered by IMS (whether or not it’s necessary is another debate) that actually creates some end-user value.

He claims his business is also not directly threatened by Asterisk because that product can’t scale to the full user base of a network operator (at any sensible cost level, I guess). I wonder what the Googles of the world would think, with their “small, cheap, and lots of them” approach to computing.

The Voice Objects rep had a great quote: “there’s no IMS killer application, but there are killer cost savings”. He was referring to automating call centre transactions, but the wider meaning won’t be lost on readers.

One idea from Cap Gemini was that IMS can be about customer service. When you bolt together transmission and service, you know where the problem is. End-to-end control of device, network and application gives the potential of end-to-end support. I’ll leave you to judge the likelihood of it working as a business proposition, but at least it’s plausible in theory.

It’s a bit chilly from the aircon in here, so I’m pleased to have the laptop on lap to keep me warm and cosy. I can’t see any immediate computing comfort, however, for vendors looking for a replacement business for circuit switches. Good bye old scale and margins, hello thin and lean.

My summary? The IMS weather forecast remains cool and cloudy, but with sunny periods. Much like London’s weather.

Comments: Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?