Download - Tata Consultancy Services
Download - Tata Consultancy Services
Download - Tata Consultancy Services
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Clarity - TCS Whitepaper<br />
Key Integration Issues in Building<br />
a Strategic OSS Platform<br />
This white paper addresses the key OSS<br />
integration issues faced by operators<br />
today and provides suggestions for<br />
transformation and improvement
2 | Key Integration Issues in Building a Strategic OSS Platform<br />
About The Authors<br />
Nadeem Khan has over 11 years of working experience with <strong>Tata</strong><br />
<strong>Consultancy</strong> <strong>Services</strong>. He has been involved in working with service<br />
providers like BT and BSNL in various capacities. For the past two years<br />
Nadeem has been working in <strong>Tata</strong> <strong>Consultancy</strong> <strong>Services</strong> Telecom Vertical<br />
and is responsible for pre-sales activities in the OSS/BSS domain.<br />
Nadeem Khan is an OSS Consultant for <strong>Tata</strong> <strong>Consultancy</strong><br />
<strong>Services</strong><br />
Mel Cantarella has over 25 years experience in the Telecommunications<br />
Industry, and in that time has held a variety of senior roles within service<br />
providers in both network engineering and network operations. He has<br />
helped system integrators and ISVs implement BSS and OSS Solutions<br />
around the world. Mel joined Clarity in 2000 as a Project Director and<br />
became Global Alliance Director in 2006. In his 7 years with Clarity he<br />
has been responsible for delivering a number of large Tier 1 Clarity<br />
implementations to key Clarity customers. Prior to joining Clarity Mel<br />
spent several years with Optus in Sydney, Time Telekom in KL and IBM<br />
Global <strong>Services</strong> in Australia.<br />
Mel Cantarella is the Global Alliance Director for Clarity International<br />
Copyright Information<br />
Copyright © 2007. Clarity International Limited. All rights reserved. Clarity International and<br />
the Clarity logo are registered trademarks of Clarity International Limited, in Australia and<br />
other countries. All other trademarks or registered service marks in this document are the<br />
property of Clarity International or their respective owners. All specifications are subject to<br />
change without notice. Clarity International assumes no responsibility for any inaccuracies in this<br />
document or for any obligation to update information in this document. Clarity International<br />
reserves the right to change, modify, transfer, or otherwise revise this publication without<br />
notice.
Table of Contents<br />
3 | Key Integration Issues in Building a Strategic OSS Platform<br />
1 INTRODUCTION.....................................................................................4<br />
2 ABSTRACT................................................................................................4<br />
3 THE CHALLENGE OF BUILDING AN OSS.........................................4<br />
4 KEY INTEGRATION ISSUES..................................................................6<br />
4.1 Integration Challenges............................................................................................ 6<br />
4.2 Key Integration Points............................................................................................ 7<br />
5 SOLUTIONS FOR THE INTEGRATION PROBLEM.........................11<br />
5.1 The Point-to-Point Integration Solution ..........................................................12<br />
5.2 Enterprise Application Integration (EAI) or Middleware Solution.............13<br />
5.3 The Unified OSS Solution....................................................................................15<br />
6 FUTURE DIRECTION............................................................................18<br />
7 CONCLUSION........................................................................................19
4 | Key Integration Issues in Building a Strategic OSS Platform<br />
1 Introduction<br />
In recent years, OSS has become an area of considerable focus as well as concern for service<br />
providers. Making the right decision with their OSS architecture will lead to considerable<br />
business benefit in the form of substantially reduced operational costs, increased revenues and<br />
increased customer satisfaction. Making the wrong decision however will lead to the risk of<br />
expending significant capital towards the implementation of a solution that appears on the<br />
surface to meet the business needs, but ends up falling short in operation, resulting in<br />
stakeholders often at a loss to pinpoint what went wrong. The major concern areas revolve<br />
around:<br />
• Complexity – networks are becoming increasingly complex with the delivery<br />
of today’s telecom products and services requiring multiple technologies and<br />
platforms<br />
• Growth – increased demand for new innovative services with faster delivery<br />
times and higher levels of service quality<br />
• Skills – shortage of specialised skills for complex network management<br />
• Data and information management – service providers that can not manage<br />
their network, service and customer data are unable to respond quickly to<br />
customer requests<br />
These concerns are further impacted by the need to integrate multiple OSS components and<br />
functions as service providers struggle to manage convergence as well as the ever growing<br />
requirements from customers for new services and higher quality of service.<br />
2 Abstract<br />
In recent years, OSS has become an area of considerable focus as well as concern for service<br />
providers. OSS Integration has always been a major challenge and often a serious impediment<br />
towards delivering true business value with new system implementation and augmentation<br />
projects, as end-to-end business processes are rarely supported by a single application.<br />
This paper addresses the key OSS integration issues faced by operators today. It looks at the<br />
point-to-point integration solution, the EAI solution and the Unified OSS solution and provides<br />
suggestions for transformation and improvement.<br />
3 The Challenge of Building an OSS<br />
The telecom industry worldwide is going through a revolutionary change. This revolution is not<br />
only in terms of increased growth of product and service types, increased revenue, ARPU,<br />
AMPU and churn but also in terms of customer expectations and the need for quality of service.
5 | Key Integration Issues in Building a Strategic OSS Platform<br />
Customers expect services that are available 100% of the time. Convergence of voice, data and<br />
video has been the catalyst to the demand for services anytime, anywhere and through any<br />
device.<br />
In the race to deliver new products and services to market quickly, service providers have found<br />
it difficult and time consuming to utilise existing or legacy solution suites. Instead they have<br />
implemented complete OSS/BSS stovepipe suites to support the new products. Doing so may<br />
have allowed them to achieve their launch dates and initial revenue targets by being “first to<br />
market” thus capturing a larger share of the market initially. However as these stovepipe suites<br />
act independently, the service provider will find it difficult to provide their customers with<br />
seamless convergent services, as manual steps are required to link the required business<br />
processes across these technology vertical suites.<br />
As a result, service fulfillment times increase, service assurance is also impacted and slowly the<br />
service provider will lose market share to competitor’s that have a more integrated OSS/BSS<br />
solution stack, that provides a single view of the customer, service and network.<br />
These well integrated service providers give their<br />
customers the warm feeling that they are truly dealing<br />
with one single coordinated service provider, while<br />
the “stovepipe operators” make the customer feel<br />
that they themselves need to be the project coordinator<br />
managing multiple disparate providers to<br />
achieve the same end result.<br />
The telecommunication landscape is continuously<br />
changing with increasingly complex networks<br />
“Only by providing one point of<br />
contact to order, ask questions,<br />
dispute bills and request repairs will<br />
providers win the continued loyalty<br />
of customers and this will require<br />
greater back-office integration.”<br />
Susan Richardson, Gartner<br />
Research, May 2005<br />
comprising both legacy and next generation technologies, provided by a myriad of network<br />
equipment vendors and interworking to provide these ever converging services.<br />
Business processes are also increasing in complexity with the need for constant change as the<br />
landscape, competition and service offerings change, and as service providers strive to achieve<br />
and improve upon best practices to remain competitive and stay ahead of the game.<br />
The service provider that can manage the constant change quickly, efficiently and as part of their<br />
normal business process will survive and prosper. Service providers with well integrated<br />
BSS/OSS solution suites across both service fulfillment and assurance, as well as across network<br />
technologies and service offerings, will be able to better respond to the changes and continue to<br />
provide seamless service to their existing and new customers.<br />
Effective BSS/OSS integration holds the key for achieving operator’s business objectives i.e.<br />
increased customer satisfaction which in turn increases market share, increases customer<br />
retention, increases revenue and lowers operational costs.<br />
This white paper identifies the key integration challenges that exist for service providers today<br />
and provides suggestions for transformation and improvements across the standard integration<br />
touch points in the OSS environment.
6 | Key Integration Issues in Building a Strategic OSS Platform<br />
4 Key Integration Issues<br />
Integration challenges are perceived differently by different people. These challenges are closely<br />
linked even though they are represented differently. In a telco environment there are three<br />
major stake holders, the customer, the business unit and the IT department. Each of them is<br />
impacted in a different way due to the challenges faced in integration.<br />
4.1 Integration Challenges<br />
Service providers are faced with the following challenges from customer demands:<br />
• Demands for ever improving service levels for both service connections and<br />
service quality<br />
• Decreased cost structure to remain competitive i.e. moving from manual<br />
activities to task automation<br />
• Content and service anytime, anywhere and through any device<br />
The root of these challenges lies in the integration of the OSS system. OSS integration<br />
challenges faced by service providers today include:<br />
• Integrating customer service level to network service level – this enables<br />
customer notification of service and performance degradation in the event of<br />
network failure. The complexity increases with multi-vendor networks and the<br />
growth of convergent services<br />
• Translating network faults to service impacts and to customers impacted – this<br />
integration is key from a business perspective as the faults which occur in the<br />
network need to be translated into the service impact and then based on the<br />
service impact, translated into which customers will be impacted. Notifications<br />
can be given to the customer in advance before the customer notices the<br />
impact of the fault. Also with the addition of integrated SLA management, fault<br />
restoration activities can be managed so that faults impacting high value<br />
customers are prioritised, protecting service provider revenues. This<br />
integration is a crucial ingredient to ensuring pro-active customer management<br />
• Translating service faults to customers and to services impacted – this<br />
integration helps the service provider’s business team to analyse the impact of<br />
faults on service. If the fault affects the basic service which has a considerable<br />
customer base, business can take a call on increasing the fault priority and<br />
business rules can be easily configured to automate this prioritisation<br />
• Single fault visibility – integrating faults captured by the OSS from disparate<br />
network devices and presenting it to the help desk system so that the agents<br />
can provide a 360 degree view of the customer from an assurance perspective
7 | Key Integration Issues in Building a Strategic OSS Platform<br />
• Integration of network element with the OSS – the service provider’s network<br />
is comprised of the various network elements from different vendors which<br />
speak and support different protocols. From NMS FCAPS functionality<br />
perspective there needs to be an integration adapter layer built to co-relate<br />
fault and performance data and ideally capture this data in the one system. The<br />
challenge is in building this adapter layer to suite the various protocols and<br />
transform the data into a common language from a fault and performance<br />
perspective. The complexity of doing this without tight integration is increased<br />
considerably with the increase of data services<br />
• Multi-vendor OSS components – traditionally a service providers OSS is built<br />
with multi-vendor OSS components. For example the service provider would<br />
have a separate fault management system, a separate performance<br />
management system etc. These have their own databases, own supporting<br />
protocols and in some cases the systems are designed specifically for either<br />
legacy or next generation technologies, requiring multiple systems in one<br />
functional domain. The complexity arises in integrating these separate systems<br />
to form a consolidated OSS perspective<br />
4.2 Key Integration Points<br />
To enable a service provider to generate new services and revenues, drive up customer<br />
satisfaction and drive down costs, tight integration within the components of an OSS, between<br />
OSS and BSS, OSS and ERP and OSS and the network is crucial. Figure 1 represents the<br />
TeleManagement Forum enhanced Telecom Operations Map (TMF eTOM).<br />
The operations process area is the heart of eTOM. It includes all operations processes that<br />
support the customer operations and management as well as those that enable direct customer<br />
operations with the customer. This includes sales management and supplier/partner relationship<br />
management.<br />
The strategy, infrastructure and product process area includes processes that develop strategy,<br />
commitment to the service provider, build infrastructure, develop and manage products, and<br />
develop and manage the supply chain. In eTOM, infrastructure refers to more than just IT and<br />
resource infrastructure that supports products and services. It includes the infrastructure<br />
required to support functional processes such as CRM. These processes direct and enable<br />
operations.<br />
The enterprise management process area includes basic business processes required to run any<br />
business. These processes focus on enterprise level processes, goals and objectives. These<br />
processes have interfaces with almost every other process in the enterprise whether<br />
operational, product or infrastructure processes. These processes include for example financial<br />
management and human resources management.<br />
The market, product and customer processes include those dealing with sales and channel<br />
management, marketing management and product and offer management as well as customer<br />
relationship management and ordering, problem handling, SLA management and billing.
8 | Key Integration Issues in Building a Strategic OSS Platform<br />
Service processes include those dealing with service development and configuration, service<br />
problem management and quality analysis, and rating.<br />
Resource processes include those dealing with development and management of the service<br />
provider’s infrastructure, whether related to products and services or to supporting the<br />
enterprise itself.<br />
The supplier/partner processes include those dealing with the service provider’s interaction with<br />
its suppliers and partners. This involves both processes that manage the supply chain that<br />
underpins product and infrastructure, as well as those that support the operations interface<br />
with its suppliers and partners.<br />
Figure 1 - TeleManagement Forum enhanced Telecom Operations Map<br />
Upon studying the TMF eTOM one begins to appreciate that in order to support the end-toend<br />
business processes that are crucial to the business bottom line, tight integration within an<br />
OSS as well as between OSS, BSS, ERP and the network is a must. Best practice business<br />
process does not exist in functional components that are provided in commercial off-the-shelf<br />
software packages. It exists by managing all business lifecycles in a seamless end-to-end fashion<br />
and by being able to monitor, control and constantly improve the processes. Only with tight<br />
integration across all functions can this be achieved.<br />
The amount of integration required to achieve this seamless end-to-end business process<br />
support is mammoth in proportion and an exercise that should be treated with the most<br />
respect. Any pre-integration of components should be carefully considered to reduce the<br />
enormity of the task where possible. The following list is by no means extensive, but gives an
9 | Key Integration Issues in Building a Strategic OSS Platform<br />
indication of some of the key integrations which are required as a starting point to achieve this<br />
seamless end-to-end business process support.<br />
External to OSS<br />
• Providing serviceability information to an order entry application (usually a<br />
CRM Module) during processing of customer service request<br />
• Receiving service requests from an order entry application once the service<br />
order is confirmed<br />
• Providing updates to the order entry application from the OSS advising status<br />
of service provisioning<br />
• Providing updates to the order entry application upon activation of the service<br />
or feature to enable notification to commence billing<br />
• Providing service and network status information to a customer problem<br />
management application<br />
• Providing SLA information about the network and the services to a customer<br />
SLA application<br />
• Providing customer service fault statistics to a customer web portal<br />
• Providing customer service performance statistics to a customer web portal<br />
• Receiving network asset details from a materials management or asset<br />
management application (usually an ERP Module) when network assets move<br />
into the network from storage or from vendors<br />
• Providing network asset details to a materials management or asset<br />
management application when network assets move from the network to<br />
storage or to vendors for repair<br />
• Providing work order and work task details to a field force management or<br />
contract work force management system as part of a either a service<br />
fulfillment or service assurance process<br />
• Receiving work order and work task updates from a field force management<br />
or contract work force management system as part of a service fulfillment or<br />
service assurance process<br />
Internal to OSS and Network<br />
• A service provisioning application receiving network resource information<br />
from an inventory management application to be able to effectively complete<br />
the provisioning process<br />
• A service provisioning application updating an inventory management<br />
application after completing a provisioning process
10 | Key Integration Issues in Building a Strategic OSS Platform<br />
• A service provisioning application sending network and service configuration/<br />
provisioning commands to a network mediation layer for transmission to the<br />
specified network management layers or direct to the network elements<br />
• A service provisioning application receiving SLA contract data from an SLA<br />
application to obtain prioritisation and escalation of customer connections<br />
• An SLA management application providing SLA contract data to a service<br />
provisioning application to allow prioritisation and escalation of customer<br />
connections<br />
• A network mediation layer sending service configuration/provisioning<br />
commands to the specified network management layers or direct to the<br />
network elements<br />
• A fault management application receiving network events from a network<br />
mediation layer<br />
• A network mediation receiving network events from the specified network<br />
management layers or directly from the network elements<br />
• A fault management application providing alarm data to a trouble ticket<br />
application to allow automated creation of trouble tickets<br />
• A fault management application providing alarm data to an SLA application to<br />
allow prioritisation and escalation of network faults<br />
• An SLA management application providing SLA contract data to a trouble<br />
ticket application to allow prioritisation and escalation of network faults<br />
• A performance management application receiving performance data from a<br />
network mediation/adaptor layer<br />
• A network mediation receiving performance data from the specified network<br />
management layers or directly from the network elements<br />
• A performance management application providing performance trends data to<br />
an SLA application to allow prioritisation and escalation of service degradation<br />
• Integration of alarms across multiple vendor equipment within one network<br />
technology to obtain a single view of that network technology platform<br />
• Integration of alarms across multiple vendor equipment and across multiple<br />
network technologies to obtain a single view of the network across vendors<br />
and technologies<br />
• Integration of performance data across multiple vendor equipment within one<br />
network technology to obtain a single view of performance for that network<br />
technology platform
11 | Key Integration Issues in Building a Strategic OSS Platform<br />
• Integration of performance data across multiple vendor equipment across<br />
multiple network technologies to obtain a single view of the network across<br />
vendors and technologies<br />
These are just a sample of some key integration points required to support some of the most<br />
basic functions in the business. To achieve true business transformation through integration,<br />
many more integration points are required and one must go down many levels of lower detail<br />
to realise the true scope and magnitude of the required integration.<br />
The end result that service providers constantly strive towards is the ability to be in any screen,<br />
performing any function and be able to provide to the user at the touch of a button all the<br />
stored and available data about a customer, a service or a network device that the service<br />
provider has collected over each of these entity’s lifetime in that service provider. This data is<br />
normally stored in a number of automated and manual systems and even paper records, and the<br />
ability to access this wealth of data is often a pipe dream. Effective integration of all these<br />
databases can make the light at the end of the pipe and the dream, seem a great deal closer.<br />
5 Solutions for the Integration Problem<br />
In 2004, Dittberner estimated telecoms around the world spent $38.6 billion on OSS/BSS<br />
application software and its integration, and for every $3 dollars spent on network management,<br />
service management and customer management software another $1 is spent by telecoms on<br />
integration. Key problems faced by service providers in achieving an integrated OSS include:<br />
• Multi-vendor OSS deployment of<br />
individual solutions for fulfillment<br />
and assurance has led to increased<br />
complication in integration. These<br />
OSS components, centered on<br />
technologies, functions or network<br />
vendors, cannot deliver<br />
sophisticated bundled products<br />
across different technologies or<br />
vendors<br />
• Data manipulation from various<br />
sources – in a multi-vendor<br />
environment, each application has it<br />
owns OSS database. From a QoS<br />
perspective data manipulation from<br />
each application’s database has to be<br />
done. This leads to issues of data<br />
integrity and latency and the<br />
fragmented repositories of OSS<br />
information cause business<br />
processes to become disconnected<br />
“In case of those vendors that have got<br />
about doing inorganic technology<br />
additions through M&A - You might hear<br />
from a salesperson who has a slick<br />
brochure that shows everything as a<br />
wonderfully integrated suite, but when<br />
the truck rolls up for the installation it’s<br />
actually a very disparate set of<br />
standalone pieces that might not be able<br />
to share data, might run on different<br />
hardware and databases, and might not<br />
be able to fit together at all. So you’ve<br />
just moved the problem from several<br />
contracts with smaller vendors to one<br />
contract, but you’ve still got these<br />
disparate systems and you don’t have<br />
any kind of integrated suite whatsoever.”<br />
Keith Willetts, Chairman,<br />
TeleManagement Forum 2006
12 | Key Integration Issues in Building a Strategic OSS Platform<br />
The need to integrate creates an initial problem during system deployment but of even bigger<br />
concern is the on-going problem in operations and maintenance. The OSS must be able to<br />
evolve as demands are placed on it. Complex architectures and commercial arrangements<br />
surrounding the OSS often limit its agility to respond to new demands. Key issues include:<br />
• An OSS made up from many “best-of-breed” or “stove-pipe” components are<br />
even harder to maintain then they are to deliver<br />
• Training and support contracts may be difficult to line up in such a way that<br />
gaps in coverage are avoided<br />
• The resulting system may be expensive and time-consuming to adapt to new<br />
market pressures<br />
5.1 The Point-to-Point Integration Solution<br />
In the past in an effort to provide a minimum level of integration, system integrators and service<br />
providers used “point-to-point” integration. Point-to-point integration entails communication<br />
between pairs of systems that need to share data. This method as a solution and architecture<br />
appear to have some merit when deploying only two applications to provide a business process,<br />
or even multiple applications where each system only needs to communicate with one other<br />
system. It also makes some sense if a deployment is not expected to experience any significant<br />
change for many years.<br />
However in today’s complex and volatile telecommunications industry it is rare for only two of<br />
the many applications required to share the same data and also be the only two involved in a<br />
specific business process. It is even rarer that there will be no change requiring new and more<br />
complex interfaces between numerous systems, because in today’s telecom environment change<br />
is one of the few “constants”. The point-to-point solution therefore becomes costly and<br />
unwieldy with duplications and overlapping integrations between numerous applications, which<br />
builds over time into a tangled architectural “spaghetti”.<br />
This creates problems<br />
during implementation,<br />
but becomes a real<br />
nightmare during ongoing<br />
operations as<br />
continual changes are<br />
required. With every<br />
new function, process or<br />
application, the time to<br />
implement and the risk<br />
of failure increases due<br />
to the ever increasing<br />
complex integration<br />
architecture.<br />
Figure 2 - Complex Point-to-Point Integration
13 | Key Integration Issues in Building a Strategic OSS Platform<br />
The ability to provide the required level of end-to-end business process support slowly grinds<br />
to a halt, and the end-to-end system performance also suffers. This solution may be sufficient for<br />
some industries, but it can not stand up to the requirements of today’s communication service<br />
providers who need to deliver and assure complex convergent services.<br />
5.2 Enterprise Application Integration (EAI) or<br />
Middleware Solution<br />
Point-to-point integration results in a significant number of integrations which increases<br />
exponentially as each new system is added. This can be reduced by utilising an EAI or<br />
middleware layer which reduces the number of integrations as each new component only<br />
integrates to the EAI therefore providing some distinct advantages over the point-to-point<br />
method. The EAI from an application integration perspective acts as a broker between multiple<br />
applications, allowing a change in one application to propagate to the required multiple other<br />
applications simultaneously.<br />
The core of the EAI is the message bus, and each application needs to integrate to this message<br />
bus via an adaptor that is specific to the EAI product or middleware that is deployed. Each<br />
application will publish messages to the bus, and the EAI ensures that each published message is<br />
only sent to the other applications that require that data and subsequently subscribe to that<br />
message.<br />
Figure 3 - EAI Integration<br />
Although the EAI solution is a significant step up from the point-to-point solution in terms of<br />
reducing the integration spaghetti, it still has its problems as it depends on predefined data<br />
structures. The adaptor that is built for each application can only accommodate scenarios that<br />
were envisaged in the original deployment. There is a need to make changes to these adaptors<br />
and add new adaptors over time as more functions, processes and applications are added to the<br />
required architecture.<br />
The EAI solution does not have the same level of architectural pitfalls found in the point-topoint<br />
solution as changes are accommodated in a more controlled manner, building on past<br />
structures and avoiding the spaghetti. However it does not necessarily solve the deployment
14 | Key Integration Issues in Building a Strategic OSS Platform<br />
issues, as the changes to build new adaptors or modify existing adaptors still require<br />
considerable time and effort by multiple application vendors.<br />
Therefore the key business objectives of rolling out new products and services faster, and<br />
having end-to-end business process support of those services to provide the required service<br />
levels are not necessarily met with an EAI solution. In 2003 it was reported that 70% of all EAI<br />
projects failed. Most of these failures were not due to the software itself or technical difficulties,<br />
but due to management issues. EAIIC European Chairman Steve Craggs has outlined the seven<br />
main pitfalls undertaken by companies using EAI systems:<br />
1. Constant change - the very nature of EAI is dynamic and requires dynamic<br />
project managers to manage their implementation<br />
2. Lack of EAI experts - EAI solution requires in-depth knowledge of complex<br />
and often proprietary systems<br />
3. Competing standards - the paradox within the EAI field is that EAI standards<br />
themselves are not universal<br />
4. EAI is a tool paradigm - EAI is not a tool, but rather a system and should be<br />
implemented as such<br />
5. Building interfaces is an art - engineering the solution is not sufficient. Solutions<br />
need to be negotiated with user departments to reach a common consensus<br />
on the final outcome. A lack of consensus on interface designs leads to<br />
excessive effort to map between various systems data requirements<br />
6. Loss of detail - information that seemed unimportant at an earlier stage may<br />
become crucial later<br />
7. Accountability - since the different departments will have conflicting<br />
requirements, there should be clear accountability for the system's final<br />
structure<br />
EAI technologies are still being developed and there still isn’t a consensus on the ideal approach<br />
or the correct group of technologies a company should use. It is not uncommon for<br />
organisations to underestimate the time, effort and inherent risk associated with an EAI<br />
implementation. A lack of standard methodologies, complex legacy systems and communication<br />
disconnects between business units are only a few of the reasons why EAI initiatives fail. EAI<br />
solutions have both its advantages and disadvantages.<br />
Advantages of an EAI Solution:<br />
• Provides real-time information access among systems<br />
• Streamlines business processes and helps raise organisational efficiency<br />
• Maintains information integrity across multiple systems
Disadvantages of an EAI Solution:<br />
• Prohibitively high development costs<br />
15 | Key Integration Issues in Building a Strategic OSS Platform<br />
• EAI implementations are very time consuming, and need a lot of resources<br />
• Requires a fair amount of up front design, which many managers are not able<br />
to envision or are not willing to invest in. Most EAI projects usually start off as<br />
a point-to-point effort, very soon becoming unmanageable as the number of<br />
applications increase<br />
The EAI solution is a step up from the point-to-point solution, but still falls short of solving all<br />
OSS integration issues.<br />
5.3 The Unified OSS Solution<br />
A Unified OSS encapsulates and consolidates all OSS operational information, functionality, user<br />
interfaces, APIs and process workflow into one OSS platform. The resulting reduction in<br />
integration and data stewardship issues and increased flexibility virtually removes the<br />
“Integration Tax” of an OSS deployment as well as the even more critical ongoing integration<br />
issues in operation of the OSS.<br />
In some respects, the Unified OSS is similar to other industry trends:<br />
• Alignment to TMF standards<br />
• Mergers and acquisitions of OSS product vendors<br />
However a Unified OSS is far more than this:<br />
• The TMF standards are addressing the problem which has arisen out of<br />
operators and OSS vendors focusing on a “best-of-breed” or “stove-pipe”<br />
model, where components by several vendors need to be integrated to form a<br />
coherent whole. Unified OSS is based on one product vendor providing the<br />
whole OSS platform<br />
• Mergers and acquisitions result in OSS product vendors acquiring wider<br />
functional scope, but based on underlying products that sometimes take years<br />
to be integrated into a coherent, fully integrated suite of products. Unified<br />
OSS is based on a suite of functional modules which have been developed from<br />
inception, to integrate and support an end-to-end process seamlessly<br />
In the manufacturing industry, a small number of products with large coverage such as SAP and<br />
Oracle are able to manage complex business models including customers, assembly lines,<br />
distribution links, suppliers and partners. Unified OSS is challenging the “best-of-breed” and<br />
“stove-pipe” approaches by asking “why can’t the telecoms industry be equipped with a single<br />
suite of software which manages its business”. Further more, Unified OSS is providing a possible<br />
answer. A Unified OSS contains:
16 | Key Integration Issues in Building a Strategic OSS Platform<br />
• An information model which holds all operational data for the OSS. In many<br />
respects, this information model exists due to the work undertaken by the<br />
TMF. The SID is a first attempt to model the telecoms operational<br />
environment holistically, attaching as much importance to relationships<br />
between business entities as to the entities themselves<br />
• An integration bus which allows a number of modules to communicate and<br />
also allows them to communicate with legacy OSS components, the network<br />
and the surrounding BSS. The TMF, through their definition of the TNA, have<br />
started to provide a framework for such an integration bus<br />
• Modular components which implement the management functions we<br />
recognise as being “best-of-breed” today such as inventory, fault, performance,<br />
activation, trouble-ticket, SLA and work-force. The user interfaces for these<br />
modules are integrated seamlessly with each other through a common desktop<br />
application<br />
• Workflows which orchestrate how these components interact in support of<br />
an end-to-end process. As the system is pre-integrated and has a shared<br />
information model, it finally becomes practical to provide end-to-end “bestpractice”<br />
process templates<br />
• A consolidated set of physical platforms, employing modern n-tier layering to<br />
deliver performance, scalability and resilience<br />
Figure 4 - Unified OSS<br />
In the same way that computer “desk-top” programs integrate a number of applications and<br />
media into a single file to enable the user to create enriched documents, the Unified OSS allows<br />
operators to focus on the end-to-end business process by pre-integrating data and functional<br />
components.
17 | Key Integration Issues in Building a Strategic OSS Platform<br />
“A new approach called “pre-integrated OSS” has emerged. Using this methodology, all key<br />
elements of an OSS solution — including network planning and configuration, service<br />
provisioning, workflow management, fault management, alarm management, SLA management,<br />
all of the administrative and reporting functions — are selected and integrated by OSS<br />
specialists.<br />
This pre-integrated approach streamlines the rollout of an OSS deployment and yields greater<br />
out-of-the-box functionality. It avoids costly one-of, technology-dependent solutions. These are<br />
substantial savings. Pre-integration presents a compelling case for OSS in the current convergent<br />
environment. This approach allows carriers to deploy and run more efficient multi-vendor,<br />
multi-technology networks. Clarity is the leader in this Next Generation trend”<br />
Frost & Sullivan 2005, www.frost.com<br />
This, in turn, provides the means to eliminate the integration challenges and risks of OSS<br />
delivery and operation requiring the integration of multiple disparate systems using either pointto-point<br />
or EAI integration solutions.<br />
Risk Area Risk Unified OSS<br />
Architecture Fragmented repositories<br />
of OSS information<br />
“Stove-pipe” OSS<br />
components cannot<br />
deliver sophisticated,<br />
bundled products<br />
Overlaps and gaps create<br />
tensions across the<br />
architecture<br />
Delivery Exhaust delivery budget by<br />
focusing on integration<br />
Data cleansing and<br />
migration costs<br />
underestimated<br />
Provides a single consolidated repository of all OSS<br />
operational information. Not only does this simplify<br />
integration, it also enhances data quality through<br />
constant self-referential checks<br />
Provides a single system which can be applied to<br />
fixed, mobile and converging environments, and can<br />
manage bundled products which are delivered over<br />
several technology and vendor domains<br />
Provides a single platform which can implement<br />
continuous end-to-end processes<br />
Allows delivery teams to focus on the business<br />
process which enriches the operational<br />
environment, rather than focus on integration and<br />
exhaust the delivery budget<br />
Provides a single target information model which<br />
allows discrepancies and misalignments to be<br />
identified faster during migration, but also inherently<br />
provides self-referential checking to maintain data<br />
accuracy once migrated
18 | Key Integration Issues in Building a Strategic OSS Platform<br />
Risk Area Risk Unified OSS<br />
On-going<br />
operation<br />
Omission of the<br />
introduction into service<br />
step<br />
Long lead-times make the<br />
system redundant<br />
Maintenance across a<br />
complex OSS<br />
architecture – the ability<br />
(or lack of) to support<br />
ever changing business<br />
needs quickly and cost<br />
effectively<br />
Allows engagement of the business earlier in the<br />
project because a pre-integrated system is available<br />
at the start for training and internal promotion<br />
Removes the expensive and time-consuming system<br />
integration activities, therefore reducing delivery<br />
time-scales<br />
Provides the network and service operator with one<br />
contact point for maintenance issues and one owner<br />
for resolving problems. Critical changes in the<br />
business that require OSS business support can be<br />
quickly configured in one product without the need<br />
for the costly and time consuming integration<br />
changes required to adaptors in the case of EAI or<br />
point-to-point integration<br />
Table 1– Unified OSS Eliminates Integration Tax<br />
6 Future Direction<br />
The long term focus is to remove dependency on proprietary platforms and move towards a<br />
platform agnostic environment, general purpose APIs and reusable components. The objective is<br />
to ensure that the architecture, design principle and developments are reusable so the ability to<br />
integrate and deliver faster becomes a reality. Some of the initiatives in these directions are:<br />
• Web services – these are designed to support interoperable machine to<br />
machine interactions over a network such as the internet which will allow<br />
remote access. Web services are web API’s which can be accessed over<br />
internet and helps in reusable code with easy access thereby enabling faster<br />
deployment hence less time to market<br />
• SOA – the architecture principles on which SOA is built on, talks about<br />
encapsulation, loose coupling, reusability and collection of services into<br />
composite services which are all towards the direction where by service<br />
delivery becomes easy, maintenance and patches become easy which helps<br />
operators in delivering services faster to the customer and with lower cost of<br />
operations<br />
Several groups have instigated initiatives that have further assisted in this regard:<br />
• Standards bodies have attempted to ease integration across fragmented OSS<br />
by defining architectures which holistically examine process and information<br />
models. The TMF NGOSS is the leading example of this initiative
19 | Key Integration Issues in Building a Strategic OSS Platform<br />
• Systems integrators have applied their project and program delivery<br />
experiences to the challenges of implementing OSS. Many have also invested in<br />
pre-integrating OSS products into their own integration and process<br />
frameworks<br />
• Product vendors have also contributed by opening their products to<br />
integration and automation through APIs that are aligned to standard<br />
functions, information models and process areas, and adopting new platform<br />
technology as it becomes available<br />
7 Conclusion<br />
Integration has always been a major challenge and often a serious impediment towards<br />
delivering true business value with new system implementation and augmentation projects, as<br />
end-to-end business processes are rarely supported by a single application. Only by reducing the<br />
number of disparate applications in the various technology, functional and vendor stovepipes,<br />
can the integration issues be substantially reduced.<br />
To achieve the process support required across the eTOM model, a service provider needs to<br />
consider implementing the OBCE principle of one OSS, one Billing System, one CRM and one<br />
ERP to minimise the number of integration points.<br />
Current mergers and acquisitions in<br />
the OSS industry focus on achieving<br />
coverage of functionality under the<br />
“umbrella” of a single OSS vendor.<br />
These offerings will contribute<br />
towards addressing the integration<br />
issues that currently impede business<br />
benefit.<br />
Continuing improvements specifying<br />
integration standards based on SOA<br />
and the conformance of vendors to<br />
these standards will continue to<br />
decrease the difficulty of integrating<br />
Figure 5 - OBCE Framework<br />
for business value. It is however,<br />
becoming more widely recognised that regardless of these other initiatives only the power of a<br />
truly Unified OSS that is pre-integrated with a common information model and workflow will<br />
allow deployments to focus on achieving maximum business benefits through end-to-end<br />
process implementation. The telco that carefully selects a truly Unified OSS will largely dodge<br />
the “Integration Tax” and rise above it’s competitors to be dominant in their chosen markets<br />
through the power of true seamless process support.
20 | Key Integration Issues in Building a Strategic OSS Platform<br />
About <strong>Tata</strong> <strong>Consultancy</strong> <strong>Services</strong> (TCS)<br />
<strong>Tata</strong> <strong>Consultancy</strong> <strong>Services</strong> is an IT services, business solutions and outsourcing organisation that<br />
delivers real results to global businesses, ensuring a level of certainty no other firm can match.<br />
TCS offers a consulting-led, integrated portfolio of IT and IT-enabled services delivered through<br />
its unique Global Network Delivery Model TM , recognised as the benchmark of excellence in<br />
software development.<br />
A part of the <strong>Tata</strong> Group, India’s largest industrial conglomerate, TCS has over 94,000 of the<br />
world's best trained IT consultants in 47 countries. The company generated consolidated<br />
revenues of US $4.3 billion for fiscal year ended 31 March 2007 and is listed on the National<br />
Stock Exchange and Bombay Stock Exchange in India.<br />
For more information, visit us at www.tcs.com<br />
About Clarity<br />
Clarity is the telecommunication industry’s Operational Support System (OSS) business process<br />
automation company – providing a pre-integrated product and database that streamlines the 17<br />
eTOM elements of OSS into a single suite. This also allows Clarity to provide executive visibility<br />
of the network's impact on revenue and customer experience across both service fulfillment and<br />
assurance.<br />
Having simplified the management of both legacy and next-generation network environments,<br />
Clarity OSS is network and services neutral, driven by templates that are rapidly configurable to<br />
allow operators to cut time to market for any new service by two-thirds. Today Clarity<br />
simplifies network support for over 90 million subscribers worldwide.<br />
Established in 1993, Clarity’s global headquarter is in Sydney, Australia, with offices in Asia, the<br />
Middle East, Europe and North America<br />
For more information, please visit us at www.clarity.com<br />
CLARITY INTERNATIONAL LIMITED<br />
LEVEL 41 NORTH POINT TOWER<br />
100 MILLER STREET<br />
NORTH SYDNEY NSW 2060<br />
AUSTRALIA<br />
TEL: +61 2 9925 5000<br />
FAX: +61 2 9955 9999<br />
. .