The notion of a service-oriented architecture (SOA) that encouraged componentized software, standardized interfaces for easy substitution of network elements, and made applications composable was pretty popular with everyone in IT. But it was downright fascinating in the world of telecom.
Two years ago, you couldn't read about a product or a standard in telecom without finding "SOA" plastered over the work. But things may be changing, and for some, SOA is losing luster in the telecom space. The biggest challenge seems to be coming up with an implementation model using SOA that also meets some of the emerging and critical telecom business goals.
Wikipedia says that SOA "provides methods for systems development and integration where systems group functionality around business processes and package these as interoperable services." At that level, it's hard to argue the value of SOA, but questions at a deeper and more practical level started emerging at some telecoms several years ago, and they seem to center on three key issues.
Three key SOA issues for telecom service providers
Issue 1: The level of componentization that is best for the application is the first issue for service providers. If we presume SOA is grouping functionality around business processes, the componentization of SOA is the componentization of the processes it defines. Where componentization is high, reuse of components is facilitated. But as the number of components grows, so does the potential risk that orchestration of the application will create massive overhead. One operator reported that taking an application and componentizing it first at a rather low level (into about 100 components) and second at a high level (into about 10 components) created a performance difference of 10,000%.
Performance now matters more than ever before to service providers because the number of consumer broadband and mobile customers, and the number of relate...
To continue reading for free, register below or login
To read more you must become a member of SearchTelecom.com
d service requests per customer, is exploding. Effective service automation has to be scalable to the scope of the customer base, and if the execution of SOA-based applications is too inefficient, it creates an ever-increasing demand for servers and data centers. But too little componentization could mean that useful software tools might not be exposed for reuse, which would raise costs.
Issue 2: The nature of the interface between components is the second issue. Web services used by search engines, social networks and other Web 2.0 companies are typically very simple, providing for the exchange of an XML template through the Web's HTTP protocol. Web services used by many service providers have tended to adopt the relatively heavyweight SOAP/WS standards. These standards are harder to develop, more expensive in terms of resources, and more complicated to sustain in operations. The impact of heavyweight interfaces on performance is clear, but the biggest issue for service providers is that the growing Web developer community obviously prefers the simpler Web 2.0 approaches.
As service providers move toward exposing service features through third-party access programs like that of the GSMA, they must expose those features in a way that developers will support. Most have looked with some envy at the success of Apple's iPhone developer program or Facebook and Google programs. These programs are based on very simple Web 2.0 interfaces that contrast sharply with service provider interfaces based on SOAP or Parlay. The wrong interfaces could destroy any hope of service partnership.
Issue 3: The level of abstraction supported by the SOA model is the third issue. Service providers sell and support services in a logical hierarchy. You can buy a "data" service, and that data service may have a number of technology choices for its implementation. Each choice may have multiple vendors whose equipment must be provisioned and managed to create and sustain the service. Thus, the service provider might like to sell "DataLine," which could be an IP tunnel, a frame relay virtual circuit, and so on. In the "IP tunnel" category, it might be an SSL tunnel, an MPLS LSP, and so on. Each of these might involve several vendors.
A highly abstract model would decompose the service as it is explained here and thus would insulate commercial processes like sales and support from the details of the equipment used for implementation. A model with limited abstraction might expose vendor-specific parameters at a high level, making the whole operations process specific to the equipment used.
Positive SOA steps for service providers
Service providers aren't alone in their SOA concerns. Enterprise SOA is not moving as fast as supporters had hoped, and some experts have even said that the whole SOA movement at the enterprise level is in trouble. The challenge for service providers is that they probably have no choice but to make SOA work. Most of the operations standards and service delivery platforms are based on SOA, making the service provider sector perhaps the most dependent of all on developing a successful and implementable SOA model.
The good news is that SOA principles support exactly the kind of model that providers are looking for. Implementation confusion is more likely to be the problem with SOA than a basic failure of the concept itself. The bad news is that enterprise experience and disappointment with SOA shows that a company can't just commit itself to SOA and expect to gain its benefits. Without effective planning on how to use SOA -- and how far to take it -- it's just as possible to create problems as to create profits.
One clear positive step for service providers to take is to get a full business-wide SOA strategy from at least one key vendor to use as a baseline. Don't assume that an SDP SOA approach, an OSS/BSS SOA approach, and a service management SOA approach can be harmonized. And don't try to create a strategy by assembling vendor SOA components. This doesn't commit the organization to that full-SOA vendor, but it does provide a blueprint that helps organize SOA planning. Components can then be inserted into the blueprint to take advantage of SOA flexibility in substituting elements of software.
Another positive step is to create a clear boundary between exposing services to third parties and the creation and operation of those services internally. It's unreasonable to think that Web developers or over-the-top players would buy into complex SOA strategies for each of the service providers they'd probably have to support.
With proper planning, SOA commitments already made or being made by service providers can succeed and capture significant benefits in cost control and service flexibility for the future.
About the Author: Tom Nolle is president of CIMI Corporation, a strategic consulting firm specializing in telecommunications and data communications since 1982. He is a member of the IEEE, ACM, Telemanagement Forum, and the IPsphere Forum, and he is the publisher of Netwatcher, a journal in advanced telecommunications strategy issues. Tom is actively involved in LAN, MAN and WAN issues for both enterprises and service providers and also provides technical consultation to equipment vendors on standards, markets and emerging technologies. Check out his SearchTelecom networking blog Uncommon Wisdom.
