Summarizing day two of SofNet.

Panel session, "How Can 21CN Help Make Customers Successful?"  was a who's who on UK telecom executives with John Cunliffe, Ericsson; John Frieslaar, Huawei; Geoff Hall, Nortel; John-Paul Hemingway, Ciena; Phil Dance, BT; David Soldani, NSN; Andy Stevenson, Fujitsu; and Phil Tilley, ALU.  With so many suppliers in such a public forum, we were not going to hear anything interesting.  A good question was "What are the top 3 enterprise services enabled by 21CN."  The answer was a general description of network IT Services and cloud-computing; which are available without 21CN.  This unfortunately became a theme for day 2 of the event, lots of discussions on architectures, potentials and capabilities, but a dearth of discussion on what the innovators (web2.0 companies) want and what are the specific services.

KeyNotes

• Helmut Leopold, Telekom Austria, discussed their SDP experiences. Good review on the challenges facing a small operator, especially on processes which are "90% of the headache" in any network transformation or new service launch.  As discussed in yesterday's weblog entry operational efficiency is the best understood part of the SDP business case: Helmut mentioned new product launch effort reduction of 70%, and TTL (Time To Launch) reduced from 9 to 5 months. An important point he raised was the SDP enabled greater transparency to understanding profit management, however, a critical issue is the BOSS (Business and Operational Support Systems) organization tends to mask such data to maintain control, hence he recommended the need for "aggressive centralization."
• Sally David, BT.  Discussed next generation wholesale business models.  Covered a number of examples of wholesale business models such as outsourcing voice (to Virgin media), managed access (mobile backhaul), QoS (Quality of Service), and security.  Good focus on the capabilities operators can offer to corporate customers and service providers.  

Panel Session: Leveraging SOA to Achieve Flowthrough for IP-Services

• Brian Buggy, Amdocs.  SOA is just a tool, need to define the model that needs to be common across all services whether mobile, cable, broadband or internet.  Upon receipt of an order it's then decomposed, designed, implemented and tested.  Critical step in the decomposition process is the mapping of customer facing services to resource facing services.  Highlighted the gap that exists in the TMF SID (Tele Management Forum Shared Information/Data) on the level of decomposition to enable re-use of resource components across services, else operators end up rebuilding silos within a SOA framework.
• Francesco Caruso, Telcordia.  Described how the core capabilities of SOA: semantic (common language), transport (common orchestration) and legacy wrapper can be applied across the product lifecycle (CRM, order management, charging/billing, provisioning/activation and service assurance).  This reminded me of the the approach taken by AT&T U-verse, which is a great case study on using SOA within a mixed (NG and legacy) environment.
• Biru Chattopadhayay, Tech Mahindra.  SOA is a little like SDP in definition, it depends upon the user.  Challenge that there is no agreement on what comprises an SOA-compliant implementation, so SOA is not generating harmonization given the variety of implementations, platforms claim SOA compliance, when in practice significant integration is still required.  SOA is not a magic bullet, still requires good design and central management.
  
• Bob Titus, Netcracker.  Today results of SOA implementations on cost saving, flexibility, improved TTL have not met those seen in other industries.  Bob highlighted the model-driven architecture gap, as per Brian Buggy's presentation.
• My take-away:  What should by now be common system across most operators remain bespoke.  I'd argue the problem is not technology, as businesses in other industries have achieved significant commonality in their systems thanks to SOA.  Rather the operator's BOSS organization guarding silos of information to maintain their organization.

Panel Session: The Reality of Convergence: Operator Experiences

• Thibaut Roussel, Orange.  Summarized Orange NeXT (New Experience of Telecom) strategy and localization issues across its OpCos (Operating Companies).  Unik (Orange's FMC service, c.f. BT Fusion): 500k customers in Feb '08, 25% of customers use at home and in the office (SME is a target segment), main selling point for customers is unlimited calling  that has resulted in an additional 67 call minutes per month.  Business Everywhere (remote intranet access): 910k users (600k in France) as of Feb '08, 24% annual growth, targeting MNC and plans to expand to SMB and SoHo segments.  
• Paulo Tavazzani, Fastweb is an all-IP triple-play network based in Italy.  Deployed an integrated CPE (Customer Premise Equipment) for converged voice, video, and data for all devices, including mobile, in the home.  No plans for IMS, soft-switch is good enough, will only implement IMS when business case justifies.  Fastweb are the only convergent MVNO in Italy, hence focus on converged services to differentiate from other MVNOs and try to keep calls on their network as much as possible to manage costs.
• Take-away: Good examples of service innovation that focuses upon the importance of providing significant customer value to stimulate adoption, even though the technologies are far from mature.

Overall Summary  

• The telecom industry is unfortunately still too 'fat and happy.'  For example Verizon announced first quarter results yesterday where net income rose 10% to $1.64 billion from $1.5 billion, and sales rose 5.5 percent to $23.8 billion.  Isn't the US in a recession?
  
• Most of the discussion at the conference is on capabilities and potentials; hence the SofNet ideals remain trapped between the CTO (who sees the strategic threat) and the CMO (who says, "Show me the money!").
• Recommend each operator identify for their specific situation 5 or 6 services they can easily enable and just do it to work through organizational issues in opening the network, because its still another 2 or 3 years before they'll have openness cracked and the strategic threat will have materialized into their financial results by then.
  

SofNet brings together three of the main drivers in the telcom industry, NGN (Next Generation Network), Web 2.0 and the telecom service layer (also known as the SDP, Service Delivery Platform).  Now when it comes to the definition of SDP, I'm usually reminded of this quote from "Through the Looking Glass:"
`I don't know what you mean by "glory",' Alice said.
Humpty Dumpty smiled contemptuously. `Of course you don't -- till I tell you. I meant "there's a nice knock-down argument for you!"'
`But "glory" doesn't mean "a nice knock-down argument",' Alice objected.
`When I use a word,' Humpty Dumpty said, in rather a scornful tone, `it means just what I choose it to mean -- neither more nor less.'

So let's see what we learnt on the definition of SDP on Day One.

The morning session I attended was entitled "Industrial Revolution 2.0: Are Service Delivery Platforms the New Production Line?"  Summarizing the presentations and discussion:

• Angelo Morelli, Accenture.  Highlighted the importance in how services are created as Web2.0 principles of lightweight programming models, mash-ups and continuous beta gain main-stream adoption.  Positioned SDP as managing the complexity of aggregating the business models between network operators, service providers, VAS (Value Added Service) aggregators and Web 2.0 companies.  Also positioned the unified user control panel (an element of the SDP) to manage the complexity of transferring content and services between devices.  The unified control panel is one of those technically feasible capabilities, but it's practicality dubious, e.g. iTunes goes onto the iPod easily thanks to Apple, for those geeks that also want to have their MP3s on their Sony PS3 there's a number of free ways from using a USB to setting up a media server on the PC.  Here the SDP is defined as providing business and content adaptation between players in the value chain.
• Giorgio Ramengi, H3G Italia.  H3G Italia has 8M customers, 39% UMTS market share in Italy, and 800k (10% penetration) Mobile TV customers.  H3G has used an SDP over several years for its m-sites that enable 3rd party services on their portal.  They used the SDP for the launch of the MobileTV, which took only 6 months from license grant to launch.  Using an SDP enables trial within 2 months, free-to-air launch in 3 months, and full PayTV launch in 5-6 months.  They currently achieve 10% of mobile TV revenue from advertising.  H3G provides a realistic and focused SDP application note.
  
• Jonas Wilhelmson, Ericsson (Drutt), explained the emerging Multimedia Marketplace composed of the following actors: Media, Customers, GAMeY (Google, Amazon, Microsoft, eBay and Yahoo!), Internet Services, Advertisers and Operators.  The role of SDP is to hide complexity in this marketplace, speed time to market, and lower costs.  Quoted data from H3G Scandinavia that 70% of customers access the operator's portal and 15% ARPU comes from VAS.
• James Steadman, Oracle:  Gave the Oracle pitch on the SDP being composed of OMA OSE, J2EE application server, and SOA for integration.  Gave an insight into the CXDN (Communication Experience Design Notation) they've developed with BT, and will open source later this year.  CXDN re-uses SOA tools from the enterprise, to make it easy to create applications agnostic to network and easily integrated into an enterprise's business processes.  The CXDN has significant potential for the industry, and the addressable market is where telco's can provide significant immediate value through the Telco API.
• Richard Mishra, Amdocs.  Highlighted the important of SDP's (Service Management Layer) awareness of the resource layer (network capabilities, e.g. QoS over a RAN or DSL link).
  
• I asked a question, "If the SDP saves money and enables new services, what are the figures?"  Broad consensus on opex savings of around 50%, which is in line mt projects, perhaps even on the conservative side.  No commitment to ARPU uplift potential, on that I have a weblog entry The Telco API: Potential to raise ARPU by up to 36%
  

Afternoon Key Note

• Matt Bross, BT.  Gave the usual world-class inspirational pitch.  Highlighting the shift in power to the user, increase in complexity and importance of green issues.  Gave a great example on the success of BT TradeSpaces in dramatically improving BT's relevance to the SMB (Small Medium Business) segment.  I often use TradeSpaces as a case study on how operators have a role in communities beyond simply enabling access to Facebook.
• Bhaskar Gorti, Oracle, provided some much needed figures on the reality of an operator's business.  Quoting observed SDP savings of: development cost and time reduced by 50%, reduced IT support cost of 30%, RFT (Right First Time) improvement of 30%, TTL (Time To Launch) improvement from 30 days to 1 day, and lowered provisioning costs by 30%.  He made and clearest statement of the show, that the SDP is about improved productivity (operational performance).

Overall, I still feel like the "Through the Looking Glass" quote is relevant in the definition of the SDP.  However, there is broad consensus and specific numbers on the process improvements provided by the SDP, what is lacking is the same specificity on the services.

"But shouldn't our suppliers be building the developer programs?" I hear some operators asking. However, infrastructure suppliers make money by selling boxes, software licenses, maintenance and support; those suppliers do not understand the end customers as well as the operator. If they do, then the operator will likely not be independent for long. There is a new category of 'Application Aggregators' that bring a menu of applications, e.g. uLocate and Useful Networks aggregate location based applications; and are dependent upon mutual service success with the operator, not selling boxes or software licenses. The bottom-line is all operators will need to combine the application eco-systems of infrastructure and handset suppliers, application aggregators and their developer communities. Only those operators in a monopoly or have resigned themselves to be a utility bit-pipe provider need not worry about such issues.

In researching application developer communities across a number of industries, reviewing with the creators and community members the successes and failures, here are some topics to consider if an operator decides to build a developer community:
 
Audience:

• Know your geeks (application developers). For many operators there are local SIs (System Integrator) and VARs (Value Add Reseller) already solving the customers' problems, this is a critical group to bring on board. This generally addresses the SMB (Small Medium Business) segment, but there are also local developers applicable to other customer segments, they're not all based in Silicon Valley or LA. And localization will become critical for an operator's long-term success against GMAY (Google, Microsoft, AOL and Yahoo!).
  
• Know your early adopters. These are generally high spending customers that will trade some of their time for exclusive access to the latest applications and have their opinions matter.  This is of great value to geeks as they lack customer access that operators can provide.

Tools and Education

• The program needs to use the latest protocols, environments and community tools. Check out Saleforce.com's Appexchange; and Orange's Widget, picture sharing and OpenID APIs. To win, an operator must educate (marketing); to educate an operator must speak (blog); to speak an operator must do/show (code examples and success case studies). The more code examples the greater the addressable pool of geeks, because less able but perhaps more innovative geeks can then "cut and paste" capabilities together.
• Do not require registration or login to educate, only have registration if the geek wants to make money. Beta programs (without a clear path to cash), NDAs and legal documents will kill any community no matter how large the operator.

Communications and Marketing

• Community communication by the operator needs to be made by Geeks, e.g. bloggers, writers; IRC (Internet Relay Chat) / wiki / forum addicts; regular conference presenters that draw a crowd; and have a track-record in writing code samples and helping others geeks.
  
• Have a "Geek Advisory Board" with expertise in the platforms, customer verticals and known to the geek community.
  
• Sell your best geeks, others will follow. Communicate success stories from the community's launch. Contextual application search to help customers find preferred/certified applications that are relevant to a customer's particular circumstance is vital.

Metrics

• Program must be aligned with the operator's overall business goals. Metrics include things such as number of new geeks, number of downloads, number of active developers, number of transactions, revenue generated from APIs.

Biz Model

• The business model must be baked into the API. Ultimately, the Telco API is just a big business development deal. If the Telco API helps geeks make money, then so does the operator.

Integration

• The application developer community should not be owned by the CTO. After building the brand and the network, the application developer community is the next most important leg of an operator's business. It must be owned by the CEO, and integrated into Marketing's processes, so the innovations get out to the customer and are effectively monetized by the operator.

The above topics may appear obvious in building an application developer community, but the challenge is getting them simultaneously implemented.  Have a look at the many developer communities being launched against these 6 topics. An operator's application developer community is not a lab's project, nor something that can be released as a Beta; it's a core business assets, on a par with brand and the network, and must be led from the top.

HomeCamera enables people to securely see what's going on at home without being an expert in geeky stuff like DDNS (Dynamic Domain Name System), NAT (Network Address Translation) and port forwarding, which are generally required for the home surveillance solutions on the market today.  HomeCamera aims to be an easy-to-use home surveillance system, with any webcam, any PC, and any Internet connection; targeting the average PC user.  The service is live and currently free because its in beta.  Once launched it will remain free with ad-support, there will also be subscription models that add capabilities and remove the advertising.  When I talk to operators about this simple proposition the common refrain is, "We thought about doing just that, we just never had the time."  HomeCamera is a spin-out from M1 (Singaporean mobile operator).

Google averages between 100k-200k relevant search terms per week on home security and monitoring, so there's definite customer demand.  The estimated number of global broadband homes with webcams in '06 was 60m according to Logitech.  IDC estimates 21m webcams will be sold in 2008 alone; average annual worldwide growth rate of 9%.  More importantly to the HomeCamera proposition there were roughly 600k network cameras sold to homes in 2006.  A network camera is a standalone unit that is used for surveillance not web chat.  For example, D-Link has added HomeCamera support into its 2120 WiFi network camera.

The use cases include monitoring one's home, kids, the elderly, pets, and domestic help.  I also think HomeCamera provides a great example of how third party applications can use the Telco API.  Take this use case as a simple example: Jim recently hired a nanny to look after his two young sons.  When he's on the road he can check-in from his mobile phone, just to make sure everything is OK.  He also shares access with his parents so they can check in from their TV.  The operator could expose capabilities such as Single Sign On (from Jim's mobile phone or his parent's STB (Set Top Box) they can access the camera directly without the hassle of entering usernames and passwords), service provisioning (Jim can set up the service for his parents, all they need to do it press the widget button on their remote), IPTV and mobile video streaming capabilities (to ensure quality delivery of video to both his mobile and parent's TV without HomeCamera dealing with the hassle of video clients and QoS (Quality of Service)).

As discussed in the article on the Telco API, the operator could use this service either own-branded, co-branded or as a third party application.  You could imagine a scenario where it's an option on the operator's Family Plan.  The more challenging part is the business model, but as discussed in the Telco API article there are a number of options which generally will be dependent upon the customer and how the operator chooses to charge for use of its network capabilities.  My recommendation is the model must be simple, common across many applications, and at this point in the commercialization of the Telco API its more important to get out there and experiment commercially (continuous beta) rather than spend time crafting complex models and agreements.

What is a 'service delivery architecture'?  It really depends upon with whom you are talking.  Are they are a vendor trying to sell IMS (IP Multimedia Subsystem), or a Java games download platform; or are they an operator responsible for value-added communication services, IPTV, or content services.  Each will likely give quite different answers.  Service delivery architectures have a long history; their roots can be traces to the FN (Feature Node) that emerged in the intelligent network (IN) concept defined by the ITU-T back in the 1980s.  In the FN a SCE (Service Creation Environment) enabled operators to create new communication services without the need to change the software in the exchanges.

This evolved into the IN SDP (Service Delivery Platform), an architecture that enables re-use of service components.  Most operators today have IN implemented in their networks, though most of the SDP implementations tend to be bundled into a specific service implementation, for example caller ring back tone.  The IN SDP has not achieved the ubiquity of deployment as a horizontal layer within the telecommunication software stack, rather a component of a vertical application.  The move from vertical (stove-pipe) to horizontal: faster and cheaper time to market for new services and enabling service innovation independent of switch vendor did not significantly happen.

As networks have evolved from circuit-centric to packet-centric, the SDP has started to extended its reach beyond communication services, to include content services, streaming services, and even broadcast services.  With this move the use of SOA (Service Oriented Architecture) as an integration framework has emerged, given the successful implementations of SOA for BOSS (Business and Operational Support Systems) systems.

So we arrive at today, where the SDP is has come full circle and is positioned again as a platform for the creation of new communication services, but this time in the IP domain encompassing IMS.  Since 1999 IMS (IP Multimedia Subsystem) has been standardized by 3GPP, it enables service control for IP based multimedia communications, across any IP based access.  So the SDP is now positioning across all services and all access, an all-encompassing service delivery architecture, with a total market size of roughly $2B in 2007, source OSS Observer.

A commonly used service delivery platform definition is an IT-based environment, enabling service creation in an environment that does not rely on a specific network element enabler. This comes from the need to cut costs in the service creation process; in saturated markets service providers want to differentiate through their service offerings.  And the need to enable third-party companies to provision services through the service provider environment.  Typically, most SDPs include a service creation environment, a service orchestration environment, a service execution environment and third-party management.

Another way to look at the SDP is to relate it to boxes/functions we already see in an operators network:

• Content Delivery Platform, e.g. a platform that enables content such as ring-tones or movies to be successfully presented and delivered to customers.
• Communications Gateway, e.g. a Parlay server that exposes call control capabilities.
• Telco API, e.g. The exposure of network capabilities across communications and content to third parties.
• BOSS, e.g. a service creation process aligning to 'Common Capabilities.'  A Common Capability is used by many different services e.g. IVR; an 'authentication' common capability that bundles the capabilities of an AAA server with some of the features of an ID management system; and accounting functions, e.g. an internal directory server.

Taking this view it becomes a little clearer why there are just so many suppliers that fall under the SDP label, a subset is listed here: Accenture, Acision, Alcatel-Lucent, AePONA/Appium, Airwide, Amdocs/Qpass, BEA/oracle, Broadsoft, CoreMedia, Comverse, Convergin, End2End/Mach, Ericsson/Drutt, Genband, HP, IBM, IMImobile, jNETx, Metaswitch, Microsoft, Motorola/Leapstone, Motricity, mPortal, NSN, NEC, NetCentrex, Nortel, OpenCloud, OpenWave, Oracle/BEA, Pactolous, Personeta, Qualcomm/Elata, Red Hat/Mobicents, Redknee, Telcordia, Telenity, Sun, Sybase/Mobile365, Ubiquity/Avaya, Verisign/mQube, Volantis.  The SDP Landscape is definitely complex, confusing and consolidating as I write.

But coming back to why an operator should consider a SDP.  The drivers for the SDP are clear: to extend the life of traditional services; lower costs associated with the development and introduction of new services; extend services across networks and devices; provide an operating environment and development tools for third-party software developers; and improve the profitability of niche services.  However, the challenges to implementation are equally as clear: managing end-to-end application performance; modular, standards-based service delivery platforms are still relatively immature; integration; service provider organizational challenges; lack of a compelling business case; lack of standards creates confusion and trepidation; and marketing challenges.

As part of the SDP (Service Delivery Platform) workshop a run I go into depth on this topic and review a number of case studies.  In general my recommendations for operators are:

• The part of SDP that deals with operations (BOSS) has a clear business case and operators are adopting the same tools as enterprises based on SOA;
• The part of the SDP focused on content services is maturing and becoming a managed service;
• The part of SDP focused upon communication services is still in an experimental stage, with some initial success focused upon enterprise services;
• The part of the SDP focused upon third parties, the Telco API is a current hot topic within the industry with a few examples of initial success such as Sprint's Business Mobility Framework.

How the parts get integrated into an all-encompassing SDP is a question I'll leave for another weblog entry.

We've all experienced it: you're on a call, not moving around, just talking and the call drops, you check the signal level on the phone and it's gone only to return to near full strength as you check.  Does the operator even know what's just happened?  And then when you're on the move, for example on the Gatwick Express (between London Gatwick Airport and Victoria Station), there are several points on the train ride where you see most people who are on the phone either start shouting at it or removing it from their ear to look at what's going on.  The phone is an invaluable source of information on the status of the operator's network, yet it remains an under-utilized asset in the fight to improve service levels on the most basic service.

This is the problem Wadaro addresses, monitoring network and service performance from the phone.  It's embedded software on the phone, from a simple SIM (Subscriber Identity Module) application to a sophisticated OS (Operating System) application.  At the lowest end it just monitors the phone state when a call terminates, so its impact on the phone is not perceptible to the user, and it enables an operator to make its existing phone portfolio become part of the network, service and usage monitoring.  Network quality is important to customers, after price is the next decision criteria. 

Operators in the US focus upon network quality as their core differentiation where they spend billions of dollars in building the brand and embedded their bylines in the public's subconscious, e.g. for Verizon their byline is "the nation's most reliable wireless network," whilst AT&T's is "the network with the fewest dropped calls."  We're also seeing operators such as O2 allow their business customers to see the status of their network, with services such as Network Manager GSM and Network Manager GPRS.  Extending that to the status and usage of the services their employees are receiving on their phones provides that last step which moves a 'nice to have' into a 'must have' differentiator.

Their application can also improve customer service.  For example, most customers have no idea what model their phone is. So when they call customer support, the first few minutes are a frustrating dialog of finding out who the customer is and what equipment they have. With Wadaro when the customer calls the support team, the CSR (Customer Service Representative) can know the phone model without asking the customer. Even if the customer has purchased their own unlocked phone elsewhere, the operator can still know the make, model and its performance history.  Next, the operator can proactively identify and remedy errors. If the Wadaro app is showing that the customer can't connect to her email server or collect her MMS, the operator can stimulate device management to correctly configure her device.

The main challenge is getting the Wadaro application onto devices.  For new devices the software can be bundled on the SIM and/or phone.  For existing devices it's a little more complex and will be dependent upon the operator's OTA (Over The Air) capabilities and how aggressively the operator promotes the application and its benefits to customers.  Its one of those areas, where you'd think operators would already be using the phones on their network to let me know how things are working from a customer's perspective.

With the launch of services such as FiOS from Verizon and U-Verse from AT&T, TV services in the US are finally entering the 21st Century, where widgets are now available on the TV such as local weather and traffic; it's slowly becoming interactive.  As anyone from the UK will attest Sky, a satellite TV service provider, has been offering interactive programming since 2001 with the launch of the "Red Button."  That is a simple red button on the TV remote that launches a mico-browser on the STB, which communicates over the dial-up telephone line for voting and getting more information on a topic (e.g. Sky News).  This concept was then extended to the Sky Key, a short-code that advertisers could use so people could go directly to the advertiser's site.  Over dial-up, in my experience, anything more that voting was not an ideal user experience.  But with STBs (Set Top Box) finally going broadband, things have got interesting, and Miniweb is ideally positioned to create a new category in interactive TV.

Miniweb is a spin-out from Sky, they created the microbrowser and the TV Key platforms, and have now created a broadband interactive TV platform and standard based (WTVML) browser that can run on most set-top boxes.  This potentially makes the viewing experience of 382 million TV households worldwide, as rich as the internet, but with the ease of use of the TV.  Miniweb's proposition is to create a new digital entertainment experience through the TV by enabling an Interactive TV experience that combines TV viewing, on-line services and interactive advertising. This generates revenue by connecting TV eyeballs through their products, relevant advertising, contextual links to content and broadcaster driven enhanced TV.  It's a business model analogous to that of Google. What Google does for Internet advertisers, Miniweb wants to do on the TV.

The immediate question that comes to mind is to point out that the Wii and PS3 both include web browsers, so why won't customers just use the existing web browsers on their TVs, especially given the growth of HDTV.  Here is where it's important to examine the user experience.  When someone is watching TV it's an engaging experience.  As an analogy, when I'm watching TV and the phone rings it's an inconvenience, whilst when I'm at my PC surfing the web I do not think twice about checking CID (Caller ID) and answering.  This is a critical point, TV viewing is engaging, so a context-switch is a significant disruption to the user experience; hence why Miniweb subtly overlays their browser and integrates it with the TV channel and its content.

I've accessed the web using both the Wii and PS3 browsers, and though it's nice to see on a HDTV, the PC it still a much easier user experience.  I've experienced the Miniweb platform and it's not the web, its interactive TV, it's a different and new experience that enables me to find out what song is being played on the program I'm watching, find-out the actors name while watching the show, see local traffic reports, find out more about the current news report, book a test-drive from the advert I've just seen, rate programs and share new discoveries with friends, and yes even order a pizza with the press of a couple of buttons on the remote.  It's really just making an appropriate experience to the TV and the context in which people watch TV, rather than force-fitting the internet model.  Regardless of its commercial success Miniweb is an important experiment for the industry in creating new and innovative interactive experiences to understand how the TV/web experience is going to evolve.

Starting with a few definitions:

• Service Fulfillment systems support processes that ensure service providers give requested services to customers in a timely and correct manner, so called Order-to-Cash cycle.
• Service Assurance solutions monitor service performance based on the customer's view, not the network manager's view, based on defined key performance indicators (KPIs), key quality indicators (KQIs) and service-level agreements (SLAs).  These solutions help service providers connect network, service performance with the end-user experience, so called Customer-Assurance cycle.

Although Service Fulfillment and Service Assurance play complementary roles, there is a disconnect between these two functions in service providers' infrastructure. This hinders the service provider's ability to improve the customer experience, reduce support costs, accelerate time-to-market of services and assure smooth introduction of launched services from day one. Hence the focus upon the integration of Service Assurance and Service Fulfillment solutions, sometimes termed Service Management, which enable service providers to have an end-to-end view of services data, without the need for replication of data across fulfillment and assurance systems.

The goal of the service provider is to provide any service on any network to any device. There are also many more services, with service bundles being frequently modified, sometimes in real time. It is therefore no longer enough to manage the customer, the network or the resource. It is now important to manage the service as an entity in its own right. In addition, service data is usually held in several systems in a service provider's environment such as a legacy fulfillment or assurance system, and the many subscriber management system silos. By linking service fulfillment and assurance, service providers have a single view of services data.

So Service Management appears to be growing out of the consolidation of these functions, more general industry consolidation, and the trend to delivering a broader integrated BOSS (Business and Operational Support System) solution.  An example of this consolidation is Subex that acquired Syndesis last year.  Syndesis is a service fulfillment platform for Triple Play services.  After the acquisition Subex created a service fulfillment and assurance division focused upon 'service agility' (the ability to provide better services and multiple services) for what Subex terms "operational dexterity" which falls into this category of Service Management.

Just to make things a little more complex, within Service Assurance is a function called Service Management (though I more frequently see it being called Service Monitoring these days) as the software systems that measure and monitor services including the overall quality of each service and its business impact on a particular set of customers. Service management systems enable CSPs (Communication Service Providers) to generate granular reporting capability by each customer and service to validate service level commitments. Key quality indicators are measured in each specific network domain to alert CSPs of degraded network performance leading to unsatisfactory customer experience.  The main vendors are HP, IBM (Vallent), Telcordia, Agilent, Ericsson and Nokia accounting for about 60% of the market.

But moving back to the broader definition of Service Management, competition in this space comes from providers focused on Service Fulfillment, Service Assurance and Service Deliver Platform providers.  It's a complex competitive landscape.  Just focusing upon Fulfillment as an example, some of the big players are, Amdocs (Cramer), Ericsson, HP, IBM (Vallent, Micromuse), Oracle (BEA, Metasolv, Portal), Sybex (Syndesis), Telcordia and Wipro.  In the small and medium sized company landscape are about 20 suppliers in this segment, shown in the attached table, let me know if there are any mistakes.  This table analyses each from their technology focus (VoIP, IMS, Triple Play / IPTV, DSL / HSD, and IP VPN / Ethernet), customer focus (ISP / xVNO, Broadband, Mobile and Cable), region focus (EMEA, LATAM, APAC and NAR), and functional focus within Service Fulfillment (Inventory, Mediation, Order Management, Work-Flow / Provisioning, Activation, Catalog, Self-Serv, and Service Tools).

Now in addition to the Fulfillment landscape there is an equally complex Assurance landscape and an even more complex Service Delivery landscape, which I'll not tackle here.  Rather to wrap up this article I thought I'd finish on the few trends I see emerging:

• Consolidation of functionality.  Just like enterprise IT, as mature functions are subsumed.  For example, once upon a time a service provider would buy a VoIP fulfillment platform, now multi-service fulfillment is the norm.
• Emergence of managed solutions.  This is coming more from the Service Delivery side of the competitive landscape.  Rather than buy a license and pay an SI, we're starting to see solutions (particularly in self-service) being managed by the technology provider on behalf of the service provider; which saves costs for the operator and the technology supplier, especially for those with scale.
• Consolidation of companies.  The big guys like Oracle and IBM have recently bought some of the medium-sized suppliers; but we're also seeing consolidation amongst the medium sized suppliers, e.g. Sigma Systems buying C-Cor, and Subex buying Syndesis, as they race to achieve scale.
• Best of Breed components do not generate a Best of Breed system.  Tier 2/3 markets have generally focused upon all-in-one solutions because of limited scale and cash.  Tier 1 operators have generally implemented a 'best of breed' component approach.  However, as we've seen in several cases, which I'll not name here, having a kitchen full of Michelin chefs does not necessarily result in a meal worthy of a Michelin star.
• Strong push with most operators to control their escalating BOSS spend on both legacy and new services.

This sets up an interesting phase in OSS consolidation, where we have three major functional segments of the BOSS industry starting to merge, a strong push to control BOSS costs from operators, emergence of business models (managed services) which require scale, and a push-back on the rational for best of breed components.  By the end of this year, I think I'll need to be updating the small-medium fulfillment landscape again.

As part of the SDP (Service Delivery Platform) workshop a run, I have a section on the ODP (On Device Portal), where I run through the ODP landscape.  I maintain a table of companies I consider relevant to the ODP Landscape, if you see any gaps or errors let me know, thanks.  During the years '05-'07 it's been a table that was becoming shorter, as start-ups in this space either ran out of cash, merged, or where acquired.  However, over the passed 6 months the table has nearly doubled in size, and more importantly the number of operator deployments is about 140 (some operators use multiple ODP suppliers so there is some double counting in that number).  This is a technology that has achieved mainstream deployment by stealth when you consider how little analyst and press coverage it receives, yet it's in the customers' face much more than iPhone, Android, WiMax, femtocell, or UMA.

In building up this landscape there are a number of categories I include:

• Traditional ODPs that sell or work with operators, e.g. Cibenix, Nokia (MOSH, Download! and Catalogs), Surf Kitchen and Yahoo! Go: a client and a back-end designed to streamline and improve the presentation of specific content services to address the '3 Ls' of Latency, Look and feel, and Lack of availability.
• Media focused ODPs, e.g. Mippin (previously RefreshMobile) and WeComm, which target brands and content owners with a solution.
• Technology providers, e.g. Adobe with its suite of Flashlite, Flashcast, Flex, and AIR (Adobe Integrated Runtime), and as the originator of the RIA (Rich Internet Application) concept which was coined by Macromedia back in '02, but more on that later.
  
• Browser based ODPs, e.g. Openwave (Midas) and Opera.
• Home screen replacements, e.g. Abaxia and Zi, that focus an just making the functions of the phone easier to use.  As an example VoiceSMS is possible today on most phones by sending voice notes over MMS without the need for a network based service.  Samsung have made the UI (User Interface) easy on most of their phones, but try sending and replying with voice notes using a Moto phone.  Its no wonder Samsung in now the #2 phone supplier worldwide, taking Moto's spot. But this difference in experience is the problem such clients solve.
  
• Mobile Widgets, e.g. Plusmo and netBiscuits: a new area and rapidly growing category that has an interesting overlap with PC based widgets that create some innovative experiences and business models.

The ODP market has been slow to take off for a variety of reasons including:

• Handset coverage, operators (excluding NTT DoCoMo, SKT and to a lesser extent Verizon Wireless) lack control on software build in the phone without incurring significant cost;
• Confusion on ODP's role as it's a client-server architecture not just a client so it must be intrinsic to the portal architecture;
• Lack of integrated end to end solutions; and
• Lack of standards and implementation norms.  

However, the factors that are now driving deployment are:

• On mobile phones MIDP2 (Mobile Information Device Profile) has become more prevalent, which is essential for creating slick experiences and enabling the application to run from start-up and not require the user to do something.
• Operators realizing that not all phones need to have the ODP.  The classic mistake was to force fit the ODP onto all current portfolio phones, which generally ensured at the lower-end there was a poor experience on phones that did not have the horse-power, which further encouraged customers not to adopt mobile data services.  Three and its X-Series campaign, demonstrated the power of restricting premium experiences to premium phones, so the user experience was cool.
• iPhone demonstrated to operators that user experience as well as look and feel are more important than price.  The "Cult of Apple" is a great example of where people pay a premium for the laptops, MP3 players, and now their phones (and it's a phone that does not have Flash so most of the cool sites do not work).

ODP is evolving, with the emergence of mobile widgets which are analogous to RIA (Rich Internet Applications), e.g. Google Earth, its becoming RMA (Rich Mobile Applications), which opens the mind to a vast array of potential applications, not just making the phone easier to use, or making purchasing content easier.  Over the next 3 years as feature phones get more horse-power we're likely to see the ODP/RMA market evolve into a standards based browser that is either AJAX-enabled browser, Flash-lite and/or script-based 'widget engines.'

In this emerging environment important operator considerations include: the software already being on the handset, client-based so the back-end is not closed; an open and large developer ecosystem using the technology; and focus upon cross-platform services, i.e. mobile is not an island RMAs must also inter-working with RIAs in Western markets.  In developing countries where most people will experience the internet through their mobile handset, then RMA/RIA inter-working is not as critical.