services domain status report issue 1 table of contents, figures, and foreword

© ALAN QUAYLE BUSINESS AND SERVICE DEVELOPMENT

THE SERVICES DOMAIN. MARKET STATUS,

CASE STUDIES, ANALYSIS AND

RECOMMENDATIONS.

AN INDEPENDENT AND QUANTIFIED

REVIEW OF WHAT IS HAPPENING WITH THE

SERVICES DOMAIN IN THE TELECOMS

INDUSTRY. THE TERM SDP (SERVICE

DELIVERY PLATFORM) IS NOT USED.

THIS IS NO TIME TO WORRY ABOUT BEING

A“DUMB-PIPE.” OPPORTUNITY IS

EVERYWHERE!

A L A N Q U A Y L E B U S I N E S S A N D S E R V I C E D E V E L O P M E N T


ISSUE 1. FEBRUARY 2012

2 OF 267

CONTENTS

FOREWORD 10

WHY WRITE THIS REPORT? AREN’T THERE ENOUGH ANALYST REPORTS OUT THERE

ALREADY? 10 STRATEGIC CONTEXT 12

ACKNOWLEDGEMENTS 15

EXECUTIVE SUMMARY 16

TELECOM REVENUES: INCREASING UNCERTAINTY 17 DEFINING THE SERVICES LAYER 23 WHY NETWORK / WEB APIS MATTER TO OPERATORS 27 MARKET SURVEY RESULTS 30 CASE STUDY LEARNING 38 TELEFONICA 38 ETISALAT 41 API STANDARDIZATION 42 RECOMMENDATIONS 43 BUSINESS REQUIREMENTS ARE AN ESSENTIAL PREREQUISITE: WITHOUT THEM DO NOT

ATTEMPT A SERVICES DOMAIN PROJECT 44 PEOPLE (IN BOTH THE OPERATOR AND VENDOR) ARE CRITICAL TO PROJECT SUCCESS 44 UNDERSTAND THE 4 MAIN BARRIERS, AND FOCUS ON OVERCOMING THEM 45 TALK TO OTHER OPERATORS: OUTSIDE OF THE VENDORS’ CONTROL 45 OTHER PROJECT RECOMMENDATIONS 46 PROCESS RECOMMENDATIONS 47 SERVICES DOMAIN FUNCTIONALITY / TECHNOLOGY RECOMMENDATIONS 48 API RECOMMENDATIONS 48 A FINAL NOTE 49

INTRODUCTION AND BACKGROUND 50

STRATEGIC CONTEXT 50 DEFINING THE SERVICES DOMAIN 53

APIS AND WHY THEY MATTER TO OPERATORS 57

WHERE’S THE MONEY IN NETWORK APIS? 59 OPERATOR ADVANTAGES WITH NETWORK APIS 61



3 OF 267

MISCONCEPTIONS AND HOME TRUTHS 62 RECOMMENDATIONS ON ENGAGING DEVELOPERS 63

SERVICES DOMAIN MARKET SURVEY RESULTS 66

ANALYSIS OF RESPONDENTS 66 OPERATOR ANALYSIS 66 SUPPLIER ANALYSIS 68 SERVICES DOMAIN PROJECT STATUS 70 VENDOR RATINGS 72 ROLE OF SERVICES DOMAIN 75 BARRIERS TO THE SERVICES DOMAIN 79 BUSINESS DRIVERS FOR THE SERVICES DOMAIN 80 SERVICES DOMAIN PRICING 83 OTHER ISSUES 86 STRATEGIC QUESTIONS 87 ARE SERVICES TRENDING AWAY FROM THE NETWORK AND INTO THE CLOUD? 87 SERVICES DOMAIN IN THE CLOUD? 92 IS THE SERVICES DOMAIN TOO LITTLE TOO LATE? 93 IS LTE IMPACTING THE SERVICES DOMAIN? 95 CAN SERVICES LAYER OR SERVICES DOMAIN BECOME AN ACCEPTED TERMS TO BREAK WITH THE

PAST SDP? 96 HOW DOES IMS FIT IN THE SERVICES DOMAIN? 96 API ROADMAP AND WAC (WHOLESALE APPLICATION COMMUNITY) WHAT’S WORKING WHAT IS

NOT? 97 IS THE MULTI-LAYER MULTI-COUNTRY SERVICES LAYER THE ANSWER FOR MOST OPERATOR

GROUPS? THAT IS USING SOA TO IMPLEMENT A DISTRIBUTED SERVICES LAYER ARCHITECTURE

TO NATIONAL, REGIONAL AND GLOBAL CAPABILITIES? WHAT ARE YOUR EXPERIENCES WITH

SUCH DEPLOYMENTS? 98 IS SOA (SERVICE ORIENTED ARCHITECTURE) OR WOA (WEB-SERVICES ORIENTED

ARCHITECTURE) THE RIGHT APPROACH FOR AN OPERATOR'S SERVICES LAYER? SHOULD

OPERATORS FOLLOW THE LEAD OF ENTERPRISES OR OF WEB-BASED SERVICE PROVIDERS LIKE

AMAZON? 99 PROJECT QUESTIONS 100 WHAT IS THE PROJECT SIZE? WHAT IS THE SPLIT IN CAPEX / OPEX? IS IT A SINGLE PROJECT, OR

A NUMBER OF PROJECTS? 100 WHAT IS MOTIVATING THE PROJECT SPEND? 102 WHAT IS THE TYPICAL RETURN ON INVESTMENT 102 WHAT ARE THE ISSUES / BARRIERS IN GETTING A SERVICES LAYER PROJECT STARTED? 103 ARE THERE SPECIFIC EXAMPLES ON WHERE IMPROVEMENTS ARE NEEDED TO ACCELERATE

MIGRATION TO A SERVICES DOMAIN? 104 WHERE ARE THE SERVICES DOMAIN PROJECTS: ONE TRACK, STALLED, ACCELERATED? 104 SERVICES QUESTIONS 105 DOES THE SERVICES DOMAIN DEAL WITH COMMUNICATION SERVICES LIKE UNIFIED

COMMUNICATIONS, PUSH TO TALK, HD VOICE, VIDEO COMMUNICATIONS, RCS, M2M, IPTV,

ETC. OR IS THAT LEFT TO A SEPARATE PLATFORM? IF SO WHO MANAGES THAT? WHY IS THE

SERVICES LAYER NOT INCLUDING ALL SERVICES OFFERED BY THE OPERATOR? 105



4 OF 267

IS THE OPERATOR’S APP STORE STILL RELEVANT? ARE YOU USING THE SERVICES DOMAIN TO

IMPLEMENT AN OPERATOR SPECIFIC APP STORE? WHAT IS ITS FOCUS AND DIFFERENTIATION

COMPARED TO THE OVER THE TOP APP STORES? 106 WHAT DO YOU CONSIDER TO BE THE BIGGEST DIFFERENCES BETWEEN DEVELOPED AND

DEVELOPING MARKETS ON THE SERVICES DOMAIN REQUIREMENTS? ARE TECHNOLOGIES

DIFFERENT, ARE THE SERVICES DIFFERENT, ARE THE PRICE POINTS DIFFERENT, IS THE LEVEL OF

AUTOMATION DIFFERENT? 107 WHAT IS YOUR VIEW ON RCS? 107 KEY POINTS FROM THE MARKET SURVEY 110

CASE STUDIES 121

INTRODUCTION 121 TELEFONICA CASE STUDY 123 TELEFONICA BACKGROUND 123 TELEFONICA AND AGILE DEVELOPMENT 124 GLOBAL TELEFÓNICA UNICA SDP 125 RECAPITULATION OF SOA 127 INTEGRATION WITH THE IT DOMAIN: ESB FEDERATION 132 BLUEVIA AND THE LONG TAIL 134 WHY BLUEVIA IS GETTING IT RIGHT 139 APLICATECA: ENTERPRISE STORE 139 KEY POINTS 142 ETISALAT SDP 146 ETISALAT BACKGROUND 146 ETISALAT STRATEGY 146 ETISALAT SDP 150 KEY POINTS 152 OI BRASIL CASE STUDY 154 OI BACKGROUND 154 OI STRATEGY 154 OI SDP 155 KEY POINTS 159 OPENCLOUD AND SOFTBANK AND TELKOMSEL CASE STUDIES: ROLE OF THE SERVICE

BROKER 160 SOFTBANK MOBILE MULTIPLE NUMBER, SINGLE PHONE/SINGLE IDENTIFY SERVICE 160 TELKOMSEL CHARGING SENTINEL & LOCATION SERVER 162 SAUDI TELECOM GROUP SERVICE DELIVERY FRAMEWORK 164 BACKGROUND 164 APPROACH 165 SERVICE DELIVERY FRAMEWORK BUSINESS CASE 166 CHALLENGES 167 KEY POINTS 168 MOBILY SDP 170 BACKGROUND 170 APPROACH 171 KEY POINTS FROM MOBILY CASE STUDY 176



5 OF 267

HSENID MOBILE: ETISALAT ROLLS OUT WORLD’S 1ST CLOUD ENABLED TELCO

APPLICATION PLATFORM 177 BACKGROUND 177 SUCCESS MEASURES OF APPZONE 179 REVENUE MODEL 180 ENGAGING DEVELOPERS 181 HSENID’S CLOUD TELECOM APPLICATION PLATFORM (TAP) 181 KEY POINTS 182 RANCORE TECHNOLOGIES: OPEN SOURCE IN THE SERVICES DOMAIN 184 VODAFONE WEB SERVICES ORIENTED ARCHITECTURE 186 KEY POINTS 190 TELENOR SDP 192 KEY POINTS 196 NETWORK API SUCCESS: TELECOM ITALIA 198 NETWORK API SUCCESS: AIRCEL 200 NETWORK API SUCCESS: VERIZON 202 VOXEO: OVER THE TOP AND COMPLEMENTARY REAL-TIME API ECOSYSTEM 206 HUAWEI CASE STUDIES 208 BACKGROUND 208 MEGAFON 209 CHINA MOBILE 211 AMERICA MOVIL 213 TATA DOCOMO 214 API STANDARDIZATION 216 OMA (OPEN MOBILE ALLIANCE) 216 GSMA ONEAPI 218 M2M AND THE SERVICES DOMAIN 223 BACKGROUND 223 OPERATOR IT BATTLE IN M2M 224 FINAL NOTE ON ENTERPRISE AND THE SERVICES DOMAIN 228 KEY POINTS FROM THE CASE STUDIES 229 TELEFONICA 229 ETISALAT 232 OI (BRASIL) 233 SOFTBANK AND TELKOMSEL CASE STUDIES: ROLE OF THE SERVICE BROKER 234 SAUDI TELECOM 235 MOBILY 236 ETISALAT SRI LANKA 236 RANCORE 236 VODAFONE 237 TELENOR 238 TELECOM ITALIA 239 AIRCEL 239 VERIZON 240 VOXEO 240 HUAWEI CASE STUDIES 240 API STANDARDIZATION 241 MACHINE TO MACHINE 242



6 OF 267

RECOMMENDATIONS 243

BUSINESS REQUIREMENTS ARE AN ESSENTIAL PREREQUISITE: WITHOUT THEM DO NOT

ATTEMPT A SERVICES DOMAIN PROJECT 244 PEOPLE (IN BOTH THE OPERATOR AND VENDOR) ARE CRITICAL TO PROJECT SUCCESS 244 UNDERSTAND THE 4 MAIN BARRIERS, AND FOCUS ON OVERCOMING THEM 245 TALK TO OTHER OPERATORS: OUTSIDE OF THE VENDORS’ CONTROL 245 OTHER PROJECT RECOMMENDATIONS 246 PROCESS RECOMMENDATIONS 247 SERVICES DOMAIN FUNCTIONALITY / TECHNOLOGY RECOMMENDATIONS 248 API RECOMMENDATIONS 248 A FINAL NOTE 249

APPENDIX 1: SERVICES DOMAIN QUESTIONNAIRE 251

SDP (SERVICES DOMAIN) QUESTIONNAIRE 2011/2012 251 STRATEGIC QUESTIONS 251 PROJECT QUESTIONS 251 SERVICE QUESTIONS 252 OTHER QUESTIONS 252 GENERAL QUESTIONS 252

APPENDIX 1 – ACRONYMS 257

APPENDIX 2 – COMPANIES INTERVIEW 264

OPERATORS 264 SUPPLIERS 266



7 OF 267

TA B L E O F F I G U R E S Figure 1. The Network, IT and Services Domains (plus the Customer) ........................................................10 Figure 2. The Network, IT and Services Domains (plus the Customer) ........................................................16 Figure 3. Estimates of Compound Annual Growth Rates for 2013 are Becoming Increasingly Uncertain ..19 Figure 4. Time Frame for when Voice Will Become ‘Just an App’ on the Network ......................................19 Figure 5. Time Frame for when SMS will become ‘just an app’ on the Network ..........................................21 Figure 6. Optimistic View of Total Telecom Revenue ...................................................................................22 Figure 7. Pessimistic View of the Total Telecom Revenues (ignore VAS) .....................................................23 Figure 8. The Three Components of the Services Domain ............................................................................25 Figure 9. Simplified Diagram of the Functions and Technology Supporting the Services Domain .............26 Figure 10. Comparison of Voice MINUTES (not revenue) for all international Phone Traffic and Skype

(source TeleGeography) ................................................................................................................................51 Figure 11. Example of Apple’s iMessage’s Impact for one iPhone Customer (source Neven Mrgan) .........51 Figure 12. Estimates of Compound Annual Growth Rates for 2013 are Becoming Increasingly Uncertain 52 Figure 13. The Three Components of the Services Domain ..........................................................................55 Figure 14. Simplified Diagram of the Functions and Technology Supporting the Services Domain ...........56 Figure 15. APIs and the Industries Using Them (Numbers from 2011, source Programmable Web) ..........58 Figure 16. How Twilio Presents its API to Developers (source Twilio) .......................................................58 Figure 17. Example API Business Models (source Programmable Web) ....................................................59 Figure 18. Operator Geography ...................................................................................................................66 Figure 19. Role of Operator Respondent ......................................................................................................67 Figure 20. Operator Respondent View on OpCo’s Economic Zone ..............................................................68 Figure 21. Supplier Type ...............................................................................................................................69 Figure 22. Role within Supplier ....................................................................................................................69 Figure 23. Operator Responses to the Question on Services Domain Project Status ...................................70 Figure 24. Supplier Responses to the Question on Services Domain Project Status.....................................71 Figure 25. Worldwide SDP Revenue (source Infonetics August 2011) .........................................................71 Figure 26. Top Application Drivers for the SDP (source Infonetics August 2011) .......................................72 Figure 27. Vendor Ratings (Reverse Alphabetical) 4-Good, 3-Average, 2-Poor ..........................................73 Figure 28. Vendor Awareness (Percentage of times vendor was rated) .......................................................74 Figure 29. Magic Quadrant Markey Survey from 2010 on Group SDP ........................................................75 Figure 30. Role of the Services Domain Across Operators in Developed and Developing Markets ............77 Figure 31. Operator Responses to Application of their Services Domain Deployments (Data for Figure 30)

.......................................................................................................................................................................78 Figure 32. Barriers to the Services Domain ..................................................................................................79 Figure 33. Data for Barriers to the Services Domain shown in Figure 32 ...................................................80 Figure 34. Operators’ Drivers for the Services Domain ...............................................................................81 Figure 35. Data for Operators Drivers for the Services Layer shown in Figure 34 .....................................82 Figure 36. Top Business Drivers for SDP (source Infonetics) ......................................................................83 Figure 37. Pricing Structure for Services Domain Projects..........................................................................85 Figure 38. Reasons for Project Overrun ......................................................................................................85 Figure 39. Reasons for Difficulty in Funding the next Round of the Project ................................................86 Figure 40. Time Frame for when Voice will become ‘just an app’ on the Network ......................................88 Figure 41. Time Frame for when SMS will become ‘just an app’ on the Network .......................................90 Figure 42. Optimistic View of Total Telecom Revenue .................................................................................91 Figure 43. Pessimistic View of the Total Telecom Revenues (ignore VAS) ...................................................91 Figure 44. Frequency of Existing Project Approval Process Inadequacies ................................................101 Figure 45. Factors Motivating Project Spend ............................................................................................102 Figure 46. Barriers to Getting the Project Started .....................................................................................104 Figure 47. Time Frame for when Voice will become ‘just an app’ on the Network ....................................114 Figure 48. Time Frame for when SMS will become ‘just an app’ on the Network .....................................115



8 OF 267

Figure 49. Optimistic View of Total Telecom Revenue ...............................................................................116 Figure 50. Pessimistic View of the Total Telecom Revenues (ignore VAS) .................................................117 Figure 51. Telefonica Operations (source Telefonica)...............................................................................123 Figure 52. Telefonica’s View on the Changes in the Telecoms Industry .....................................................124 Figure 53. Service Availability Across the Telefonica Group (2009/2010).................................................126 Figure 54. High Level View of the Global SDP Interfaces..........................................................................127 Figure 55. Why SOA (in fact most IT) Projects Fail ...................................................................................129 Figure 56. Before and After SOA Vision ....................................................................................................130 Figure 57. Conceptual View of a Typical SOA Implementation (source TIBCO) .......................................131 Figure 58. Example SOA Implementation ...................................................................................................131 Figure 59. High Level Architecture of the Global SDP...............................................................................132 Figure 60. Enterprise Service Bus Federation between the Services domain and IT Domain ....................133 Figure 61. UNICA Project recommendation on ESB Federation ...............................................................134 Figure 62. Blue Via Process (source Telefonica) .......................................................................................136 Figure 63. BlueVia Approach in Sharing Revenues with Developers (source Telefonica) .........................137 Figure 64. BlueVia Developer Segmentation (source Telefonica) ..............................................................138 Figure 65. twitea.me Service (source Telefonica) .......................................................................................139 Figure 66. Aplicateca Marketplace User Interface (source Telefonica) .....................................................140 Figure 67, High Level View of Aplicateca Marketplace (source Telefonica) ..............................................140 Figure 68. Support Model behind Aplicateca (source Telefonica) ..............................................................141 Figure 69. Etisalat Countries of Operation .................................................................................................146 Figure 70. Etisalat Marketing Vision (source Etisalat) ..............................................................................147 Figure 71. SDP Business Drivers (source Etisalat) ....................................................................................147 Figure 72. More Details on the Business Drivers (source Etisalat) ............................................................149 Figure 73. SDP Revenues (source Etisalat) ................................................................................................150 Figure 74. High Level View of the Etisalat SDP (source Etisalat)..............................................................152 Figure 75. SDP is implemented with Ericsson (source Etisalat) .................................................................152 Figure 76. Oi’s Network Strategy (Source Oi) ............................................................................................155 Figure 77. Oi SDP, High Level View (source Oi) .......................................................................................156 Figure 78. Oi SDP Architecture (source Oi) ...............................................................................................157 Figure 79. Emergency SMS Request Case Study (Source Oi) .....................................................................158 Figure 80. Dynamic SIM Card Allocation Case Study (Source Oi) ............................................................158 Figure 81. SoftBank’s Multiple Number, Single Phone/Single Identify Service ..........................................161 Figure 82. Telkomsel Charging Sentinel and Location Server Implementation ..........................................163 Figure 83. Saudi Telecommunication Group Operations (Source STC) .....................................................164 Figure 84. STC’s Business Objectives (Source STC) .................................................................................165 Figure 85. STC’s Approach to Raising Revenue (Source STC) ..................................................................166 Figure 86. STC’s SDP (Source STC) ..........................................................................................................168 Figure 87. Mobily’s Data Evolution (Source Mobily) ................................................................................170 Figure 88. Mobily Account Management Application (Source Mobily) .....................................................171 Figure 89. Mobily’s Applications (Source Mobily) ....................................................................................172 Figure 90. Mobily’s Cross-Platform App Store (Source Mobily) ...............................................................172 Figure 91. Drivers for Mobily’s SDP (Source Mobily) ..............................................................................173 Figure 92. SDP Project Timeline (Source Mobily) ....................................................................................174 Figure 93. Mobily’s SDP Interfaces (Source Mobily) ................................................................................174 Figure 94. Services based on User Preference (Source Mobily) ................................................................175 Figure 95. Lean Operation via the SDP (Source Mobily) ..........................................................................176 Figure 96. App Store Template....................................................................................................................178 Figure 97. USSD Screen Sample .................................................................................................................179 Figure 98. Etisalat Mobile Application Forum ...........................................................................................181 Figure 99. hSenid Cloud Telco Application Platform ................................................................................183 Figure 100. Types of Services (source Vodafone) ......................................................................................186 Figure 101. API Distribution (source Vodafone) ........................................................................................187



9 OF 267

Figure 102. Internet Service Dilemma (Source Vodafone) .........................................................................188 Figure 103. Network, IT and Services Domains (source Vodafone) ...........................................................189 Figure 104. Target Architecture (source Vodafone) ...................................................................................190 Figure 105. Telenor Group .........................................................................................................................192 Figure 106. How the Old CPA Worked (source Telenor) ..........................................................................193 Figure 107. Telenor CPA Website (source Telenor) ...................................................................................194 Figure 108. Telenor CPA Renewal (source Telenor) .................................................................................195 Figure 109. CPA Renewal Main Suppliers (source Telenor) .....................................................................195 Figure 110. Breadth of Service Exposure Models (source Telecom Italia) .................................................198 Figure 111. Breadth of Capabilities Exposed (source Telecom Italia) ......................................................199 Figure 112. Telecom Italia’s SDP 2.0 Architecture (source Telecom Italia) .............................................199 Figure 113. Pocket Apps Experience (source Aircel) .................................................................................200 Figure 114. Aircel’s APIs (source Aircel) ..................................................................................................201 Figure 115. Verizon Service Control Gateway Architecture (Source Verizon) ..........................................203 Figure 116. Location‐enhanced Call Center and IVR Applications ............................................................204 Figure 117. Hosted IVR Platform Vendors (Source Ovum) ........................................................................206 Figure 118. Huawei Software Division’s Approach to Innovation ............................................................209 Figure 119. MegaFon Core Communications Roadmap .............................................................................210 Figure 120. China Mobile’s Strong Position within China’s Content Industries .......................................211 Figure 121. Role of SDP within China Mobile ............................................................................................212 Figure 122. Business Impact of SDP ..........................................................................................................213 Figure 123, America Movil’s Multi-Screen Video Situation .......................................................................214 Figure 124. Business Impact of Tata DoCoMo’s SDP ...............................................................................215 Figure 125. GSMA OneAPI Version One Capabilities (Source GSMA) .....................................................219 Figure 126. GSMA OneAPI Version Two Capabilities (Source GSMA) ....................................................219 Figure 127. M2M Addressable Devices .....................................................................................................223 Figure 128. Main M2M Components and Market Segments ......................................................................224 Figure 129. Simplified M2M Solution .........................................................................................................225 Figure 130. M2M Pricing Challenge: Value per bit varies Greatly (source Deutsche Telekom) ..............225 Figure 131. M2M Pricing Challenge: Requirements vary Greatly (source Deutsche Telekom) .................226 Figure 132. Components of an M2M Solution ...........................................................................................228



10 OF 267

FOREWORD

WHY WRITE THIS REPORT?

AREN’T THERE ENOUGH ANALYST REPORTS OUT THERE ALREADY?

In this report the term Services Domain is used instead of SDP (Service Delivery Platform) as it is simply too ill-defined; abused by suppliers; and limits its scope by presuming a box with interfaces. Operators today are implementing new organizations (e.g. Telefonica Digital) built with new people, new processes and new IT-centric systems so they can deploy new services faster, maintain / improve legacy services at lower cost, and respond to the external environment faster.

Depending on the operator's situation the services domain can vary from a global multilayer, multi-country architecture; through an extension of the existing back-office SOA (Service Oriented Architecture); to a web-centric, hybrid cloud-based infrastructure. The services domain has become as important as the network domain and the IT domain (business and operational support systems), to the future success of Telcos.

Figure 1 shows a simple graphic of the three domains1 that make up an operator’s business, and how they related to the customer’s experience. A customer can have multiple devices connected to different access networks yet still be able to access their services, applications or content. Specifically, a video chat service works on the TV (assuming its video communications enabled as we’re seeing at CES 20122), smartphone, tablet, laptop and desktop; just like Skype does today across a customer’s devices.

Figure 1. The Network, IT and Services Domains (plus the Customer)

1 The external environment is not included in the diagram for simplicity; it’s an underlying assumption of the report that the services domain enabled operators as an organization to better respond to the external environment.

2 Consumer Electronics Show, http://ces.cnet.com/

http://ces.cnet.com/



11 OF 267

This report brings together over two decades of experience from being at the bleeding-edge of service innovation in telecoms. An important point to note in my experience is I work for both operators and suppliers in building the new businesses discussed in this report, hence I bring direct objective experience not opinion formed from web-based desk research of biased marketing materials. Producing a report is not something I typically do for a number of reasons: people tend not to want to pay for reports as their vendors provide free consulting services; and analyst firms in co-operation with the vendors (the analysts’ main source of revenue) produce free reports and guidance.

Unfortunately people ignore the vested interests behind such free advice; you get what you pay for, unless of course you’re the product for sale3. So if making money from this report is going to be difficult, why bother? Simply, the gap between what is discussed in private in the industry and what is presented in the industry press has never been so wide in my opinion. Someone's got to try to act as the industry's conscience to close this gap, so I'm having a go given my independence from trying to sell network equipment or maintain the Telco’s share price this quarter.

The share of voice in our industry is dominated by the vendors; the messages in that voice have a singular purpose, encourage operators to buy more network stuff. We’ve seen it in 3G/UMTS (Universal Mobile Telecommunications System) and IMS (IP Multimedia Subsystem) and are currently seeing it on LTE (Long Term Evolution), VoLTE (Voice over LTE) and RCS / RCSe (Rich Communications Suite)4. As an industry we need to spend more pragmatically, being first to launch something is not necessarily the wisest move. Announcing yet more confusing terms to customers such as LTE or VoLTE or RCS or RCSe5 or some flavor of 4G, without a clear meaningful customer benefit is simply wasting cash we increasingly cannot afford to waste. We’re going to need to start tightening our belts and make pragmatic investment decisions that impact our customers’ experiences not network bragging rights.

To be fair, operators are not innocent in the challenges facing our industry. Bell Labs research and innovation and similar Telco led research around the world died a long time ago in operators; when I started my career in BT over 20 years ago I realized within a couple of months of starting the job that research was near irrelevant to the organization.

3 See cartoon at the end of this weblog entry on ‘Facebook and You’, http://www.alanquayle.com/blog/2011/10/sdp-global-summit-2011-highlig.html

4 Note there is significant confusion around RCS and RCSe within the market. RCSe is quite different in user proposition than RCS. RCSe is a subset of RCS but with more implementation guidelines. It maintained the name RCS to some extent for purely political reasons, to avoid making a clear separation from the work of the past, which given its different user proposition would have helped in removing some confusion in the market. This will be discussed in more detail in the survey results.

5 In fact many in the industry are confused on these acronyms as revealed in the market survey. If the industry is confused, how can the customer be anything other than confused? In the US T-Mobile offers 4G to its customers using HSPA, while Verizon offers 4G LTE. Neither are technically 4G according to telecommunication standards. Hopefully we can find a customer-centric mid-point between all the acronyms and the way Apple quietly added iMessage to iOS5, yet started substituting high margin SMS revenues with lower margin data revenues from operators.



12 OF 267

Today operator R&D (Research and Development) is performed in reviewing requests for information and participation in the many overlapping standards bodies. Some standards are critically important to telecoms and are fundamental to its success, but we’ve taken a good thing too far so that as an industry we waste resources in irrelevant, long, wasting debates, which are in the limit solved by vendors with much frustration about the obsolesce and overload of requirements. But this report is not aimed at discussing the broader problems we face on the effectiveness and efficiency of our industry, I just highlight this point to be even handed that both operators and suppliers have a share in the problems we face.

Services are critical to the industry’s past, and will be to its future. We obsess about being a “dumb pipe” while there are opportunities everywhere that we choose not to grasp, or grasp in embarrassing self-focused ways that inevitably result in failure. As an industry we’ve never really had to develop business6, customers came to us. In the emerging competitive environment business development is going to be critical, and this is part of the services domain.

The services domain is distinct and must be managed differently from the network and IT domains. Simply, the network and IT domains cannot fail, the network must remain up, and that mantra influences everything through to how projects are evaluated based on the certainty of commercial success. While for the services domain its focus is innovation, failure at least in the market is essential to innovation, this will be explored in more detail through the case studies. Just look at our track record over the past two decades in our inability to grasp this simple concept. It’s no longer about technology, people and processes must change before technology if we are to successfully implement the services domain.

My aim with this report is to bring together the successes we’re seeing in the market through a series of case studies, an independent survey of the market to capture the reality of where we are and what we are planning, with a set of independent recommendations on how we can move forward and better nurture service innovation rather than kill it.

STRATEGIC CONTEXT

As the telecom industry moves into a new phase where revenue growth slows because voice and messaging services have matured and internet access growth begins to slow, the focus is turning to the increasing role unregulated services play in operators’ future revenue and margin growth, traditionally called VAS (Value Added Services).

The bulk of a Telco’s spending today remains solidly in the network and IT domains, and marketing the brand (operators are marketing-focused not sales-focused businesses). However, operators are beginning to make, albeit small, investments in structuring their business to better support service innovation; that is across people, processes and technology. This business-led initiative requires a services domain, a component of an operator’s operations equivalent to the network and IT (BOSS (Business and Operational Support Systems)) domains, as shown in Figure 1.

6 Except in the more IT-centric part of enterprise services offered from operators.



13 OF 267

Regulation will remain a strong force in telecoms. Operators in many markets continue to release pricing plans that demonstrate a lack of competitive forces, or terms and conditions that would not be possible in a competitive market. Also the focus of many national governments on universal broadband access as a social right and creator of national wealth will maintain regulatory oversight on operators for at least the next decade.

The term value added services (VAS) has been in use for over 50 years in the telecoms industry, and reflects the voice bias of the industry. In that there is voice, and anything else is a value add on top of the voice service. This is a legacy term that does not represent the rich diversity of services operators can offer such as home monitoring, unified communications, enterprise application stores, cloud storage, document management and collaboration, payTV, etc. VAS as a term should be laid to rest. There are regulated and unregulated services; growth will come from unregulated services, and this is where we must invest through the services domain. Specifically it is price regulation, as all services are subject so some form of regulation, for simplicity I use the term regulated and unregulated in this report with the assumption I’m referring to price regulation.

Another important trend in the industry is the ITization7 to telecoms. This goes beyond the origin of the specific standards in use and the increasing role of software, but into the processes and methods used to build the business. The Open Group with TOGAF (The Open Group Architecture Forum) has brought together the thought leadership of the IT industry to define the steps required to make IT projects work. In TOGAF the first step is the business architecture, and that is the approach we’re taking in focusing on the services domain. It is not a box, like an SDP (Service Delivery Platform), or an IT architecture like SOA (Service Oriented Network). The Services domain is a solution to the business problem of being able to deliver better services to customers faster, lowering the cost of operating and improving legacy services, and responding to the external environment faster.

Business requirements define the services domain more than any piece of technology. Taking such an approach is not intuitively obvious to many in the telecoms industry, with its long history of building national networks based on specialized technology and global standards. But as the pipes get fatter, and the services that drive the bulk of the telecoms revenues (voice and messaging) become just apps, what is means to be a service provider is changing.

Governance is a fundamental issue that continues to retard the implementation and success of the services domain. The IT and network domains, which are starkly different to the services domain, dominate budget spend and revenues within an operator, they consider the services domain to be a tax on their organizations. And similarly the OpCos (Operating Companies within an Operator Group) dominate what they do in-country, and consider group-wide services domain projects to equally be a tax on their hard earned revenues.

The small services domain projects by spend and revenue impact are simply too small for the CEO to be concerned about, and the time frame of their impact is beyond 3 months, hence out of their focus which is the next investor call. Yet that is what is required to enable the change necessary to a services and customer focused organization. Arguments of, ‘it’s strategic’, have been tried before with the SDP and failed. Something different is required.

7 http://www.alanquayle.com/blog/2010/08/more-on-the-the-itization-of-t.html



14 OF 267

There is no obvious answer to this governance issue; else it would already be solved. We’ll review case studies where progress is being made in the implementation of a services domain, but in the limit the future of the services domain and an operator’s relevance to customers beyond internet access are hanging in the balance.

The Web Service Providers and their investors have placed a bet that operators are incapable of change given the dominance of the IT and network domains, and the investor / short-term focus of a Telco CEO, as case studied in the innovator’s dilemma8. It’s up to all of us as an industry to prove them wrong.

8 The term disruptive technologies was coined by Clayton M. Christensen and introduced in his 1995 article Disruptive Technologies: Catching the Wave, which he co-wrote with Joseph Bower. The article is aimed at managing executives who make the funding/purchasing decisions in companies rather than the research community. He describes the term further in his book The Innovator's Dilemma. Innovator's Dilemma explored the cases of the disk drive industry (which, with its rapid generational change, is to the study of business what fruit flies are to the study of genetics, as Christensen was advised in the 1990s) and the excavating equipment industry (where hydraulic actuation slowly displaced cable-actuated movement).

In his sequel, The Innovator's Solution Christensen replaced the term disruptive technology with disruptive innovation because he recognized that few technologies are intrinsically disruptive or sustaining in character; rather, it is the business model that the technology enables that creates the disruptive impact. The concept of disruptive technology continues a long tradition of the identification of radical technical change in the study of innovation by economists, and the development of tools for its management at a firm or policy level. However, Christensen's evolution from a technological focus to a business modeling focus is central to understanding the evolution of business at the market or industry level. For example, Christensen's contemporary emphasis on the applied business model rather than the technology itself was developed by Henry Chesbrough's pioneering notion of Open Innovation.

In keeping with the insight that what matters economically is the business model, not the technological sophistication itself, Christensen's theory explains why many disruptive innovations are not "advanced technologies", which the technology mudslide hypothesis would lead one to expect. Rather, they are often novel combinations of existing off-the-shelf components, applied cleverly to a small, fledgling value network.