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

ALAN QUAYLE BUSINESS AND SERVICE
DEVELOPMENT

TH 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 QUANTIFIED
REVIEW 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

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

2 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

3 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

4 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
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
MACHINE TO MACHINE 242

5 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

6 OF 267


TA BLE O F FI GU RE 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

7 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

8 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

9 OF 267


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

1The 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/

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

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

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

12 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

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

14 OF 267

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

Recommended

Recommended

More Related Content

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

Similar to Services Domain Status Report Issue 1 Table of Contents, Figures, and Foreword (20)

More from Alan Quayle

More from Alan Quayle (20)

Recently uploaded

Recently uploaded (20)

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