PDF of this tutorial
Distributed service-creation models do exist, but they focus primarily on the integration of network-side resources and have ignored the integration of IT. As new services have begun to proliferate, additional demands to integrate the existing IT back office with distributed resources internal and external to the service provider arise. Competition demands that service providers add new services quickly and on a smaller initial scale. Furthermore, these providers must continue to support such services over time to maintain scalable, available services. Given these technical and economic pressures, existing service models simply do not address the needs of service providers. These providers seek a more systemic approach that is survivable as an investment and is also adaptable for the creation of next-generation services as the market requires them.
Services Development: Challenging and Complex
Services development has always posed a special case for telecommunications companies, because requirements demanded massive levels of scalability, reliability, and real-time interaction with network elements. Service creation demands complex interactions between a detailed set of separate systems—for network events, network software, and back-office applications.
Figure 1 depicts a generic example of a networked service surrounded by application services that form the in-place resources the service model must coordinate. Although the network component is not trivial, back-office integration often makes telecommunication services extremely complex. In many cases, the work truly begins when a service provider sets out to bill for a service and weave together organizational workflow with electronic service information.
Figure 1. Telecom Services Draw from Many Applications and Resources
This type of integration usually happens on a case-by-case basis, differing from carrier to carrier. For example, in a long-distance telephone call, the following interactions take place:
- The customer dials the number.
- The local switch identifies the call as long distance.
- The local switch looks up the customer's record to determine which long-distance company the customer uses and then routes the call to the long-distance switch.
- The long-distance switch looks up the number in the signaling database to determine the point code of the switch nearest to the called party and connects to this switch.
- The local switch rings the destination telephone, and the called party picks up phone and begins the conversation.
- The destination phone hangs up; the circuit is disconnected.
- The long-distance switch generates a CDR.
- The local (originating) switch generates a CDR for access billing to the long-distance company.
This relatively familiar example suggests that services require complex interactions with networks, IT, and customers. Much of the mechanics of this telephone call involve network and switch resources, but there are several other key systems. Provisioning is the process of setting up service or, in this case, populating a database with the proper long-distance information for a given customer. Billing, which will be at the core of our later discussion, involves generating a statement from the CDR; often, several bills are generated from a single call, including billing between carriers.
The Benefits and the Limits of IN
First-generation service creation and network management solutions used service-creation environments (SCEs) with proprietary-based component frameworks. The predominant example of this is the intelligent network (IN). Developed in the 1980s, the IN was an attempt to overcome the inherent limitations and costs present in the mainframe-like proprietary services model by defining standardized, off-switch service components.
Figure 2 depicts the role of the IN in the service development model. The centerpiece of the model is the service creation environment for automated modeling and generation of real-time service management software. The model has been largely successful because it has allowed the service providers to utilize the generic call control functionality of switches as a resource for the development of new, independently managed services. For example, the IN environment allows carriers to deliver seamless 800 number services across a heterogeneous switching environment and interconnections.
Figure 2. Consolidating Service Development Resources Using IN
As a framework for services such as wireless, calling card, and virtual private network (VPN), the benefits of the IN services model include the following:
- lower cost—One key benefit is the ability to leverage new advances in computing by deploying off-switch architectures on commercially available computing platforms.
- resource consolidation—Another benefit is a greater degree of control, including the ability to use existing development tools to tailor services for specific requirements and to perform network management with heterogeneous switching assets.
SCEs allow reusable service logic to be shared from one service to another. However, these approaches have tightly coupled service logic to the target system, primarily because the original services for which they were developed were based on proprietary systems that operated on-switch, in much the same manner as mainframe IT. Each IN service is crafted separately, requiring custom integration with its own stovepiped set of constituent back-office components.
Although IN has offered a labor-saving approach to the development of applications, it has completely omitted the task of integrating services with back-office systems for billing, provisioning, network management, and customer care. Service providers have cost-effective mediation devices to manage data formats and network elements, but these devices did not extend beyond the single-system model because installations were proprietary. Change was difficult, and interoperability was low. Indeed, it has been almost impossible to leverage back-office resources across separate service lines.
Accelerated Life Cycle Expectations
Based on discussions with a diverse group of operations professionals, the consensus is that next-generation services represent a new and different challenge. Particularly adamant about this are competitive local exchange carriers (CLECs). CLECS and new national network providers are situated at the forefront of this new marketplace, offering a host of telephone, data, and Internet services. There are corresponding demands on service-provider operations groups to roll out new services quickly and, at the same time, integrate complex workflow processes within a multivendor environment. Despite many advances in systems and software-development tools, service providers—large as well as small—are playing a game of catch-up. Competitive pressures are forcing service providers to generate incremental revenues from existing customers, which necessitates developing services quickly to capture immediate market opportunities. In this process, the cost-recovery expectation of supporting and maintaining new service launches is becoming increasingly uncertain.
Past services have been developed using very costly and long-term project management approaches. Today, the financial profile of services projects is beginning to look very different. Figure 3 indicates a major concern of service-provider engineers everywhere: the need to support ongoing projects requiring adaptable service definitions (i.e., services that are rolled out one after another and that constantly evolve).
Figure 3. Project Break-Even Time Has Become Much Shorter
Next-Generation Services Requirements
As a result of the changes in the market, the requirements set for telecommunications services is beginning to look different from the original conditions that gave rise to IN. The new application services framework must support the following operational needs:
- shorter launch times—Service deployment lifecycles are measured in months, not years.
- smaller per-project revenues—Each service will generate lower initial revenues than a traditional service.
- faster return on investment—Each project must become profitable, quickly.
- support for successive product launches—Services will build upon each other's successes using adaptive processes.
- consolidation—Services must be able to work together and can be bundled easily by using service-provider IT resources.
- customer interaction—Enterprises especially require that they be able to self-configure services automatically.
Traditional approaches to services development—even INs—have lacked the ability to address these fast-turnaround project requirements. Another shortcoming is that there is no extensibility of resources created for one service in order to develop another. Note that in Figure 3 there are no efficiencies shown in launching a second (quite often a follow-on) service. An ideal solution to this problem would offer a high degree of change tolerance, and it should be easy to expand on a service investment through a succession of individual service projects.
This task is compounded by the old rule of telecom operations: Public network services must still be designed for continuous operations and have the following built-in network and application-level aspects:
- robustness and reliability
- performance and scalability
Managers cannot afford multiyear development schedules using large development staffs of the past. Uniting network and enterprise domains into a common logical service framework is paramount for success, as enterprise and public network services merge. To meet the changing market, complex application services must be aligned and managed across interconnected, networked facilities.
