This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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
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
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
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
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
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.
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.
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.
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.
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.