And, inevitably, has come the global industry initiative to make it all official and boost the case for applications. In this case it’s the Wholesale Applications Community (WAC) , which “aims to unite a fragmented marketplace and create an open industry platform that benefits everybody – from applications developers and network operators to mobile phone users themselves.”
Launched during the hoopla of Mobile World Congress in February, the WAC so far embraces 24 service providers and three mobile device vendors, all big names in the mobile business. (See MWC 2010: Operators Form WAC Pack for Apps Push.) So it is serious stuff.
It’s them again
As is often the case with telecom services, much of the initial impetus for this movement has come from outside the telecom industry. Service providers generally have watched agog as Apple Inc. (Nasdaq: AAPL)’s iTunes AppStore has hit stratospheric levels of downloads and applications choice, as millions of users have demonstrated that, at last, here is something that they are prepared to buy in quantity – and something that telecom service providers could offer, too.
Certainly, the expansion and impact of Apple’s AppStore has been phenomenal. From its launch in mid-2008 it had grown to over 140,000 third-party applications by 2010, generating around 2 billion downloads (and numbers of dollars of the same order). According to AdMob Inc. , which serves banner and text-link ads on mobile Web pages for more than 15,000 mobile sites and applications globally, in December 2009 36 percent (about 1.5 billion) of global ad requests on its network were made by iPhones or iPod Touch devices, with the majority of requests due to apps.
“Major carriers have gone with SDP initiatives in the 2008/9 timeframe, whereas in 2007 they were still kind of scratching their heads and asking whether there was really a business case, and would people really use these applications,” says Joe C. Dyoub, worldwide solution manager for the HP Inc. (NYSE: HPQ) SDP Service Governance Framework (SGF). “What Apple did was to make a lot of those naysayers in marketing departments into believers. Now they view data services and apps as a proven, lucrative market moving at warp speed – now we have to do something.”
For Dyoub and many others in the telecom industry, that something is now obvious: Carriers and service providers need to exploit their network and IT assets and capture more of the service or application value chain. Indeed, Service Provider Information Technology (SPIT) is it. (See The SPIT Manifesto.)
Apple’s AppStore, for example, shares the application value between Apple and the developer (an agency business model), while the carrier receives only its normal data-service revenue – and data service plans being bid down by the carriers as they scramble for market share of these new, innovative devices on their respective networks.
“Many of our customers realize that, long term, that is not the best strategy for the communication provider. They would like to get to a more controlled environment where they can add their own value, their own differentiation to the subscriber experience,” says Dyoub. “And an SDP, because of its services-oriented architecture, RESTful Web 2.0 service exposure, and ability to bring in [telecom things] like location services, billing services, charging – whether prepay or postpay – and subscriber persona will help to differentiate the carrier from just being a pure bit pipe and hosting over-the-top services.”
In short, SDPs are a central component in the transformation of telecom network providers into more complex value-added service and application providers.
The exposure problem
But, if telecom service providers are going to steal Apple’s thunder by using SDPs to create their own agency business models with app developers and achieve differentiation by allowing telecom/subscriber attributes and capabilities to be included in apps, they have some problems to overcome. Primarily, developers need to master telecom APIs that give access to network capabilities, and these are notoriously recondite to non-telecom software developers. Further, there is a host of security, performance, and other issues to address before the engineering department will allow hordes of third-party developers loose on the communication provider’s network.
The access aspect is further complicated because just about every operator that already exposes its network capabilities to third-party developers has, for historical and business reasons, taken a different approach. Some are already based on SOAP/XML interfaces, while others have used Parlay X, or native interfaces, XML interfaces like the LIF MLP standard for location, and others use their own SDKs. But REST (Representational State Transfer) – hence RESTful as an adjective – has now emerged as an API approach that is very easy for third-party developers to use, as it is based entirely on a restricted set of widely used and understood standards – basically, HTTP.
“RESTful SDPs are fast becoming the preferred method for accessing subscribers and resources for a given service provider,” says Jaime Palmer, senior director of technology for BroadSoft Inc. “Primarily because it is lightweight, does not require advanced software development skills and permits for rapid application development. This is in contrast to other protocols such as SOAP that are still widely used, but better suited to perform transactional messaging such as provisioning or back-end systems integration.”
So SDP vendors now have a strong motive for making their products RESTful, and this Who Makes What thus takes a look at what this means for SDP products and their vendors’ approaches. However, caution is needed, because SDP is a very elastic term and can embrace a wide range of functions and, therefore, hardware and software products to implement them.
“More and more what we are seeing is that operators are creating a service delivery platform which is not a single box; it’s a complete environment based around an integration technology,” says Graham Cobb, director of service delivery marketing at Telcordia Technologies Inc. “Telcordia and companies like us supply the real-time systems that enable interactive services, whilst IBM or Oracle are building those environments and putting in some basic components such as a gateway function. Then services and service enablers are exposed, noting that one man’s service is another man’s enabler.”
So readers should resist the idea that an SDP is necessarily a single, well defined product like a server/software combination that can be ordered from a catalogue. And even if some can be, there are all the associated requirements for BSS/OSS, data management, charging/billing, e-commerce, ads, customer management, personalization, and so on that are needed to make third-party applications fly in a commercial environment.
The lack of a product archetype is somewhat unfortunate for a Who Makes What, and so the approach taken here is to take a fairly relaxed view as to what is, or is not, a true SDP, and to consider a fairly broad span of types of SDP and SDP-related products. Preemptively, the answer to your PR firm's "Why isn't my client's box/solution/magic dust included?" will have to be, for now, 'I dunno.' "
Here’s a hyperlinked contents list:
- Page 2: What I – SDPs
- Page 3: What II – RESTful Technology
- Page 4: Another Angle – Hosted/Managed-Services Providers
- Page 5: Vendors & Products
- Page 6: Vendor Angles & Activities I
- Page 7: Vendor Angles & Activities II
- Page 8: Vendor Angles & Activities III
Next Page: What I – SDPs