978-1-4244-6705-1/10/$26.00 ©2010 IEEE

Operations Impact Analysis for Applications Onboarding Strategies

Steven Izzo, Elissa Matthews, Vanita Katkar

Bell Labs Alcatel-Lucent

Murray Hill, New Jersey

Abstract— Service providers are being thrust into the Internet

Web 2.0 world where rapid innovation and flexible, open

business models are the norm. Network Services operators have a

critical need to establish and execute a business strategy that

leverages their own particular operating strengths in

combination with the application and service innovations thriving

in the internet marketplace. They recognize that to support new

applications and services they need to change the way they plan

and deliver services to end customers and partners. In this paper

we focus on the applications onboarding planning aspects of the

enablement strategy and explore two key questions: (i) what

operations changes are required to support the possible

variations in enablement strategy, and (ii) how can those

operations changes be defined and evaluated for speed to market

and cost impact.

Keywords- Applications Onboarding; Enablers; eTOM; Service

Delivery Environments

I. INTRODUCTION

The deployment of any application onboarding strategy requires comprehensive operations planning and disciplined execution to ensure a successful launch. Network Service Providers understand that to support new applications and services they need to change the way they plan and deliver services to end customers as well as partners. Planning for such changes entails addressing two key questions. Namely: (i) what operations changes are required to support the possible various applications enablement strategies, and (ii) how can those operations changes be defined and evaluated for speed to market and cost impact? In this paper we explore an Operations Impact Analysis Framework to determine the operations changes required by an applications onboarding strategy. The approach involves: (1) characterizing applications delivery environments to identify drivers impacting operations, (2) characterizing applications “delivery enabling interactions” and “delivery roles” for identifying capabilities needed to support the operational lifecycle of the service and (3) selecting the operations functions/processes and developing use cases for determining operational impact. The results can then be evaluated on critical variables such as speed to market and cost. The framework approach is illustrated through example use case analysis.

II. CHARACTERIZING APPLICATION DELIVERY

There exists a vast body of technical and business literature on Web 2.0 and the related evolution of the communications industry. A list of over 1800 web application programming interfaces (API) cataloged at ProgrammableWeb.com [1] and service providers’ technical work in the Open Mobile Alliance on mobile service enabler specifications [2] are just a small example of the magnitude and complexity associated with applications design, development and delivery environments. A quick survey of the volume of literature on the subject made it apparent that it was critical to identify a small set of key operations change drivers in order to conduct a structured analysis of the Applications Onboarding operations. Given that the larger the difference in business processes between the current and new service/application delivery approaches, the higher the operations impact, we examined the major applications delivery trends to see where there were wide variations in service/applications delivery business methods or processes.

A. Identifying Drivers of Operations Impact

Simple mobile phones have evolved into portable, hand-held computers and proliferated with many physical forms and operating system environments, forcing content and applications providers to adapt accordingly. In addition, wireless network providers may have hundreds [3] of user device variations that can require different builds of an application. Apple, on the other hand, has created a common environment across over 25M mobile end-points [4]. The relationship of the application to the device and the degree to which the application is specific to a device differ significantly in solutions being offered.

Web 2.0 is not only re-inventing existing business models, but inventing new ones [5]. An application/service can be offered/delivered directly to end-users with a retail business model, or indirectly with a wholesale business model wherein the network, including enablers, is offered to third party application or content providers. Applications could also be offered/delivered through a “virtual mall” by a provider acting as a broker of applications/services. Clearly the business model for who offers/delivers the application to the end-user can vary significantly.

The term ‘mash-up’ is widely used to describe application enablers where providers are able to mix and match capability from multiple sources. A typical example is a “call-a-cab” telecom mash-up as described in [6]. However, we also found examples of other ways that service provider APIs can be offered to the market, as in the Blackberry Push APIs described in [7]. The degree of structure of the enabler offered and how it is offered determines use by developers. This variation in application development approaches will have an impact on operations complexity associated with applications onboarding.

There are variations in how APIs are offered. One in particular is based on a degree of ‘openness’ to outside parties. In one article [8] Facebook, the leading social networking site, has been defined ‘closed’ by the author. This contrasts with a more open approach by many APIs cataloged at ProgrammableWeb.com. Because porting, testing, activating and deploying applications within the confines of a closed infrastructure involve considerably more effort than the same activities in an open environment the difference between closed and open environments is critical to understanding the operations impact.

Finally, the business entities responsible for the enablers used in application delivery can vary. Impact on onboarding operations will depend on the nature of key enablers components hosted by the network or service provider. Resources that are not fully owned and operated by the network or service provider create additional business and operations complexity impacting magnitude of operations changes.

The five key drivers we identified as critical to understanding the operations impact associated with any application onboarding strategy are:

• End point device and related users

• Retail or wholesale business model

• How the API is offered to the market

• How the enabler is used by developers

• Ownership and control of the enablers

We note that this set is not exhaustive and could change as the industry & technology evolve. Fig.1 below illustrates how these application drivers become characterization attributes that represent a range of possibilities for defining application onboarding strategies. These ranges are left to be qualitative until a reliable quantification model can be defined in a practical analysis of a particular applications onboarding strategy.

Figure 1. Drivers of Operations Impact

III. CHARACTERIZING THE INTERACTION OF ENABLER

FUNCTIONS

In addition to characterizing the applications in terms of their delivery environments, it is also necessary to understand the type, number and interactions between enablers used to create a particular type of application. To accomplish this characterization in a simple form, we adapted a form of use case notation developed by the TeleManagement Forum (TMF). The TMF Service Delivery Framework Overview [9] defines a reference model that establishes a vocabulary and common understanding for discussing the concepts of enablers (called "services" by TMF), interfaces, and delivery roles. An example of this notation is shown in Fig.2 below.

As defined by the TMF, a service exposes one or more service management interfaces or service interaction interfaces. A service may also rely on capabilities exposed by other services as represented by a ‘consumption’ interface. These concepts are illustrated on the right side of the diagram above. The other type of function is Management Support Services. These are the capabilities needed to support the operational lifecycle of the services. This lifecycle includes provisioning, installation, usage, monitoring, configuration, update and other management functions.

Figure 2. TMForum Service Delivery Framework Notation

A key element is the idea of a domain to mark the boundaries between the network, the application or content providers and the users. This designation of ownership, responsibility or control of each enabler has significant operations impact and is another factor in characterizing applications for analysis using our framework.

IV. SCOPE OF IMPACTED FUNCTIONS AND DEVELOPING USE

CASES

The third part of our Operations Impact Analysis Framework is to identify the key operations process areas that need to be examined in detail to evaluate the operations impact of any particular applications enablement strategy.

We based our operations analysis structure on the TMF eTOM model version 7.5 (see [10]). Using eTOM Levels 2 and 3 process decompositions, we selected the 18 Operations Support and Readiness (OS&R) Level 3 processes that apply to preparing an application for launch, and grouped them into clusters roughly corresponding to chronological phases of the process. This clustering aligns the dependencies that are most likely to occur, and allows them to be considered jointly during the analysis. This grouping is shown in Table I below.

TABLE I. TMF ETOM LEVEL 3 PROCESSES

Group ID ETOM Level 3 OS&R Process

Group 1

CRM Layer Manage Customer Inventory

Service Layer Manage Product Offering Inventory

Resource Layer Manage Service Inventory

Enable Resource Inventory

Group 2

CRM Layer Support Order Handling

Service Layer Enable Service Configuration and Activation

Resource Layer Enable Resource Provisioning

Group 3

CRM Layer Support Problem Handling

Service Layer Support Service Problem Management

Enable Service Quality Management

Support Service Instance Rating

Resource Layer Enable Resource Provisioning

Enable Resource Trouble Management

Enable Resource Performance Management

Enable Resource Data Collection

Group 4

CRM Layer Support Customer Interface Management

Support Billing

Resource Layer Manage Workforce

A. Developing Use Cases

A key aspect of any operations analysis is to be able to compare the present method of operations (PMO) to some defined future method of operations (FMO). In this section, we show by example how applications onboarding use cases are developed using the characterization of application delivery drivers and interaction of enablers described earlier.

A use case approach provides a way to define actors and interactions, including a visual representation of relationships among actors in a structured and methodical way. To illustrate how this takes place in the Operations Impact Analysis Framework, we developed several example applications onboarding use cases:

• Present Method of Operation (PMO) Baseline, representing a current wireline or wireless network provider offering conventional voice and data service

• Use Case 1: Retail VoIP Consumer Service delivered in a consolidated environment by a single service provider.

• Use Case 2: Retail Special Video Service, delivered as a set of content components owned and managed by different entities.

1) Baseline Present Method of Operations (PMO) For this analysis, the PMO is assumed to represent a current

wireline or wireless network provider offering conventional voice and data service. Any additional services are offered in a parallel rather than integrated environment, typically on a separate platform that may or may not interface with the other services for such functions as billing, security and high-level governance. Tools and databases may be shared but are only rarely fully converged. Launching new services and/or applications involves designing and installing the new (and parallel) platform components, building and activation of any desired interfaces, and absorbing the new requirements into the existing tool and database environment.

2) Use Case 1: Retail VoIP Consumer Service We chose this example, because it will seem very familiar,

and we believe that this will help illustrate how the analysis proceeds. The user device in this use case is assumed to be a Windows PC. The offered service is therefore relatively device independent, however we assume it does require a SIP-enabled soft phone download to the PC. As determined by our strategy, this is a retail offer and all of the application resources are entirely managed by the network.

The service package is assumed to be a structured voice offer combined with feature change portal functions. The enablers are assumed to be based on an open platform provided by a vendor without any custom modifications. The management services support functions required include activation, feature change and billing.

Based on this definition, Use Case 1 is relatively simple in terms of operations impact on the PMO. Fig.3 below illustrates how this Use Case 1 can be characterized by key attributes of the framework.

Figure 3. Use Case 1 Application Characterization

3) Use Case 2: Retail Special Video Service For this use case, we vary the definition to include more

complex elements to illustrate the robustness of our analysis approach. In this use case, the application is device dependent and relies on the specific mobile device capability in terms of video download and display. Consistent with our strategy, the Travel Video Access Service is retailed by the service provider. The service package combines the enablers of user location awareness and video content distribution. Note that the video content may be either cached in the network for faster response or accessed from the content provider on demand when needed. Because the network provider is selling the application, they pay the content provider for accessed material. Similarly the network provider pays for access to map services. Thus, the management support services include usage data collection, settlement and payment status functions that are made available to the third party content and map partners. Fig. 4 illustrates that Use Case 2 is more complex than Use Case 1, involving third party hosted and developed capability and using specific device functionality.

Figure 4. Use Case 2 Application Characterization

V. EXAMPLE USE CASE ANALYSIS RESULTS

In this section we provide the results of analyzing two of the 18 OS&R operations processes that have significant

relevance for the use cases described in the preceding section: the service inventory function and the service activation function. In each analysis we applied the Framework to compare the Baseline PMO with Use Case 1 and Use Case 2 to evaluate the characteristics and scope of operations impact.

A. Analysis 1: Establish Service Inventory

In order to onboard any new service, it is necessary to establish and manage the database supporting the service inventory components, also known as the service catalogue. In the PMO, it is typically the case that all the data needed for the end-to-end service is defined as needed by individual organizations and systems. There are generally multiple copies of some data and often-different naming conventions to accommodate current systems and practices. Table II summarizes our analysis for the establish service inventory function.

In order to onboard the more straightforward services represented by Use Case 1, the PMO approach may continue to work for a while, but breakdown as more and more services are added, or as the complexity of the application begins to slide toward Use Case 2. The need to expand the functionality of the platform as parallel sub-platforms becomes increasingly difficult to support and to expand, for both the tools and database components as well as the infrastructure.

Use Case 2 represents a significant challenge to the status quo. The entire environment supporting the portfolio of services needs to expand in both scope and function, which becomes unmanageable if the PMO structure is used. For example, the billing data that needs to be exchanged between the parties would need to be duplicated for each database instance that would have update/entry functions (e.g. every service) and would need to be verified for every query, bill rendering and report generated. Repudiation of any disputes or mediation of any shared revenue would be a vastly time-consuming activity.

TABLE II. MANAGE SERVICE INVENTORY IMPACT

OS&R Process:

Manage Service

Inventory

Description: Establish and manage service

inventory database (service cataloging)

PMO FMO: Use Case 1 FMO: Use Case 2

Service data model is developed for the "whole service“ Duplicate copies are distributed to several systems and elements Product-service additions / changes are comprehensive and often time consuming

PMO may work in the near term Next generation SDE provides opportunity to leverage enhanced granularity in service definition

Requires “granular” middle layer of product-service definition Service data model is built up by component Service data distribution is "as needed" or even dynamic and real-time Service changes may require less end-end re-design Process focus on inventory data re-use and integration

B. Analysis 2: Service Activation

The other operations readiness process example looks at the Service Activation process. In the PMO, the current approach is to handle each new service as a distinct project that requires coordinated analysis and change of systems and processes to accommodate that particular service. Table III summarizes our analysis of service activation.

In Use Case 1, the PMO tools, techniques and platform assumptions will certainly work in a low volume environment, but Use Case 1 as well as Use Case 2 illustrates the potential for many more applications to be delivered in shorter time cycles. Again, we conclude that the PMO may work for a low volume of internally developed applications, such as Use Case 1, but will begin to succumb to interface and tool design and instantiation complexity as the scenario begins to move toward the complications of Use Case 2.

Use Case 2 illustrates the nature of the change required to industrialize a higher volume of applications and partners involved in the launch process. The impact of a more modular ‘ownership’ of the enablers involved in building the complete service requires management support systems and work group structure that assigns full ownership for each component of the service. The coordination work between these work groups is focused on integration and testing of the activation of the new application.

TABLE III. SERVICE ACTIVATION OPERATIONS IMPACT

OS&R Process:

Enable Service

Configuration

and Activation

Description: Establish processes, systems

and work organization for service activation

PMO FMO: Use Case 1 FMO: Use Case 2

Each new product is an integrated package that impacts multiple business process owners Service activation readiness requires all systems and owners involved in each part of the overall business process to be ready

PMO may work in the near term, but SDE provides opportunity to leverage enhanced granularity in service activation approach

SDE Management Support infrastructure aligned with modular services, “ownership” can be simplified and cross-domain coordination and testing can be reduced Inventory focus shifts to re-use and integration

VI. CONCLUSION

This paper proposes a structured method for analyzing the operations impact of applications onboarding strategies. We focus on applications onboarding planning due to the future importance of applications enablement strategies to service providers. The framework provides a methodology to capture

the relevant definition of the application onboarding strategy and assign the operations impact to operations domains. The method is based on: (1) characterizing the complexity of application delivery in terms of five key drivers of operations impact, (2) characterizing the applications delivery enabling interactions and delivery roles and (3) determining the key operations readiness process domains to be examined.

Analyzing the operations impact of new services and network technologies is a challenge made more difficult due to the lack of consistent methods. Our experience is that when an operation plan relies on ad hoc analysis the result can be increased risk of launch delay and post-launch service problems. We hope that operations planners will apply the operations impact analysis method described here to plan and evaluate plan applications onboarding strategies. Improved methods of planning operations change will allow service providers to better adapt to the continuing, rapid innovation in network technology.

REFERENCES

[1] ProgrammableWeb.com. (2010, March 19). API Directory. Retrieved

from http://www.programmableweb.com/apis

[2] Open Mobile Alliance. (2010, March 19). Current OMA Work Program. Retrieved from http://www.openmobilealliance.org/Technical/OMAWP/Current/menu.aspx

[3] Whoop, Inc. (2009) Whoop, Inc. Mobile Marketing Manifesto. Retrieved from http://www.whoop.com/Media/Papers

[4] Gartner, Inc. (2010, February 23). Gartner Says Worldwide Mobile Phone Sales to End Users Grew 8 Per Cent in Fourth Quarter 2009; Market Remained Flat in 2009. Retrieved from http://www.gartner.com/it/section.jsp?type=press_releases&format=archive&year=2010&show_archived=true

[5] Michael Rappa, "Business Models on the Web," <http://digitalenterprise.org/models/models.html>, Sunday, 17-Jan-2010 13:05:27 EST.

[6] Banerjee, N. and Dasgupta, K., "Telecom mashups: enabling web 2.0 for telecom services," in Conference On Ubiquitous Information Management And Communication Proceedings of the 2nd international conference on Ubiquitous information management and communication, 2008, pp.146-150.

[7] Research in Motion, Inc. (2008) BlackBerry Push APIs: Accessing the power of BlackBerry Push Technology. Retrieved from http://na.blackberry.com/eng/developers/

[8] Kirkpatrick, M. (2009, April 27). Despite New Openness, Facebook Remains Fundamentally Closed. Retrieved March, 2010, from ReadWriteWeb website: http://www.readwriteweb.com/archives/despite_new_openness_facebook_remains_fundamentall_1.php

[9] TM Forum. (2009). TR139, Service Delivery Framework Overview, Release 2.0. Service Delivery Framework. Retrieved from http://www.tmforum.org/ServiceDeliveryFramework/4664/home.html

[10] [TM Forum. (2009). Business Process Framework - enhanced Telecom Operations Map. Retrieved from http://www.tmforum.org/BusinessProcessFramework/1647/home.html.