I've been a long time proponent on the importance of APIs (Application Program Interfaces) to operators' evolving business models, in fact, of APIs for any web based business model as discussed in this API Management Whitepaper. However, time is moving on and operators continue to struggle with implementing the basics given their business model (charge before the customer even knows they want / need the service, not sharing the love with developers) and lack of board level commitment (most developer communities and API initiatives remain window dressing for investment analysts not a strategic objective).  As evidence on the latter point just look at the relative size of investments in LTE and APIs, they're different by orders of magnitude.

Operators have been working at developer communities for nearly a decade with little success beyond a few strategic partners. Given the success of Apple and Android, we're seeing renewed operator effort in developer communities, e.g. WAC (Wholesale Application Community). Yet the mistakes of the past continue to be made. I've discussed developer needs and the core advantage operators have in engaging developers, but operators remain focused on nickel and diming their customers and developers in the face of a clearly winning model from a customer engagement perspective.

We're now in 2010 and Apple and Android have fundamentally changed the world's perception of where the value resides. People pay for expensive devices and the apps / services / VAS (Value Added Services) are free. Its just like the web, you pay for the laptop and then all the cool stuff of the web is available for 'free.'  We had our chance and blew it because of the telcos' business model and a lack of board level commitment - I apologize for the repetition.

The technology behind the app stores created by Apple, Android, RIM, etc. has been available to operators for most of this decade: ODPs (On Device Portals), device management, content ingestion, location, presence, charging, trial to buy, ad support, etc. Device fragmentation was and remains an issue, but it was compounded by the silly notion that the ODP had to work across all of the operators devices.

Operators continue to make good business out of selling content (games, ring-tones, movies, wallpapers, etc.) especially in developing nations, its a $70B business. So the OTT (Over The Top) app stores of Apple and Android have some commercial catching up to do, but that's really not their focus, rather its about delivering customer value so more devices are sold or OS (Operating System) users gained to spy on. The death knell has sounded as Apple/Android have won the customer engagement battle.

So where does this leave operators? Cricket (mPortal) and Bharti Airtel (Cibenix) provide good examples of what to do in developed and developing markets: APIs are important but forget about per dip charges; an operators' developer community is no longer relevant rather focus on ingestion and partnering; and its all about the customer experience, i.e. making it easy for customers to do stuff. These examples are showing ARPU increases in the multiple 10%s, as discussed in the original API ARPU uplift analysis.

On the enterprise side we have CEBP (Communication Enabled Business Processes) as discussed in this whitepaper, and there's the M2M (Machine to Machine) opportunity: security, mHealth, connected car, connected home, etc. This is where Amdocs jNetx impressed me with their vision of how their SDP enables an operator to play a role in the internet of things, see diagram below. And yes, both Apple and Google have a clear plan on how they will move into that space. Hence, operators need to get their act together and really commit to service innovation, get board level commitment, and execute before the web service providers run rings around them yet again.

 

I was reviewing some old slides last night and saw some material I put together nearly 3 years ago that made me both happy and sad.  Funny how three years later telcos are still struggling, whereas the consumer electronics / OS / web service providers have done and moved on...

1. Without direct Customer Access nothing matters

2. Do not charge, share in revenue stimulated

3. Mitigate device fragmentation - it's the only technical issue

4. Keep the process Simple, Stated, Time-lined, Online and above all Followed

5. Create a class of Showcase Developers - quality matters

6. Focus on Enterprise as much as Consumer

7. Partner with the Platform Developer Communities

8. Market Showcase applications and those developers willing to share 50:50 rather than 70:30 in revenue

9. Accept Platform Developer Certifications (e.g. Java certified) wherever possible

10. App Store must be front and center of all operator customers' experiences - just like Apple iPhone

In previous articles I've discussed the three dimensions upon which a customer pays: cash, time/attention and privacy.  As we're seeing with Facebook and Google's problems, society is starting to realize the value of privacy - businesses of all sizes should be even more concerned.  Google has caused significant market disruption using a very old business model of ad-support - this business model can be traced back to Egyptian / Babylonian times with sponsored tablets (not the iPad type), more recently classified adverts in the Times newspaper from a few hundred years ago, and of course today those creepy (according to the Australian Government) little text boxes advertising something you'd rather not click on.

The ad-sponsored model is very effective in disrupting many industries, enabling web service providers to come in and shake up industries from OS (Chrome OS / Android) through enterprise applications (Google Apps) and telecoms (Google Voice), to advertising and newspapers.  But nothing in life is for free, in the ad-sponsored model people pay in time / attention and privacy rather than in cash.

Operators have a business model based around the customer paying in cash, and its quite a big industry at $2T per year.  There's an important psychology around what happens when someone pays cash for a service even if its only a few pennies, they develop expectations.  When things do not work, or are a pain to use because of annoying advertising they complain.  So an operator's business model based on the customer pays is great ($2T per year), but it is also at risk from disruptive business models (ad-sponsored), and its limited in practice on how far it can extend into ad-support.

So getting to the point of this article, third party application / API business models for consumer; note I'm not focused on the enterprise or B2C segments, that's another story.  Over the past couple of years I've been trying to persuade operators that their business model provides them with a unique opportunity to attract developers that can not be copied by the web service providers.  That is when an application stimulates revenue earning traffic the operator "shares the love," say 5%; that's potentially billions of dollars for developers, this wipes out anything the web service providers can offer.  So there's no need to charge for most APIs, and in any case all the APIs offered by Google/Android, Apple/iPhone/iPad, RIM and Nokia/Symbian are for free.  So there's simply no way operators can charge for most APIs without looking silly, the purpose of APIs is to simply to make applications easier to use.

There's a critical point we need to consider about the importance of third party applications / content: they are value added services which have caused the terminal decline in ring-tones and games sold from operators' portals as operators have simply not responded to the change in customers' behavior.  It will not be long before the VAS of SMS and voice are also under attack from these third party applications.

To date no operator has adopted this approach of "sharing the love" with developers and not charging for most APIs - its not an alien concept as they do "share the love" with resellers.  Instead they continue to nickel and dime developers with API charges and reject any notion of sharing the love, hence a fundamental advantage is lost.  The clock is ticking on when third party VAS move on from ring-tones and games to something juicier.

Hybrid TV is not new; it's been within the industry's lexicon for many years, the transition should not be a surprise.  However, for many executives the shift to hybrid TV has been a quiet revolution.  Especially given two of the telco industry's most successful TV deployments, Verizon FiOS (2.9M customers in Q4 2009) and Orange TV (2.1M customers in 2009), are both hybrid TV.  The whole of the payTV industry is now taking notice of what this means.

The report is available from Mind Commerce.  It brings together work performed on hybrid TV over the passed year through over 200 operator and supplier interviews and online questionnaires, gathering information on deployment experiences, market requirements, competitive landscape, and technology trends.  I'd like to thank everyone who helped in creating this report.

Report Structure
This 114 page report including 57 figures examines the current status of hybrid TV and Over The Top (OTT) TV with the following sections:

• Introduction: providing definitions and a brief global round up of hybrid TV activities, including standardization.
  
• Understanding the TV ecosystem: an important section for all readers from the telco industry.  Neither IPTV nor hybrid TV can be treated as an isolated industry; they're the delivery pipes for the much larger, complex and well established TV industry.
  
• Deployments and learning: reviewing hybrid TV deployments and the lessons learnt.
  
• Drivers for and business case of hybrid TV: based on market research in understanding why operators are moving to hybrid TV.
  
• Interactive services and STB (Set Top Box) applications: understanding an important category of services enabled by hybrid TV.
  
• OTT market status: examining this complex and rapidly changing Internet TV market.
  
• Hybrid TV suppliers: reviewing both solution providers and STB suppliers.
  
• Operator rankings and requirements: based on market research of operators' perceptions of suppliers and their requirements for hybrid TV solutions.
  
• Future of hybrid TV and recommendations for members of the ecosystem.
  

Target Audience

• PayTV operators (telcos, cable operators, satellite TV, and terrestrial TV) providing insight into the factors behind hybrid TV's success, and recommendations in retaining value in the evolution of the TV industry.
• PayTV and telco equipment providers: understanding the emerging hybrid TV opportunity and operators' requirements.
• STB application developers: helping understand where to focus in building STB applications.
• Investors: where the investment opportunities reside in the emerging Hybrid TV landscape.

The report is available from Mind Commerce.
 

Firstly, thanks to the over 150 survey responses to the Telco Business Model Evolution Questionnaire.  Responses came from all around the world with a even split between Americas, EMEA, and APAC; from mobile, converged and cable operators; their suppliers, application developers and a few web-based service providers.  The responses to the multi-choice questions are available in this PDF.

Just quickly reviewing the results.  There's a strong consensus (87.5%) that operators must take a different approach to Google in how they sell their users' eyeballs / privacy to advertisers, though there was 9.4% that disagreed.  For operators adopting an OTT (Over The Top) business model there was lower agreement of 55%, with a significant neutral vote at 34.4%.  On whether the customer would choose the operator as their trusted agent the vote was split with 56.3% agreeing and 36.3% disagreeing, so its clear there is still much debate on that point.  

Operators adopting a freemium model has support with 70%, the rest voting neutral.  In being able to make a business out of API exposure; with 79.4% agreeing its clearly seen as a real business opportunity for operators.  But as discussed in a previous article operators still have much work to do on basic business planning.  Then on where they'll be successful in API exposure the votes broke down: enterprise (75.6%), local content owners (57.5%) and internal development (56.3%) scored strongly; with consumer applications only gathering 18.1%.

On WAC, "The Wholesale Application Community will be successful," there is some uncertainty to its success with 50% neutral and 32% disagreeing with the statement.  I guess too many cooks in the kitchen, which to be frank remains the main problem for mpayments in developed markets.

Interestingly 83.1% think operators will be unable to make a business out of app stores as the consumer electronics manufacturers do not need to make money in the stores, only in the devices they sell.  With a similar score (84.4%) that operators' app stores must focus on applications that use their network, as all other applications will be commoditized by the consumer electronics manufacturers.  Some good steer on where operators should focus their efforts.

Nearly 80% think the trend of operators sharing networks will increase from radio towers and access equipment, to sharing complete networks.  Only the services layer and billing will be unique.  

There was more of a split on the question "An incumbent operator's ability to have an engineer at a customers' home potentially with their purchased consumer electronics, e.g. buy the TV at Amazon and have it delivered and set up by the operator.  Means operators can make a business out of home network solutions and services."  With 67% agreeing and 22% disagreeing.

"Churn will increase once all operators offer triple/quad play?"  had strong disagreement of 55%. This is an interesting discussion point, currently bundling does reduce churn.

Generally neutral response to "Canoe Ventures, the US cable industries attempt to work with the advertising industry on targeted advertising, will be a success."  I thought the neutral response was in part mobile / converged operators being unaware of Canoe, but MSOs had a similar profile.  So a cause for concern in the industry for being able to find a way to make targeted advertising work in a meaningful way for advertisers.  Then on which operators can make advertising work, the bias is towards mobile operators rather than cable. 

This was just a bit of fun, but I hope provides some insight into what the industry is thinking at the moment, a PDF of the results is available here.

In a previous weblog article, "Unmuddling APIs, Developer Communities, Developers, Third Parties, App Stores, App Warehouses, and Widgets....."  I discussed the confusion around the terms and set out some of the categories of third parties that could use operators' APIs:

• 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.

What I'm seeing in the market is because of the current confusion a serious mistake is being made, most operator API initiatives are trying to use their developer community as customers with the wrong business model.  The problem is their developer community is full of developers looking for the operator to be a channel to market, and expect to share in the revenue stimulated, not be "nickeled and dimed" on APIs,  Apple and Google do not charge for their APIs.  Operators are missing the bulk of the potential customers for the network APIs, those third parties with their own channel to market who just want to use the operator as a network.

So operators need to look at two sets of API business models:

• One for third parties with their own channel to market with straight forward API charges that discount in volume (enabling a wholesale model); and
• A pure revenue share model for developers looking to use them as a channel to market.

If an operator wants to make its API business successful, and not a fashion accessory, operators needs to sell their network APIs to third parties with their own channel to market.  This is not a developer community, these third parties will not come to the operator.  These third parties are paying their hard earned cash, they're business customers and must be treated as such.  Some of the example services enabled by network APIs include communication enabled business processes, M2M, home security, and content charging using the mobile account.  Operators need to package a number of solutions together and get out there and sell what their APIs can do.

If operators do not want to dirty their hands by having to sell their APIs, they need to get partners on board such as Kore Wireless (M2M), HomeCamera (security), Voicesage (CEBP), Oracle, and SAP as soon as possible.  Critically, operators must make make clear their API business models (both of them) and go to market plans for the different groups of third parties to stop the current confusion and frustration.

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?