Services Domain Status Report Issue 1 Table of Contents, Figures, and Foreword

ALAN QUAYLE BUSINESS AND SERVICE DEVELOPMENTTH E S E RV I CE S D OM A IN. M A RKE T S TATU S, C A S E STU D I ES, A N A LYS I S AND R E C OM M E NDATI ON S. AN INDEPENDENT AND QUANTIFIEDREVIEW OF WHAT IS HAPP ENING WITH THE SERVICES DOMAIN IN THE TELECOMS INDUSTRY. THE TERM SDP (SERVICE DELIVERY PLATFORM) I S NOT USED.THIS IS NO TIME TO WORRY ABOUT BEING A“DUMB-PIPE.” OPPORTUNITY IS EVERYWHERE! © ALAN QUAYLE BUSI NESS AND SERVICE DEV ELOPMENT

© ALAN QUAYLE BUSINE SS AND SERVICE DEVEL OPMENT ISSUE 1. FEBRUARY 20 12 CONTENTSFOREWORD 10WHY WRITE THIS REPORT? AREN’T THERE ENOUGH ANALYST REPORTS OUT THEREALREADY? 10STRATEGIC CONTEXT 12ACKNOWLEDGEMENTS 15EXECUTIVE SUMMARY 16TELECOM REVENUES: INCREASING UNCERTAINTY 17DEFINING THE SERVICES LAYER 23WHY NETWORK / WEB APIS MATTER TO OPERATORS 27MARKET SURVEY RESULTS 30CASE STUDY LEARNING 38TELEFONICA 38ETISALAT 41API STANDARDIZATION 42RECOMMENDATIONS 43BUSINESS REQUIREMENTS ARE AN ESSENTIAL PREREQUISITE: WITHOUT THEM DO NOTATTEMPT A SERVICES DOMAIN PROJECT 44PEOPLE (IN BOTH THE OPERATOR AND VENDOR) ARE CRITICAL TO PROJECT SUCCESS 44UNDERSTAND THE 4 MAIN BARRIERS, AND FOCUS ON OVERCOMING THEM 45TALK TO OTHER OPERATORS: OUTSIDE OF THE VENDORS’ CONTROL 45OTHER PROJECT RECOMMENDATIONS 46PROCESS RECOMMENDATIONS 47SERVICES DOMAIN FUNCTIONALITY / TECHNOLOGY RECOMMENDATIONS 48API RECOMMENDATIONS 48A FINAL NOTE 49INTRODUCTION AND BACKGROUND 50STRATEGIC CONTEXT 50DEFINING THE SERVICES DOMAIN 53APIS AND WHY THEY MATTER TO OPERATORS 57WHERE’S THE MONEY IN NETWORK APIS? 59OPERATOR ADVANTAGES WITH NETWORK APIS 61 2 OF 267

© ALAN QUAYLE BUSINE SS AND SERVICE DEVEL OPMENT ISSUE 1. FEBRUARY 20 12MISCONCEPTIONS AND HOME TRUTHS 62RECOMMENDATIONS ON ENGAGING DEVELOPERS 63SERVICES DOMAIN MARKET SURVEY RESULTS 66ANALYSIS OF RESPONDENTS 66OPERATOR ANALYSIS 66SUPPLIER ANALYSIS 68SERVICES DOMAIN PROJECT STATUS 70VENDOR RATINGS 72ROLE OF SERVICES DOMAIN 75BARRIERS TO THE SERVICES DOMAIN 79BUSINESS DRIVERS FOR THE SERVICES DOMAIN 80SERVICES DOMAIN PRICING 83OTHER ISSUES 86STRATEGIC QUESTIONS 87ARE SERVICES TRENDING AWAY FROM THE NETWORK AND INTO THE CLOUD? 87SERVICES DOMAIN IN THE CLOUD? 92IS THE SERVICES DOMAIN TOO LITTLE TOO LATE? 93IS LTE IMPACTING THE SERVICES DOMAIN? 95CAN SERVICES LAYER OR SERVICES DOMAIN BECOME AN ACCEPTED TERMS TO BREAK WITH THEPAST SDP? 96HOW DOES IMS FIT IN THE SERVICES DOMAIN? 96API ROADMAP AND WAC (WHOLESALE APPLICATION COMMUNITY) WHAT’S WORKING WHAT ISNOT? 97IS THE MULTI-LAYER MULTI-COUNTRY SERVICES LAYER THE ANSWER FOR MOST OPERATORGROUPS? THAT IS USING SOA TO IMPLEMENT A DISTRIBUTED SERVICES LAYER ARCHITECTURETO NATIONAL, REGIONAL AND GLOBAL CAPABILITIES? WHAT ARE YOUR EXPERIENCES WITHSUCH DEPLOYMENTS? 98IS SOA (SERVICE ORIENTED ARCHITECTURE) OR WOA (WEB-SERVICES ORIENTEDARCHITECTURE) THE RIGHT APPROACH FOR AN OPERATORS SERVICES LAYER? SHOULDOPERATORS FOLLOW THE LEAD OF ENTERPRISES OR OF WEB-BASED SERVICE PROVIDERS LIKEAMAZON? 99PROJECT QUESTIONS 100WHAT IS THE PROJECT SIZE? WHAT IS THE SPLIT IN CAPEX / OPEX? IS IT A SINGLE PROJECT, ORA NUMBER OF PROJECTS? 100WHAT IS MOTIVATING THE PROJECT SPEND? 102WHAT IS THE TYPICAL RETURN ON INVESTMENT 102WHAT ARE THE ISSUES / BARRIERS IN GETTING A SERVICES LAYER PROJECT STARTED? 103ARE THERE SPECIFIC EXAMPLES ON WHERE IMPROVEMENTS ARE NEEDED TO ACCELERATEMIGRATION TO A SERVICES DOMAIN? 104WHERE ARE THE SERVICES DOMAIN PROJECTS: ONE TRACK, STALLED, ACCELERATED? 104SERVICES QUESTIONS 105DOES THE SERVICES DOMAIN DEAL WITH COMMUNICATION SERVICES LIKE UNIFIEDCOMMUNICATIONS, 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 THESERVICES LAYER NOT INCLUDING ALL SERVICES OFFERED BY THE OPERATOR? 105 3 OF 267

© ALAN QUAYLE BUSINE SS AND SERVICE DEVEL OPMENT ISSUE 1. FEBRUARY 20 12IS THE OPERATOR’S APP STORE STILL RELEVANT? ARE YOU USING THE SERVICES DOMAIN TOIMPLEMENT AN OPERATOR SPECIFIC APP STORE? WHAT IS ITS FOCUS AND DIFFERENTIATIONCOMPARED TO THE OVER THE TOP APP STORES? 106WHAT DO YOU CONSIDER TO BE THE BIGGEST DIFFERENCES BETWEEN DEVELOPED ANDDEVELOPING MARKETS ON THE SERVICES DOMAIN REQUIREMENTS? ARE TECHNOLOGIESDIFFERENT, ARE THE SERVICES DIFFERENT, ARE THE PRICE POINTS DIFFERENT, IS THE LEVEL OFAUTOMATION DIFFERENT? 107WHAT IS YOUR VIEW ON RCS? 107KEY POINTS FROM THE MARKET SURVEY 110CASE STUDIES 121INTRODUCTION 121TELEFONICA CASE STUDY 123TELEFONICA BACKGROUND 123TELEFONICA AND AGILE DEVELOPMENT 124GLOBAL TELEFÓNICA UNICA SDP 125RECAPITULATION OF SOA 127INTEGRATION WITH THE IT DOMAIN: ESB FEDERATION 132BLUEVIA AND THE LONG TAIL 134WHY BLUEVIA IS GETTING IT RIGHT 139APLICATECA: ENTERPRISE STORE 139KEY POINTS 142ETISALAT SDP 146ETISALAT BACKGROUND 146ETISALAT STRATEGY 146ETISALAT SDP 150KEY POINTS 152OI BRASIL CASE STUDY 154OI BACKGROUND 154OI STRATEGY 154OI SDP 155KEY POINTS 159OPENCLOUD AND SOFTBANK AND TELKOMSEL CASE STUDIES: ROLE OF THE SERVICEBROKER 160SOFTBANK MOBILE MULTIPLE NUMBER, SINGLE PHONE/SINGLE IDENTIFY SERVICE 160TELKOMSEL CHARGING SENTINEL & LOCATION SERVER 162SAUDI TELECOM GROUP SERVICE DELIVERY FRAMEWORK 164BACKGROUND 164APPROACH 165SERVICE DELIVERY FRAMEWORK BUSINESS CASE 166CHALLENGES 167KEY POINTS 168MOBILY SDP 170BACKGROUND 170APPROACH 171KEY POINTS FROM MOBILY CASE STUDY 176 4 OF 267

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

© ALAN QUAYLE BUSINE SS AND SERVICE DEVEL OPMENT ISSUE 1. FEBRUARY 20 12RECOMMENDATIONS 243BUSINESS REQUIREMENTS ARE AN ESSENTIAL PREREQUISITE: WITHOUT THEM DO NOTATTEMPT A SERVICES DOMAIN PROJECT 244PEOPLE (IN BOTH THE OPERATOR AND VENDOR) ARE CRITICAL TO PROJECT SUCCESS 244UNDERSTAND THE 4 MAIN BARRIERS, AND FOCUS ON OVERCOMING THEM 245TALK TO OTHER OPERATORS: OUTSIDE OF THE VENDORS’ CONTROL 245OTHER PROJECT RECOMMENDATIONS 246PROCESS RECOMMENDATIONS 247SERVICES DOMAIN FUNCTIONALITY / TECHNOLOGY RECOMMENDATIONS 248API RECOMMENDATIONS 248A FINAL NOTE 249APPENDIX 1: SERVICES DOMAIN QUESTIONNAIRE 251SDP (SERVICES DOMAIN) QUESTIONNAIRE 2011/2012 251STRATEGIC QUESTIONS 251PROJECT QUESTIONS 251SERVICE QUESTIONS 252OTHER QUESTIONS 252GENERAL QUESTIONS 252APPENDIX 1 – ACRONYMS 257APPENDIX 2 – COMPANIES INTERVIEW 264OPERATORS 264SUPPLIERS 266 6 OF 267

© ALAN QUAYLE BUSINE SS AND SERVICE DEVEL OPMENT ISSUE 1. FEBRUARY 20 12 TA BLE O F FI GU RE SFigure 1. The Network, IT and Services Domains (plus the Customer) ........................................................10Figure 2. The Network, IT and Services Domains (plus the Customer) ........................................................16Figure 3. Estimates of Compound Annual Growth Rates for 2013 are Becoming Increasingly Uncertain ..19Figure 4. Time Frame for when Voice Will Become ‘Just an App’ on the Network ......................................19Figure 5. Time Frame for when SMS will become ‘just an app’ on the Network ..........................................21Figure 6. Optimistic View of Total Telecom Revenue ...................................................................................22Figure 7. Pessimistic View of the Total Telecom Revenues (ignore VAS) .....................................................23Figure 8. The Three Components of the Services Domain ............................................................................25Figure 9. Simplified Diagram of the Functions and Technology Supporting the Services Domain .............26Figure 10. Comparison of Voice MINUTES (not revenue) for all international Phone Traffic and Skype(source TeleGeography) ................................................................................................................................51Figure 11. Example of Apple’s iMessage’s Impact for one iPhone Customer (source Neven Mrgan) .........51Figure 12. Estimates of Compound Annual Growth Rates for 2013 are Becoming Increasingly Uncertain 52Figure 13. The Three Components of the Services Domain ..........................................................................55Figure 14. Simplified Diagram of the Functions and Technology Supporting the Services Domain ...........56Figure 15. APIs and the Industries Using Them (Numbers from 2011, source Programmable Web) ..........58Figure 16. How Twilio Presents its API to Developers (source Twilio) .......................................................58Figure 17. Example API Business Models (source Programmable Web) ....................................................59Figure 18. Operator Geography ...................................................................................................................66Figure 19. Role of Operator Respondent ......................................................................................................67Figure 20. Operator Respondent View on OpCo’s Economic Zone ..............................................................68Figure 21. Supplier Type ...............................................................................................................................69Figure 22. Role within Supplier ....................................................................................................................69Figure 23. Operator Responses to the Question on Services Domain Project Status ...................................70Figure 24. Supplier Responses to the Question on Services Domain Project Status.....................................71Figure 25. Worldwide SDP Revenue (source Infonetics August 2011) .........................................................71Figure 26. Top Application Drivers for the SDP (source Infonetics August 2011) .......................................72Figure 27. Vendor Ratings (Reverse Alphabetical) 4-Good, 3-Average, 2-Poor ..........................................73Figure 28. Vendor Awareness (Percentage of times vendor was rated) .......................................................74Figure 29. Magic Quadrant Markey Survey from 2010 on Group SDP........................................................75Figure 30. Role of the Services Domain Across Operators in Developed and Developing Markets ............77Figure 31. Operator Responses to Application of their Services Domain Deployments (Data for Figure 30).......................................................................................................................................................................78Figure 32. Barriers to the Services Domain ..................................................................................................79Figure 33. Data for Barriers to the Services Domain shown in Figure 32 ...................................................80Figure 34. Operators’ Drivers for the Services Domain ...............................................................................81Figure 35. Data for Operators Drivers for the Services Layer shown in Figure 34 .....................................82Figure 36. Top Business Drivers for SDP (source Infonetics) ......................................................................83Figure 37. Pricing Structure for Services Domain Projects..........................................................................85Figure 38. Reasons for Project Overrun ......................................................................................................85Figure 39. Reasons for Difficulty in Funding the next Round of the Project ................................................86Figure 40. Time Frame for when Voice will become ‘just an app’ on the Network ......................................88Figure 41. Time Frame for when SMS will become ‘just an app’ on the Network .......................................90Figure 42. Optimistic View of Total Telecom Revenue .................................................................................91Figure 43. Pessimistic View of the Total Telecom Revenues (ignore VAS) ...................................................91Figure 44. Frequency of Existing Project Approval Process Inadequacies ................................................101Figure 45. Factors Motivating Project Spend ............................................................................................102Figure 46. Barriers to Getting the Project Started .....................................................................................104Figure 47. Time Frame for when Voice will become ‘just an app’ on the Network ....................................114Figure 48. Time Frame for when SMS will become ‘just an app’ on the Network .....................................115 7 OF 267

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

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

© ALAN QUAYLE BUSINE SS AND SERVICE DEVEL OPMENT ISSUE 1. FEBRUARY 20 12 F O R E WO R D 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 itis 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 operators situation the services domain can vary from a global multilayer,multi-country architecture; through an extension of the existing back-office SOA (Service OrientedArchitecture); to a web-centric, hybrid cloud-based infrastructure. The services domain has becomeas 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, andhow they related to the customer’s experience. A customer can have multiple devices connected todifferent 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 aswe’re seeing at CES 20122), smartphone, tablet, laptop and desktop; just like Skype does today acrossa customer’s devices. Figure 1. The Network, IT and Services Domains (plus the Customer)1The external environment is not included in the diagram for simplicity; it’s an underlying assumption of the report that theservices domain enabled operators as an organization to better respond to the external environment.2 Consumer Electronics Show, http://ces.cnet.com/ 10 OF 267

© ALAN QUAYLE BUSINE SS AND SERVICE DEVEL OPMENT ISSUE 1. FEBRUARY 20 12 This report brings together over two decades of experience from being at the bleeding-edge ofservice innovation in telecoms. An important point to note in my experience is I work for bothoperators and suppliers in building the new businesses discussed in this report, hence I bring directobjective experience not opinion formed from web-based desk research of biased marketingmaterials. Producing a report is not something I typically do for a number of reasons: people tendnot to want to pay for reports as their vendors provide free consulting services; and analyst firms inco-operation with the vendors (the analysts’ main source of revenue) produce free reports andguidance. Unfortunately people ignore the vested interests behind such free advice; you get what you payfor, unless of course you’re the product for sale3. So if making money from this report is going to bedifficult, why bother? Simply, the gap between what is discussed in private in the industry and whatis presented in the industry press has never been so wide in my opinion. Someones got to try to actas the industrys conscience to close this gap, so Im having a go given my independence from tryingto 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 asingular 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 arecurrently 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 tolaunch something is not necessarily the wisest move. Announcing yet more confusing terms tocustomers such as LTE or VoLTE or RCS or RCSe5 or some flavor of 4G, without a clearmeaningful customer benefit is simply wasting cash we increasingly cannot afford to waste. We’regoing to need to start tightening our belts and make pragmatic investment decisions that impact ourcustomers’ experiences not network bragging rights. To be fair, operators are not innocent in the challenges facing our industry. Bell Labs researchand 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 thejob 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.html4 Note there is significant confusion around RCS and RCSe within the market. RCSe is quite different in user propositionthan RCS. RCSe is a subset of RCS but with more implementation guidelines. It maintained the name RCS to some extentfor purely political reasons, to avoid making a clear separation from the work of the past, which given its different userproposition would have helped in removing some confusion in the market. This will be discussed in more detail in thesurvey results.5In 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, whileVerizon offers 4G LTE. Neither are technically 4G according to telecommunication standards. Hopefully we can find acustomer-centric mid-point between all the acronyms and the way Apple quietly added iMessage to iOS5, yet startedsubstituting high margin SMS revenues with lower margin data revenues from operators. 11 OF 267

© ALAN QUAYLE BUSINE SS AND SERVICE DEVEL OPMENT ISSUE 1. FEBRUARY 20 12 Today operator R&D (Research and Development) is performed in reviewing requests forinformation and participation in the many overlapping standards bodies. Some standards arecritically important to telecoms and are fundamental to its success, but we’ve taken a good thing toofar so that as an industry we waste resources in irrelevant, long, wasting debates, which are in thelimit 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 andefficiency of our industry, I just highlight this point to be even handed that both operators andsuppliers 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 inembarrassing self-focused ways that inevitably result in failure. As an industry we’ve never really hadto develop business6, customers came to us. In the emerging competitive environment businessdevelopment 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 ITdomains. Simply, the network and IT domains cannot fail, the network must remain up, and thatmantra influences everything through to how projects are evaluated based on the certainty ofcommercial success. While for the services domain its focus is innovation, failure at least in themarket is essential to innovation, this will be explored in more detail through the case studies. Justlook at our track record over the past two decades in our inability to grasp this simple concept. It’sno longer about technology, people and processes must change before technology if we are tosuccessfully implement the services domain. My aim with this report is to bring together the successes we’re seeing in the market through aseries of case studies, an independent survey of the market to capture the reality of where we are andwhat we are planning, with a set of independent recommendations on how we can move forward andbetter nurture service innovation rather than kill it. STRATEGIC CONTEXT As the telecom industry moves into a new phase where revenue growth slows because voice andmessaging services have matured and internet access growth begins to slow, the focus is turning tothe 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, andmarketing the brand (operators are marketing-focused not sales-focused businesses). However,operators are beginning to make, albeit small, investments in structuring their business to bettersupport service innovation; that is across people, processes and technology. This business-ledinitiative requires a services domain, a component of an operator’s operations equivalent to thenetwork 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. 12 OF 267

© ALAN QUAYLE BUSINE SS AND SERVICE DEVEL OPMENT ISSUE 1. FEBRUARY 20 12 Regulation will remain a strong force in telecoms. Operators in many markets continue torelease pricing plans that demonstrate a lack of competitive forces, or terms and conditions thatwould not be possible in a competitive market. Also the focus of many national governments onuniversal broadband access as a social right and creator of national wealth will maintain regulatoryoversight 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 ontop of the voice service. This is a legacy term that does not represent the rich diversity of servicesoperators 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 laidto 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 allservices are subject so some form of regulation, for simplicity I use the term regulated andunregulated 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 theorigin of the specific standards in use and the increasing role of software, but into the processes andmethods used to build the business. The Open Group with TOGAF (The Open GroupArchitecture Forum) has brought together the thought leadership of the IT industry to define thesteps required to make IT projects work. In TOGAF the first step is the business architecture, andthat 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). TheServices domain is a solution to the business problem of being able to deliver better services tocustomers faster, lowering the cost of operating and improving legacy services, and responding to theexternal environment faster. Business requirements define the services domain more than any piece of technology. Takingsuch an approach is not intuitively obvious to many in the telecoms industry, with its long history ofbuilding national networks based on specialized technology and global standards. But as the pipesget 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 ofthe services domain. The IT and network domains, which are starkly different to the servicesdomain, dominate budget spend and revenues within an operator, they consider the services domainto be a tax on their organizations. And similarly the OpCos (Operating Companies within anOperator Group) dominate what they do in-country, and consider group-wide services domainprojects 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 theCEO to be concerned about, and the time frame of their impact is beyond 3 months, hence out oftheir focus which is the next investor call. Yet that is what is required to enable the change necessaryto a services and customer focused organization. Arguments of, ‘it’s strategic’, have been triedbefore 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 13 OF 267

© ALAN QUAYLE BUSINE SS AND SERVICE DEVEL OPMENT ISSUE 1. FEBRUARY 20 12 There is no obvious answer to this governance issue; else it would already be solved. We’llreview case studies where progress is being made in the implementation of a services domain, but inthe limit the future of the services domain and an operator’s relevance to customers beyond internetaccess are hanging in the balance. The Web Service Providers and their investors have placed a bet that operators are incapable ofchange given the dominance of the IT and network domains, and the investor / short-term focus ofa Telco CEO, as case studied in the innovator’s dilemma8. It’s up to all of us as an industry to provethem wrong.8 The term disruptive technologies was coined by Clayton M. Christensen and introduced in his 1995 article DisruptiveTechnologies: Catching the Wave, which he co-wrote with Joseph Bower. The article is aimed at managing executives whomake the funding/purchasing decisions in companies rather than the research community. He describes the term further inhis book The Innovators Dilemma. Innovators Dilemma explored the cases of the disk drive industry (which, with itsrapid generational change, is to the study of business what fruit flies are to the study of genetics, as Christensen was advisedin the 1990s) and the excavating equipment industry (where hydraulic actuation slowly displaced cable-actuated movement).In his sequel, The Innovators Solution Christensen replaced the term disruptive technology with disruptive innovationbecause he recognized that few technologies are intrinsically disruptive or sustaining in character; rather, it is the businessmodel that the technology enables that creates the disruptive impact. The concept of disruptive technology continues a longtradition of the identification of radical technical change in the study of innovation by economists, and the development oftools for its management at a firm or policy level. However, Christensens evolution from a technological focus to abusiness modeling focus is central to understanding the evolution of business at the market or industry level. For example,Christensens contemporary emphasis on the applied business model rather than the technology itself was developed byHenry Chesbroughs pioneering notion of Open Innovation.In keeping with the insight that what matters economically is the business model, not the technological sophistication itself,Christensens theory explains why many disruptive innovations are not "advanced technologies", which the technologymudslide hypothesis would lead one to expect. Rather, they are often novel combinations of existing off-the-shelfcomponents, applied cleverly to a small, fledgling value network. 14 OF 267

Services Domain Status Report Issue 1 Table of Contents, Figures, and Foreword

by Alan Quayle

Accessibility

Categories

Upload Details

Usage Rights

Statistics