Download - Tata Consultancy Services

Clarity - TCS Whitepaper 

Key Integration Issues in Building 

a Strategic OSS Platform 

This white paper addresses the key OSS 

integration issues faced by operators 

today and provides suggestions for 

transformation and improvement

2 | Key Integration Issues in Building a Strategic OSS Platform 

About The Authors 

Nadeem Khan has over 11 years of working experience with Tata 

Consultancy Services. He has been involved in working with service 

providers like BT and BSNL in various capacities. For the past two years 

Nadeem has been working in Tata Consultancy Services Telecom Vertical 

and is responsible for pre-sales activities in the OSS/BSS domain. 

Nadeem Khan is an OSS Consultant for Tata Consultancy 

Services 

Mel Cantarella has over 25 years experience in the Telecommunications 

Industry, and in that time has held a variety of senior roles within service 

providers in both network engineering and network operations. He has 

helped system integrators and ISVs implement BSS and OSS Solutions 

around the world. Mel joined Clarity in 2000 as a Project Director and 

became Global Alliance Director in 2006. In his 7 years with Clarity he 

has been responsible for delivering a number of large Tier 1 Clarity 

implementations to key Clarity customers. Prior to joining Clarity Mel 

spent several years with Optus in Sydney, Time Telekom in KL and IBM 

Global Services in Australia. 

Mel Cantarella is the Global Alliance Director for Clarity International 

Copyright Information 

Copyright © 2007. Clarity International Limited. All rights reserved. Clarity International and 

the Clarity logo are registered trademarks of Clarity International Limited, in Australia and 

other countries. All other trademarks or registered service marks in this document are the 

property of Clarity International or their respective owners. All specifications are subject to 

change without notice. Clarity International assumes no responsibility for any inaccuracies in this 

document or for any obligation to update information in this document. Clarity International 

reserves the right to change, modify, transfer, or otherwise revise this publication without 

notice.

Table of Contents 


1 INTRODUCTION.....................................................................................4 

2 ABSTRACT................................................................................................4 

3 THE CHALLENGE OF BUILDING AN OSS.........................................4 

4 KEY INTEGRATION ISSUES..................................................................6 

4.1 Integration Challenges............................................................................................ 6 

4.2 Key Integration Points............................................................................................ 7 

5 SOLUTIONS FOR THE INTEGRATION PROBLEM.........................11 

5.1 The Point-to-Point Integration Solution ..........................................................12 

5.2 Enterprise Application Integration (EAI) or Middleware Solution.............13 

5.3 The Unified OSS Solution....................................................................................15 

6 FUTURE DIRECTION............................................................................18 

7 CONCLUSION........................................................................................19


1 Introduction 

In recent years, OSS has become an area of considerable focus as well as concern for service 

providers. Making the right decision with their OSS architecture will lead to considerable 

business benefit in the form of substantially reduced operational costs, increased revenues and 

increased customer satisfaction. Making the wrong decision however will lead to the risk of 

expending significant capital towards the implementation of a solution that appears on the 

surface to meet the business needs, but ends up falling short in operation, resulting in 

stakeholders often at a loss to pinpoint what went wrong. The major concern areas revolve 

around: 

• Complexity – networks are becoming increasingly complex with the delivery 

of today’s telecom products and services requiring multiple technologies and 

platforms 

• Growth – increased demand for new innovative services with faster delivery 

times and higher levels of service quality 

• Skills – shortage of specialised skills for complex network management 

• Data and information management – service providers that can not manage 

their network, service and customer data are unable to respond quickly to 

customer requests 

These concerns are further impacted by the need to integrate multiple OSS components and 

functions as service providers struggle to manage convergence as well as the ever growing 

requirements from customers for new services and higher quality of service. 

2 Abstract 

In recent years, OSS has become an area of considerable focus as well as concern for service 

providers. OSS Integration has always been a major challenge and often a serious impediment 

towards delivering true business value with new system implementation and augmentation 

projects, as end-to-end business processes are rarely supported by a single application. 

This paper addresses the key OSS integration issues faced by operators today. It looks at the 

point-to-point integration solution, the EAI solution and the Unified OSS solution and provides 

suggestions for transformation and improvement. 

3 The Challenge of Building an OSS 

The telecom industry worldwide is going through a revolutionary change. This revolution is not 

only in terms of increased growth of product and service types, increased revenue, ARPU, 

AMPU and churn but also in terms of customer expectations and the need for quality of service.


Customers expect services that are available 100% of the time. Convergence of voice, data and 

video has been the catalyst to the demand for services anytime, anywhere and through any 

device. 

In the race to deliver new products and services to market quickly, service providers have found 

it difficult and time consuming to utilise existing or legacy solution suites. Instead they have 

implemented complete OSS/BSS stovepipe suites to support the new products. Doing so may 

have allowed them to achieve their launch dates and initial revenue targets by being “first to 

market” thus capturing a larger share of the market initially. However as these stovepipe suites 

act independently, the service provider will find it difficult to provide their customers with 

seamless convergent services, as manual steps are required to link the required business 

processes across these technology vertical suites. 

As a result, service fulfillment times increase, service assurance is also impacted and slowly the 

service provider will lose market share to competitor’s that have a more integrated OSS/BSS 

solution stack, that provides a single view of the customer, service and network. 

These well integrated service providers give their 

customers the warm feeling that they are truly dealing 

with one single coordinated service provider, while 

the “stovepipe operators” make the customer feel 

that they themselves need to be the project coordinator 

managing multiple disparate providers to 

achieve the same end result. 

The telecommunication landscape is continuously 

changing with increasingly complex networks 

“Only by providing one point of 

contact to order, ask questions, 

dispute bills and request repairs will 

providers win the continued loyalty 

of customers and this will require 

greater back-office integration.” 

Susan Richardson, Gartner 

Research, May 2005 

comprising both legacy and next generation technologies, provided by a myriad of network 

equipment vendors and interworking to provide these ever converging services. 

Business processes are also increasing in complexity with the need for constant change as the 

landscape, competition and service offerings change, and as service providers strive to achieve 

and improve upon best practices to remain competitive and stay ahead of the game. 

The service provider that can manage the constant change quickly, efficiently and as part of their 

normal business process will survive and prosper. Service providers with well integrated 

BSS/OSS solution suites across both service fulfillment and assurance, as well as across network 

technologies and service offerings, will be able to better respond to the changes and continue to 

provide seamless service to their existing and new customers. 

Effective BSS/OSS integration holds the key for achieving operator’s business objectives i.e. 

increased customer satisfaction which in turn increases market share, increases customer 

retention, increases revenue and lowers operational costs. 

This white paper identifies the key integration challenges that exist for service providers today 

and provides suggestions for transformation and improvements across the standard integration 

touch points in the OSS environment.


4 Key Integration Issues 

Integration challenges are perceived differently by different people. These challenges are closely 

linked even though they are represented differently. In a telco environment there are three 

major stake holders, the customer, the business unit and the IT department. Each of them is 

impacted in a different way due to the challenges faced in integration. 

4.1 Integration Challenges 

Service providers are faced with the following challenges from customer demands: 

• Demands for ever improving service levels for both service connections and 

service quality 

• Decreased cost structure to remain competitive i.e. moving from manual 

activities to task automation 

• Content and service anytime, anywhere and through any device 

The root of these challenges lies in the integration of the OSS system. OSS integration 

challenges faced by service providers today include: 

• Integrating customer service level to network service level – this enables 

customer notification of service and performance degradation in the event of 

network failure. The complexity increases with multi-vendor networks and the 

growth of convergent services 

• Translating network faults to service impacts and to customers impacted – this 

integration is key from a business perspective as the faults which occur in the 

network need to be translated into the service impact and then based on the 

service impact, translated into which customers will be impacted. Notifications 

can be given to the customer in advance before the customer notices the 

impact of the fault. Also with the addition of integrated SLA management, fault 

restoration activities can be managed so that faults impacting high value 

customers are prioritised, protecting service provider revenues. This 

integration is a crucial ingredient to ensuring pro-active customer management 

• Translating service faults to customers and to services impacted – this 

integration helps the service provider’s business team to analyse the impact of 

faults on service. If the fault affects the basic service which has a considerable 

customer base, business can take a call on increasing the fault priority and 

business rules can be easily configured to automate this prioritisation 

• Single fault visibility – integrating faults captured by the OSS from disparate 

network devices and presenting it to the help desk system so that the agents 

can provide a 360 degree view of the customer from an assurance perspective


• Integration of network element with the OSS – the service provider’s network 

is comprised of the various network elements from different vendors which 

speak and support different protocols. From NMS FCAPS functionality 

perspective there needs to be an integration adapter layer built to co-relate 

fault and performance data and ideally capture this data in the one system. The 

challenge is in building this adapter layer to suite the various protocols and 

transform the data into a common language from a fault and performance 

perspective. The complexity of doing this without tight integration is increased 

considerably with the increase of data services 

• Multi-vendor OSS components – traditionally a service providers OSS is built 

with multi-vendor OSS components. For example the service provider would 

have a separate fault management system, a separate performance 

management system etc. These have their own databases, own supporting 

protocols and in some cases the systems are designed specifically for either 

legacy or next generation technologies, requiring multiple systems in one 

functional domain. The complexity arises in integrating these separate systems 

to form a consolidated OSS perspective 

4.2 Key Integration Points 

To enable a service provider to generate new services and revenues, drive up customer 

satisfaction and drive down costs, tight integration within the components of an OSS, between 

OSS and BSS, OSS and ERP and OSS and the network is crucial. Figure 1 represents the 

TeleManagement Forum enhanced Telecom Operations Map (TMF eTOM). 

The operations process area is the heart of eTOM. It includes all operations processes that 

support the customer operations and management as well as those that enable direct customer 

operations with the customer. This includes sales management and supplier/partner relationship 

management. 

The strategy, infrastructure and product process area includes processes that develop strategy, 

commitment to the service provider, build infrastructure, develop and manage products, and 

develop and manage the supply chain. In eTOM, infrastructure refers to more than just IT and 

resource infrastructure that supports products and services. It includes the infrastructure 

required to support functional processes such as CRM. These processes direct and enable 

operations. 

The enterprise management process area includes basic business processes required to run any 

business. These processes focus on enterprise level processes, goals and objectives. These 

processes have interfaces with almost every other process in the enterprise whether 

operational, product or infrastructure processes. These processes include for example financial 

management and human resources management. 

The market, product and customer processes include those dealing with sales and channel 

management, marketing management and product and offer management as well as customer 

relationship management and ordering, problem handling, SLA management and billing.


Service processes include those dealing with service development and configuration, service 

problem management and quality analysis, and rating. 

Resource processes include those dealing with development and management of the service 

provider’s infrastructure, whether related to products and services or to supporting the 

enterprise itself. 

The supplier/partner processes include those dealing with the service provider’s interaction with 

its suppliers and partners. This involves both processes that manage the supply chain that 

underpins product and infrastructure, as well as those that support the operations interface 

with its suppliers and partners. 

Figure 1 - TeleManagement Forum enhanced Telecom Operations Map 

Upon studying the TMF eTOM one begins to appreciate that in order to support the end-toend 

business processes that are crucial to the business bottom line, tight integration within an 

OSS as well as between OSS, BSS, ERP and the network is a must. Best practice business 

process does not exist in functional components that are provided in commercial off-the-shelf 

software packages. It exists by managing all business lifecycles in a seamless end-to-end fashion 

and by being able to monitor, control and constantly improve the processes. Only with tight 

integration across all functions can this be achieved. 

The amount of integration required to achieve this seamless end-to-end business process 

support is mammoth in proportion and an exercise that should be treated with the most 

respect. Any pre-integration of components should be carefully considered to reduce the 

enormity of the task where possible. The following list is by no means extensive, but gives an


indication of some of the key integrations which are required as a starting point to achieve this 

seamless end-to-end business process support. 

External to OSS 

• Providing serviceability information to an order entry application (usually a 

CRM Module) during processing of customer service request 

• Receiving service requests from an order entry application once the service 

order is confirmed 

• Providing updates to the order entry application from the OSS advising status 

of service provisioning 

• Providing updates to the order entry application upon activation of the service 

or feature to enable notification to commence billing 

• Providing service and network status information to a customer problem 

management application 

• Providing SLA information about the network and the services to a customer 

SLA application 

• Providing customer service fault statistics to a customer web portal 

• Providing customer service performance statistics to a customer web portal 

• Receiving network asset details from a materials management or asset 

management application (usually an ERP Module) when network assets move 

into the network from storage or from vendors 

• Providing network asset details to a materials management or asset 

management application when network assets move from the network to 

storage or to vendors for repair 

• Providing work order and work task details to a field force management or 

contract work force management system as part of a either a service 

fulfillment or service assurance process 

• Receiving work order and work task updates from a field force management 

or contract work force management system as part of a service fulfillment or 

service assurance process 

Internal to OSS and Network 

• A service provisioning application receiving network resource information 

from an inventory management application to be able to effectively complete 

the provisioning process 

• A service provisioning application updating an inventory management 

application after completing a provisioning process


• A service provisioning application sending network and service configuration/ 

provisioning commands to a network mediation layer for transmission to the 

specified network management layers or direct to the network elements 

• A service provisioning application receiving SLA contract data from an SLA 

application to obtain prioritisation and escalation of customer connections 

• An SLA management application providing SLA contract data to a service 

provisioning application to allow prioritisation and escalation of customer 

connections 

• A network mediation layer sending service configuration/provisioning 

commands to the specified network management layers or direct to the 

network elements 

• A fault management application receiving network events from a network 

mediation layer 

• A network mediation receiving network events from the specified network 

management layers or directly from the network elements 

• A fault management application providing alarm data to a trouble ticket 

application to allow automated creation of trouble tickets 

• A fault management application providing alarm data to an SLA application to 

allow prioritisation and escalation of network faults 

• An SLA management application providing SLA contract data to a trouble 

ticket application to allow prioritisation and escalation of network faults 

• A performance management application receiving performance data from a 

network mediation/adaptor layer 

• A network mediation receiving performance data from the specified network 

management layers or directly from the network elements 

• A performance management application providing performance trends data to 

an SLA application to allow prioritisation and escalation of service degradation 

• Integration of alarms across multiple vendor equipment within one network 

technology to obtain a single view of that network technology platform 

• Integration of alarms across multiple vendor equipment and across multiple 

network technologies to obtain a single view of the network across vendors 

and technologies 

• Integration of performance data across multiple vendor equipment within one 

network technology to obtain a single view of performance for that network 

technology platform


• Integration of performance data across multiple vendor equipment across 

multiple network technologies to obtain a single view of the network across 

vendors and technologies 

These are just a sample of some key integration points required to support some of the most 

basic functions in the business. To achieve true business transformation through integration, 

many more integration points are required and one must go down many levels of lower detail 

to realise the true scope and magnitude of the required integration. 

The end result that service providers constantly strive towards is the ability to be in any screen, 

performing any function and be able to provide to the user at the touch of a button all the 

stored and available data about a customer, a service or a network device that the service 

provider has collected over each of these entity’s lifetime in that service provider. This data is 

normally stored in a number of automated and manual systems and even paper records, and the 

ability to access this wealth of data is often a pipe dream. Effective integration of all these 

databases can make the light at the end of the pipe and the dream, seem a great deal closer. 

5 Solutions for the Integration Problem 

In 2004, Dittberner estimated telecoms around the world spent $38.6 billion on OSS/BSS 

application software and its integration, and for every $3 dollars spent on network management, 

service management and customer management software another $1 is spent by telecoms on 

integration. Key problems faced by service providers in achieving an integrated OSS include: 

• Multi-vendor OSS deployment of 

individual solutions for fulfillment 

and assurance has led to increased 

complication in integration. These 

OSS components, centered on 

technologies, functions or network 

vendors, cannot deliver 

sophisticated bundled products 

across different technologies or 

vendors 

• Data manipulation from various 

sources – in a multi-vendor 

environment, each application has it 

owns OSS database. From a QoS 

perspective data manipulation from 

each application’s database has to be 

done. This leads to issues of data 

integrity and latency and the 

fragmented repositories of OSS 

information cause business 

processes to become disconnected 

“In case of those vendors that have got 

about doing inorganic technology 

additions through M&A - You might hear 

from a salesperson who has a slick 

brochure that shows everything as a 

wonderfully integrated suite, but when 

the truck rolls up for the installation it’s 

actually a very disparate set of 

standalone pieces that might not be able 

to share data, might run on different 

hardware and databases, and might not 

be able to fit together at all. So you’ve 

just moved the problem from several 

contracts with smaller vendors to one 

contract, but you’ve still got these 

disparate systems and you don’t have 

any kind of integrated suite whatsoever.” 

Keith Willetts, Chairman, 

TeleManagement Forum 2006


The need to integrate creates an initial problem during system deployment but of even bigger 

concern is the on-going problem in operations and maintenance. The OSS must be able to 

evolve as demands are placed on it. Complex architectures and commercial arrangements 

surrounding the OSS often limit its agility to respond to new demands. Key issues include: 

• An OSS made up from many “best-of-breed” or “stove-pipe” components are 

even harder to maintain then they are to deliver 

• Training and support contracts may be difficult to line up in such a way that 

gaps in coverage are avoided 

• The resulting system may be expensive and time-consuming to adapt to new 

market pressures 

5.1 The Point-to-Point Integration Solution 

In the past in an effort to provide a minimum level of integration, system integrators and service 

providers used “point-to-point” integration. Point-to-point integration entails communication 

between pairs of systems that need to share data. This method as a solution and architecture 

appear to have some merit when deploying only two applications to provide a business process, 

or even multiple applications where each system only needs to communicate with one other 

system. It also makes some sense if a deployment is not expected to experience any significant 

change for many years. 

However in today’s complex and volatile telecommunications industry it is rare for only two of 

the many applications required to share the same data and also be the only two involved in a 

specific business process. It is even rarer that there will be no change requiring new and more 

complex interfaces between numerous systems, because in today’s telecom environment change 

is one of the few “constants”. The point-to-point solution therefore becomes costly and 

unwieldy with duplications and overlapping integrations between numerous applications, which 

builds over time into a tangled architectural “spaghetti”. 

This creates problems 

during implementation, 

but becomes a real 

nightmare during ongoing 

operations as 

continual changes are 

required. With every 

new function, process or 

application, the time to 

implement and the risk 

of failure increases due 

to the ever increasing 

complex integration 

architecture. 

Figure 2 - Complex Point-to-Point Integration


The ability to provide the required level of end-to-end business process support slowly grinds 

to a halt, and the end-to-end system performance also suffers. This solution may be sufficient for 

some industries, but it can not stand up to the requirements of today’s communication service 

providers who need to deliver and assure complex convergent services. 

5.2 Enterprise Application Integration (EAI) or 

Middleware Solution 

Point-to-point integration results in a significant number of integrations which increases 

exponentially as each new system is added. This can be reduced by utilising an EAI or 

middleware layer which reduces the number of integrations as each new component only 

integrates to the EAI therefore providing some distinct advantages over the point-to-point 

method. The EAI from an application integration perspective acts as a broker between multiple 

applications, allowing a change in one application to propagate to the required multiple other 

applications simultaneously. 

The core of the EAI is the message bus, and each application needs to integrate to this message 

bus via an adaptor that is specific to the EAI product or middleware that is deployed. Each 

application will publish messages to the bus, and the EAI ensures that each published message is 

only sent to the other applications that require that data and subsequently subscribe to that 

message. 

Figure 3 - EAI Integration 

Although the EAI solution is a significant step up from the point-to-point solution in terms of 

reducing the integration spaghetti, it still has its problems as it depends on predefined data 

structures. The adaptor that is built for each application can only accommodate scenarios that 

were envisaged in the original deployment. There is a need to make changes to these adaptors 

and add new adaptors over time as more functions, processes and applications are added to the 

required architecture. 

The EAI solution does not have the same level of architectural pitfalls found in the point-topoint 

solution as changes are accommodated in a more controlled manner, building on past 

structures and avoiding the spaghetti. However it does not necessarily solve the deployment


issues, as the changes to build new adaptors or modify existing adaptors still require 

considerable time and effort by multiple application vendors. 

Therefore the key business objectives of rolling out new products and services faster, and 

having end-to-end business process support of those services to provide the required service 

levels are not necessarily met with an EAI solution. In 2003 it was reported that 70% of all EAI 

projects failed. Most of these failures were not due to the software itself or technical difficulties, 

but due to management issues. EAIIC European Chairman Steve Craggs has outlined the seven 

main pitfalls undertaken by companies using EAI systems: 

1. Constant change - the very nature of EAI is dynamic and requires dynamic 

project managers to manage their implementation 

2. Lack of EAI experts - EAI solution requires in-depth knowledge of complex 

and often proprietary systems 

3. Competing standards - the paradox within the EAI field is that EAI standards 

themselves are not universal 

4. EAI is a tool paradigm - EAI is not a tool, but rather a system and should be 

implemented as such 

5. Building interfaces is an art - engineering the solution is not sufficient. Solutions 

need to be negotiated with user departments to reach a common consensus 

on the final outcome. A lack of consensus on interface designs leads to 

excessive effort to map between various systems data requirements 

6. Loss of detail - information that seemed unimportant at an earlier stage may 

become crucial later 

7. Accountability - since the different departments will have conflicting 

requirements, there should be clear accountability for the system's final 

structure 

EAI technologies are still being developed and there still isn’t a consensus on the ideal approach 

or the correct group of technologies a company should use. It is not uncommon for 

organisations to underestimate the time, effort and inherent risk associated with an EAI 

implementation. A lack of standard methodologies, complex legacy systems and communication 

disconnects between business units are only a few of the reasons why EAI initiatives fail. EAI 

solutions have both its advantages and disadvantages. 

Advantages of an EAI Solution: 

• Provides real-time information access among systems 

• Streamlines business processes and helps raise organisational efficiency 

• Maintains information integrity across multiple systems

Disadvantages of an EAI Solution: 

• Prohibitively high development costs 


• EAI implementations are very time consuming, and need a lot of resources 

• Requires a fair amount of up front design, which many managers are not able 

to envision or are not willing to invest in. Most EAI projects usually start off as 

a point-to-point effort, very soon becoming unmanageable as the number of 

applications increase 

The EAI solution is a step up from the point-to-point solution, but still falls short of solving all 

OSS integration issues. 

5.3 The Unified OSS Solution 

A Unified OSS encapsulates and consolidates all OSS operational information, functionality, user 

interfaces, APIs and process workflow into one OSS platform. The resulting reduction in 

integration and data stewardship issues and increased flexibility virtually removes the 

“Integration Tax” of an OSS deployment as well as the even more critical ongoing integration 

issues in operation of the OSS. 

In some respects, the Unified OSS is similar to other industry trends: 

• Alignment to TMF standards 

• Mergers and acquisitions of OSS product vendors 

However a Unified OSS is far more than this: 

• The TMF standards are addressing the problem which has arisen out of 

operators and OSS vendors focusing on a “best-of-breed” or “stove-pipe” 

model, where components by several vendors need to be integrated to form a 

coherent whole. Unified OSS is based on one product vendor providing the 

whole OSS platform 

• Mergers and acquisitions result in OSS product vendors acquiring wider 

functional scope, but based on underlying products that sometimes take years 

to be integrated into a coherent, fully integrated suite of products. Unified 

OSS is based on a suite of functional modules which have been developed from 

inception, to integrate and support an end-to-end process seamlessly 

In the manufacturing industry, a small number of products with large coverage such as SAP and 

Oracle are able to manage complex business models including customers, assembly lines, 

distribution links, suppliers and partners. Unified OSS is challenging the “best-of-breed” and 

“stove-pipe” approaches by asking “why can’t the telecoms industry be equipped with a single 

suite of software which manages its business”. Further more, Unified OSS is providing a possible 

answer. A Unified OSS contains:


• An information model which holds all operational data for the OSS. In many 

respects, this information model exists due to the work undertaken by the 

TMF. The SID is a first attempt to model the telecoms operational 

environment holistically, attaching as much importance to relationships 

between business entities as to the entities themselves 

• An integration bus which allows a number of modules to communicate and 

also allows them to communicate with legacy OSS components, the network 

and the surrounding BSS. The TMF, through their definition of the TNA, have 

started to provide a framework for such an integration bus 

• Modular components which implement the management functions we 

recognise as being “best-of-breed” today such as inventory, fault, performance, 

activation, trouble-ticket, SLA and work-force. The user interfaces for these 

modules are integrated seamlessly with each other through a common desktop 

application 

• Workflows which orchestrate how these components interact in support of 

an end-to-end process. As the system is pre-integrated and has a shared 

information model, it finally becomes practical to provide end-to-end “bestpractice” 

process templates 

• A consolidated set of physical platforms, employing modern n-tier layering to 

deliver performance, scalability and resilience 

Figure 4 - Unified OSS 

In the same way that computer “desk-top” programs integrate a number of applications and 

media into a single file to enable the user to create enriched documents, the Unified OSS allows 

operators to focus on the end-to-end business process by pre-integrating data and functional 

components.


“A new approach called “pre-integrated OSS” has emerged. Using this methodology, all key 

elements of an OSS solution — including network planning and configuration, service 

provisioning, workflow management, fault management, alarm management, SLA management, 

all of the administrative and reporting functions — are selected and integrated by OSS 

specialists. 

This pre-integrated approach streamlines the rollout of an OSS deployment and yields greater 

out-of-the-box functionality. It avoids costly one-of, technology-dependent solutions. These are 

substantial savings. Pre-integration presents a compelling case for OSS in the current convergent 

environment. This approach allows carriers to deploy and run more efficient multi-vendor, 

multi-technology networks. Clarity is the leader in this Next Generation trend” 

Frost & Sullivan 2005, www.frost.com 

This, in turn, provides the means to eliminate the integration challenges and risks of OSS 

delivery and operation requiring the integration of multiple disparate systems using either pointto-point 

or EAI integration solutions. 

Risk Area Risk Unified OSS 

Architecture Fragmented repositories 

of OSS information 

“Stove-pipe” OSS 

components cannot 

deliver sophisticated, 

bundled products 

Overlaps and gaps create 

tensions across the 

architecture 

Delivery Exhaust delivery budget by 

focusing on integration 

Data cleansing and 

migration costs 

underestimated 

Provides a single consolidated repository of all OSS 

operational information. Not only does this simplify 

integration, it also enhances data quality through 

constant self-referential checks 

Provides a single system which can be applied to 

fixed, mobile and converging environments, and can 

manage bundled products which are delivered over 

several technology and vendor domains 

Provides a single platform which can implement 

continuous end-to-end processes 

Allows delivery teams to focus on the business 

process which enriches the operational 

environment, rather than focus on integration and 

exhaust the delivery budget 

Provides a single target information model which 

allows discrepancies and misalignments to be 

identified faster during migration, but also inherently 

provides self-referential checking to maintain data 

accuracy once migrated


Risk Area Risk Unified OSS 

On-going 

operation 

Omission of the 

introduction into service 

step 

Long lead-times make the 

system redundant 

Maintenance across a 

complex OSS 

architecture – the ability 

(or lack of) to support 

ever changing business 

needs quickly and cost 

effectively 

Allows engagement of the business earlier in the 

project because a pre-integrated system is available 

at the start for training and internal promotion 

Removes the expensive and time-consuming system 

integration activities, therefore reducing delivery 

time-scales 

Provides the network and service operator with one 

contact point for maintenance issues and one owner 

for resolving problems. Critical changes in the 

business that require OSS business support can be 

quickly configured in one product without the need 

for the costly and time consuming integration 

changes required to adaptors in the case of EAI or 

point-to-point integration 

Table 1– Unified OSS Eliminates Integration Tax 

6 Future Direction 

The long term focus is to remove dependency on proprietary platforms and move towards a 

platform agnostic environment, general purpose APIs and reusable components. The objective is 

to ensure that the architecture, design principle and developments are reusable so the ability to 

integrate and deliver faster becomes a reality. Some of the initiatives in these directions are: 

• Web services – these are designed to support interoperable machine to 

machine interactions over a network such as the internet which will allow 

remote access. Web services are web API’s which can be accessed over 

internet and helps in reusable code with easy access thereby enabling faster 

deployment hence less time to market 

• SOA – the architecture principles on which SOA is built on, talks about 

encapsulation, loose coupling, reusability and collection of services into 

composite services which are all towards the direction where by service 

delivery becomes easy, maintenance and patches become easy which helps 

operators in delivering services faster to the customer and with lower cost of 

operations 

Several groups have instigated initiatives that have further assisted in this regard: 

• Standards bodies have attempted to ease integration across fragmented OSS 

by defining architectures which holistically examine process and information 

models. The TMF NGOSS is the leading example of this initiative


• Systems integrators have applied their project and program delivery 

experiences to the challenges of implementing OSS. Many have also invested in 

pre-integrating OSS products into their own integration and process 

frameworks 

• Product vendors have also contributed by opening their products to 

integration and automation through APIs that are aligned to standard 

functions, information models and process areas, and adopting new platform 

technology as it becomes available 

7 Conclusion 

Integration has always been a major challenge and often a serious impediment towards 

delivering true business value with new system implementation and augmentation projects, as 

end-to-end business processes are rarely supported by a single application. Only by reducing the 

number of disparate applications in the various technology, functional and vendor stovepipes, 

can the integration issues be substantially reduced. 

To achieve the process support required across the eTOM model, a service provider needs to 

consider implementing the OBCE principle of one OSS, one Billing System, one CRM and one 

ERP to minimise the number of integration points. 

Current mergers and acquisitions in 

the OSS industry focus on achieving 

coverage of functionality under the 

“umbrella” of a single OSS vendor. 

These offerings will contribute 

towards addressing the integration 

issues that currently impede business 

benefit. 

Continuing improvements specifying 

integration standards based on SOA 

and the conformance of vendors to 

these standards will continue to 

decrease the difficulty of integrating 

Figure 5 - OBCE Framework 

for business value. It is however, 

becoming more widely recognised that regardless of these other initiatives only the power of a 

truly Unified OSS that is pre-integrated with a common information model and workflow will 

allow deployments to focus on achieving maximum business benefits through end-to-end 

process implementation. The telco that carefully selects a truly Unified OSS will largely dodge 

the “Integration Tax” and rise above it’s competitors to be dominant in their chosen markets 

through the power of true seamless process support.


About Tata Consultancy Services (TCS) 

Tata Consultancy Services is an IT services, business solutions and outsourcing organisation that 

delivers real results to global businesses, ensuring a level of certainty no other firm can match. 

TCS offers a consulting-led, integrated portfolio of IT and IT-enabled services delivered through 

its unique Global Network Delivery Model TM , recognised as the benchmark of excellence in 

software development. 

A part of the Tata Group, India’s largest industrial conglomerate, TCS has over 94,000 of the 

world's best trained IT consultants in 47 countries. The company generated consolidated 

revenues of US $4.3 billion for fiscal year ended 31 March 2007 and is listed on the National 

Stock Exchange and Bombay Stock Exchange in India. 

For more information, visit us at www.tcs.com 

About Clarity 

Clarity is the telecommunication industry’s Operational Support System (OSS) business process 

automation company – providing a pre-integrated product and database that streamlines the 17 

eTOM elements of OSS into a single suite. This also allows Clarity to provide executive visibility 

of the network's impact on revenue and customer experience across both service fulfillment and 

assurance. 

Having simplified the management of both legacy and next-generation network environments, 

Clarity OSS is network and services neutral, driven by templates that are rapidly configurable to 

allow operators to cut time to market for any new service by two-thirds. Today Clarity 

simplifies network support for over 90 million subscribers worldwide. 

Established in 1993, Clarity’s global headquarter is in Sydney, Australia, with offices in Asia, the 

Middle East, Europe and North America 

For more information, please visit us at www.clarity.com 

CLARITY INTERNATIONAL LIMITED 

LEVEL 41 NORTH POINT TOWER 

100 MILLER STREET 

NORTH SYDNEY NSW 2060 

AUSTRALIA 

TEL: +61 2 9925 5000 

FAX: +61 2 9955 9999 

. .

Download - Tata Consultancy Services

Create successful ePaper yourself

Delete template?

Save as template?