Cognition 2.0

A number of telephone companies are undergoing strategic transformation projects. These projects are both expensive and critical to their operations and overall success, and usually revolve around process optimization and service design that allow them to better exploit their capabilities and technical infrastructure. Technologies used in Service Oriented Architectures (SOA) are particularly well suited for this task, as well as proceeding in alignment with industry standards and best practices such as NGOSS, eTOM, and ITIL. As a consultant at TELUS, I have been part of many successful implementations of systems with increasing complexity, but have also witnessed and been part of projects aimed at revamping applications that are reaching their end of life and don't meet the necessary conditions for supporting operations beyond their current use and scope.

It is precisely in this context that this blog attempts to address a central piece of business transformation that is both obvious, but often disregarded as a by-product of data modeling. This piece revolves around the concept and meaning of a service ID. In fact, as part of the new SID model, we now need to concentrate on and identify not only the common services that are being provided to customers, such as Data, Voice, TV, Email, etc., which belong to the Customer Facing Services category, or CFS. Since proper modeling and separation of concerns is one of the goals of SID and NGOSS as a function of business transformation processes, Resource Facing Services, or RFS, represent a different kind of service that customers often don't see or even know about. In many cases, and ideally so, CSRs shouldn't even be concerned about RFS, only CFS. So what are RFS?

RFS are system abstractions that map CFS to network resources, or any resource both logical and physical. This abstraction is to be interpreted as 'resource usage' or consumption by actual CFS instances and should be treated the same as any other instance in terms of lifecycle and management process. As such, RFS constitute service instances that reserve, assign, or consume resources on the network that are essential for providing services that are tangible to the customer and that are paid for.

Many would agree that the success of a service provider pivots on the following core issues:

• Time to market new products
• Service delivery and order management
• Resource utilization
• Operational costs
• Quality of service
• Service assurance

The IT Infrastructure Library (ITIL) provides best practices designed to promote quality computing services and for managing services in all their stages. The ITIL v3 'Core Volumes' address the following areas:

• Service Strategy
• Service Design
• Service Transition
• Service Operation
• Continuous Service Improvement

These areas of concern of ITIL are the same as the lifecycle requirements for services, both CFS and RFS. In this sense, you can see the dependencies between the ITIL core volumes and the providers' core issues, and how important it is for service providers to follow the ITIL best practices for service design and implementation.

In particular, and returning to the main topic of the blog, RFS selection and implementation should align to ITIL recommendations in order to support the core issues we outlined. Specifically, service IDs are unique identifiers of particular types of services required to interact with necessary resources on the network. Furthermore, service IDs are abstract keys to globular service information and their underlying resources. This globular service information can also contain other service IDs from resources that are linked or form part of a cluster or 'higher order' service.

Let's take an example to illustrate the importance of the above mentioned service design. For example, let's take the case of a Service Provider (SP) that offers Triple Play (3P) services to its customers. As such, it either owns the required infrastructure or it leases it from an ILEC. In either case, the CFS will be the Voice, the High Speed Internet, and the TV service and other optional services such as email, or web hosting, or music, etc. As far as network resources required to provision the services, the SP will need to provide connectivity to the customer location. For that it will need to verify and assign:

• the capabilities of the physical infrastructure connecting the customer's address to a Central Office, or service circuit
• a port on the DSLAM with the necessary capacity requirements
• a transport circuit or VLANs from the POP to the distribution network (BRAS, Soft Switch, Video Servers)
• all required logical resources, i.e. telephone number, IP address, email address, video content or channels, etc.

Since all of the above mentioned resources are assigned to the services they support, there must be a handle to be able to change them when necessary, or by request from the customer or from other consumers of the resources, including other systems supporting the SP's operations. From the above shopping list, it would be only natural to create RF services for each of the items, i.e.:

• a service circuit RF service
• a port RF service
• one or more VLAN RF services that can be mapped to the corresponding circuits
• as many RF services to consume the required logical resources

The advantages of this model, besides that it follows and extends the TM Forum's SID model, it also allows for optimal use of resources and for proper process engineering enterprise-wide. The main reason for that is the ability to decompose requests for the required resources into RF service orders and instances that reflect their status and have pre-defined workflows for fulfillment and exception handling. Furthermore, as these processes are pre-defined they can also be triggered in parallel, hence avoiding latency and complex dependencies.

From the relatively simplistic example above, we have seen that creating RF services for individual network resources, both logical and physical, provide a level of abstraction that isolates the finer grained atomic resource allocation and construction from the customer facing service activation, hence allowing for minimal latency, and bottom-up workflow orchestration and order decomposition that works closely with canned network resources and operational processes.

So, to the question at the beginning of this entry, service IDs are then communicable pieces of information about the state of the services and resources that provide reusable components of a subscriber's service. They act as buffers that provide a unique handle to those resources, but that also isolate upstream services from changes in the resources as a result of assurance or network upgrade and modernization. This way, rather than communicating the actual resource values to the entire SP eco-system, only the service IDs are shared and consumed by both operations personel, interested systems and coupled processes.