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!

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.
 

As mentioned in a previous aricle on virtualization I use SaaS (Software as a Service) and PaaS (Platform as a Service) interchangeably as I remain unconvinced of the difference from a customer's perspective.  The cloud computing market size, depending upon how it's defined, is estimated to be about $50B by 2011, of which 70% is in PaaS/SaaS, 30% in IaaS (Infrastructure as a Service).

Within PaaS we must define the focus of the platform, e.g. web applications, CRM applications, billing applications or SDP.  Google, through its App Engine offer, enables businesses to host their websites and data in the Cloud and enable them to use services like BigTable. The two things are important to note:  you can only host python applications as of today and you pay per bandwidth, storage and CPU used for hosting this web application; and you can easily integrate with other Google Services and Google Accounts.

Amazon does not offer a way to host web applications on the Cloud, but simply provides virtualized hardware (IaaS).  The main IaaS providers I see in the market are: Amazon, Joyent, Flexiscale, Reckspace, f5 and GoGrid (plus there are lots of brokers and niche providers).  The savings come through economies of scale and statistical multiplexing to give a higher average processor utilization (>50%) compared to a typical 10-20% untilization within an enterprise, generally a factor of between 5-7 in savings is possible, which is significant.

So the choice a customer makes between IaaS and PaaS needs to analyze:

•  Vendor Lock-in: if you deploy on Google or Microsoft Clouds, you make a choice on both technologies and with which services you'd like to integrate;
•  Ease of Use: deploying a web application is easier to do than deploying and managing a complete infrastructure; and
•  PaaS or IaaS: do you want the Cloud Provider to offer you a way to host your applications (if you can accommodate with their technical restrictions) or an infrastructure allowing you to host your applications (without restrictions) the way you want?

Operators pour money into their data centres and custom systems integration; Vodafone Live as a great example of a vast custom CDM (Content Delivery Management) development with little to show in service differentiation or lower operational costs.  Today, suppliers such as Ericsson and IMIMobile (see this previous article) offer content delivery management as a PaaS, smaller operators have widely adopted this approach.  

I think this trend will naturally extend to the SDP as operators look to minimize investment in large speculative SI projects.  Hence, there is an immediate business opportunity for the NEPs (Network Equipment Provider) to deliver a PaaS SDP, especially to small and medium sized operators or operators undergoing rapid growth.   A PaaS approach allows the operator to flexibly customize their platform to react to local market conditions, while taking advantage of the 5-7 times cost advantage of using a cloud based approach.

However, for both IaaS and PaaS the critical issue is SLAs (Service Level Agreement), this is going to be a critical barrier for many operators.  SLAs within the data center are easy; the challenge comes for the end-to-end SLA (which includes the WAN, and enterprise network availability.)  Here the need for remote infrastructure to monitor and manage link availability in partnership with operators is essential, as well as integrate into the existing network infrastructure.  SLAs are one of the reasons Google is investing in undersea optical capacity and other global optical infrastructure, to enable it to get preferential access to global connectivity to offer its cloud services with a global SLA.  Some operators are in an advantageous position, they can provide the WAN SLA, hence why I think PaaS in telco is an interesting opportunity especially for SDP.

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 :)