There were four stand-out conclusions for me. Firstly, the explicit statement that IMS is a long-term strategic investment. This ought to be self evident, but of course we all know that IMS has gone through a rapid curve of hype and deflation. The optimism about IMS providing a much needed fillip to the industry that emerged a few years ago rapidly grew out of all proportion. As Marc LeClerc from Ericsson noted, internet time may be a useful term in some contexts, but it isn’t for IMS, and to apply the same time expectations that people applied during the dotcom bubble are completely unrealistic. Of course, that is precisely what the industry did and is now paying for it. But long-term in this case means for the next 10 or 15 years.

It’s clearly not enough to expect IMS to fly on the basis of either the technology vision or the initial service rollout alone – a point I heard eloquently made in 2005 by a veteran of the IN world, who argued that much the same mistakes had been made at the outset of that era. Plus ça change…which brings me to the second point. In Paris, this issue was explicitly addressed and tied to the strategic dimension. That is, several operators argued that there is a defined number of services that would be required in order to build the business case for IMS. Further, the business case would work provided that the operator stuck to plans and executed this strategy to build a level of critical mass in their market.

In fact, the number of services that were identified was relatively modest, with a range of 3 – 5 providing some kind of consensus (granted, from a limited sample of subjects). That doesn’t sound much given the potential of IMS to be a platform that can enable a huge range of services. At least it should be achievable. If not, why bother at all?

The third point to note was that the arguments that have sometimes been apparent regarding the respective roles of IMS and SDP seemed to have reached a quiet resolution. At previous conferences, questions have often been framed to position IMS and SDP as competing technologies and, to some extent, people have been happy to promote this conflict. This was definitely absent in 2008. In numerous presentations, I saw diagrams that showcased operator’s SDPs. But, the crucial point here is that the service enablers that feed into the SDP to enable it to support the (hopefully) wonderful array of services (whether traditional telco or web 2.0-orientated) were provided by the IMS. Thus, IMS is seen in what is, in our opinion, its true light – as a standardised means of exposing service enablers to applications. It doesn’t matter if these applications are hosted within an operator’s network, or outside, it’s a vital part of the overall SDP framework. And, given the complexity of the network information that needs to be available to applications, it needs to be a pretty demanding beast. And perhaps not a malicious squid.

So, a more realistic view of IMS seems to have emerged. It’s not a panacea, but it’s a solution that will probably be at the heart of operator strategies for many years to come. It will defintely continue to evolve and may change in some aspects, but the basic architecture offers much. It’s just that it isn’t a quick fix – it needs investment and development to achieve critical mass. And there’s probably a good deal of work to do – as Telus noted, there’s some way to go before vendor interoperability is really achieved. But, the IMS vision is one that is completely complementary to the overall SDP framework an operator adopts; indeed, it’s an essential element of the SDP strategy. You can’t build services that really leverage the network unless you can access core capabilities of that network.

Which brings me to our final point. There were several presentations that highlighted the APIs that certain operators intend to expose to third parties – Telefonica’s presentation really stood out here. These APIs expose capabilities from the operator network that are unavailable from other sources. The idea, or so it seemed to me in the case of Telefonica, is not to compete with the social networking sites or over-the-top providers, but rather to expose capabilities that further enrich applications that are emerging, presumably so that Telefonica can extract some value in tandem with such application vendors. Is IMS necessary to support these APIs? Probably not – but it would be extremely hard to envisage how every operator, particularly those with multiple networks, could create their own infrastructure for capturing and exposing those capabilities. They probably could, but it might just end up looking uncannily like IMS.

For the larger network operators, having a centralised service infrastructure that offers common assets and resources; standardised interfaces; the ability to host multiple applications and deliver them across network boundaries to any connected user; expose various capabilities for both internal and external access; and allow clear consistent charging for everything is compelling. In the opposing camp, the whole things smacks of protectionism on behalf of the network operators, confronted with a new challenge from nimble internet arrivistes, such as Google, Facebook etc. Further, the architecture is unwieldy; standardisation will inevitably creep towards vendor-specific implementations; and it’s just IN with bells on. Indeed, according to some bloggers, the whole thing is one immense menacing squid, seeking to smother competitors and consumer choice in its dreadful tentacles.

I attended a useful seminar recently entitled mashup. More details can be found here: http://www.mashupevent.com/  I must admit, I was rather new to the concept of mashup applications. I now know that it’s simply another term for the sort of blended applications that we have been discussing since the IMS industry started to gather momentum. Only, it’s the radical folks from IT and web 2.0 who have captured media attention and the imagination of the industry by coining the term. So, a mashup application combines various capabilities from different sources and delivers new functionality by building on these. A key differentiator is that APIs are available to allow more or less any web developer to pull a mashup together. Now it seems that standard telco capabilities such as voice, conferencing and presence need to be added to mashups to help create even more value. This is all well and good, but is also precisely what we have been talking about in the IMS camp for several years: if the interfaces available to third party developers are presented using the right (i.e. familiar and less complicated) APIs, telco enablers (or service capabilities) can be leveraged to create new and interesting applications, or, to use the new terminology, mashups. The point I and many others made more than two years ago was that we simply didn’t know what kind of new applications would become available. But this was precisely the point: neither did 3GPP nor anyone else. IMS is about providing the potential to create any application that can be conceived. Perhaps mashup activity is the first stirrings of life in the vast pool of internet developers that we all hoped might be brought to bear on the problem.

What was interesting about the mashup applications on display at the event – and most others that I have heard about – is that the majority are targeted towards ordinary consumers. And yet, telcos are supposed to be dreading the impact that these applications could have on their revenues. We have to ask – where’s the money in many of these sites? For social networking, advertising and promotion seem to provide potential revenue streams. But, what about the enterprise segment? This is a vital source of revenue and one that has largely been overlooked up till now. And yet, as far as I can tell, many early IMS deployments are focused explicitly on this segment, with IP centrex as the leading application. Whisper it quietly, but perhaps the telcos have known what they are doing all along. Perhaps the mashup camp has been so focused on liberalisation and net neutrality, as well as the dinosaurs of the telco world that they haven’t recognised this as a segment with real financial potential.

I saw one application in particular that caught my attention. This was targeted towards estate agents. Agencies could provide a specific number to be displayed on the sale board that stands outside each property that they are marketing. Prospective buyers can dial that number and the agency is able to direct the call to the agent responsible for that particular property. The application also integrates with the estate agents CRM and adds CTI capabilities, so that agents can be alerted to missed calls, with the additional bonus of being able to determine the property about which the calling party was enquiring; or have news of such enquiries diverted to their mobile phones. This application has been created by SMS Card and more details can be found here: http://www.smscard.com/?p=31

The application can be integrated with the client’s existing IVR system, but could also be offered in a hosted environment, servicing either large chains of agencies, or multiple companies. This is the bit that interests me from an IMS perspective. What if a service provider offered enablers to companies such as In Property, allowing them to access common resources within the framework? In this case, In Property could act as an ASP and connect to the MRF of an operator’s IMS platform. Isn’t this what IMS can achieve? Doesn’t this extend IMS into the mashup world?

If mashups are to be significant revenue generators, the addition of capabilities such as speech (including ASR and TTS), conferencing, presence, etc (all of which can be offered in a standardised fashion via IMS)es will be attractive, as well as integration with SMS and other messaging systems. At present, mashups may well attempt to offer these capabilities, but will do so in a variety of ways. IMS could be the missing link to merge the two worlds.

But, I would go further and suggest that the really important lesson here is that even if an operator chooses not to deploy IMS, the use of IMS-standard components will yield benefits in terms of simplifying integration of such new applications. Thus, we may see only the largest operators choosing to implement a complete IMS solution, but smaller ones selecting only the components that make sense. These can then be leverage to add value to all manner of applications, classical, mashup, or otherwise, and we may even see the value of IMS being acknowledged by both the telecoms and IT communities.

The lesson for vendors? Make sure you follow the standards; you never know when they might provide a crucial competitive advantage. The lesson for operators? Implement whatever SDP you want, but make sure that you use the useful bits of IMS that make sense, and offer connectivity via suitably abstracted APIs to third parties that can do innovative things that you haven’t considered, but which leverage your network. The lesson for the mashup guys? Don’t write IMS off – it could be the best and simplest way to add telecoms enablers to your imaginative services.