I would like to thank Jeroen Visser from BT for his suggestion of this article to explain SOA, SDP and IMS; and then explain how they fit together.

Service Oriented Architecture Defined

SOA (Service Oriented Architecture) has emerged as a successful integration framework for BOSS (Business and Operational Support Systems) within operators.  We are now witnesses that success driving SOA into the services layer of operators.  But what is SOA?

SOA is just an evolution of distributed computing and modular programming.  It’s an IT (Information Technology) architecture (note, it does not specify the technology for its implementation) enabling the creation and execution of business processes, packaged as services, throughout their lifecycle.  The promise of SOA is that the marginal cost of creating the nth application is near zero, as all of the software required exists to satisfy the requirements of other applications. Only orchestration is required to produce a new application.  From a telco perspective it’s a flexible architecture that enables service innovation, mass customization and leverages an IT standard, avoiding yet another expensive ‘telco-special.’

SOA defines the IT infrastructure to allow different applications to exchange data to form business processes, e.g. a “new employee set-up process” that could require services from multiple IT platforms, ordering of equipment (e.g. phone, mobile and PC), etc. SOA separates these functions into distinct units “services,” which can be distributed over a network and can be combined and reused to create new business applications, e.g. “temporary employee set-up process.” These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.

OASIS (the Organization for the Advancement of Structured Information Standards) defines SOA as the following:
A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

Services are unassociated units of functionality, which have no calls to each other embedded in them.  This causes some confusion from a telco perspective as services are what customers pay for, so the term SOA services is often used to differentiate from end-customer services. SOA services typically implement functions such as filling out an online application for an account, viewing an online bank statement, or placing an online booking or airline ticket order. Instead of services embedding calls to each other in their source code, protocols are defined which describe how one or more services can talk to each other. This architecture then relies on a business process expert to link and sequence services, in a process known as orchestration, to meet a new or existing business system requirement.

Underlying and enabling all of this is metadata which is sufficient to describe not only the characteristics of these services, but also the data that drives them. Generally web services are used to implement the SOA.  A web service refers to clients and servers that communicate using XML messages that follow the SOAP standard. In such systems, there is often machine-readable description of the operations offered by the service written in the Web Services Description Language (WSDL), and Universal Description, Discovery and Integration (UDDI) is used to discover those services.  In SOA’s implementation XML has been used extensively to create data which is wrapped in a description container. The services themselves are typically described by WSDL, and communications protocols by SOAP, with UDDI being used to discover those services.

However, SOA is not tied to a specific technology.  It can be implemented using a wide range of technologies, including SOAP, REST, RPC, DCOM, CORBA, Web Services or WCF. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without a service having fore-knowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.

Of course nothing stays the same.  Advanced SOA or SOA 2.0 is the “the next-generation version of SOA” combining service-oriented architecture and Event Driven Architecture (EDA).  An event is simple a change of state, e.g. new employee contract signed, which then triggers an business process.  Building applications and systems around an event-driven architecture allows these applications and systems to be constructed in a manner that facilitates responsiveness, because event-driven systems are, by design, able to cope with unpredictable and asynchronous environments.  EDA is complementary to SOA as its just adding the triggers to start processes and enable processes to adapt to changing circumstance, i.e. exist in the real world.

And finally on the practical application of these concepts, some of the issues are:

• Complexity – SOA is very flexible, perhaps too flexible, SOA service definitions do result in capabilities being misinterpreted.
• Security – security at the service level is not appropriate; it must be managed at the network level.
• Interoperability – as it’s an architecture the implementation allows lots of opportunities for many incompatibilities between vendor implementations.  So when a vendor claims SOA compliance, the response is ‘So what!’  SOA compliance does not guarantee interoperability of services between operators, or even interoperability between SOA-based functions within an operator.
• Processing power – its important to implement what is necessary, do not build a ‘Grand Architecture,’ build lean.
• Hype – the standards are still evolving, and will continue to do so.  Hence build lean as next year or within 18 months the implementation will need to evolve to remain competitive.

Service Delivery Platform Defined

What is a ‘service delivery platform’?  It really depends upon with whom you are talking.  Are they a vendor trying to sell IMS (IP Multimedia Subsystem); or a Java games download platform; or an operator responsible for value-added communication services, IPTV, or content service?  Each will likely give quite different answers.  Service delivery platforms have a long history; their roots can be traces to the FN (Feature Node) that emerged in the intelligent network (IN) concept defined by the ITU-T (International Telecommunications Union) back in the 1980s.  In the FN a SCE (Service Creation Environment) enabled operators to create new communication services without the need to change the software in the exchanges.

This evolved into the IN SDP (Service Delivery Platform), an architecture that enables re-use of service components, that good old chestnut of ‘remove the service silos to save money.’  The benefits of taking a horizontal (layered) approach versus a vertical (stove-pipe) are: faster and cheaper time to market, and enabling service innovation independent of switch vendor.  Most operators have IN implemented in their networks, though most of the SDP implementations tend to be bundled into a specific service implementation, for example caller ring-back tone or prepay billing.  The IN SDP has not achieved the ubiquity of deployment as a re-usable layer within the telecommunication software stack; rather it is a component of a vertical application.  The barrier remains ‘incrementalism’, that is, it is cheaper to deploy service X as a vertical than incur the additional costs of deploying an SDP.

As networks have evolved from circuit-centric to packet-centric, the SDP has extended its
reach beyond communication services, to include content services, streaming services, and even broadcast services.  So the SDP is now positioning across all services and access, an “all-encompassing service delivery architecture”.  But the challenge of ‘incrementalism’ remains.  In addition, there is no one standards body leading the creation of reference SDP architectures or implementation norms.  Currently, we’re seeing initiatives for vendor-specific frameworks, or common application-network interfaces within an operator group.

There are a number of standards bodies working in the SDP space including Parlay, Open Mobile Alliance (OMA) Service Environment (OSE) and the TMF’s SDF TeleManagement Forum’s (TMF) Service Delivery Framework (SDF).  There are many other service layer initiatives including Product and Service Assembly Initiative (PSA) which are not covered in this article.  OSA Parlay is part of the 3GPP IMS, and exposes enablers such as presence and call control to applications.  The OSE is as architecture that provides a common structure and rule set for specifying enablers, e.g. presence, location, etc.  The TMF SDF definition provides the terminology and concepts needed to reference the various components involved, such as applications and enablers, network and service exposure, and orchestration. The TMF uses these in the definition of the processes and entities needed for managing the SDF components.

A service delivery platform (SDP) is an IT-based environment, enabling service creation in an environment that does not rely on a specific network element enabler. This need comes from two major trends:  The need to cut costs in the service creation process, in saturated markets service providers want to differentiate through their service offerings; and the need to enable third-party companies to provision services through the service provider environment.  Typically, most SDPs include: service creation environment, service orchestration environment, service execution environment and third-party management.

I abstract this a little further and think of the SDP as having 3 main systems:

• Content Delivery Management: System that ingests, presents and delivers content to customers on their mobiles, STBs (Set Top Boxes), PCs or other devices.
• BOSS integration: Processes associated with service creation, delivery and life-cycling.
• Telco API: Exposing capabilities from the network to operator services, partner/co-branded applications and 3rd party applications.

I find the above definition helps in understanding where a supplier is coming from in their definition of and SDP.  Stepping back from the definitions and functions, as discussed in the article “An Industry At The Crossroads,” the SDP will be the innovation engine in operators.  It will have multiple elements for multiple suppliers, what is critical is not the architecture (as this article shows, we have more than enough of those).  Rather we must focus on the business requirements of service innovation to drive a lean implementation that’s going to evolve far faster than any previous operator platform.

IP Multimedia Subsystem Defined

I’ve talked about the IP Multimedia Subsystem (IMS) in several other articles such as SofNet Day 3, The Divergence of CDMA and UMTS Operators on IMS, SCIM: Its time for operators to sort out the services layer mess, Critical Gap in IMS/SDP business cases.
Simply IMS is an architecture for delivering internet protocol (IP) multimedia sessions (e.g. voice and video) across multiple access networks.  This is done by having a horizontal control layer that isolates the access network from the service layer. Services need not have their own control functions, as the control layer is a common horizontal layer.  Hence why I focus on the IP session control capabilities within IMS and the relevance to operators such as Verizon and Sprint in supporting voice over their EVDO network.

So How Do SOA, SDP and IMS Fit Together?

After that lengthy definition section, summing up how these acronyms fit together:

• IMS is service control for IP multimedia sessions; it sits between the network (transport) and the SDP, think of it being within the control layer of the network.  An operator does not require IMS, but they need IP session control whether it be SIP/soft-switch based or IMS based.
• SDP is service management across content-based and session-based services; think of it as the services layer of the network.  Most operators have SDP components in their network already, they’re just not integrated into a coherent services layer.
• SOA is an architecture the SDP can be based upon that leverages IT volumes.  But as discussed in the definition of SOA, being ‘SOA compliant’ is a bit like saying ‘based on modular software programming techniques.’