At MWC 2010 there was a workshop on OneAPI were the GSMA announced the launch of a commercial pilot in Canada with the country's operators Bell Mobility, Rogers Communications, and TELUS to demonstrate the viability and benefits of providing third parties with standardized application programming interfaces (APIs).

Through the OneAPI initiative, the GSMA is promoting the adoption of a common, lightweight and web-friendly set of APIs to provide third parties with easy access to network capabilities. The Canadian pilot is the first time commercial access to network assets of multiple operators is possible through a single gateway, in a consistent and simple way using OneAPI.  What this means is a third party does not need to worry about which operator the user is with, its a single API framework with common authentication, common terms and conditions, and common charges.  Pricing is yet to be announced, which is a critical issue - I hope they've listened to third parties on what they require.

A few examples of what this means.  

• HomeCamera, the world's easiest to use internet home surveillance service, is one of the services being launched through this pilot; throughout Canada HomeCamera now have a single API to access, making it simple for customers: they just enter their mobile number and can receive motion detection alerts by SMS or MMS as well as clips from their webcams.  So in a matter of a few minutes, with NO modification to the service platform HomeCamera is available to all Canadians.
• If an Enterprise wants of add SMS alerts to its internal approval process to speed up decision making.  An internal IT developer can add the capability with just a few lines of code.  There's no complexity of working out which network the employee is on, building three versions of the interface and trying to get the CFO to sign off on three separate charging plans.

This is a critical step in the industry getting its act together and a necessary step in working with third parties, which is a much broader category than simply web developers as discussed in this previous article.  No operator has an excuse in not following the Canadian lead, unless they have decided being a pipe provide is their preferred business model, and are happy to forgo up to 36% of their revenue to OTT (Over The Top) providers.  I show below the slides presented at the workshop to get the message out to the industry - we need to act fast.

I've covered Fonolo in previous articles since 2008, last year they were one of Time Magazine's top 50 websites of 2009, in the same league as Facebook, Google, Amazon, etc.

If you need to call your bank, airline, operator, car rental agency, travel service, or one of those many other companies that waste your time by making you wait on the phone.  Fonolo does all the IVR (Interactive Voice Response) navigation and waiting for you, then once connected to an agent calls you back.

They now have an iPhone app, here's the announcement on their site, and below I show the UI (User Interface).  Its an obvious service for operators to provide - call mediation between enterprise and their customers - yet they have not.  For enterprises, connecting with customers is important, hence why they have 800 numbers.  But customers' time is much more important than a call which is generally at zero incremental charge given today's phone plans.  Fonolo intelligently connects enterprises to their customers, in a way that helps respect the customer's time and ensures more accurate call center navigation.

This service bypasses the operator from providing value in connecting enterprises and customers.  This is a core value proposition of operators, yet they have missed the boat in delivering value around their core product.  They can be forgiven for struggling with handset centric games and content, its a fragmented business where they lack control.  But in the core voice product no such excuses apply, this is a clear signal to the industry that unless things change soon and fast operators are heading towards commoditized pipes.

I presented at a recent sales conference for a large security / IT solution provider on the evolution of the telco industry and the role security and protection plays in that evolution.  I show below a cut down version of the slides I presented, removing the discussion on specific market opportunities and actions.

In the discussion on telco evolution I focused on 4 area:

• Web evolution: discuss the 3 phases of web evolution and the emerging role of a "trusted agent." Operators know much more about their customers than web service providers.  Critically, ad-sponsored models mean the advertiser is the customer not the user.  However, for telcos the users are the customers, hence telcos have far better fit in being the trusted agent than most web service providers. Yet operators remain dumbfounded on how to adopt this role.  TiVo and Amazon are two examples of trusted agent, e.g. with TiVo I turn on my TV and my favorite shows as well as suggestions of shows I may like are there.  TiVo uses my data to create a vastly better experience than flicking through uninteresting channels.  Operators can do what TiVo does but on a much broader scale.
• Power of devices: we've moved to the PC model for mobile devices, and as STBs include Java so that will be the case for IPTV within a few years.  In mobile we'll likely consolidating onto 5 OS (Operating Systems), significantly reducing the fragmentation that's stifled growth in mobile applications.  However, end devices will need protection.  An operators' security layer must focus on the device, as well as the network and services.
• Customer perceptions:  I've covered this in several previous articles, customers no longer make a distinction between web and voice services they're all just services.  For operators to remain relevant as service providers they must play a role across a broader range of services, and not just act as a pipe-provider also a trusted agent.
  
• Rate of service innovation:  Operators are opening their networks to increase the rate of service innovation, but in doing so its never been easier to get malware onto a phone and in time a STB.  The 'elephant in the room' in opening the network is security.  Operators must take an integrated approach using their SDP (Service Delivery Platform): including network, devices and services - because its about their customers NOT just their network.
  

In summary: customer data, trust, security and protection are critical for operators to get right in this emerging environment.

Operators need an integrated security and protection layer, not point solutions for each service as is the case today.  That is protection from malware across all network services e.g. IP, SMS, MMS, WAP push, widgets, apps, etc.  And protection in the network, in devices and in services.

SDP vendors need an integrated security solution across network, services and end-points, which means a partnership with a leading security/protection technology provider is key.  Its a rapidly growing problem as its a highly profitable and more importantly safe criminal business compared to drugs or prostitution; hence a specialist security/protection partner is essential.

Even though M1 is a small mobile operator, roughly 1M customers, it remains one of the most innovative mobile operators.  M1's business strategy is simple: to constantly deliver value to its customers by rolling out new and innovative applications and services.  In mid-2008, M1 began its search for a next generation service delivery platform (NG SDP) to provide a framework for traditional telecommunication services, next generation of value-added services, and enabling it to remove its old IN that limited its ability to innovate.

M1 selected an open source JAIN SLEE (Java™ APIs for Intelligent Networks Service Logic Execution Environment) solution provided by its long-time IT partner hSenid, called the mChoice SDP.  M1's relationship with hSenid goes back to 2002. For nearly eight years, hSenid has helped M1 implement major projects such as the deployment of MySQL cluster, mChoice Rewards, mChoice Recharge, and mChoice Reporting - a comprehensive business intelligence system to help M1 to make strategic decisions and revenue calculations. These solutions were built on open source, resulting in significant cost savings in terms of licensing and maintenance fees.

The standard application programming interfaces (APIs) help M1 provision, control and bill for all the value-added services they provide, whether the services are developed in-house or created by third-party application.  This is a key point the APIs are not just for third parties, they're for internal consumption as well.  M1 set out with the objective of looking for a SOA (Service Oriented Architecture) based solution, given their enterprise architecture.  I discussed SOA in this article.

For M1 its main benefits in adopting a NG SDP are:

• Opens up service innovation, letting third parties offer services to M1's customers or using M1's network capabilities to their customers, which opens up 1000s of new applications and services;
• Launch new services faster, moving from months to days in launching new services (factor of 10 improvement);
• Protects existing investments while enabling future growth, i.e. reusing amortized equipment, e.g. SMSCs, while putting growth onto lower cost platforms (a 10/100 factor cost reduction for growth); and
• Lower operational overhead by simplify on-boarding, contracts, etc. enabling M1's limited people resources to launch 100s more services each year.

hSenid's whitepaper provides more details on the M1 case study. 

There's an interesting discussion the industry needs to have on whether a SOA or a looser web-centric integration framework is the right long-term approach.  For smaller operators this distinction is mute, but the larger the operator, the closer its cost-basis need to tend towards Google - as in the limit they're both service providers.

Network APIs do not require a developer community.  Its just an API: publish, provide code examples, define the process on how a third party can access the API, and you're done.

Network APIs are not necessary for an operator's App Store.  For example operators have been selling content and apps on their portals for years, its a $71B business.  APIs can make some apps cooler, easier to use, contextually relevant; but the two are not dependent, i.e. an operator can offer APIs without an App Store, and can have an App Store without APIs.

Developers are not a homogeneous group, they have a multitude of needs and business models.  They varying from geeky individuals to global enterprises.  Operators must think about a broader category of "Third Parties" when they examine customers of their APIs.  Examples include:

• Enterprises (e.g. where an enterprise's IT developer may want to use presence for their corporate communications);
• Trusted third parties (e.g. local SIs that can use the APIs for the solutions to their SMB (Small Medium Business) customers);
• Trusted third parties that can help operators work better (e.g. someone helping T-Mobile analyze their customer data to they finally start treating me as a customer not a credit card to be billed monthly);
• Content owners that can use APIs to make their audience relationship stronger (e.g. Real Madrid giving up on email and now using SMS to great effect); and
• Developers / service providers who need a channel to market through the operator or web-based developers / service providers who have their own channel.

Developer communities are necessary for OS platforms, e.g. Java development community or the Apple iPhone developer community.  Operators do not need a developer community, they need an ingestion process to get stuff into their stores, and they need a simple process to get third parties approved to use their APIs - these two processes are different.  It makes a lot of sense for the developer communities (e.g. Java) to also act as warehouse, making it much easier to retailers (e.g. operators, Amazon.com, etc.) and developers to have a single point to remove the critical barrier of approval expenses - we're taking about 1000s of approvals being removed per app.

Widgets are just a bookmark with the logic preloaded, data is loaded at the point of execution.  They run in a browser.  It is not a business model, its not revolutionary, its just making things better given the vagaries of internet connectivity over mobile networks.  Think of it like WAP (but its not crap), it makes it easier for customers to use web services on their phone.  Voice, SMS, WAP, and the web browser are equally useful interfaces for accessing services depending on the device, the application, and the customer.

I show below in a single diagram the two faces of the operator as a network, and as a channel to market. And linking that to APIs, Developer Communities, Developers, Third Parties, App Stores, App Warehouses, and Widgets.

API Management has been touched upon by several articles in this weblog.  To expand on this topic to help us understand its function and strategic importance to operators I've put together a whitepaper with Sonoa Systems, a leading provider of API Management to companies such as MTV Networks, Alcatel Lucent and Guardian Life Insurance.  The API Management whitepaper is available here.  

To set the scene on what is covered in the whitepaper: within and between enterprises APIs have been used for over two decades, from the early days of EDI (Electronic Data Interchange) to today's rich RESTful protocols. The reason API Management arose is that delivering simplicity in APIs to developers involves significant complexity in operations for the provider, some of the issues include:

• Authentication and security from multiple providers;
• Multiple API calls and calls across multiple services;
• Different protocols, API versions, and interaction models;
• Variance in performance between different APIs;
• Composition of off-network APIs such as Facebook and Twitter
• Poor visibility into API performance;
• Limited troubleshooting and debugging capabilities for API calls;
• Limited bandwidth, connectivity issues over the wireless network;
• Scalability of the servers underlying the API endpoint;
• Limited memory, CPU, storage on the device limits the client-side API processing capability.

APIs are also fundamental to telecommunications; there is a very long history. Back in 1878 the world's first commercial telephone exchange was opened in New Haven, USA. The switch exposed an interface that enabled people to make requests to set up telephone calls. Over 130 years later telephony switches are still exposing an API for exactly the same purpose. What has changed is the magnitude of types of requests and the sources of those requests - people, computers, private branch exchanges, credit card machines, and many other clients.

As waves of technology have followed the birth of the Internet 40 years ago, enabling the emergence of the World Wide Web about 20 years ago, driving widespread broadband access over the past 10 years.  We have now reached a point where telecommunications and the web are merging into a powerful pervasive services platform.

Previous work has shown that capability exposure has the potential to raise average ARPU by 12-36%. There are many examples of operators today making money out of capability exposure such as Telenor's Content Provider Access which generates $100M per year. Globe in the Philippines generates 1000 new value added services per year with over 1B transactions; that project had an ROI (Return On Investment) of under 2 months. And Telus was able to launch 40 rather than 4 applications per year to its small medium business segment and lower its cost to launch new services by over 75%.

However, operators' networks remain surprisingly under-utilized by the millions of developers building the web; Apple shows the power of harnessing that community for just one proprietary handset. Critical factors in its success are providing direct access to a large engaged customer base; and of relevance to this discussion a rich, easy to use set of web-centric APIs within a common framework. Developers care about cash and/or fame - customers are necessary for both. Operators must reach a point where web developers consider an operator's STB as easy to reach as an internet site is today for the delivery of their services.

Wholesaling capabilities is a core competence of operators since the emergence of the intelligence layer on top of the telephony switch. As an example, 800 (free phone) numbers are a capability that is applied to many business problems. Operators do not create "airline customer complaint toll-free phone services," they enable businesses do that with the capability they wholesale. This is a critical point: APIs are not limited to consumer applications; rather, enterprises are major adopters of APIs. For example, in an enterprise workflow where a request to made for a new purchase, this triggers a message to the approving manager, who confirms the order is OK, and the order is placed. If the messaging and confirmation are done via an SMS or automated phone it can speed up a business processes from days to minutes - which is a very compelling business case.

As telecom and web merge the operator can wholesale a multitude of capabilities, including messaging, billing, click to call, mobile content, conferencing, location, single sign-on, address book, age verification, identity, profile, presence, call control, mobile lookup, IPTV content, connection status, quality of service, messaging short codes, video streaming, set top box APIs, mobile device APIs, to name just a few. All of these need to be provided under the secure policy control operators provide today for their customers. As these APIs are offered to web developers, most operators are struggling to provide the simplicity and scale necessary to gain adoption while maintaining security and reliability of these services.  The figure below shows the role of API Management.

Operators are sitting on a gold mine of capabilities. A new generation of applications are being built by a rapidly expanding pool of developers. These developers are trained in web applications and services, searching for differentiation, and driving consumer demand for mobile internet service. Success will be driven by the population of innovative apps, which in turn will be driven by the simplicity and consistency of access to the operator's capabilities.  API management plugs a critical gap in an operator's ability to monetize its existing capabilities and more importantly enable a rich, easy to use set of web-centric APIs within a common framework and a consistent security model to engage the millions of web developers building applications today.

I know it is frustrating for many in the telecom industry that have just persuaded their management team to invest in API exposure, that we must now step-up-the-game and invest in API Management.  But we've got to try and increase our rate of innovation towards that of the internet to remain relevant to developers, partners and most importantly our customers.  The API Management whitepaper is available here.  

Last year I was reading Jack Weatherford's book "Genghis Khan and the Making of the Modern World."  One of Genghis Khan's early critical achievements was stopping the inter-clan wars, so the Mongols focused outside Mongolia, and went on to conquer most of the known world.  Taking each city-state in turn through a simple 3 step plan:

• Shock and awe;
• Containment with the latest siege weapons; and
• Logistical support to outlast the city and cause its fall.

The above summary is a gross simplification as they also innovated in war technology and strategy (feigned retreat).  The simplification is for the purpose of this analogy.

The success of open web-based APIs got me thinking about that early achievement of Genghis Khan.  It has enabled a far richer service environment over the web than any individual service provider could hope to achieve.  One simple example, check out the latest Samsung's InternetTV with a whole range of widgets built into the TV covering YouTube, Flickr, Yahoo! etc.

Telcos are still behaving like the city states.  Thinking they're safe with the wall granted by a state license from the OTT (Over The Top) threat.  But looking to history showed those walls were of little use against the 3 step plan.  So drawing an analogy to today's situation:

• Shock and Awe: The financial analysts and investment bankers (both of whom grossly lack regulation, but that's another story) have partially created the 'shock and awe' in the valuations they assign to telcos versus the cloud/web-based service providers.  As well as the popular prophesy-type messaging on the inevitably of the Telcos' demise, it reminds me what Cisco did in the '90s with its evangelical marketing on the inevitability of IP.  But more importantly, operators themselves are creating a self-fulfilling prophesy: I've presented many service innovations, and talked about some of them in this weblog, yet the common refrain remains "Yes, but..."
• Containment with the latest siege weapons:  Service innovation is the latest weapon of choice from the cloud-based service providers, its success is evidenced by customers increasingly using OTT (Over The Top) services, not just on mobile phones such as iPhone, but on any internet connected device, e.g. Samsung's InternetTV.
• Logistical support:  The vast global data centers of cloud-based service providers; e.g. Google has over 350k servers distributed throughout the world.  It is so vast that it has changed the structure of the internet in the passed 2 years, creating a category of hyper-giants such as Google and Microsoft who are no longer dependent on a global transit backbone and directly connect to IXP (Internet eXchange Points) forming a significant component of the internet backbone.

For operators to avoid the fate of the city states, in becoming vassals of the Mongolian state they must harness the same principles of acting together, open APIs, service innovation, and global logistics.  

• Act together: this goes beyond GSMA's OneAPI, which is critical.  Cable Labs in the US is a great example of an industry co-coordinating.  Fragmentation is killing the industry, co-ordination is required in committing to common OS(s), committing to devices over multiple years (like Apple's commitment to the iPhone), committing to common cross-carrier services that do not require IMS, committing to acting as a vibrant innovative services industry.  Also as a petty peeve of mine; there are very few 'special requirements' - the number of meetings I have with multinational operators and hear about how one OpCo (Operational Company) has special requirements based on what appears to be no other rational argument than maintaining their job.
• Open APIs: operator must bring together the web, network and device based APIs in a way that's easy to use for developers, content owners, enterprises and their customers.  I've discussed API management in the SDP Asia Summary article and will also be discussing it in more detail in a later article in December.
• Service innovation - just do it, no more "Yes, but..."  We should be honest with ourselves as an industry, we just don't know exactly what is going to be a successful service; so its important to fail and fail often as that is the essence of innovation (as long as you learn a little each time you fail.)
• Global Logistics.  The telecoms industry as whole has a combined computing resource far in excess of the Cloud-based service providers.  Operators need to examine how to create a federation of clouds to share services, capabilities, and application-level connectivity to deliver valuable services to end customers that just work.

The Telecoms industry must meet the 'Genghis Khan' challenge head-on with the same tools and strategies, else become a vassal (pipe provider) of the Cloud-based Service Providers.  Being a pipe provider does not give an operator the same valuation multiple as a utility (generally 7), Telecoms operators do not have a monopoly like water or electricity - hence their multiple will tend to 1!

The 4th annual SDP Asia Conference took place in Singapore from 27-28 October 2009.  It was as well attended as ever, with over 70 attendees from around the region.  Some of the operators presenting at the conference included:

• Krishna N Basudevan, GM, Information Technology, Aircel Ltd, India;
• Clark Lam, Director of Service Platforms in Consumer Products, SingTel, Singapore;
• Rahadian Krishna Sundara, Head of Business Research, R&D Center PT Telkom, Indonesia;
• Andrea Demaria, Project Manager Service Layer & Messaging Innovation, Telecom Italia, Italy;
• Alex Ibasco, Group Head, Strategic Business Development, Smart Communications, Philippines; and
• Dr. Jan-Bon Chen, Chunghwa Telecom, Taiwan.

For me the key theme was a shift in the focus of the conference away from 'why an operator should deploy a next generation SDP' to commercial and operational performance improvement.  Operators such as SingTel and Telecom Italia were sharing their deployment experiences from 3 years of operations.  I show below a summary of some of the slides I found interesting at the conference.  In my opening presentation I claimed we've reached the end of the beginning in the SDP story, the focus must change from technology to how the SDP can transform operators so they remain relevant to customers as service providers, not just bit pipe providers.

My presentation at the conference was titled "SDP Evolution: Revolution, Convolution, Amalgamation or Elimination?"  I examined the impact the confluence of several critical technologies / developments have on the SDP such as: cloud computing/managed services; and open initiatives such as Joint Innovation Labs, GSMA's OneAPI, OMTP's BONDI, and OSGi (Open Services Gateway initiative).  Reviewing key trends in operators' requirements and their competitive environment as web and telco converge on the handset.  Presenting a view on the current and likely future evolution of the SDP: will it change, get more complex, will silos finally consolidate, or will it simply go away?  A key message was the importance of API management for operators across the device, network and web.

On Thursday the 29 October I ran a one day workshop at the conference entitled: Application Stores, Developer Communities, Content, Games and Widgets: Strategic Market Review and Operator Opportunity / Risk Analysis.  A sample of the workshop is shown below.

I also presented at a supplier event during the week on why Operators need Developers, presentation is show below.  The week spent in Singapore was a turning point for me in the SDP journey.  SDP is now a core part of an operator's capability set, the challenge now is how to use the capabilities provided to remain relevant to customers as service providers given the Over The Top (OTT) Tsunami that's about to hit the industry.  What we've witnesses to date with Skype, Jahjah, Yahoo! IM, YouTube, and Hulu is only a trickle, the OTT business case now makes business sense.

O2 Litmus just announced the winners of its application competition:

• Intelligenti Publishing, who takes home the £10k prize; and

Two apps shortlisted by a judging panel of O2 customers were:

• Percula Software's EventHorizon; and
• Live TalkBack.

Live TalkBack is founded by Matt Millar, who was on my panel session at the Smart Pipes Event in May (Day One weblog entry, Day Two weblog entry).  Live TalkBack is an interesting app, enabling broadcasters and event organizers to interact with their audience in real-time in a modern, graphics rich, web-like experience.  Currently its available across the Apple, Ovi and O2 Litmus stores - again further evidence that O2 Litmus understands what developers need with direct customer access.  The app moves audience interaction beyond the stone age of calling / texting - which is on the decline as people become disenchanted with the premium charges imposed on them which is then used to pay for Simon Cowell's next conspicuous consumption.  And instead enables a graphical, point and click, instantaneous interaction; with vastly more detailled audience analytics.  Broadcasters, event organizers and advertising agencies should give Live TalkBack serious attention.



Intelligenti Publishing provides a platform for authors and publishers to get their content onto the Apple iPhone/iPod Touch platform.


Percula Software's EventHorizon is a cute app for viewing upcoming events.

Patrick Murphy (email Pat) has just released an excellent report on the status of communication enabled business processes (CEBP) that is likely to become a reference text in the emergence of this important category for both operators and application developers.  

The report provides an overview of the CEBP industry relative to Telco APIs and voice centric application providers. After a minimum of 3 to 10 years of work by a wide range of service providers and application vendors the industry is at the end of its initial phase of technology-led innovation, this report provides important guidance on the next phase of business-led innovation. During the technology-led phase there have been successes, failures, consolidations, mergers, and acquisitions. However, IPOs, exits, or standalone profit centers within large companies have been few. Yet, revenue is being generated and hard earned profits ramped up by a few smart and well timed vendors. As with any technology wave, most firms will fail.  The report is pragmatic, it aims to help the reader improve their odds for Crossing the Chasm. Put simply the industry has reached the end of the beginning of CEBP innovation and Geoffrey Moore's Chasm is in front.
 
A review is provided of the emergence of CEBP, and some needed clarity on the relationship between CEBP and Unified Communications (UC).   Some vendors have attempted to muddy the water in claiming CEBP is enabled by their UC solutions, as they try to persuade enterprises / operators to buy / resell their UC platforms.  Relevant network API providers are reviewed, e.g. Orange, BT Ribbit, Voxeo, Broadsoft and ProgrammableWeb.com.  Several CEBP application vendors are case studied including Jott, Varolii, and eSTARA.  The conclusions provide both clear guidance on how to navigate the business-led innovation phase, as well as some all important market size estimates of CEBP, which is currently at $3-4B.
 

The Broadband World Forum is the main telecommunication industry's event for broadband, drawing thousands of attendees from more than 100 operator companies and all the top broadband vendors.  Keynotes at the event came from industry leaders such as Hans Vestberg, CEO Ericsson, Jean-Phillip Vanot, SVP of Innovation and Marketing for Orange, and Mika Vehviläinen, COO of NSN.  The plenary sessions packed out and main theater at CNIT in Paris, and at the same time the exhibition floor was packed.

One of the highlights at the event for me was HomeCamera, who I reviewed on this weblog as a start-up to watch, won the InfoVision Award.  Its great to see innovative services being recognized by the IEC at the same level as the big names such as Huawei and NSN.  This was a key theme of the conference, across all the keynotes was the importance of enabling open innovation from third parties to maintain an operator's relevance as a service provider to customers, not just a pipe provider. 

Following this theme I ran a session "Stimulating Service Innovation through the Application Developer Community: Open Innovation".  On the panel were:

• Varun Arora, CEO HomeCamera;
• Christophe Francois, VP Mobile Multimedia Products and Services, Orange Partner;
• Sean O'Sullivan, CTO Dial2do;
• James Steadman, Senior Director, Product Management Oracle; and
• Ian Valentine, CEO, Miniweb.

The panel covered the ecosystem of operator, middleware and developers, so we could achieve an adequate breadth of views.   The panel is also a mix of voice 2.0, web 2.0 and TV 2.0 developers.  There is much to be gained by mobile and broadband operators looking at how the TV guys package their content, and for the TV guys to see the challenges operators face in creating development communities and application stores.  The session was purely discussion, no slideware.  An interactive session with the audience.  I only asked the opening question, the audience and the panel did the rest.

To set the scene I reviewed some of the challenges operators face given their decade long search to work with developers.  I reviewed the critical result of a developer survey I ran earlier this year were 50% of developers who had engaged with operators have given up, its described in the slides I gave at the Cable Labs conference.  Another example is Fonolo, at the 4GWE conference the CEO made a statement I hear too often; "We tried working with operators, it was too hard, we gave up and now go direct."  BTW, Fonolo, is one of Time Magazine's Top 50 websites, I reviewed Fonolo as a start-up to watch last year.  I tried (and failed) to help Fonolo get into operators; the general reaction from operators was "Cool, I love it.  But I'm not sure because...."  I was hoping for the reaction, "Cool, I love it.  Let's get it in the App Store and see what customers think."  Its not just processes, a cultural change is required in being open to innovation; rather than risk avoidance.

I opened with the question, "If you could have one wish to make working with an operator easier, what would that wish be?"  Some of the issues raised included:

• Fair revenue share, with 70/30 being one limit, but operators taking increaing share for additional services such as marketing;
• Speed: short time to get to market, Apple claims the fastest time from code for customer, Microsoft claims 10 days, Verizon Developer Community aims for 14 days;
• Simplicity in the processes for getting in front of the customer.  Most operators hide their customers away from developers, leading to developer frustration.  An operator's core value is delivering a large engaged audience to developers; and
  
• Let customers decide, operators have proven poor in consumer service selection, let's face it they're mostly grey-haired or balding 40/50s males; its not an ideal demographic for 'picking' services.

From that, the discussion moved onto the challenges of:

• Visibility, given Facebook's >350k apps and iPhone's >65k apps; what can operators do to help developers promote their apps;
• Marketing, the importance of the operator to actively market applications;
• Device fragmentation, a critical technology issue for operators to mitigate;
• Value and relevance of customer info, such as phone activity, SMS history, in network / out network, etc; and
  
• Similarities between TV and Mobile industries in the emerging app ecosystem with many insights on packaging provided by the TV industry from Ian Valentine of Miniweb.
  

In the time available we were only another to scratch the surface of the topic, we did not have a chance to cover:

• Charging for APIs (Application Program Interface);
• Charging for testing;
• Enterprise stores;
• Operator in competition with developers, as some operators plan to build their own apps/widgets;
• Store within a store concept, e.g. an Orange store in Nokia Ovi store; and
• Operator collaboration to avoid re-certification, e.g. say Telenor approves an app, why is that not good enough for other operators.

After the session the organizers came in and asked us to move onto the next sessions as the discussion was continuing long passed the end of the panel session.

In a later article I'll review some of the sessions I attended in the Conference agenda which included more than 250 speakers in over 50 breakout sessions, keynote addresses, plenary panels, and workshops.  Sessions such as 'Demystifying SaaS/ Cloud Computing: The Myths versus the Facts' with presenters from Amazon, Salesforce.com, Amdocs, BT, and IDC proved very interesting.

At the 4G Wireless Evolution conference earlier this week in LA I moderated the session "The Ecosystem of Application Developers."  On the panel were:
Shai Berger, CEO Fonolo;
Kent Winter, SVP Sales Apex Voice
TS Ramakrishnan, CTO BubbleMotion;
Francisco Kattan, Sr. Director Developer Ecosystem Alcatel-Lucent; and
Karl Good, Technical Director Truphone.

A video of the panel session will soon be available at the 4GWE video site.  Once its available, I'd recommend that operators take a look at the session as it provides a great summary of developers' needs and frustrations.

The panel presents a great diversity of application developers, from those going around the operator, those supplying services at the core of the network, and those supplying apps that can use the APIs being offered in the operator developer communities.  There is much scar tissue present in the panel from the trials and tribulations of working with operators.  Francisco is building ALU's developer ecosystem to support its customers; and in the past ran Adobe's developer ecosystem, so brings a broad based experience of the challenges faced by content owners as well as app developers.  On Francisco's weblog is a great summary of the panel session.

I started with an opening with the question, "If you could have one wish to make working with a operator easier, what would that wish be?"  Francisco kicked off with a simple request, "Listen."  This is very true; many operators have a rather limited view of what a 'developer' requires, then build something focused on their own needs.  As you would imagine, this approach results in some of the failures we've seen in operator developer communities.

Using the collective noun 'Developers' hides a diversity as great as saying 'People.'  Operators need to consider the needs of content owners, professional stand-alone consumer-focused app developers (e.g. games), communication centric app developers (e.g. BubbleMotion), enterprise app developers, internal enterprise IT organizations, etc.  Each have different needs, an operator must take the time and listen to the developer market and understand their diverse needs.  I know only a few operators that have taken the time to listen intently to a broad spectrum of developer needs.

Shai made a statement I hear too often; "We tried working with operators, it was too hard, we gave up and now go direct."  BTW Shai's site, Fonolo, is one of Time Magazine's Top 50 websites.  I reviewed his service last year.  I tried (and failed) to help Shai get into operators; the general reaction from operators was 'Cool, I love it.  But I'm not sure because....'  I was hoping for the reaction, 'Cool, I love it.  Let's get it in the App Store and see what customers think.'  I'm hoping the openness we're seeing from Verizon Developer Community and China Mobile's MMarket will be delivered in practice.

Other requirements raised during the discussion included direct access to engaged customer base, messaging and calling APIs to avoid having to put equipment in the network, and copy Apple / Android's simple clear online process.  Marketing was a particular discussion point as apps now get lost in the 65k apps in the Apple App Store, or the 350k apps in Facebook.  TS, previously from Facebook, highlighted the importance of social discovery, that is seeing what stuff your friends are using. We're seeing that start to appear in stores such as Nokia Ovi and Vodafone Betavine; marketing is going to be a critical aspect of the stores.  In the limit operators must decide it they are retailer, if so, then marketing of the goods in their store is going to be vital to the store's success.

This is just the tip of a far broader and insightful conversation around developer requirements.  Keep an eye on the 4GWE video site for when the video becomes available.  I recommend that operators take a look at the session as it provides a great summary of developers' needs and frustrations.

I hope you managed to have an enjoyable summer break.  With the end of the summer holidays comes conference season... 

At the 4G Wireless Evolution conference next week in LA I'll be moderating the session "The Ecosystem of Application Developers" (4G1-04), on Tuesday 1st Sept, 2:00-3:15pm.  On the panel will be:
Shai Berger, CEO Fonolo;
Ben Levy, CEO Apex Voice
TS Ramakrishnan, CTO Bubble Motion;
Francisco Kattan, Sr. Director Developer Ecosystem Alcatel Lucent; and
Karl Good, Technical Director Truphone.

All panel members bring extensive scar tissue from working with operators.  Though there's an idealized image of some geek working in the back bedroom creating applications; the vast majority are created by developers such as these panelists.

I'll be opening with the question, 'If you could have one wish to make working with a operator easier, what would that wish be?"  We'll then open up into a broader discussion on: Who are these mysterious appliation developers? What do they need? What are their preferences amongst all the developer communities: Apple, Nokia, RIM, Android, Microsoft, AT&T, Verizon, Ericsson, Alcatel Lucent, Rogers, O2, Vodafone, Joint Innovation Labs, etc? What are their experiences in working across the many different communities? Why haven't operator development communities achived the engagement of Apple's App Store? Is service exposure relevant to developers? Can operators charge for service exposure in consumer services? What should operators do to better engage with developers?
 
At the Broadband World Forum in Paris 7-9 Sept I'll be running the session "Stimulating Service Innovation through the Application Developer Community: Open Innovation" on Wednesday, 9 Sept form 09:30  - 11:00.  On the panel will be:
Varun Arora, CEO Home Camera (who are also shortlisted for an award at the BBWF conference);
Steve Glagow, VP Marketing Operations Orange;
Thomas Howe, CEO The Thomas Howe Company;
Ben Levy, CEO APEX Voice;
Sean O'Sullivan, CTO Dial2do;
Gil Rosen, VP Strategic Initiatives Amdocs;
Ian Valentine, CEO, Miniweb; and
Ty Wang, Senior Director, Product Management Oracle.

This session is more of a mix between voice 2.0, web 2.0 and TV 2.0 developers, the middleware suppliers that enable developers and operators to work together, and poor Steve Glagow representing the operator community :)  Again I'll be opening with the question, 'If you could have one wish to make working with a operator easier, what would that wish be?"  The discussion will be broader driving down in the best practices and problems in mobile, broadband and IPTV silos.

Operators around the world are adopting the Web 2.0 paradigm to harness internet service innovations onto their networks, e.g. Verizon's Open Developer Initiative, BT's aquistion of Ribbit, O2 Litmus, and Vodafone's Betavine, commonly referred to as Telco 2.0. This session will discuss with some leading '2.0' developers what they need from an operator's application developer community to enable mutual success. Questions: What is meant by Telco/Web 2.0? What is the state of current service provider Telco 2.0/Web 2.0 activities? What capabilities can telcos expose that Web 2.0 companies need? What are Web 2.0 companies doing today to bypass the telcos for various service enablers? Where is the money to be made by telcos and application developers working together? What are good and bad practices in application developer communities?

And finally in Stockholm on the 15th Sept at the Oracle SDP in Action event, I'll be presenting on the "The Business Case for Opening up the Network."  I hope we get a chance to meet at one of these conferences.

As a consumer, of all my bills my mobile/wireless phone bill remains the most troublesome.  Electricity, water, gas, broadband, TV and even fixed/VoIP telephony appear with few surprises.  A quick search online shows there is a significant problem with mobile operator's billing.  My recent experience with T-Mobile US made me realize they do not understand me as a customer, and their behavior is a disincentive to trusting them to use new services.

After a busy July and August a big mobile bill arrived, thanks to the punitive overage charges US mobile operators impose on their customers.  For customers of mobile operators outside the US, imaging a phone bill arriving where the operator decides to charge all your in-country calls over a certain number of minutes as if you're internationally roaming.  So a $70 bill can become a $300 or higher bill.

In discussing the extortion with T-Mobile, I was told to check my minutes from my phone using the shortcode, which is OK if I'm actually in the country.  If they checked their records they'd see I travel regularly, and more importantly have never checked my minutes.  I asked why they could not automatically move me to a higher plan as my minutes run out.  The suggestion was ignored, even though its fair to both parties.  From this experience I will not trust T-Mobile to experiment with new services.

In the end I was blackmailed into signing to another contract to partially reduce the bill.  This as a critical barrier for US operators, why will customers play with innovative new services, when even on the basic telephone service they run the risk of getting stung by unforeseen charges.  Until operators get the customer service basics right, why would they be trusted like Apple or Google?

The Cable Labs Summer Conference was held at Keystone Colorado.  Its a gathering of the North Amercia cable industry, its similar to the Mobile World Congress for meeting with many of the industry's execs as you walk between meetings.  Given most MSOs do not directly compete, there's lots of friendly and open discussions on technical and operational issues.  Topics covered in the conference include evolving cable networks for business services, 3DTV, HD Voice, online video, OpenCable home networking, and lots of Tru2way sessions.

OpenCloud ran a great panel discussion event last week entitled "The Stranded Service Provider," accompanied by a white paper that's available on their website.

On the panel were myself and:   

• Tereza Borges, head of NSN's next gen applications
• Keith Dyer, Editor of Mobile Europe
  
• John Logsdon, MD of NetDev
• Marlon Bowser, MD of HTK
• Kris Kimbler, Executive Editor Moriana Group
• Graham Francis, Marketing, OpenCloud
• Chris Haddock, Alliances & Partnerships, OpenCloud
  

Some quotes from the white paper that explain why operators are stranded include:

• "Service Providers are stranded by a 25 year old operating system. Imagine a web application developer trying to compete in today's market using Windows 1 as its operating system! The truth is, much of the infrastructure supporting today's networks is stranded in the mid 1980s. Unfortunately for Service Providers, their customers are living in 2009 and their expectations of Service Providers is increasingly shaped by services on the web (such as Google, Facebook and Twitter) and consumer equipment providers (for example Apple, Sony and Nintendo). Even evolved IN products only pay lip service to IT and web based technologies, yet do not enable Service Providers to play a significant role in the emerging services landscape beyond connectivity."
• "Change can only come from within, for some Service Providers it will be a stark financial hole in the business model that prompts change, while others will recognise the large gap in their service innovation ability from their customers' perspective. Both will be adopting processes and technologies to enable them to play a part in the emerging services landscape by understanding developer's needs, exposing capabilities, enabling service reuse, and leveraging their core voice assets by mashing them up with the web. This will allow them to share in the value created in the new service delivery landscape, and avoid becoming commoditised pipes to the Net."

The panel discussion covered many issues, such as the failure to launch of IMS, the migration to IP for transport yet the lack of migration for session control.  So networks now enable service bypass without putting operators in a position to add value.  The role openning the network plays internally (between marketing and network operators) and externally (both strategic partners and third parties), as discussed in this article The Telco API: Potential to raise ARPU by up to 36%.

A point I raised was the responsibility NEPs (Network Equipment Providers) must play in stranding operators.  They asked operators to believe not think on IMS which has wasted years, they've failed to deliver an integrated, open, standards based application server infrastructure, and failed to help operators manage the risk in migrating their IN (Intelligent Network) into the 21st century.  Now blame also lies with operators, but my point was to highlight the critical role NEPs play in rescuing the stranded operator - and hence the importance open, standards based application servers such as OpenCloud play in rescuing the stranded operator.

Earlier this week I discovered Telstra have launched an integrated storefront experience called the TelstraOne Experience: across the phone's features, web, content, games, customer relationship management, and all the other services they provide.  Critically, its front-and-center of the customer's phone experience and aimed at one-click access.  See picture and video below on its operation.  Its based on SurfKitchen's SurfKit Mobile Internet Platform.

After reviewing Cricket's MyHomeScreen, supplied by mPortal, in the previous weblog entry; its great to see other operators harnessing the potential of the On Device Portal (ODP) to deliver an integrated experience to customers.  How easy it will be to put such as experience on say a Nokia S40 device that's also running Ovi will be a test of whether some handset manufacturers are now in competition with their primary channel to market. 

In cases where the operator can not put its experience front-and-center, they should evaluate whether it makes commercial sense to remain a channel for those devices.  For example, on the iPhone operators have already decided being a channel is OK.

In the article Reinventing the On Device Portal - The App Store, I reviewed how Apple's implementation of its App Store on the iPhone provides a template for operators and how the struggling ODP (On Device Portal) can come into its own. 

I've reviewed the ODP landscape, its struggles and evolution in previous weblog articles.  Originally created to improve the operator's walled garden portal experience, it was over-sold as providing a solution across all devices.  In practice, the user experience of an ODP on a significant minority of devices was a good way of deterring customers from data services.

The Operator's App Store is not a new concept; there are early adopters, for example: Verizon AppZone is built using mPortal's ODP.  The critical issue is not technology; operators must simply commit, pre-load their ODP App Store, and have an integrated storefront strategy.  Fortunately, given the processing power in phones today, most devices are now addressable by ODPs.

Cricket's MyHomeScreen is an excellent example of such as implementation, supplied by mPortal.  Firstly, its preloaded; its front-and-center of the customer's experience, see figure below - its the overlay bar/carousel with cute icons; its much more than a widget engine it has a back-end to provide a unified storefront and integrated into the operator's back-end systems.  Services included in MyHomeScreen:

• Website widget, and of course any website can be presented as a widget
• Storefront widget for graphics, tones, themes, games or ringbacks.  Here Cricket can aggregate a number of catalogs to present a unified storefront - see the The Emerging App Store Ecosystem article on why this is important to operators;
• Account status widget to see the prepaid balance, call detail records, status of orders, etc;
• And of course the the usual weather, news, gossip, entertainment widgets;

Cricket has shown the industry how to tackle the consumer electronic and OS app stores head on.  Rather than complain about Nokia Ovi, operators now have a template on how to deliver an integrated storefront experience across the web, content, games, customer relationship management and all the other services they provide, all front-and-center of the customer's phone experience.

Virtualization is a hot topic, made more so by IBM's potential acquisition of Sun; two leading proponents of virtualization and cloud computing.  From an enterprise perspective the drivers for virtualization are saving cost; and improving employee efficiency, manageability of IT and enterprise security.  Take for example desktop virtualization, e.g Sun Ray thin clients, it's your standard PC experience except its running in the cloud so you can use any client as your own, no boot-up time, screen as you left it the night before, and the data is kept within the enterprise.  Other virtualization examples include Salesforce.com, a leading light in Software as a Service (SaaS), virtualizating the CRM (Customer Relationship Management) application.

Virtualization can be applied across a number of aspects, e.g. data center, server, application, service, desktop, database, storage, mobile device, network, and the focus of this paper the service delivery platform (SDP.)  By the way, I'm going to look at the opportunities and threats virtualization presents to telcos in another article coming soon.

These virtualizations fall into two broad categories, SaaS and IaaS (Infrastructure as a Service).  The SaaS model is being extended to include Platform as a Service, e.g. BT Ribbit's (communications focused) and Sun's Zembly (social network focused) which provide development environments.  The distinction between SaaS and PaaS is more marketing, e.g. Salesforce.com has Appexchange for developers to create new applications, so could claim to be a PaaS; hence I'll use SaaS and PaaS interchangeable until someone points out the error of my ways.

We're seeing operators deploy SDPs as a traditional licensed product running on servers within their IT infrastructure.  But what does SDP virtualization mean to operators?  Are the cloud based SDPs a threat or a complement?

There are two main functions of the SDP: Service Factory (e.g. iPhone SDK) and Service Shop (e.g. iTunes).  The Service Shop can sell to a number of customers, e.g. consumers, enterprises or developers, though the developer shop is really more of a factory store.  The Service Factory provides the tools to ensure the application works on and can use capabilities being exposed by the device and/or network/factory.  Now within the SDP there are functions such as policy, identity, security, charging, cataloguing, sand-box, etc.  I'm not going to go into those details in this article.

Looking at how the cloud SDPs are monetizing themselves:
BT Ribbit's, charge for communication APIs, e.g. seats, calling, texting, transcription, etc.
Sun's Zembly, charge for use of their hosting infrastructure;
Mashery, charge for API use which they aggregate making it easier for developers to access;
Microsoft Azure, none made public, but given its focus on working with operators will likely look at revenue share or hosting charges; and
Salesforce.com, charge for seats and additional revenue from applications.

But back, like a broken record, to the fundamental issue - customer access.  Sun's Zembly is focused upon social networks, e.g. Facebook, where you can create cool apps, like 'stamping on friends' rather than 'poking' them, and get ad revenue from the impressions, of which Sun takes its share for hosting.  Salesforce.com has an extensive customer base and sales force, the apps help sell its core service and win additional revenue.  Mashery and Ribbit provide services that require enterprises to bring their own customers, e.g. Mashery's hosting of 'developer.nytimes.com' or Ribbit's focus on verticals such as Salesforce.com customers or the 'travel and hospitality' sector.

So the consumer/enterprise Service Shop is clearly something that an operator needs to have if it wants to sell services.  Going back to the Factory analogy, there are multiple stages in production, e.g. dye factories, cloth factories, and jeans factories.  A telco's role in service exposure (location, presence, calling control), policy, identity, security, and charging means it's the finishing factory that ensures the product is fit for purpose, wraps it up in a pretty bow and addresses it to a specific customer.  Which means an operator's Service Factory must be able to work with the many other cloud based factories, e.g. Microsoft Azure, partner operators with their development programs, Sun Zembly, etc.  However, such a factory runs the risk of being bypassed, by others further up the supply chain going direct to the consumer.  How operators as an industry structure their factories to minimize this threat as been discussed from an industry perspective in these articles.

• Why the Mobile Industry needs to keep an eye on Cable's Canoe Ventures
• Options on how the Telco industry can work with the App Development Industry
• The Long Slow March towards a Utility Business Model: Mobile World Congress Summary 2009

What all this means to an individual operator's SDP plans will be explored in another article coming soon :)

In the Mobile World Congress Summary weblog entry I made reference to the Cable industries targeted advertising initiative, Canoe Ventures.

Canoe Ventures is backed by most of the US cablecos, including Comcast, Cox, Cablevision, Charter, Bright House, and Time Warner.  Its purpose is to make cable's advanced advertising applications easier to buy and use, and on making the results easier to measure.  N.B. this is a quite customer focused mission; not one mention of technology or esoteric audience qualifiers.  The head of Canoe is David Verklin, the former CEO of Aegis Media Americas.  N.B. they brought in an ad-man, so the organization understands what the customer (advertising industry) needs.

So Canoe can work among disparate MSOs and cable systems, its platform uses the Enhanced TV Binary Interchange Format (EBIF) and tru2way, and defines a common way to collect and report audience data. Focusing on CableLabs's EBIF enables coverage of most set-tops in the market today, including those used by Verizon FiOS.  Canoe is initially focused on a product called 'Creative Versioning,' which will use the cable industry's architecture and ad zones in an effort to make targeted ads more relevant to their viewers.   They've defined two templates, based on EBIF: One for voting and polling, and one for "request for information" applications.

Imagine these scenarios, you're watching the game show and as the presenter asks you to vote and some cute buttons appear at the bottom of the screen, and from the remote you place your vote.  Or an advert for a national pizza chain comes on, at the bottom of the screen appears a button with 'place your order with your local pizza place now' which again is activated with the remote.  All designed for easy viewing on the 10 ft viewing experience.  But most importantly on the back-end; the system makes it easy to target and measure within how advertisers do business today.

Canoe is focused squarely on serving the cable industry at this point.  But EBIF is relevant to both the satellite TV and telco TV service providers.  In fact, Verizon is a leader in EBIF, recently announcing its Verizon FiOS Widget Bazaar based on EBIF.

The critical characteristics in Canoe are:

• Industry acts in co-ordination, not multiple independent operator activities.
• They create a JV, so competitive issues between operators are removed
• It's led by someone from the customer's industry, so its focuses on what matters to the customer (advertisers).
• Its starts small, with incremental improvements that are easy to understand, and then quietly quantifies and tests them out before bringing them to market.

For both the advertising challenge and the third party developer challenge facing the mobile and broader telco industry, Canoe provides a clear case study how another industry is tackling the problem.  But as a note of caution, Comcast's cable ad business accounts for 5 percent (and falling) of the MSO's total revenue.  Don't expect these JVs to have a dramatic change on the existing business model.