Integrating the etom business process framework into the Ericsson seamless modeling

Transcription

1 MASTER Integrating the etom business process framework into the Ericsson seamless modeling Joshy, N.; Shenoy, N.R.A. Award date: 2010 Link to publication Disclaimer This document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Student theses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the document as presented in the repository. The required complexity or quality of research of student theses may vary by program, and the required minimum study period may vary in duration. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Users may download and print one copy of any publication from the public portal for the purpose of private study or research. You may not further distribute the material or use it for any profit-making activity or commercial gain

2 TECHNISCHE UNIVERSITEIT EINDHOVEN Department of Mathematics and Computer Science Integrating the etom Business Process Framework into the Ericsson Seamless Modeling by Nimmy Joshy and Nithin Shenoy SUPERVISED BY dr.natalia Sidorova (TU/e) Barbara Pareglio (Ericsson) Eindhoven, August 2010

3 Abstract Ericsson, a telecommunication industry, is faced with the problem of managing change and complexity involved in developing the products it offers, because of the growing business needs. In order to address this concern, BMUM (Business Unit Multimedia) business unit in Ericsson is in the process of developing a methodology called Ericsson Seamless Modeling (ESM) for modeling the products they offer. The idea behind ESM is to model the product at different levels of abstraction using the architectural and modeling concepts. These levels of abstraction are realized by structuring ESM into different modeling layers. The ongoing research work related to ESM involves defining templates, guidelines, languages for modeling and mandating terminologies. This is done by study on various frameworks and standards available. As part of this research, one of the areas of focus is the use of etom (enhanced Telecom Operations Map) framework in ESM. etom is a widely accepted framework for business processes in information, communication and entertainment industries [18]. The framework mainly focuses on business processes involved in telecommunication service providers enterprise environment. Since the service providers are customers of Ericsson, using etom in ESM can help Ericsson in understanding their customer environment better and in aligning their products with the customer needs. Moreover, it helps maintain common terminology in interactions with customers. The objective of this thesis work was to define a method for integrating etom into ESM. This required understanding the concepts and terminologies used in etom and ESM. The study on ESM was an ongoing process as it was parallely being developed and updated by the research team of Ericsson. We present the current state-of-art of ESM based on the understanding obtained. We also provide an overview of etom. The approach that we followed to integrate etom into ESM involves aligning a product offered by Ericsson to etom processes by establishing a mapping between them. The results obtained from the mapping process are then used to show how and where etom can be used in ESM. As a part of the mapping process, we discuss various important decisions taken before carrying out the mapping, the mapping methodology followed and different ways in which a product can be associated to the etom processes. The mapping methodology is applied to one of the products of Ericsson. We present a detailed discussion on the mapping performed and the analysis of the results obtained. Based on the understanding obtained from the mapping performed we propose a generic mapping methodology. Simple models are proposed to present the mapping results in ESM. The models are based on different ways a product could be associated to etom processes. The models proposed use notations provided by the ArchiMate language, as ArchiMate is one of languages of choice for modeling in ESM. We also discuss the use of etom in different layers of ESM and show a loose coupling between the layers using etom terminology. As a result of the research work carried out, we could integrate etom into ESM by means

4 ii of capturing the mapping results in ESM. We conclude our work with discussion on etom and mapping in general and modeling in ESM with respect to Ericsson.

5 Acknowledgement We would like to express our sincere gratitude to our thesis work project supervisors dr. Natalia Sidorova and Barbara Pareglio for their continuous support and guidance throughout the duration of our thesis project and report writing. Without their encouragement and suggestions, this project might not have seen its completion. This thesis would not have been possible without the experience and helpful insights of Magnus Wilson and Jos den Hartog and who has been closely involved during the entire research. It has been a very pleasant collaboration. We would like to thank all the colleagues with which we have collaborated during the research period and the pleasant working environment. Furthermore, we would like to thank all the interviewees for their participation and time. We would like to explicitly thank Toine van Duiven for his close involvement and additional insights throughout the research and Ard-Jan Moerdijk and Jan van der Meer for giving us the opportunity to perform this research at Ericsson. We are greatly indebted to prof. dr.jos Baeten, prof.dr.mark van de Brand, dr.manohara M. Pai, and dr. Radhika M. Pai for considering us worthy for this great opportunity to gain and expand our knowledge through this program. Finally, we would like to thank our family and friends and the Almighty for always being there as a support. Eindhoven, August 2010 Nithin Shenoy Nimmy Joshy

6 iv

7 Contents 1 Introduction Research Question Thesis Structure Background Ericsson Overview Ericsson Seamless Modeling (ESM) Business Modeling Capability Modeling Realization Modeling enhanced Telecom Operations Map (etom) etom Levels Benefits of etom ArchiMate Language ArchiMate Layers and Aspects Concepts Relationships Services Viewpoints v

8 vi CONTENTS 3 Mapping Ericsson s Product to etom Decisions on Mapping Ringback Solution Description Key Roles Logical Overview Mapping Methodology Generic Mapping Methodology Conclusion Modeling in ESM Modeling Approach Capability Modeling Business Modeling Map Models for Using etom in ESM Conclusion Conclusions Limitations of the Work Recommendations A Archimate 61 B Mapping Results 67 C Models Created Using Archimate Language 71 References 71

9 List of Figures 1.1 Thesis structure Organizational scope of the masters thesis Osterwalder Canvas [2] Business Model for Google Book Search State-of-the-art of ESM etom- Level 0 processes etom- Level 1 processes etom- Level 2 processes in the Operations area etom -Problem Handling process decomposition into Level 3 processes [20] ArchiMate layers and aspects [15] ArchiMate Concepts: an example Structural relationship [11] Dynamic relationship [11] Grouping relationship [11] Services in ArchiMate language [11] Metamodel of business process viewpoint [12] Ericsson process mapping (BMUM) Roles in Ringback solution [6] Logical overview of Ringback solution Business entities as described in etom [22] vii

10 viii LIST OF FIGURES 3.5 Roles in Ringback solution with etom terminology Level 3 decomposition of Retention and Loyalty process [20] Mapping between Ringback solution and Personalize Customer Profile for Retention and Loyalty process Mapping between Ringback solution and Establish and Terminate Customer Relationship Database tables Mapping results at the Level 1 processes in etom Mapping results at the Level 3 processes in etom Mapping results at the Level 2 processes in etom A part of Ringback solution modeled by using the mapping results in Archi- Mate Relating the mapped etom process to product specific business process Service realization viewpoint Target Customer(TC) Canvas Blocks of Target Customer (TC) canvas with etom terminology Map models for using etom in ESM Example model for supply data Map Model interpretation A-1 Application layer concepts [11] A-2 Business layer concepts [11] A-3 Technology layer concepts [11] A-4 Relationships [11] A-5 Notations for concepts and relationships [17] A-6 ArchiMate Metamodel [14] B-1 Mapping results at level B-2 Mapping results at level 3 CRM B-3 Mapping results at level 3 RM&O B-4 Mapping results at level 3 S/PRM

11 LIST OF FIGURES ix C-1 Ringback Solution modeled for Bill Inquiry Handling C-2 Ringback Solution modeled for Bill Payments and Receivables Management 73 C-3 Ringback Solution modeled for Rating and Discounting C-4 Ringback Solution modeled for S/PRM Management C-5 Ringback Solution modeled for Bill Payments and Receivables Management 76 C-6 Map models-level 3 CRM processes C-7 Map models-level 3 RM&O processes C-8 Map models-level 3 S/PRM processes

12 Chapter 1 Introduction In the field of telecommunication the business needs changes along with the advent of new technologies. This constant change is accompanied with increased complexity starting from the design of a product till the delivery of the product. Managing this level of change and complexity involved in a product development is very important in this fiercely competitive industry. Ericsson being a telecommunication-based company is facing the same problem and has initiated a program called the modeling program to address this issue. The modeling team (members of the modeling program), are developing a methodology based on the architectural and modeling concepts. The methodology is called Ericsson Seamless Modeling. Ericsson Seamless Modeling (ESM) methodology is split into three modeling layers namely[4]: 1. Business modeling 2. Capability modeling 3. Realization modeling These layers represent different levels of abstraction with business being the highest level of abstraction and realization being the lowest. Business modeling deals with representing the product at a high level in terms of business values, needs and the stakeholders involved. Capability modeling captures the functionalities that have to be supported in order to deliver the business values and realization modeling captures the details of the realization of these capabilities with existing technology. The idea behind ESM is to understand What are the right things to do? and How to do the things right? in a unified way. One of the key ingredients in achieving this is by adopting well established frameworks and using the terminology that customers of Ericsson use. This ensures that there is consistency in the language used within and outside Ericsson. Among the three layers of modeling, the concept of realization modeling is already well understood in Ericsson. They already follow the standards and protocols applicable at this level. However, there is little 1

13 2 CHAPTER 1. INTRODUCTION knowledge and experience in terms of the practical modeling of business and capabilities. Therefore the current research work of the modeling team focuses on the first two layers of modeling. The work involves defining templates, guidelines and mandating terminologies to be used based on the study of various frameworks and standards available. As part of the research, the modeling team wanted us to use the etom (enhanced Telecommunication Operations Map) and provide suggestions on using etom in ESM. etom is a widely accepted business process framework for information, communication and entertainment industries [18]. We found that etom can be used to improve Ericsson s internal process structure or can be used to align the products offered with focus on customers 1. The modeling team suggested us to use etom for alignment of Ericsson s products. Based on this, we formulated our research question and defined the steps needed to answer this question. 1.1 Research Question The main research question for our thesis work is How can etom be practically applied in Ericsson Seamless Modeling? In order to answer the main research question, we have formulated the following research goals (RG): 1. Understand the state-of-the-art of ESM. 2. Understand the etom business process framework. 3. Define an approach to use etom by mapping one of the Ericsson product into etom. 4. Model the chosen product in ESM and use the mapped data to show where and how etom can be used in ESM. 5. Formulate suggestions on a possible logical link between business modeling and capability modeling based on the research carried out. 1.2 Thesis Structure This thesis report consists of five main chapters, with appendices. Below is a brief description of each of the chapter. 1 Customers here refers to telecom service providers

14 1.2. THESIS STRUCTURE 3 Figure 1.1: Thesis structure Chapter 1 Introduction discusses the context of the problem being addressed, the research question and the research goals associated with it. Chapter 2 Background provides an overview of Ericsson, Ericsson Seamless Modeling (ESM), enhanced Telecom Operation Map (etom) and Archimate. Chapter 3 Mapping Ericsson s product to etom discusses in detail the mapping methodology that was followed to establish a relation between the business processes of etom and the functionalities of the product. Chapter 4 Modeling in ESM provides a formal way of using etom for products modeled in ESM. Chapter 5 Conclusion provides the outcomes of this work along with limitations of the work and recommendations. In Figure 1.1 we show the split of the main research question into five research goals (RG1-RG5) and the corresponding chapters which address the research goals.

15 4 CHAPTER 1. INTRODUCTION

16 Chapter 2 Background This chapter provides an overview of Ericsson followed by details of the necessary background information on the concepts that are used in the upcoming chapters. The chapter is divided into four sections. The first section is a brief overview of Ericsson as a company and of the modeling program to which the Master project belong. The second section discusses the Ericsson Seamless Modeling methodology. The third section concentrates on enhanced Telecommunication Operations Map (etom) business process framework and its benefits. The fourth section discusses the modeling language ArchiMate and its concepts. 2.1 Ericsson Overview Ericsson is a leading provider of telecommunications equipment and related services to mobile and fixed network operators globally.ericsson offers end-to-end solutions for all major mobile communication standards. Its profile also includes provisioning of broadband and multimedia solutions for operators, enterprises and developers. Over 1,000 networks in more than 175 countries utilize Ericsson s network equipment and 40 percent of all mobile calls are made through its systems.the networks supported for operators serve more than two billion subscribers. The networks managed for operators serve more than 700 million subscribers[3]. Ericsson has three main business units. Business Unit Networks (BNET) focuses on networks for mobile and fixed line public telephone networks. Business Unit Global Services (BUGS) provides telecoms-related professional services, including for example taking responsibility for running an operators network and related business support systems. 5

17 6 CHAPTER 2. BACKGROUND Figure 2.1: Organizational scope of the masters thesis Business Unit Multimedia (BMUM) provides charging, provisioning, IPTV, mobile TV and other support and media systems, primarily for telecom operators. The master thesis was carried out in Ericcson,NL(ETM). It has two business units BMUM and BUGS. As shown in Figure 2.1,the modeling program, to which we belong, is a part of BMUM Research & Development center. 2.2 Ericsson Seamless Modeling (ESM) As already discussed, Ericsson Seamless Modeling has three layers and the current area of research is on the first two layers of the modeling methodology. Therefore we emphasize only those layers in the following discussion Business Modeling Business modeling layer deals with representing the solution at a high level in terms of business values, needs and the stakeholders involved. It involves creation of business models and the value network for the solution. The business model captures the essentials of business such as objectives, key activities, the partners and the cost and the revenue streams in an organized fashion. It allows the extraction of value that the solution offers to different stakeholders. Here, the value of a solution is the mental estimation a consumer makes between the perceived benefits and costs of receiving these benefits. For creating the business models, the modeling team of Ericsson has suggested the use of the business model template as described by the Osterwalder Canvas [2].

18 2.2. ERICSSON SEAMLESS MODELING (ESM) 7 Figure 2.2: Osterwalder Canvas [2] Osterwalder canvas divides the business model into nine building blocks, as shown in Figure 2.2.Further each of these nine blocks can be grouped into four areas: offer, customer, infrastructure and finance. The groupings are as shown in Table 2.1. Grouping Offer Customer Infrastructure Finance Building blocks Value propositions Customer segments, Channels and Customer relationships Key resources, Key activities, Key partners Cost structure, Revenue streams Table 2.1: Osterwalder Canvas Groupings Brief explanation of each of the building block is given below. The flow of explanation is based on the order of groupings shown in Table 2.1. This order presents a natural flow of understanding the canvas starting with the offer provided to the customer followed by the infrastructure required and finances involved in providing the offer.to better understand each of the building block an example business model of Google Book Search, which allows search and preview/access of millions of books online [1], is presented using Osterwalder canvas in Figure Value propositions: Value propositions help in representing the needs of the customers, the customer problems addressed and the offerings provided, thus extracting the value that is being given to the customer by the product.

19 8 CHAPTER 2. BACKGROUND Figure 2.3: Business Model for Google Book Search 2. Customer segments: It represents existing and potential market segments in which the products and services can be offered profitably. It covers the target customers for the product offered. 3. Channels: Channels are the medium through which the product reaches the customer. This block captures the various sales and distribution channels that could be used for delivering the product to the customers. 4. Customer relationships: This helps in representing what kind of relationship an enterprise maintains and should maintain with the different customer segments identified. 5. Key resources: This captures the resources required to realize the value proposed, maintain the customer relationship and handle the channels. 6. Key activities: The key activities are the processes that are followed to realize the value proposed. 7. Key partners: Some part of the product may be outsourced/implemented outside the enterprise by suppliers/partners. This area of the canvas captures these partner relations. 8. Cost structure: This captures the various factors that influence the cost involved in the realization of the value offered to the customers.

20 2.2. ERICSSON SEAMLESS MODELING (ESM) 9 9. Revenue stream: This is used to capture the various means by which an enterprise can make profit by selling the products and services. In the business modeling layer, modeling team recommends the use of two canvases when creating the business model, namely 1. Target Customer(TC) canvas 2. Ericsson canvas. The target customer canvas describes various aspects of the business model for Ericsson s customers (Operators and service providers). The Ericsson canvas focuses on the business model of Ericsson capturing various business aspects of product being modeled. Business modeling is a two step process in which the target customer canvas is created first and then the Ericsson canvas. The basic principle behind having this two step process is to first understand the needs and challenges of the customers and take this as a requirement to decide on the values and the functionalities Ericsson should support Capability Modeling Capability modeling layer details the product modeled in the business modeling layer at a next level of abstraction. It is divided into three layers which are business layer details, data and application layer details and the technology layer details at a high level. These three layers of the capability modeling are founded based on the three architectural layers of the TOGAF Architecture Development Methodology (ADM) namely the Business Architecture, Information system architecture and the Technology architecture. Though, there is a correspondence between the capability modeling and ADM layers, the seamless modeling does not want to adopt the concepts and terminologies as mentioned in the ADM directly. This is mainly because of two reasons which are explained in the following two paragraphs. Ericsson is a global company delivering diverse services to their customers. For example Ericsson can be seen as an enterprise providing system integration services to the service providers; it can be seen as a supplier providing different products; it can be seen as a hosting provider hosting the products within its own network infrastructure. Adoption of ADM would differ based on the understanding used to describe Ericsson as an enterprise. The idea is to iteratively consider all the different roles played by the Ericsson and define the capability modeling with details concerning all the roles. As the modeling team is a part of BMUM (Business unit Multimedia) R&D, the role played by Ericsson is that of a supplier. The ADM is not the only method which can be adopted in different layers of capability modeling. The TMF (TeleManagement Forum), also provides the various frameworks

21 10 CHAPTER 2. BACKGROUND such as business process framework (etom), information framework (SID - Shared Information/Data model), the applications framework (TAM - Telecom Application Map) which could be adopted into capability modeling. Therefore, it is important to understand various available frameworks and terminologies rather than directly adopting ADM. In fact, as already discussed our research area focuses on the understanding how etom terminologies could be used in the ESM. Language for capability modeling The layers of capability modeling actually represent different domains of an enterprise. Each of the domains can be modeled using the domain specific modeling languages [9]. For example the business processes in the business layer can be modeled using any business process modeling language. However, the modeling team wanted to adopt an integrated language which models the heterogeneous domains of an enterprise in an integrated way. Therefore, ArchiMate was chosen as the language for modeling in the capability modeling layer [9]. Also, the structure of the ArchiMate language neatly corresponds to business, information systems and the technology architecture addressed in the TOGAF ADM. A detailed explanation on ArchiMate language is given in section 2.4. Viewpoints in capability modeling It is often the case that details of different layers in the capability modeling are recorded and used by different stakeholders involved, right from the management level to product developers. Each of these stakeholders requires specific information presented in an accessible way. To address this problem, the concept of view and viewpoints are used in capability modeling. TOGAF defines a view as a representation of related set of concerns [10]and a viewpoint as a definition of the perspective from which a view is taken [10]. In simpler terms, a view is what you see, and a viewpoint is where you are looking from [12]. The capability modeling currently adopts the concepts of viewpoints as described by the metamodels of viewpoints defined by ArchiMate. It is also seen that there is a fair amount of correspondence that exist between the viewpoints defined in the TOGAF and ArchiMate[18]. Since Ericsson follows TOGAF in ESM, and there is alignment between TOGAF and ArchiMate, using ArchiMate as the modeling language is a logical choice Realization Modeling The Realization modeling layer represents the product at a detailed level and elaborates on how the application components defined in the capability modeling are actually going to be implemented. This involves decision on how to actually break down the components into modules for implementation, what kind of implementation specific frameworks are

22 2.3. ENHANCED TELECOM OPERATIONS MAP (ETOM) 11 to be used and so on. As already mentioned, this is not the current area of focus and detailed discussion of this is out of the scope of this project. The different layers of ESM and its relations to other concepts used in modeling are described in Figure 2.4. The different relationships and their meanings are shown at the top right corner of Figure 2.4. It can be seen that there is alignment between the B, C, D layers of TOGAF ADM and the three layers of ArchiMate; Capability modeling adopts the B, C, D layers of TOGAF ADM in its three layers and also plans to adopt etom in the business layer;the business modeling adopts the Osterwalder canvas. There also exists a loose coupling between the different modeling layers, this is to signify that the link between the layer exists only on the basis of terminologies used in these layers. There is no direct link between the layers. The feedback link between each of the layers signifies that ESM is iterative. For example, once the business model is created it is not the final version. It may be refined based on the understanding obtained at the capability modeling. ESM is a methodology and therefore needs a platform for implementation. Ericsson has chosen PowerDesigner (PD), provided by Sybase, as the tool for implementing ESM. Ericsson is working with Sybase to customize PD to provide necessary support for modeling in ESM. 2.3 enhanced Telecom Operations Map (etom) etom is an internationally accepted Business Process Framework in the ICT (Information&Communication Technology)industry published and maintained by TMF (TeleManagement Forum). It categorizes the business processes that a service provider will use in a structured manner. The business processes defined in the framework are as a result of efforts by TMF and involvement from the members of TMF which involves the global telecommunications industry, as well as academia. It provides a business perspective of the service provider for other enterprises involved in the ICT value chain. The contents of this section are largely based on the etom documentation published by TMF[22] etom Levels etom structures the business processes into a hierarchy of processes with the details of each process captured at different levels. At present, etom has four levels into which processes are decomposed ranging from level 0- level 3.The level number is an indication of the degree of detail of each process. Higher the level number more are the details of the processes described in that level.

23 12 CHAPTER 2. BACKGROUND Figure 2.4: State-of-the-art of ESM

24 2.3. ENHANCED TELECOM OPERATIONS MAP (ETOM) 13 Figure 2.5: etom- Level 0 processes Level 0 At level 0, the framework has three major process areas of an enterprise, as shown in Figure 2.5. A brief description of each of the process areas is explained below. 1. Strategy, Infrastructure and Product (SIP): This process area includes processes that develop strategies of enterprise; that plan, develop and manage the delivery and enhancement of infrastructures and products; and that develop and manage the Supply Chain. These processes direct and facilitate processes within the Operations process area. 2. Operations(OPS): This process area includes all the core operations processes that support the customer, supplier, service, network operations and management operations. These processes cover the day-to-day processes like the billing of customer. It also covers the operations support and readiness processes which ensure the proper functioning of day-to-day processes. These are distinct because, unlike SIP, they directly support the customer, are intrinsically different from the SIP processes and work on different business time cycles. 3. Enterprise Management: This process area includes generic processes that focus on setting and achieving of strategic corporate goals and objectives, as well as providing those support services that are required throughout an Enterprise. For example Financial Management, Human Resources Management, Risk Management processes, etc. Along with the major process areas, level 0 also describes the key areas of focus of a service provider to pursue the business, called as functional process structures which span across the two process areas as the four horizontal blocks as shown in Figure 2.5. A brief description about each of them is as follows:

25 14 CHAPTER 2. BACKGROUND Figure 2.6: etom- Level 1 processes 1. Market Product and Customer processes include the sales and channel management, marketing management and product and offer management, managing customer interface, problem handling, ordering, billing and SLA management. 2. Service processes deals with development, delivery and operational management of services. 3. Resource processes includes the processes that are concerned with development and delivery of resource infrastructure and its operational management. 4. Supplier/Partner processes deal with the processes which involve the enterprise interaction with its supplier/partner. Level 1 The level 0 processes are further decomposed into level 1 processes which provide deeper insight of the level 0 processes. This is as shown in Figure 2.6. These processes are grouped based on two perspectives called as the horizontal and the vertical process groupings. Each of the process groupings is discussed below. Horizontal Level 1 process groupings give a view of functionally-related processes within the business, such as those involved in managing contact with the customer. This structuring by horizontal functional process groupings is useful to those who are responsible for creating the capability that enables, supports or automates the processes. There are four horizontal process groupings in the operations process area which are:

26 2.3. ENHANCED TELECOM OPERATIONS MAP (ETOM) Customer Relationship Management (CRM): This horizontal functional process grouping considers the essential knowledge of customers needs and includes all functionalities necessary for the acquisition, enhancement and retention of a relationship with a customer. CRM also includes the collection of customer information and its application to personalize, customize and integrate delivery of service to a customer, as well as to identify opportunities for increasing the value of the customer to the enterprise. 2. Service Management & Operations (SM&O): This horizontal functional process grouping focuses on the knowledge of services (Access, Connectivity, Content, etc.) and includes all functionalities necessary for the management and operations of communications and information services required by or proposed to customers. 3. Resource Management & Operations (RM&O): This horizontal functional process grouping maintains knowledge of resources (application, computing and network infrastructures) and is responsible for managing all these resources.(e.g. networks, IT systems, servers, routers, etc.) utilized to deliver and support services required by or proposed to customers. The purpose of these processes is to ensure that infrastructure runs smoothly, is accessible, maintained and responsive to the needs of the services and customers. 4. Supplier/Partner Relationship Management (S/PRM): Supplier/Partner Relationship Management(S/PRM) processes align closely with a supplier s or partner s Customer Relationship Management processes. These processes enables the inclusion of distinct Supplier/Partner Relationship Management processes in the etom framework. Similarly there are four process groupings for SIP process area. They are : 1. Marketing and Offer Management: This horizontal functional process grouping focuses on including functionalities necessary for defining strategies, developing new products, managing existing products and implementing marketing and offering strategies suitable for information and communications products and services. 2. Service Development and Management: This horizontal functional process grouping focuses on planning, developing and delivering services to the Operations domain. It includes processes necessary for defining the strategies for service creation and design, managing existing services, and ensuring that capabilities are in place to meet future service demand. 3. Resource Development and Management: This horizontal functional process grouping focuses on planning, developing and delivering the resources needed to support services and products to the Operations domain. It includes processes necessary for defining the strategies for development of the network and other physical and non-physical resources, introduction of new technologies and interworking with

27 16 CHAPTER 2. BACKGROUND existing ones, managing existing resources and ensuring that capabilities are in place to meet future service needs. 4. Supply Chain Development and Management: This horizontal functional process grouping focuses on the interactions required by the enterprise with suppliers and partners, who are involved in maintaining the supply chain. Vertical Level 1 process groupings represent a view of end-to-end business processes, which span across the organizational boundary. eg. Processes involved in the billing of the customers. This grouping is important to the people who concentrate on meeting customer expectations as product offerings, or the infrastructure that supports the operations functions and products, or the suppliers and partners involved in the enterprise s offering to customers. There are three vertical end-end process groupings in the Operations (OPS) process area are called as the FAB processes. They are: 1. Fulfillment: This grouping ensures that the customers are provided with their requested products in an efficient manner. It is responsible for providing customers with their requested products in a well-timed and proper manner. It translates the customer s need into a product, which can be delivered using the specific products or by different products in the enterprise s portfolio. This is performed by informing the customers of the status of their purchase order and provide completion on time of the request and ensuring customer satisfaction. 2. Assurance: This vertical end-end process grouping is responsible for the execution of maintenance activities to ensure that services provided to customers are continuously available and performing to SLA or QoS performance levels. 3. Billing: This vertical end-end process grouping is responsible for the collection of appropriate usage records, production of timely and accurate bills, for providing pre-bill use information and billing to customers, for processing their payments, and performing payment collections. Operations Support and Readiness (OSR) is differentiated from real-time FAB processes. It focus on providing management, logistics and administrative support to the FAB process groupings, support and automation in FAB, i.e. on-line and immediate support of customers, with OSR ensuring that the operational environment is in place to let the FAB processes do their job. The three vertical end-to-end process groupings in the SIP process area are: 1. Strategy and Commit: This vertical end-end process grouping is responsible for the generation of strategies in support of the Infrastructure and Product Lifecycle processes. It is also responsible for establishing business commitment within the enterprise to support these strategies.

28 2.3. ENHANCED TELECOM OPERATIONS MAP (ETOM) 17 Figure 2.7: etom- Level 2 processes in the Operations area 2. Infrastructure Lifecycle Management: This vertical end-end process grouping is responsible for the definition, planning and implementation of all necessary infrastructures (application, computing and network), as well as all other support infrastructures and business capabilities (operations centers, architectures, etc.). 3. Product Lifecycle Management: This vertical end-end process grouping is responsible for the definition, planning, design and implementation of all products in the enterprise s portfolio. The horizontal functional process groupings and the vertical end-to-end process groupings form the matrix structure of the etom framework. As process decomposition proceeds, the level 1 process is decomposed into a set of constituent process elements at the level below. The decomposition level 1 processes into level 2 processes is as Figure 2.7. For example in the Operations Area the CRM has three processes problem handling, customer QOS/SLA management belonging to assurance vertical grouping. These level 2 processes are further decomposed into level 3 processes. Decomposition of a level 2 process, problem handling, into level 3 processes is as shown in Figure 2.8. Brief and extended descriptions of these processes are explained in [20]. The level 3 could be further decomposed into deeper levels by users of etom framework based on the business needs of the enterprise.

29 18 CHAPTER 2. BACKGROUND Figure 2.8: etom -Problem Handling process decomposition into Level 3 processes [20] Benefits of etom The important contribution of etom is the standardization of business processes thus acting as a reference framework for an ICT industry [19]. Therefore, entities of the ICT industries which include operators, service providers, system integrators, vendors/suppliers or partners, etc can benefit by adopting etom. The framework can be used by all these entities because it is defined as generically as possible, so that it is independent of the organization, technology and service [21]. Some of the benefits of using etom are discussed below. etom offers a standard structure, terminology and classification scheme for describing business processes that can be understood and used by both the people specifying and operating the end-to-end business, and also those people who are responsible for creating the capability that enables the processes. Thus, it minimizes the ambiguity in the interactions increasing the effectiveness and efficiency of interaction. It provides a baseline of business processes which could be further customized and extended according to the business needs of an enterprise. It allows different entities in the ICT industry to create products using etom framework as a reference framework. It guides in gap analysis of products to identify missing steps and improvement areas in a processes thus producing more complete products. Usage of etom by service providers and vendors allows system integrators to easily integrate the services provided by vendors into the service provider s network.

30 2.4. ARCHIMATE LANGUAGE 19 Figure 2.9: ArchiMate layers and aspects [15] 2.4 ArchiMate Language This section gives a brief introduction to ArchiMate modeling language followed by the different layers and aspects of the language, graphical notations used to describe the different aspects in different layers with examples and a brief explanation on the viewpoints provided by ArchiMate with example. ArchiMate is an enterprise architecture modeling language which is a product of a Dutch consortium of the Telematica Instituut and industrial and academic partners. The language aims at providing architecture language and visualization techniques for the integration of different domains of an enterprise [15]. It achieves this by providing a meta model to link different domains of the enterprise ArchiMate Layers and Aspects ArchiMate broadly classifies the enterprise into three different layers horizontally as presented in Figure 2.9. Below we give a brief description of each of the layer [15]: 1. The Business Layer offers products and services to external customers, which are realized in the organization by business processes performed by business actors. 2. The Application Layer supports the business layer with application services which are realized by (software) applications. 3. The Technology Layer offers infrastructure services (e.g., processing, storage, and communication services) needed to run applications, realized by computer and communication hardware and system software.

31 20 CHAPTER 2. BACKGROUND Figure 2.10: ArchiMate Concepts: an example The language also defines the three aspects of an enterprise, namely the information, behavior and structure, shown vertically in Figure 2.9. The three aspects of the language were actually inspired by three aspects of a sentence in natural language which are the object (information), the verb (behavior) and the subject (structure) [16] Concepts The architectural elements that are modeled in the three horizontal and vertical groupings are referred to as concepts in ArchiMate language. ArchiMate has defined a general set of architecture concepts and has proposed a graphical notation for representing each of these concepts. The concepts in the information aspect are called passive elements, behavioral aspect are called behavioral elements and structural aspect are called active elements. The active structure elements are the subjects of an activity [16]. The active structure concepts are assigned to behavioral concepts, to show who or what performs the behavior. The passive structure elements are the objects on which behavior is performed. The business role, business process and the business object shown in Figure 2.10 are examples of some of the concepts that exist in the business layer of ArchiMate. In the given example, the concept business process shows what activity is being performed and so it represents the behavioral aspect. The concept business role performs the business process and therefore is an active element representing the structural aspect. The concept business object is acted upon by the business process and therefore it is a passive element representing the information aspect. There are over fifty concepts that are discussed by ArchiMate with graphical notations for each of these concepts. We refer to Appendix A for whole set of concepts Relationships In addition to the concepts, ArchiMate defines the main relationships between concepts in the business layer, the application layer, and the technology layer and the relationships between the concepts within each layer (i.e. the relationships between the aspects). With the help of predefined concepts and relationships ArchiMate provides meta models for

32 2.4. ARCHIMATE LANGUAGE 21 each layer and also the meta model to represent links between the different layers. The relationships in ArchiMate are classified into three groups [11]: 1. Structural relationships: A structural relationship models the structural coherence of concepts of the same or different types. For example, Figure 2.11 shows a realization relationship which links a logical concept like the service with a more concrete concept like the process that realizes it. Figure 2.11: Structural relationship [11] 2. Dynamic relationships: A dynamic relationship models the dependencies between behavioral concepts. For example, the flow relationship describes the exchange or transfer of, information or value between processes, functions and components[11]. Figure 2.12 shows the flow between two components. Figure 2.12: Dynamic relationship [11] 3. Other relationships: The relationships that do not fall under structural and dynamic relationships fall into this category. For example, the grouping relationship cannot be modeled as structural or dynamic. The grouping relationship is as shown in Figure All the relationships defined in ArchiMate and the graphical notations used for representing these relationships are given in the Appendix A.

33 22 CHAPTER 2. BACKGROUND Figure 2.13: Grouping relationship [11] Services In ArchiMate, services play a central role in each of the layers. In general, services are provided by organizations to their customers, by applications to business processes, or by technological facilities to applications. ArchiMate defines a service as a unit of functionality that some entity (e.g., a system, organization or department) makes available to its environment, and which has some value for certain entities in the environment [16]. The services defined by ArchiMate are business service, application service and infrastructure service which corresponds to the functionality provided at business, application and infrastructure layers respectively [13]. A service in ArchiMate is a concept belonging to the behavioral aspect. We give below a brief description of each of the service as defined in [11]. 1. A business service or organizational service represents a coherent piece of functionality that offers added value to the environment, independent of the way this functionality is realized internally. These services are defined in the business layer. 2. An application service is an externally visible unit of functionality provided by one or more components, exposed through well-defined interfaces, and meaningful to the environment. The service concept provides a way to explicitly describe the functionality that components share with each other and the functionality that they make available to the environment. 3. An infrastructure service exposes the functionality of a node to its environment. This functionality is accessed through one or more infrastructure interfaces. An infrastructure service should be meaningful from the point of view of the environment; it should provide a unit of functionality that is in itself useful to its users, such as application components and nodes. Each of the services discussed above is classified into external services and internal services. External services are those services that are provided by one layer to the other; internal services are those services provided with the same layer. For example a distinction can be made between external organizational services, offered to external customers, and

34 2.4. ARCHIMATE LANGUAGE 23 internal organizational services, offering supporting functionality to business processes within the organization [13]. Services at different layers of ArchiMate and their relationships are shown in Figure It shows that the external services of the higher layer may depend on services in the same architectural layer (internal services) or one layer below (external services). For instance, application services may depend on external infrastructure services and also on services offered by internal application services [11]. Figure 2.14: Services in ArchiMate language [11] Viewpoints The viewpoints in ArchiMate are a selection of relevant subset of the concepts and the representation of that part of an architecture that address the specific set of concerns targeted for specific set of stakeholders [12]. ArchiMate has defined the meta models for various viewpoints considering the common set of concerns to be addressed. It also provides a framework for classification of the viewpoints based on the purpose and the abstraction level of the viewpoint. Figure 2.15 shows the business process viewpoint used to show the high-level structure and composition of one or more business processes. It consists of the concepts such as the business object which is used by the behavioral element such as business process/interaction. The business process/interaction can be triggered by an event or by another business process.

35 24 CHAPTER 2. BACKGROUND Figure 2.15: Metamodel of business process viewpoint [12]

36 Chapter 3 Mapping Ericsson s Product to etom This chapter is dedicated to the discussion of the mapping that was carried out. It starts with a general overview of the mapping. The first section discusses the decisions that were taken before performing the mapping. The second section provides an overview of the product chosen for the mapping. The third section explains the steps involved in the mapping methodology in detail. The fourth section discusses the generic mapping methodology based on the mapping performed. The fifth section concludes this chapter. The mapping that we are trying to establish is between a product of Ericsson and the etom processes. The mapping was carried out to identify those etom processes to which the product has association. In order to carry out the mapping, the approach adopted was to follow the textual descriptions given for each of the process in etom process decomposition documentation. There are two types of descriptions given for each of the process, the brief description and the extended description, explaining the responsibilities that the process should support. We used the extended descriptions of the processes for our mapping as it explains the functionalities represented the process in detail. This kind of mapping can be made at any level of decomposition and it is the description of the process for that level that decides whether or not the product maps to the process. So, when a Level 1 mapping is made, it is only the Level 1 process description (and not the details at the Level 2 process) that applies. Therefore, it is possible that a Level 1 process might be assessed as supported, even though some of the contained Level 2 process functionalities are not satisfied. Similarly, if assessment is made at Level 2, and if all the functionalities of Level 2 processes are satisfied by the product, then it follows automatically for the corresponding Level 1 and no explicit assessment need be made for that Level 1. This applies throughout the etom decomposition hierarchy [etom link]. 25

37 26 CHAPTER 3. MAPPING ERICSSON S PRODUCT TO ETOM It is important to note that for any given process, there are several ways in which it can be supported by a product. Capturing this information is necessary for the mapping to be useful. We identified some of the ways in which the product can be associated to an etom process which are as follows: 1. A product could completely or partially provide the functionalities attributed to a process. For example, a product might support most of the capabilities of the Retention and Loyalty process. 2. A product could supply data to a given process. For example, a product might provide billing related data to many processes such as Bill Inquiry Handling and Bill Invoice Management. 3. A product could make use of data provided by a given process. For example, a product might be able to use the performance degradation report provided by Supplier/Partner Performance degradation Report process to take necessary action. A product can not only be associated in three ways mentioned above, but also can be associated in any of the combination of the three ways. For example, the product can provide the functionality attributed to the process as well as supply data to the process. 3.1 Decisions on Mapping Following are the decisions that were taken before we carried out the mapping process. First decision was on the choice of product for mapping. There were four products available at Ericsson (BMUM R & D, NL) to start with. Two of them were completed and available to be deployed at customer environment. The other two were in their initial stages of development. Since the idea was to map an existing product into etom, we needed a product which was completed. Further, due to time constraints, the following criteria were used for selection among the two well-established products. Lower complexity Availability of product information Support from Ericsson personnels Based on the above mentioned criteria, it was decided by the modeling team to choose Ericsson Multimedia Ringback solution for mapping. The product will be referred to as Ringback solution throughout the report. The next section of this chapter provides an overview of the Ringback solution. The second decision was to identify the process areas of etom framework to which the product had to be mapped. Based on the understanding of Ringback solution obtained

38 3.1. DECISIONS ON MAPPING 27 Figure 3.1: Ericsson process mapping (BMUM) from the commercial description document [5], it was clear that the functionality provided by the product directly supports the subscribers of of the Service providers (Ericsson s customers). This kind of support is covered by the operations area of etom colored blue in Figure 3.1 (For more information on operations area, refer to Chapter 2 Section 2.3). Thus, we indentified that Ringback solution should be mapped into the operations area of etom. The third decision was to identify the roles played by Ericsson with respect to Ringback solution. From the commercial description document[5] of Ringback solution we could identify that Ericsson can play the role of supplier/vendor, system integrator and hosting provider with respect to Ringback solution. However, Ringback solution belongs to Ericsson BMUM R& D, which plays the role of supplier/vendor. Therefore, our concentration for mapping was limited to the role of supplier. The fourth decision was on the approach to be followed for mapping. We could follow one of the two approaches: 1. List all the functionalities of the product. For each of the functionality, check if the functionality could be mapped to any of the etom processes. 2. Scan through all the etom processes and check if the etom processes could be mapped to any of the functionalities provided by the product. We adopted the second approach, as the processes defined in etom framework were well structured. There was already a list of defined processes in etom that had to be scanned. As already discussed, the etom processes are hierarchically grouped into 4 different levels starting from level 0 to level 3. So, the fifth important decision for mapping was to choose the level at which mapping should be started. Level 0 spans across the SIP and Operational processes of the etom framework. Since we are looking only at the operational processes we did not choose level 0 as our starting point. Level 3 explains the processes in detail and there are 176 processes at this level which is too many to start with. Therefore, we could start our mapping at either level 1 or level 2.

39 28 CHAPTER 3. MAPPING ERICSSON S PRODUCT TO ETOM In practice, the mapping can be started right from level 1 and then be further analyzed at deeper levels based on the mapping done at level 1. The mapping at this level is feasible if there is an in-depth knowledge of the product being mapped and the etom framework. However, because of the lack of expertise in both the product chosen and the etom framework we started mapping the product at level 2. Apart from the lack of expertise there are several other reasons why we chose level 2 as the starting point for our mapping process. They are as follows: The description given at level 2 are detailed enough to start the mapping. The number of processes required to map at this level is 32 which is neither too few nor too many map. It reduces the number of processes to be mapped at level Ringback Solution Description The Ringback solution gives users the ability to replace their traditional ringback tone - the tone the calling party hears before the phone is answered or voic activates, with a Multimedia content (audio or video clip, a picture or an advertisement) [6]. The product takes care of call handling for those calls for which a ringback clip needs to be played. It detects the capabilities of the end-user terminal and selects the right content type; tone or video for each ringback call.the solution includes subscriber management and content management services. The various market segments targeted by the product are the consumers, enterprises, the operators and service operators. The various offerings of the product, targeting the mentioned market segments are [6]: 1. Consumer Ringback: This is the regular personalized greeting service where subscribers express their individuality by provisioning dedicated content for callers. 2. Operator Ringback: This gives the operator the possibility to spread their brand to people calling their subscribers. 3. Enterprise Ringback: This offers the enterprise the possibility to let people that call their employees, listen to an enterprise brand message. 4. Consumer Ringback Advertising: Advertisers can be targeted by offering the alerting phase of the call as advertisement channel towards consumers Key Roles The key roles involved in the product are the subscribers, the operator, the service provider and the content provider as shown in Figure 3.2 Basically the following responsibilities

40 3.2. RINGBACK SOLUTION DESCRIPTION 29 Figure 3.2: Roles in Ringback solution [6] and relationships can be distinguished: The operator offers the necessary infrastructure like network capacity, disk storage, etc to one or more service providers to run Multimedia Ringback solution (agreement between operator and service provider). The service provider offers subscribers a Multimedia Ringback subscription (agreement between service provider and subscriber). It offers accounts to one or more content providers to use disk space, upload, publish content etc. Depending on the agreements made the service provider can sell the content usage to the subscribers. Note: The operator and the service provider can be the same entity The content provider is the party that provides ringback content like music, video clips (in case of Consumer Ringback), advertisements (in case of an Consumer Ringback advertising) or branded messages (e.g. in case of Operator or Enterprise Ringback). The subscribers are those who subscriber for Ringback service. subscriber could be an end user or enterprise. In this case the Logical Overview The logical overview of the Ringback solution along with it logical components are as shown in Figure 3.3. Logical Components Brief explanations on logical components of the Ringback solution are given below. The details are from Ringback documentation [6], [5]. 1. Subscriber Management and Content Management: The subscriber management takes care of various features related to subscriber such as:

41 30 CHAPTER 3. MAPPING ERICSSON S PRODUCT TO ETOM Figure 3.3: Logical overview of Ringback solution Subscription: The customers of service providers can subscribe/unsubscribe from Ringback service. Inbox: Each subscriber is assigned with an Inbox where the content purchased can be stored, viewed and deleted. Caller group: Subscribers can create caller groups and assign members to these groups. The subscriber can then assign each group with content which will be played back to the members in the group when they call the subscriber. Content preview and Purchase: Subscribers can preview the content and then purchase them. Schedule: Subscribers can select content to be played back to callers according to a selected schedule. Gift content: Subscribers can gift content to other subscribers. 2. Media Streamer:The Media Streamer provides the streaming of content (audio, picture or video) to the User Equipment of the caller. 3. PGS Application Server: The Application Server provides advanced call control like matching the calling party terminal capabilities and the Media Streamer capabilities to determine the media type to be used.it also determines the content to be streamed,sets up call to the called party,monitors the calling and called party and connects or disconnects the Media Streamer. 3.3 Mapping Methodology The methodology that we followed to do the mapping is as follows: 1. Representing roles using etom terminology. 2. Mapping the product at different levels of etom framework.

42 3.3. MAPPING METHODOLOGY 31 Figure 3.4: Business entities as described in etom [22] 3. Managing the mapping results. 4. Analyzing and visualizing the mapping results. We explain each of the steps mentioned in the methodology with respect to the Ringback solution, with appropriate examples. Step 1: Representing roles using etom terminology The first step of the mapping methodology is to represent the roles involved in the product in terms etom terminology. These roles are the business actors involved in the telecommunication value network. They may be the operators, service providers, subscribers and so on. (Figure3.2 shows the key roles involved in the Ringback solution). The etom framework provides a standard way of defining these roles. It categorizes these roles into 5 different groups and refers to them as business entities. It uses this standard terminology in the process descriptions which we intend to use for our mapping. Therefore, it is important to represent the roles involved in Ringback solution in terms of terminology provided by etom. The business entities defined by etom are as shown in Figure 3.4. A brief description of each of the entities from etom documentation [22] along with the role in the Ringback solution it represents is given below. Customer: The customer represents an end customer responsible for ordering, using and paying for the products. In Ringback solution, the role of subscriber represents the customer entity.

43 32 CHAPTER 3. MAPPING ERICSSON S PRODUCT TO ETOM Figure 3.5: Roles in Ringback solution with etom terminology Service Provider: The Service Provider presents an integrated view of products to the customer. It is responsible for the contractual interface with the customer to, sell products to the customer, provide the customer with contact and support, and bill the customer for the products supplied. The service provider can deliver some or all of a service product to the customer itself, or it might subcontract out provision of parts, or even all, of the product to other service providers. In Ringback solution, the key roles namely the operator and the service provider represent the service provider entity. Complementary Provider: The Complementary Provider extends the product provided by the service provider and offers additional capability that the service provider is not itself offering to the customer, i.e. it complements the product being provided by the service provider and adds value to it, but is not essential for provision of the product itself. There might be some content providers who provide media content which complements the product. Therefore, the content provider can play the role of complementary provider. Intermediary: The Intermediary supplies a service for a fee. For example, a localized selling function in a market where the service provider has a limited presence and/or understanding is a typical service provided by an intermediary. None of roles in the Ringback solution represents this entity. Supplier: The Supplier interacts with the service provider in providing hardware, software, product and services which are assembled by the service provider in order to deliver its solutions or services to the customer. In Ringback solution, this definition of supplier can be used to represent the role played by Ericsson, content provider. The key roles along with the corresponding etom terminology associated with each of the role are as shown in Figure 3.5. Step 2: Mapping at different levels of etom framework

44 3.3. MAPPING METHODOLOGY 33 Map product at level 2 of etom framework: To map the Ringback solution into the etom framework at level 2 we identified the following two approaches that could be adopted. (a) Self analysis: The idea behind this approach was to: Study the commercial and the technical description documents of Ringback solution. Study the description of processes in the etom framework. Do the mapping based on the understanding achieved as a result of study of these descriptions. (b) Interview the Ringback solution experts: The idea behind this approach was to first study the description of the processes in the etom framework. Then, based on the understanding of the processes conduct interviews with the Ringback solution experts to see if there exists a mapping or not. For the first method to be successful, the person carrying out the mapping should have a clear understanding the various levels of details presented in the documentation of Ringback solution and the etom processes based on the self study. Since, we were naive to both the Ringback solution and etom processes we did not adopt this methodology. However, the second method does not impose such demands as the person carrying out the mapping can always get reliable information based on direct discussion with the Ringback solution experts. Moreover, it could also provide better understanding of the etom processes because of the expertise of the solution experts in the field of telecommunication. We choose this method for our mapping. Before we started with the actual mapping process we had discussions with the product manager of the Ringback solution to explain the work we are doing. We also gained some insight into the high level functionalities that the product provided. However, to do the mapping more knowledge was needed on the solution. So, we planned to identify experts from Ringback solution to start with the interview process. The four functional groupings (horizontal processes) at level 1 of the etom framework were used. The horizontal process grouping was used instead of vertical process grouping as it provided a clear organizational boundary relating the similar functionalities into one group. During the interview we discussed the etom process based on the process description and tried to extract the answers for the questions given below for each of the etom process. (a) Does Ringback solution have functionalities that could be associated to the process? (b) How is the Ringback solution associated to the process? (Does it provide the functionality, supply data) (c) Does Ringback solution need to be associated to this process? (d) If yes how? If no, why not?

45 34 CHAPTER 3. MAPPING ERICSSON S PRODUCT TO ETOM (e) Will it add value to the operators if Ringback solution supports this process? (f) Is the process automated/semi-automated/manual? Following is an example of mapping done at level 2 for the etom process Retention and Loyalty belonging to the Customer Relationship Management. Process description [20] Retention and Loyalty processes deal with all functionalities related to the retention of acquired customers, and the use of loyalty schemes in the potential acquisition of customers. They establish a complete understanding of the needs of the customer, a determination of the value of the customer to the enterprise, determination of opportunities and risks for specific customers, etc. These processes collect and analyze data from all enterprise and customer contact. Interview details The following are the details of the interview that we conducted for this process based on the description given above and the scenario we considered in the discussion. (a) Does Ringback solution have functionalities that could be associated to the process? Yes, it is associated because it provides the support for loyalty schemes as mentioned in the description of Retention and Loyalty process. For example, Ringback solution provides free subscription period to new subscribers, free tones to the subscribers. It also provides functionalities like personalization of user profile, uploading user content, gift a song feature which helps in the retention of the subscribers. (b) How is Ringback solution associated to the process? (Does it provide the functionality, supply data) Ringback solution is associated to the process as it provides some of the functionality of Retention and Loyalty process. However, it does not provide all the necessary functionality as specified in the description of the process. For example, it does not help in determination of value of the customer (subscriber) to the enterprise (service provider); it does not help in determination of risks for specific customers (subscribers). Therefore, Ringback solution is associated to the process by partially providing the functionality. (c) Is it necessary to provide the other functionalities specified in the process description? No, it is not necessary as it is not the responsibility of the Ringback solution itself to determine the value of the subscriber to enterprise or determination of risks for specific subscribers. It is to be taken care of by the service provider himself. (d) Is the process supported automated/semi-automated/manual? The process is automated.

46 3.3. MAPPING METHODOLOGY 35 Figure 3.6: Level 3 decomposition of Retention and Loyalty process [20] Map product at level 3 of etom framework: To do the mapping at level 3 the idea was to take only those level 2 processes into which Ringback solution could be mapped and analyze them further at level 3. Initially, the plan was to follow the same interviewing technique for the level 3 processes. However, in the course of mapping the level 2 processes we realized that the experts we interviewed though had an excellent knowledge on the Ringback solution, they were not well versed with etom processes. Also, there were too many processes that had to be mapped and it was difficult for us to arrange meeting with the experts to conduct the interviews as their schedule used to be very busy. So, we switched to the self analysis method described previously. This seemed to be a feasible option as we had gained more knowledge on the Ringback solution and also we had some experience of mapping already. In case of doubts regarding the mapping we contacted the concerned expert for resolution. To explain the mapping done a level 3 let us consider the decomposition of Retention and Loyalty process, discussed above, at level 3. The following Figure 3.6 shows the level 3 decomposition of Retention and Loyalty process. Each process is described in detail below. Personalize Customer Profile for Retention and Loyalty: Process description [20]: The purpose of this process is to provide the personalization opportunities for customers that will encourage them not to switch to another Service Provider. Personalization allows delivery of services that more closely match the customer s needs. Collection of Personalization Information also discourages switching since the customer would have to build up the same personalized experience with the next Service Provider. Loyalty schemes allow tangible benefits to be offered to good customers in a mass-market. Self-Analysis: Based on the Ringback solution documentation [6], [8] we found that the Ringback solution does provide personalization opportunities for the customers (subscribers). The features in Ringback solution that allows personalization are the ability for the customers (subscribers) to create caller groups, create playlist from songs purchased, assign songs to individuals or caller groups, assign songs for a particular period, allow personal content upload and so on [7]. All these features are grouped into

47 36 CHAPTER 3. MAPPING ERICSSON S PRODUCT TO ETOM Figure 3.7: Mapping between Ringback solution and Personalize Customer Profile for Retention and Loyalty process two services namely the Playlist Management Service and Caller Group Management Service as specified in Interface specification [7]. This is as shown in Figure 3.7. It also provides the necessary platform to implement various loyalty schemes in terms of promotions by providing free ringtones, free subscription period. Build Customer Insight: Process description [20]: The purpose of this process is to ensure that Service Provider and the customer feel confident that the relationship is founded on up-to-date, accurate and legally compliant information. The Service Provider will incorporate into the customer profile, all relevant information gathered through all contacts with the customer (usage pattern, demographics, life stage, household, community of interest, business direction). Customer and market information from other sources may be gathered, which will build a better understanding of the customer. Customer Information must be made available to any process that needs to access it. This customer information will be used to continually refine the means and style of interaction, and the solution sets and customer experience offered. Self-Analysis: Ringback solution currently does not support this process. Though, it provides the top songs purchased, most popular categories and so on in general, it does not provide a mechanism to suggest songs or categories to one particular customer (subscriber) based on his/her usage pattern, area of interest as mentioned in the description of Build Customer Insight. However, it is possible to provide these kind of features, as Ringback solution will have all the necessary information to do this [7]. This will also help in retention of the acquired customers and thus add value to the operators/service providers. Here, we build the customer insight only with respect to Ringback solution. If this process is already supported by the service provider, which builds customer insight on a bigger scope, then

48 3.3. MAPPING METHODOLOGY 37 Figure 3.8: Mapping between Ringback solution and Establish and Terminate Customer Relationship Ringback solution could supply data to such process. Analyze and Manage Customer Risk: Process description[20]: The purpose of this process is to ensure that risk analysis is based on information collected from all processes and that consistent risk assessment is used across the Enterprise. Its purpose is also to track and improve Operations, target and win the right customers and improves Sales Conversion rate. It determines the credit risk, fraud risk, influence risk, and churn risk. It identifies treatments to manage these risks and focuses on using customer information. Self-Analysis: Ringback solution does not interact with all the processes and based on that analyze the risk involved for the customer. Ringback solution is a solution given to the customer and it is irrelevant from the point of view of Ringback solution to provide a consistent way of assessing the risk across the enterprise. It should be taken care of by the service provider itself. Establish and Terminate Customer Relationship: Process description [20]: Verify the customer identity, manage the customer identity across the Enterprise, and manage termination as appropriate. The need for complete termination of relationships needs to be differentiated from just terminating all services. Self-Analysis: If the process is considered with respect to Ringback solution then it does provides this functionality. It does verify the customer identity by authenticating the customer (subscriber). It manages the customer identity and termination by providing mechanism to subscribe and unsubscribe features through subscription management services [8] and [7]. Therefore, it could be concluded that Ringback solution provides this functionality. This mapping is as shown in Figure 3.8. Validate Customer Satisfaction: Process description [20]:

49 38 CHAPTER 3. MAPPING ERICSSON S PRODUCT TO ETOM The purpose of this process is to validate that predicted/expected value is delivered by the solution and that the after-sales processes (billing and assurance) are initialized. It validates that the customer is capable of realizing maximum value from the operation or use of the solution and that intense Provider involvement is no longer needed to manage the solution. This process ensures that the customer is satisfied that the solution that was actually delivered meets original or updated expectations and agreements and that the solution is operable by the customer. Self-Analysis: Ringback solution does not provide any functionality related to this process. However, when the process is considered with respect to Ringback solution then it is possible to validate the customer satisfaction by including mechanisms like review/feedback and ratings on the Ringback solution. Out of the 32 processes at level 2, we found 13 processes relevant to Ringback solution. This reduced the number of processes to mapped at level 3 from 176 to 61. And out of those 61 level 3 processes we found 30 level 3 processes relevant to Ringback solution. The mapping results that we obtained were verified with one of the experts belonging to Ringback solution. Step 3: Managing the mapping results One of the important parts of the mapping process was to manage the data that was collected during the mapping. Most of the results that we obtained from our mapping were recorded on paper and in s. Results stored in this format are not easily manageable and moreover analyses of mapping results are not easy. In order to easily manage and analyze the mapping results it could be either stored in an excel sheet or can be stored in a database. If the mapping is conducted by an employee already having the knowledge of etom and the product being mapped then it is suggested to use a excel sheet to capture the details of mapping. If the mapping is to be conducted for multiple products involving multiple employees then it is suggested to use a tool or web portal with questionnaire to capture the mapping details and generate various desired results. We considered the second scenario and stored the mapping results in database. The database that we used for this purpose was MS Access. We created two tables in our database. The two database tables are shown in Figure 3.9. The short description of each of the table and their columns are explained below. etombuzprocesses: This table consists of the descriptions of various etom business processes at level 2 and level 3. Column description: ProcessName: Name of the etom business process. Description: The extended description of the business process obtained from the etom process decomposition document. VerticalGroup: The end-end vertical group of etom to which the process belongs.

50 3.3. MAPPING METHODOLOGY 39 Figure 3.9: Database tables HorizontalGroup: The functional horizontal group of etom to which the process belongs. ProcessLevel: The level to which the process belongs. It can be either level 2 Level 3. ProcessMapping: This is an inventory of results obtained as a result of mapping the Ringback solution into etom framework. Column description: ProcessName: Name of the etom business process. HorizontalGroup: The functional horizontal group of etom to which the process belongs. ProcessLevel: The level to which the process belongs. It can be either level 2 Level 3. ProcessMapping: This is an inventory of results obtained as a result of mapping the Ringback solution into etom framework. Functionality: Refers to the etom functionalities, given as a part of extended process description, which the Ringback solution supports. EricssonRole: This column refers to the role played by Ericsson with respect to the product being mapped. These are the professional services that are provided by Ericsson. The values that it can take are Supplier, System Integration and Hosting provider (However, we concentrated only on the supplier role). ProcessInvolvement: This column explains how Ringback solution maps to etom process (by providing functionality of, supplying data to, making use of the process). This column is also used to represent that the process could be provided by the solution being mapped by setting the value to Can provide functionality. AutomationLevel: This column is to explain the way in which the functionality is provided, whether it is Automated, Semi-automated or Manual. Comments: This column is to provide extra comments which could not be conveyed through the other fields in the table. If the mapping is to be conducted for multiple products involving multiple employees

51 40 CHAPTER 3. MAPPING ERICSSON S PRODUCT TO ETOM Figure 3.10: Mapping results at the Level 1 processes in etom then it is suggested to use a tool or web portal with questionnaire to capture the mapping details and generate various desired results. Step 4: Analyzing and visualizing the mapping results The final step of our mapping methodology is the analysis and visualization of mapping results stored in the database. Analysis of the mapping results can help in identifying missed functionalities in the product with respect to etom and the necessity to provide the functionality in terms of added value to the customer. It provides insights into details like the number of etom processes the product currently supports, the impact the product has on the customer s environment. Based on this kind of analysis, decisions on the roadmap for the product can be presented. To better understand the mapping, visualization techniques can be used to present the mapping results. For example, charts or graphs can be used for this purpose. Following are some of the analysis results represented in pie charts that provides the results of the mapping carried out. Figure 3.10 shows that out of the total mapped processes at level 2 61% was not applicable meaning they are not related to the solution and the rest 39% are related. Also, it shows the amount of involvement in each of the functional areas of etom. This kind of analysis can be used to show to the customers that there is a major involvement with the CRM systems in the customer environment. Figure 3.11 explains the mapping results at level 3. Here it can be seen that 7% of the mapped results says Can provide functionality meaning 7% of the functionality was missed in the actual solution (Note: Build Customer Insight and Validate Customer Satisfaction are among the functionalities that were missed at level 3, which was discussed as an example of mapping at level 3).This kind of information can be useful in extending the functionality provided by the product. In discussions related to the mapping results with the Ringback solution expert, we were informed that some of the functionalities are already covered by the advanced version of Ringback solution. Also, the kind of analysis shown in Figure 3.10 and 3.11 is extracted by mapping multiple products, it provides a view of the area that is least supported. This

52 3.4. GENERIC MAPPING METHODOLOGY 41 Figure 3.11: Mapping results at the Level 3 processes in etom Figure 3.12: Mapping results at the Level 2 processes in etom information can be used to see if a new product solution can be created to support these areas. Figure 3.12 is the mapping results for at level 2. The red borders around the process represents that Ringback solution is associated to these processes of etom. Representing the results in this form can be helpful in interactions with customers for the suppliers. As it provides a view of which systems will actually have impact. Results of the same kind at level 3 can be used by the system integrators to understand which systems will be impacted. The results shown above are just some of the examples. There can be various kinds of analysis that can be done of the data obtained from mapping. 3.4 Generic Mapping Methodology In the previous section we discussed the mapping methodology that was carried out. Based on the knowledge that we gained by performing the mapping process, we refine the

53 42 CHAPTER 3. MAPPING ERICSSON S PRODUCT TO ETOM mapping methodology and propose a generic mapping methodology that can be followed by an enterprise that wants to map its product to etom. The generic mapping methodology proposed is given below. The steps followed are based on the decisions taken on mapping explained in section 3.1 and the mapping methodology that we followed which is explained in section Identifying the process areas to be mapped The product to be mapped to etom may belong to any of the three major etom process areas (Refer Chapter 2 section 2.3). In this step, identify the process area to which the product should be mapped. This can be done can by having a basic information available on the product. 2. Representing roles using etom terminology Identify the different roles played by the business actors involved in the telecommunication value chain and represent them using etom terminology. In Ringback solution, the roles were already given. 3. Mapping the product at different levels of etom Map the product selected at different levels of etom. Select the level of mapping based on the expertise in etom and the need of mapping (For example, a high level mapping is sufficient if the mapping results are to be used in customer interactions). Capture the mapping results in an excel sheet, tool or web portal. 4. Analyzing and visualizing the mapping results Perform analysis on the mapping results to identify gaps and improvements. Visualize the results as appropriate, for better understanding and presenting the results to different stakeholders. 3.5 Conclusion The main intent of this chapter was to establish a mapping between Ericsson product and the etom framework. This was achieved by defining a mapping methodology to be followed. The steps in the methodology are explained by applying it to one of the products offered by Ericsson called as the Ericsson Multimedia Ringback solution. This includes the mapping carried out at different levels along with the analysis and visualization of mapping results and its benefits. By following the mapping methodology, we were able to establish a relation between the etom processes at different levels and the functionalities provided by Ringback solution. These mapping results are further used to integrate etom into ESM which is explained in the next chapter. As a result of this mapping activity we found different possible ways in which a product could be associated to etom. Also, based on the understanding gained by applying the

54 3.5. CONCLUSION 43 initial mapping methodology we were able to propose a refined mapping methodology that can be used by an enterprise that wants to map its product to etom.

55 44 CHAPTER 3. MAPPING ERICSSON S PRODUCT TO ETOM

56 Chapter 4 Modeling in ESM This chapter discusses the work related to modeling carried out as a part of the thesis. The chapter is divided into three sections. The first section discusses modeling the mapped data into ESM. The second section explains the methodology for using etom in ESM (here is where we discuss logical link). The third section concludes this chapter. 4.1 Modeling Approach After mapping the Ringback solution into etom, the next task was to model Ringback solution and identify how etom could be used in ESM. To continue with the modeling we identified two approaches that could be followed. First, the top down approach in which we start with business modeling, then the capability modeling. Second, the bottom up approach in which we start with the capability modeling followed by the business modeling. It is to be noted that realization modeling is out of the scope of this work. We followed the bottom up approach, as the Ringback solution documentation [6], [8] had descriptions on necessary details on components and services that could be used for capability modeling. At the time of modeling the structure of ESM was not yet available but it was clear that ArchiMate would be used as the modeling language. Therefore, we used the meta model provided by ArchiMate for our modeling. For the complete Archimate meta model refer to Appendix A Capability Modeling First, we started with modeling business layer of the capability model. To model this layer, one of the main concepts required is the business processes. However, there was no business processes defined in the Ringback solution documentations. Therefore, we directly used the etom business processes (identified as a part of mapping in chapter 3) in the models. 45

57 46 CHAPTER 4. MODELING IN ESM Then we identified the application layer concepts like the application components and the application services. After modeling these two layers we established the relationships between them based on the meta model suggested by ArchiMate. Similarly, we modeled the infrastructure layer. In the model, different colors are used to signify each of the layers of ArchiMate. The yellow, blue and green colors are used to represent business, application and infrastructure layer respectively. As discussed already, the modeling was carried out in PowerDesigner. Figure 4.1 shows one such model that was created. Various models that were created are presented in Appendix C. The model created is based on the etom level 2 business process Retention and Loyalty which is same as the example used for explaining the mapping in chapter 3 section 3.3. It can be seen that the Subscription Handling service is mapped to the etom business process Establish and Terminate Customer Relationship as in Figure 3.8. The only difference is that the relationship between the two is replaced by the relationship specified in ArchiMate meta model and they are represented by ArchiMate notations. As shown in the model, the business service that is realized by the business processes is Customer Self Care which is used by the End User of the Ringback service through the WEB/WAP/IVR/SMS interfaces. This does not mean that Customer Self Care is completely realized by Retention and Loyalty business process. This business process realizes only a part of the service. The other business processes involved in the service is not shown as example concentrates only on Retention and Loyalty business process. The concepts identified in the model were based on the descriptions provided on each of the concept by ArchiMate and based on the descriptions found in Ringback solution documentation [6],[8],[7]. For example, the concepts at the application layer like the Subscriber Management (SM) component was identified from [6], [8] which provides various services related to subscriber like subscription handling, caller group management, etc. SM component was chosen as a component as it matches the definition of ArchiMate component. The SM component exposes its services to the external environment through Ringback Integration API [8]. The SM component is a part of the bigger component called the SMCM (Subscriber Management and Content management) component which provides services related to content management (A discussion on functionality provided by this component is in chapter 3 section 3.2). The application components identified at the application layer uses the services provided at the infrastructure layer. In the example shown in Figure 4.1 HTTP Request Handling and Database services are the infrastructure services provided by WEB/WAP server and the Data Warehouse nodes respectively. These infrastructure services provided by the nodes are made available to the external environment through infrastructure interfaces. In this example, the Data Management service is made available through the JDBC interface [6]. In Figure 4.1, the business processes Build Customer Insight and Validate Customer Satisfaction are colored differently to notify that it is currently not a part of Ringback solution but could be, as discussed in chapter 3. Since the etom business processes are generic, we derived the processes that were more

58 4.1. MODELING APPROACH 47 Figure 4.1: A part of Ringback solution modeled by using the mapping results in Archi- Mate

59 48 CHAPTER 4. MODELING IN ESM Figure 4.2: Relating the mapped etom process to product specific business process related to Ringback solution and would relate to etom processes defined in the model. For example consider the level 3 business process Establish and Terminate Customer Relationship. This process verifies and manages customer identity across enterprise and manages termination as appropriate. The process which takes care of all of this with respect to Ringback solution is Subscription Management process. This is shown in Figure 4.2. Similarly, we have derived two more business processes namely the Caller Group Management and Playlist Management also shown in Figure 4.2. The etom processes in Figure 4.1 can be replaced with Figure 4.2along with other Archi- Mate concepts can make the model cluttered. Therefore, we replaced etom processes in Figure 4.1 with the derived processes and captured the relationship between the etom processes and the derived business processes in a separate model. This relation represents the mapping between etom and the product in terms of processes. A formal way of capturing this mapping relation is proposed using models which we call map models. These map models are explained in detail in the section 4.2. By the time we completed the models, the structure of ESM was available in the PD though not a complete one (The structure of ESM is explained in chapter 2 section 2.2). As discussed, there were also selected ArchiMate viewpoints that were included as a part of capability modeling. The modeling team suggested us to model the Ringback solution using the meta model of the viewpoints that were in ESM. Since, our focus was on business layer and application layer, we modeled some of the viewpoints that deal with these areas. An example of one such viewpoint is Service Realization Viewpoint. The service realization viewpoint is used to show how one or more business services are realized by the underlying processes (and sometimes by application components) [12].

60 4.1. MODELING APPROACH 49 Figure 4.3: Service realization viewpoint Figure 4.3 is a service realization viewpoint for Ringback solution which explains that the business service Customer self care identified in the product viewpoint is realized by Subscription Management, Playlist Management and Caller Group Management business processes. These processes in turn uses the application level services Subscription Handling, Organizing Playlist, and Organizing Caller Group respectively which is realized by the Subscriber Management component. The actors that perform this business processes are the Prepaid/postpaid User and the Enterprise both of them playing the role of Subscriber. Similarly, it also explains the realization of Content Purchase service Business Modeling After completing the modeling of the Ringback solution in the capability modeling we proceeded with business modeling. Business modeling involves creation of business models using Osterwalder canvas for target customer and Ericsson itself (Business modeling is discussed in detail in chapter 2 section 2.1). We started with the target customer (TC) canvas and defined all the nine building blocks of the canvas based on the understanding gained from [6], [5]. The TC canvas for Ringback solution is shown in Figure 4.4. Similar canvas can be created for Ericsson based on the TC canvas. Since our focus was on incorporating etom into ESM, we wanted to check if etom could be incorporated into the business model. We identified two blocks in which etom could

61 50 CHAPTER 4. MODELING IN ESM Figure 4.4: Target Customer(TC) Canvas be used namely: the key partners and the key activities. In key partners block, the partners listed can be tagged with the roles defined in etom (different roles in etom are explained in chapter 3 section 3.3). It is important to specify the role because same partners may play different roles in different business models. As already discussed, Ericsson can play the role of supplier, system integrator or hosting provider in the case of Ringback solution. All of these roles are covered under supplier role of etom. In the customer canvas it can be seen that Ericsson is a key partner but it does not tell anything about the role played by Ericsson. In order to clearly specify that the role played is Supplier, Ericsson in the key partner section of TC canvas (Figure 4.4) is tagged with the etom role Supplier. This is as shown in Figure 4.5(a). In the key activities block, a section of the activities can list any or all of the functional process groupings (the horizontal grouping) of the etom level 1 process. We chose functional grouping over the vertical end-end process grouping because it is most often the case that among the three vertical grouping some of the fulfillment and assurance related processes are always supported by any product. However, this need not be the case for functional groupings. For example in the Ringback solution if there was no support for managing the suppliers of our customers in that case we need not consider the processes related to supplier/partner relationship management grouping. The modified key activities block of the business model in Figure 4.4 is as shown in Figure 4.5(b). Since the customers have to support all the four functional groupings for Ringback solution all of them are specified. Similarly, in the key activities block of the Ericsson canvas there can be a section based on the etom processes specified in the Customer canvas. For example, if in the TC canvas

62 4.2. MAP MODELS FOR USING ETOM IN ESM 51 Figure 4.5: Blocks of Target Customer (TC) canvas with etom terminology all four functional groupings are specified then in Ericsson canvas we can check if we need to provide some kind of support for all the four or only some of them. Ringback solution supports some parts of all the four functional groupings and therefore will have all the four in key activities of Ericsson canvas. The canvas may undergo multiple iterations as more knowledge is gained on the product customer. Initially, it is good to start with level 1 etom processes and as we refine the canvas in subsequent iterations the details of the etom related processes can be specified in more detail, say, at level Map Models for Using etom in ESM In the previous section, explanation on how etom could be used in modeling of a product with respect to Ringback solution was provided. In this section we define generic models for using etom in ESM. We call them map models as they capture the mapping between the etom and product processes. The map models that we propose are based on different ways in which a product can support the etom business processes. As discussed in chapter 3, there are three ways which were identified. It could provide functionality completely/partially, supply data, or make use of the data provided by the process. Based on these cases we defined three different map models. The map models are as shown in Figure 4.6 a, b and c. These models are created using the ArchiMate notations. Figure 4.6 (a) Completely/partially provide functionality represents the case where the etom business process is either completely or partially supported by the product. In this case, the comments field can be used to specify if we partially provide or completely provide the functionality along with the actual functionalities that are provided. Moreover, the comments field of the etom business process can have the corresponding etom process description. To represent the link between etom process and product specific process we needed a relationship that

63 52 CHAPTER 4. MODELING IN ESM Figure 4.6: Map models for using etom in ESM linked two business processes. Since we are using ArchiMate language we considered using ArchiMate relationships for this. There we two relationships that could be used they were Flow and Triggering. Neither of two could be used to model the Provide functionality link between the two business processes. Therefore, we used the Association relationship which is used to model relationships between objects that cannot be covered by more specific relationship (Appendix A). Figure 4.6 (b) Supply data is the case where the etom process is supported by supplying data to it. Here we used two types of relationships. One is the Flow relation which represents the direction of data flow between the processes. The Flow relation is used as it describes the exchange or transfer of information between processes (Appendix A). The other relation is the Access relation which specifies the actual business object involved in the data flow. This is an optional relation and need not be a represented if the business object being used is not known or does not exist. Access relation is used as it is the standard relationship between a business object and business process as defined by ArchiMate (Appendix A). Figure 4.6 (c) Make use of represents the case where product makes use of data from the etom process. This is similar to the case where etom process is supported by supply data, Figure 4.6 (b). The only difference is the direction of the data flow.also,

64 4.2. MAP MODELS FOR USING ETOM IN ESM 53 Figure 4.7: Example model for supply data it is possible that a process could be supported in combination of any of the three ways. For instance, a product can supply data and make use of an etom process. This could be modeled by combination of map models. This would mean that there is more than one type of relationship that exists between the two processes. In such cases all the relationships modeled between the two processes should be interpreted using the logical and semantics. Figure 4.7 explains an example scenario where the product related process Collect and Distribute Service Usage process supplies data to the etom process Bill Inquiry Handling and Bill Payments and Receivables Management via the business object Ringback Data. The map models actually captures the mapping results obtained as a result of mapping a product into etom. All the models created based on the map models for the mapping results obtained in chapter 3 is presented in Appendix C. Here, the etom process could be either at level 2 or level 3. Level 3 is more suitable than level 2 as level 3 provides more details and also it becomes easier to link to the product related business process. Though, etom processes are directly used in the models, these processes are just a reference to the business processes that the service providers/operators would use. In practice, the actual relation exists between the business process of the service provider/operator and the business process involved in a product offered by Ericsson. However, it is not always possible to know exact business process of all Ericsson s customers and this is one of the reasons why etom is used as reference. The actual interpretation of the map models in Figure 4.6 is given in Figure 4.8. It shows that the etom process represents the actual business process at the service provider/operator end and can be associated to business process of Ericsson product. This helps establish a relation between the service provider/operator business process and Ericsson product business process, represented by the dash-dot line, without having to know the service provider/operator business process. In the bottom up approach of modeling, explained in the previous section, Figure 4.2

65 54 CHAPTER 4. MODELING IN ESM Figure 4.8: Map Model interpretation (which just links etom business process and product related business process) could be modified to adhere to relationship specified by map models in this section. By using the etom terminology in business modeling and capability modeling and by adhering to the map models specified in this section it is possible to have a logical link between the two layers. This reasoning is explained below by considering the top down approach for modeling. The top down flow is discussed only in relation with the use of etom terminology and it is not the complete step by step top down flow. Top down approach 1. In the business modeling layer use etom level 1 functional groupings in the key activities block of the customer canvas and tag the key partners block with etom roles. 2. Specify the etom related key activities in Ericsson canvas based on the etom related key activities in the customer canvas. The etom processes used could be at level 1 or level In the capability modeling, in business layer use the etom business processes specified in the Ericsson canvas and further decompose them into more detailed etom processes (level 2/level3). 4. Identify the different ways in which the product must support the etom business processes and model them using the map models explained in this section. The above mentioned approach ensures that a loose coupling exists between the business modeling and the capability modeling with respect to etom terminology. 4.3 Conclusion The main intent of performing modeling was to identify how etom could be used in ESM. This was achieved by modeling the mapping results obtained by mapping Ringback

66 4.3. CONCLUSION 55 solution to etom. As a result of this modeling activity, we were able to identify a way to incorporate etom terminology as a part of the Osterwalder canvas in business modeling. We proposed simple models called map models for representing the mapping results as a part of capability modeling. We also suggested a way of using etom terminology as a loose coupling between the business and the capability modeling.

67 56 CHAPTER 4. MODELING IN ESM

68 Chapter 5 Conclusions The objective of this thesis work was to identify how etom can be integrated into Ericsson Seamless Modeling. The approach that we followed to realize the objective was to definine a methodology for mapping products to etom. The mapping methodology defined was applied to one of the products offered by Ericsson. By performing the mapping it was possible to map the functionalities of the product selected at different levels of etom processes. The mapping results were validated by one of the experts of product. Based on the understanding obtained from the mapping process carried out we defined a generic mapping methodology that can be used by any enterprise that wants to use etom. We proposed simple models called as map models for capturing the mapping results obtained in mapping methodology. As a result of the research work carried out, we could integrate etom into ESM by means of capturing the mapping results in ESM. We were also able to shoe possible link between the modeling layers of ESM with respect to etom. The approach explained in this report is bottom up in the sense that the work was carried out on an existing product. However, we also explained the use of map models for the case of a new product being developed. Based on the research carried out, we provide conclusion on using etom, Conclusions on mapping a product to etom, and conclusions on modeling in ESM. The conclusions related to etom and mapping are discussed in general sense and conclusions of modeling in ESM are discussed with respect to Ericsson. 1. Conclusion on using etom A supplier can be benefit by aligning the products to etom with focus on customers. A supplier can use etom as a catalogue/checklist to verify that all the necessary functionalities are included in the new products being developed and thus providing more complete products to the customers. They can also map existing products into etom to identify new or missing functionalities which can be incorporated in the future releases of the product. 57

69 58 CHAPTER 5. CONCLUSIONS A system integrator can use etom to better understand the service provider s environment and see how easily a given product can be integrated into service provider s environment. A hosting provider can use etom to understand what kind of business processes should it have in order to be able act as a hosting provider. Since etom is widely accepted business process framework in ICT industry, it helps maintain a common language in interaction with customers and partners. 2. Conclusion on mapping a product to etom Mapping helps the product suppliers in aligning the products they offer to etom with focus on customers. Aligning the products can help identify product gaps and improvement areas. This provides an opportunity to improve or extend the product offering provided to the customers. The mapping activity that we performed as a part of this thesis work for Ringback solution helped us identify some improvement areas. It allows the suppliers to think in terms of what the customers actually do and helps them provide the necessary support to the customers through their products. The mapping results will give an idea of where the product fits and the impact it has on the customer s environment. The mapping results obtained by mapping at different levels of etom can be used by different stakeholders of the product. For instance, detailed mapping results can be used by the system integrators to easily integrate the product into the customer environment. High level mapping results can be used by the market unit in interactions with customers. It also builds trust among the customers, as they become aware that the product is compliant to etom processes. Mapping multiple products into etom allows the suppliers analyze the products offered at enterprise level. This in turn helps identify potential areas that the suppliers have very less exposure in terms of service they offer to their customers. Analysis on these areas or gaps will help suppliers in deciding if they want to extend or create a new product for the given gap. 3. Conclusions on Modeling in ESM ESM provides a structured way of modeling a product by representing it at different layers of abstraction. The business models in the business layer capture the needs and the value of the product at high level for both customers and Ericsson. The capability modeling helps realize the value by modeling the needs in terms of functionalities the product offer. The actual implementation of the functionality modeled is then realized in the realization modeling.

70 5.1. LIMITATIONS OF THE WORK 59 When all the products follow the same structure and terminology as defined by ESM there is consistency in the models and related artifacts that are created. Hence, the models will be easier to understand and helps other stakeholders easily learn how a particular capability was implemented. ESM uses the concept of viewpoints which helps capture only those things that are required by a particular stakeholder. This helps in easy communication with different stakeholders of the product. When ESM is used for modeling multiple products it helps in creating a repository of components and services that could be reused in other products. This helps Ericsson in achieving one of its long term goals which is the concept of service orientation. Reuse is possible as the models created follow the concept of services and components as specified in the meta models of Archimate. It may not be always possible to implement products that are made of independent components or services. However, there can be some level of reusability. Finally, the benefits of integrating etom into ESM have the benefits of using etom as well as the benefits of mapping and modeling in ESM. Benefits of mapping, because it actually captures the mapping between etom and a product; and benefits of modeling, because the map models defined captures the mapping results in a formal way. 5.1 Limitations of the Work The limitation of the work that was carried out is as follows. The results proposed in this thesis are on the basis of work done on only one Ericsson s solution namely Ericsson Multimedia Ringback solution. Therefore, an additional evaluation on other products is needed. The thesis covers only a single iteration of business modeling and capability modeling because of the time constraints. Therefore, the models created cannot be considered as complete and multiple iterations are needed before finalizing the models. The mapping methodology proposed is related to the hierarchical decomposition of the etom processes. Therefore, if the structure of the etom changes then mapping methodology has to be adapted accordingly. Since the research focuses on using etom in ESM methodology defined by Ericsson, the conclusions of this research might be not applicable to other enterprises. However, the mapping methodology does not depend on the structure of ESM and could be used in a different enterprise.

71 60 CHAPTER 5. CONCLUSIONS 5.2 Recommendations Below we list some recommendations. Evaluate the proposed mapping methodology and the map models by applying it to various products offered by Ericsson. This could provide insights into areas that are not explored in this thesis work and thus help in refining the methodology. Gain a clear understanding of etom processes by encouraging its use in every product offered by Ericsson, as the etom processes are generic and independent of any technology or implementation. Model the business, application and infrastructure layer of the capability modeling based on the meta models defined in Archimate. Then use these models to generate different views according to the viewpoints defined by Archimate. Define clearly the artifacts and the purpose of the artifacts that are to be modeled in different layers of ESM, Also, define if the artifacts are mandatory or optional. Provide necessary guidelines and examples for efficiently modeling in ESM.

72 Appendix A Archimate This appendix provides definitions of the concepts and relationships defined in ArchiMate and notations used to represent the same. It also provides the metamodel provided by the Archimate for different layers. Figure A-1: Application layer concepts [11] 61

73 62 APPENDIX A. ARCHIMATE Figure A-2: Business layer concepts [11]

74 Figure A-3: Technology layer concepts [11] 63

75 64 APPENDIX A. ARCHIMATE Figure A-4: Relationships [11]

76 Figure A-5: Notations for concepts and relationships [17] 65

77 66 APPENDIX A. ARCHIMATE Figure A-6: ArchiMate Metamodel [14]

78 Appendix B Mapping Results 67

79 68 APPENDIX B. MAPPING RESULTS Figure B-1: Mapping results at level 2

80 Figure B-2: Mapping results at level 3 CRM 69

81 70 APPENDIX B. MAPPING RESULTS Figure B-3: Mapping results at level 3 RM&O Figure B-4: Mapping results at level 3 S/PRM

82 Appendix C Models Created Using Archimate Language 71

83 72 APPENDIX C. MODELS CREATED USING ARCHIMATE LANGUAGE Figure C-1: Ringback Solution modeled for Bill Inquiry Handling

84 Figure C-2: Ringback Solution modeled for Bill Payments and Receivables Management 73

85 74 APPENDIX C. MODELS CREATED USING ARCHIMATE LANGUAGE Figure C-3: Ringback Solution modeled for Rating and Discounting

86 Figure C-4: Ringback Solution modeled for S/PRM Management 75

87 76 APPENDIX C. MODELS CREATED USING ARCHIMATE LANGUAGE Figure C-5: Ringback Solution modeled for Bill Payments and Receivables Management

88 Figure C-6: Map models-level 3 CRM processes 77

89 78 APPENDIX C. MODELS CREATED USING ARCHIMATE LANGUAGE Figure C-7: Map models-level 3 RM&O processes

90 Figure C-8: Map models-level 3 S/PRM processes 79