> Archive > Issue XXIII: October/November 2008 > Defining Business Services in the Telecommunications Industry
Stuart Kerrigan

Stuart Kerrigan


Stuart Kerrigan is a Principal Engineer at Ericsson Ireland were his main focus areas include Enterprise Architecture, Enterprise Service-oriented Architecture, SOA Governance, Software Product Lines and Business Transformation.

Stuart has over 13 years industry experience in enterprise application development and software architecture predominantly in the telecommunications industry in the area of service and network management for tier 1 service providers.

Stuart has held several positions within Ericsson (previously Marconi Communications PLC) Data-Networks Division Network Management including Head of Strategy and Solutions, CTO and chief architect.

He holds an MBA from University College Dublin and a Bachelor of Science from Dublin City University.


rss  subscribe to this author

Richard van Schelven

Richard van Schelven


Richard van Schelven is a Senior Consultant at DNV-CIBIT in the Netherlands. His main focus area is enterprise service-oriented architecture and governance.

Richard has over 20 years experience in software architecture, enterprise application development in computer networking and telecommunications, specifically in the area of service and network management for tier 1 service providers.

In his previous position as principal engineer within Ericsson (Marconi Communications PLC) Data-Networks Division Network Management, he acted as a Service-Oriented consultant, advising and evangelizing on all aspects of service-orientation for the development of Operation Support Systems.


rss  subscribe to this author


Defining Business Services in the Telecommunications Industry

Published: November 17, 2008 • SOA Magazine Issue XXIII

Abstract: For many companies in the telecommunications sector, SOA adoption is essential to their growth and survival. This article explores the integration of concepts associated with SOA and service-orientation into a typical telecom enterprise by explaining how key SOA characteristics and principles tie into the typical telecom organizational structure, leading to an opportunity to define business services and establish a Service Solution Set Inventory (SSSI) as the foundation from which services can be repeatedly composed into aggregate applications. Along the way, we will explain some basic terminology related to distinguishing core from context processes and differentiating between the various types of clients and consumers that acquire service-oriented systems (which we'll refer to as "products").

Introduction: Understanding Core and Context

Business transformation is about aligning people, process and technology initiatives with the businesses strategy. Telecom business models are changing to meet enhanced customer expectations and to face increased competition. As a result, telecom businesses must find ways to differentiate themselves.

This brings us to the concept of what is "core" and what is "context" to a business. In essence, any corporate activity that increases shareholder value is core. Anything that does not is context. As Geoffrey Moore puts it: "A business process is core when its outcome directly affects the competitive advantage of the company in its targeted markets. Here is the ground upon which companies must differentiate to win power, and the goal of core work is to create and sustain that differentiation." [REF-1]

But what has this to do with IT? Firstly, the organization must be in a position that it can reason with the core and context business processes [REF-2]. For example, resources may need to be diverted away from context activities and towards core activities, which may even introduce the need to outsource those context activities.

If we assume that the organization is structured in the appropriate manner, we must then concern ourselves with aligning IT with the business. The issue facing IT is that core and context processes are buried in monolithic applications and it becomes extremely difficult to abstract, expose and/or retire context data and functionality. Furthermore, there is no way to reuse context processes, turning them into core.

For a telecom business to realize true business transformation and compete effectively, it must be structured in such a way to achieve a separate of core and context. To accomplish this, many telecom organizations are adopting a service-centric approach to structuring their organizations, which is realized through SOA.

The remainder of this article will explore how the successful adoption of SOA leads to the service-oriented organization, here forth referred to as the service-oriented enterprise (SOE). Using the telecom industry as an on-going example, we will discuss concepts associated with services and explain the difference in how services help realize the overall business value of an enterprise. We will then go on to link services to the attainment of the SOE via SOA. It is the resulting business transformation that creates opportunities for commercial product vendors to lead the market both in terms of innovation and operational excellence.

Basic Concepts: Enterprise Products, Customers and Users

The objective of any commercial business is to provide value to its customers and users, thus ensuring sustaining business models that maximize the economic value of the organization. This is provided for by the product or service that the business offers. We can refer to these products or services as the enterprise products. From the perspective of the telecom operator, enterprise products would include: IPTV, Multimedia Messaging Service (MMS), Short Message Service (SMS), Push to Talk (PTT), and so on.

Before we continue, we should differentiate between end-customers and end-users of the enterprise products and internal customers and internal users. Firstly, let's draw a distinction between a customer and a user. A customer acquires a product and a user consumes it. Thus, an internal customer and user acquire and use products produced for use within the organization, whereas end-customers and end-users represent the product's ultimate destination.

Figure 1 explores the relationship between the enterprise products, end-customer/user and customer/user further. To help understand this, it is worth introducing some terminology from the Information Technology Infrastructure Library (ITIL), which introduces the concept of a Type I, Type II and Type III service provider:

  • Type I: exists within an organization solely to deliver service to one specific business unit
  • Type II: services multiple business units in the same organization
  • Type III: operates as an external service provider serving multiple external customers

(In this context, the service provider is a producer of any IT service.)

Type I and II service providers offer products and services that are internal to the organization, which corresponds to internal customers and users. Their job is to support the end-customers and end-users and their IT enterprise is responsible for helping them provide this support.

Figure 1

With a Type III service provider, an IT product offering is considered an enterprise product, for example IPTV. In this scenario, IPTV is delivered as a product to the enterprises internal customer, which is then subsequently delivered to the external end-customer and end-user. Of course, for the telecom operators, this will be a combination of IT/BSS/OSS (Business Support Systems, Operational Support Systems).

Figure 1 illustrated a simplified view of a telecom operator's enterprise partitioned into three major support areas: the IT organization, the BSS organization, and the OSS organization. Each is responsible for providing services vis-à-vis the business processes and capabilities of the organization along with the supporting IT/BSS/OSS products necessary to manage and deliver the overall enterprise product.

Understanding Business Services

Now that we've covered some basic concepts and terminology associated with enterprise products, we need to ask the question: How do we manage and deliver these products and what organizational structure best suits such a business environment?

This leads us to the concept of the service-oriented enterprise. Service-orientation presents an ideal vision of a world in which resources are cleanly partitioned and consistently represented as services, the more apt term being business services. A business service can be defined as a coherent piece of functionality that offers added value to an IT enterprise, independent of the way this functionality is realised internally [REF-3].

It is this business service that is the key to realizing the service-oriented enterprise because it provides the opportunity to structure the enterprise to be more flexible, adaptable, and agile. The concept of the business service is not new, as many organizations have been applying service-orientation in some form or another, either as consumers or providers of business services; however, it has so far been mostly ad hoc.

With SOA, business services become an element of the organization that can be assessed with respect to actual strategic value. For example, business services can be outsourced, in-sourced or brought together into shared services centres. When properly built, business services can be used as a basis for the:

  • measurement of costs of products or services
  • identification of areas of potential cost savings
  • study and improvement of business process performance
  • business and process innovation

Examples of business services include Authorize Credit, Implement, Configure & Activate Service or Configure & Activate Resource. Such services provide value to a telecom operator's BSS/OSS business area by supporting the management of the telecom services themselves.

Figure 2

Business services can be realized by studying business behaviour, which in turn is comprised of three generalized concepts (Figure 2) [REF-5]:

  • Business process - A flow of business activities with one or more clear starting points and leading to a clearly defined result. Business processes are concerned with business activities and their ordering in time so as to achieve a specific result. For example, Selling, Order Handling, Service Configuration & Activation, Resource Provisioning, etc..
  • Business function – This represents functionality which may be useful for one or more business processes. A business function essentially groups behaviour. For example, skills, capabilities, resources, applications, and so forth. Business functions are about the what, whereas business processes are about the why.
  • Business activity or task - This is the smallest level of decomposition of business behaviour. A business activity has the right level of granularity to determine the assignment to specific business roles.

Business services should work as independently from each other as possible, with well defined contracts and mirroring how the business really works. It must be noted that there are no predefined rules as to the exact level granularity of a business service. Indeed, at the extreme case, you could look at the entire enterprise as delivering a single business service. However, you will need to decompose this further to ensure that it delivers some level of value. How you carry out this decomposition will need to be defined and governed by your organization in order to ensure some level of uniformity and consistency.

Once business services are defined, they can be sequenced in order to fulfil the highest level business processes - those processes that ultimately realise the business objective.

Figure 3

Figure 3 illustrates how business services exist at level 3 of eTOM processes. These business services could further be decomposed until the appropriate level granularity is reached. Consider a lead-to-cash business process, which will need to execute various business services, such as Customer Relationship Management, Selling, Order Management, etc. These same business services can also be reused by other processes like pre-sales, problem management, quality management, and planning.

SOA Fundamentals

Organizing the enterprise around business services is the key to enabling business agility. The constant challenge is to translate these business services into reusable software services, which allows us to establish an environment whereby the business is aligned with IT and whereby we can maintain that alignment by constantly recomposing business services as the business changes over time.

SOA is quickly becoming the de-facto-standard for the attainment of this alignment [REF-4]. That brings us to the inevitable question: What is an SOA? It is an architectural style, and hence technology agnostic, based on a number of architectural principles [REF-5]:

  • Reusability - Reuse business logic represents automatable and repeatable business activities. This implies that reusable services need to be functionally agnostic and positioned at enterprise level. Reuse is realized through analysis and design processes that produce the services.
  • Standardized Contracts - Services express their purpose and capabilities through standardized contracts, including functional and non-functional aspects. These contracts are vital for people to interpret and build predictable solutions out of the services. NGOSS contracts are a good starting point.
  • Loose Coupling - The service consumer, service contracts and service implementation must be – to whatever extent possible - decoupled from each other. The looser the coupling between entities, the more we can have the opportunity for the independent design and evolution of the underlying service logic and implementation. Service Abstraction is a design principle that needs to be used to achieve decoupling.
  • Autonomy - Services must be able to execute their work with autonomy so as to guarantee consistent behavioural predictability to their consumers. This means that services require a high level of control over their execution environments.
  • Discoverability - In order to promote reuse within an organization everybody must be able to identify and understand the services.

Reusability is a key design principle which must be factored in from the start. The other principles are needed to support reusability. Furthermore, there are some key concepts to an SOA (Figure 4) that must also be understood.

The first one is the service inventory, which is a collection of independently standardized and governed services. The second is the service composition, which is an aggregate of services. The idea is to take services from the inventory and compose them into composite applications. The third one is service-oriented solution logic (or service-oriented infrastructure) to deliver on the design principles and key elements.

Figure 4

SOA in a Telecom Enterprise

Back to the telecom story. We established that the telecom operator can organizes its business around services. A vendor needs to provide products/solutions for the telecom operator to support those services. The vision is to create an inventory of reusable software services, which covers the BSS/OSS domain based on an SOA. These services are based on the service-orientation principles, which means that many of them will be effectively reusable. From these reusable services we can compose service solution sets that cover solutions from a complete business process to part of the process to business activities. These service solution sets could be bundled into products or could be composite applications (customized solutions). They are kept in an inventory (the Service Solution Sets Inventory or SSSI), where they can be discovered and where they are independently governed so that the architectural principles and concepts are constantly protected and adhered to (Figure 5).

Figure 5

Figure 5 shows all the characteristics of a Software Product Lines approach, which addresses [REF-6]:

  • The development of a reusable base of core assets.
  • The development of products that utilize those core assets.
  • The management to orchestrate the entire affair.

A software product line shares a similar definition to the traditional product line, in that it is a set of (software) systems that share a common managed set of features satisfying the specific needs of a particular market segment or mission. However, it extends this definition because they are developed from a common set of core assets in a prescribed way. In a software product line approach, the reuse is planned, enabled, and enforced.

A software product line approach, as put forward by the Software Engineering Institute (SEI) [REF-5], presents a number of patterns which can be used to address the complexity of and enterprise-level SOA.

Exploratory L3 VPN Telecom Service Example

To make this more concrete, let's explore in more detail a particular scenario of a telecom operator delivering an enterprise product. We'll take a look at the structure of that operator and its overall service offering can be decomposed into actual software services. As shown in Figure 6, this example is based on an enterprise product called Layer 3 VPN, which is ordered by a bank.

Figure 6

As a starting point, let's begin with a look at the operator's business architecture. We will be specifically looking to identify business services, based on business functions, business activities and business processes. To keep the example somewhat manageable, we will focus on the Operations business function.

As has already been stated, a business function can consist of multiple business services. In Figure 3 we identified multiple business services within the operator's organization. We can clearly place several of these within the Operations business function. For the purpose of this article, we will only explore one specific business service called Configure & Activate Resource, as highlighted in Figure 7. (With regards to this figure, it should be noted that it has already been decomposed to level 3 as per the TM Forum Business Process Framework, eTOM).

Figure 7

The Configure & Activate Resource service is still quite coarsely grained, so we can break it down further into multiple level 4 business services (which can subsequently be broken down into multiple level 5 and level 6 business services). In essence, the process of decomposition continues until an appropriate level of granularity is reached or you have come to the smallest level of decomposition possible, which is the business activity. In fact, Figure 8 illustrates the decomposition to the business activity level.

Figure 8

Traditionally, the business process logic required to configure and activate the resources would have been buried within monolithic applications, thus making consolidation, retirement or re-orchestration (making a new core processes) of the software resources extremely difficult.

As business services, however, this now becomes possible. These services can go into the SSSI (Figure 9), ready to make up new solutions or composite applications. It is this whole approach that is fundamentally different to how applications are designed and built before. As shown in Figure 10, it is from the SSSI service inventory that we can now put together various composite applications.

Figure 9

Figure 10


Telecom operators are transforming their businesses to adaptive enterprises. IT/OSS/BSS organizations need to respond quickly to meet business demands, support new strategies and improve the overall end-user experience. A telecom vendor must be able to respond to the changes of the operator's business by delivering products as telecom services. A comprehensive understanding of enterprise products and how end-customers acquire and end-users consume the business services that comprise these products is required.

This approach can form the basis for defining vendor products that help align the business of the operators with IT and provides the opportunity to introduce enterprise wide SOA via ubiquitous productized services in the OSS domain. The basis for these products is Service Solution Sets which are kept in the SSSI service inventory and are independently governed to promote vendor enterprise-wide reuse, both from solution and product development perspectives.

Realizing this is a considerable challenge because it can affect all aspects of the vendor organization, from product areas, to development, people and process. If a vendor is to embrace the service-oriented paradigm, then it must set itself up as a software product line organization. In the end, it will provide great opportunity to reap the benefits of a true software product line and deliver on the vendor's commercial and operational objectives.


[REF-1] Living On The Fault Line. G.A. Moore. HarperBusiness. 2002.

[REF-2] Enterprise SOA. D. Woods, T. Mattern. O'Reilly. 2006.

[REF-3] Enterprise Architecture at Work. M. Lankhorst et al. Springer 2005.

[REF-4] SOA for Profit. M. van den Berg et all. IBM SOGETI. 2007.

[REF-5] SOA Principles of Service-Orientation, T. Erl. Prentice Hall. 2007.

[REF-6] Software Product Lines, P. Clements, L. Northrop. Addison-Wesley 2002