TOPICS

• Home
• Online press
• Case studies
• White papers
• Features
• Interviews
• Register
• Industry newsletters
• Directory
• Events
• Contact us

Home > Features > DATA MANAGEMENT/COMMON LANGUAGE - Singing from the same song-sheet

02 April, 2008 10:45  

DATA MANAGEMENT/COMMON LANGUAGE - Singing from the same song-sheet

What's in a name and why the need for a Common Language? Well, the difference between profit and loss, for a start,  says Allen Seidman

The educated layman might wonder what semantics - essentially the study of the meaning of words - has to do with our industry's business of moving speech, content and data around the world in ever faster and cheaper ways.

The answer lies in the fact that unless we can employ standardised methods to define and describe the many components, attributes and functions that make up the world's networks, then we'll be left floundering in an unmanageable sea of proprietary definitions and descriptions that will make the Tower of Babel sound simple by comparison.
This certainly isn't a new problem in human history. While many creation myths contain a common tale of the first men naming plants and animals, neither the physical nor life sciences would have progressed without standardised systems of measurement or nomenclature. Given that the future success of our industry relies on combining ever-larger numbers of devices, servers and network elements into a single functional entity, the need for a rational common language that can describe all these assets in consistent and meaningful ways is essential, not optional.

This issue however isn't just of concern to those focused on the back office or on engineering operations. Without the ability to clearly define and communicate about   equipment, network connections, locations and services, we'll be completely unable to implement the wider shared ‘Information Infrastructure' concepts that cross-boundary services based on Web 2.0.rely on. How can different applications, content and network owners share information and hardware assets to create meshed and merged services without common ways of defining and communicating about those assets? Or even know which geographies they reside in? Integration costs even within a single company can be an onerous overhead and the absence of standard terms makes inter-company cooperation even more complex and time wasting.

Service providers have certainly already spent many hundreds of millions of dollars over the last decade on trying to rationalise their network inventory systems and find better ways of extracting the maximum value from their fixed assets. Anecdotal evidence suggests that some operators had, in the past, even managed to ‘mislay' significant chunks of their physical networks through poor record keeping, incompatible data formats and the departure or retirement of experienced engineers. Additional surveys from organisations like the Yankee Group show that ‘dirty' and inaccurate data will collectively cost US and European operators a total of $6.3 billion each year by 2010, with knock-on effects that impact heavily on provisioning, fault finding and network engineering. All too often, expensive human resources are wasted trying to resolve problems caused by misleading data records.
Significant too in this drive for a clearer understanding of the cost/performance issues of the infrastructure itself have been the various TMF initiatives such as the enhanced Telecommunications Map (eTOM) and the Structured Data/Information (SID) model. Although also heavily focused on the semantics of our industry, these have increasingly been adopted by both service providers and vendors to solve real world problems and remove unnecessary costs from both business relationships and operations engineering.   While extremely valuable, these approaches only go part of the way to solving the overall problem and are insufficiently granular in depth and detail to drill down to the kinds of elemental component details that are really required. Ultimately, poor network equipment information impacts in numerous ways across almost every aspect of service providers' operations  - and on their relationships with their vendors, customers and partners.

But how exactly does - or should - a common language for describing components work in the telecoms industry? Can we quantify the benefits to service of using a standardised naming system for the multiplicity of different elements - inevitably from different manufacturers with inevitably different naming conventions - that have to be combined to create a network and deliver a service?

Consider one of the most basic, bottom-up building blocks of any communications infrastructure - the humble plug-in card or blade. Each will inevitably have multiple markings such as part numbers, revision numbers, com codes and stencilling - but might not even carry the name of the actual manufacturer or vendor. To add to the potential for confusion and hassle, most boards have to be removed from their racks before their provenance can be properly identified with all the add-on impact that has on interrupted services.
Even where a local ‘asset tag' is created by an individual service provider, in an attempt to standardise their own inventory management systems, these often result in multiple representations of the same device type, adding still further to the overall confusion and waste. If service providers are unable to correctly identify equipment, then they leave themselves open to confusion about their available inventory, their assets can become effectively ‘stranded' and they will often have to invoke costly data synchronisation, reconciliation and stocktaking measures to resolve these problems.

That's a concept that extends not just to the equipment or its location, but also how it is connected to other equipment, what the significance or ‘context' of that connection is, and what might happen to it if there's a requirement to swap out equipment at either end. Clearly, if we take into consideration equipment, its location and the connections between them, then we're talking about the need for an entire Information Infrastructure I mentioned earlier. And that's far-reaching stuff, especially when you take into account that analyst firms such as Stratecast are already referring to Information Infrastructure as ‘the next OSS' battleground.

For example, Arun Dharbal, SVP Communications Industry Solutions, SAP, has said to me that SAP continues to see and enable an increased focus on the management of information across the enterprise. Its Master Data Management solution embraces this trend with the capability to synchronize, and unlock the value of information across a spectrum of systems and data management areas transcending product, customer, asset and service domain.
However, the wider Information Infrastructure issue can also manifest itself in the naming problem I mentioned earlier, impacting heavily on the vendor community. Although many service providers use the proprietary naming conventions of each of their vendors, this approach creates its own kinds of confusion. Because manufacturers have their own multiple drivers for identifying equipment - such as tracking manufacturing changes, marketing, ordering and so on - there is very rarely a strict one-to-one relationship enforced between equipment type and part number. For example, suppliers might use different multiple part numbers for a single equipment type sold across different geographical markets. Conversely, multiple equipment types can be represented by the same part number and revision codes - so making it impossible to rely on vendor-supplied part numbers and revisions to uniquely identify the equipment types both within and between suppliers.

There is huge variation amongst vendors in how they record their own equipment. As a result, there are no clear guidelines on how information revision and interchangeability should be interpreted. The greatly differing formats also make it impossible to create a normalised equipment identification mechanism that is based solely on a vendor-assigned part number and/or revision codes. This concept of a normalised equipment identifier is central to any sensible model for equipment tracking as it ensures that different equipment types can be tracked with easy interchangeability when there are equipment revisions.
Adding to this complexity is the issue of how equipment information is actually managed and distributed by the vendors. Numerous non-standardised formats are inevitably used, with important documents stored in Microsoft Word and Adobe PDF formats, distributed on CDs and hard copy paper manuals or distributed through web links. With each supplier providing different sets of attributes and attribute values, it becomes difficult to model the information with any sense of consistency and this often involves complex mapping algorithms.
For an industry that's betting its future on making the move towards introducing ‘just-in-time' service creation and provisioning principles, many service providers are still stuck managing their inventories with very 20th century technologies. While we might have a range of different tools available to us now to help data capture and warehouse management - such as linear bar code labels, standard 2-D symbology labels, RFID tags and autodiscovery - these will only work efficiently if they are supported by standardised equipment information formats.

Although some good work has been done in this area already by various industry bodies, the actual implementation of these has to be carried out by the individual service providers, network owners and vendors. It's here that the realities on the ground often interfere with good intentions from above, resulting in multiple standards-based proprietary identification mechanisms with heterogeneous part number and revision variances.
On top of this, both vendors and operators also often end up wasting valuable time and energy by forming cross-business teams of engineers and procurement staff in attempts to create internal naming and identifier conventions. With each service provider or vendor around the world attempting to deal with this complexity in their own way, the management overheads involved place a very heavy burden on an industry already trying to streamline its operations as much as possible.

Tony Gladden, Director of Products and Technology at SITACORP has told me that data problems aren't new, but as the global marketplace demands more and more automation across corporate boundaries, data issues become more transparent and manifest themselves in exception processing creating higher costs and lost revenue in areas like invoice reconciliation, order fulfillment, shipping and receiving. So, clearly, this is an issue that lies at the heart of operators' ability to make progress.

To resolve these problems, Telcordia developed its Common Language® Information Services initiative which has grown in recent years to become the industry's default centralised information registry and clearinghouse, capable of providing the structure, format, unique and meaningful identifiers, syntax and common language registries that are needed to reduce operational and capital expenses. With nearly 100 service providers and 1,000 equipment vendors now using Common Language, hard evidence exists that shows some service providers now being able to reduce their master data administration and maintenance costs by as much as 90 per cent for equipment, location, connections and service master data. Significant savings are also made in supporting areas such as spares inventories, systems integration and network utilisation.

These benefits extend beyond global operators to the firms that they serve. SAP ‘s Arun Dharbal says that enterprises are keen to exploit synergies between organisations. In fact, SAP's work with key industry solutions such as Common Language allows its customers the ability to get a single view of their assets across the corporation. Ultimately, this challenge needs to be addressed on a broader basis than just the individual enterprise - the industry needs to adopt a strategy to manage information across corporate boundaries as the information processes of each operator is intertwined with a broader ecosystem of trading partners and equipment vendors.

Although we are all at the beginning of solving the Information Infrastructure issue, and it's size dictates that a Common Language won't be implemented overnight, there are operators and enterprises that are making rapid progress. Daniele Fracasso, Common Language Director at Telecom Italia, for example, says that Common Language has helped Telecom Italia to have up to 95 per cent flow-through as part of its operations, reducing its cost of systems integration.

Colin Orviss, Senior VP at Patni Telecoms Consulting, emphasises the benefits to the entire industry - operators, systems integrators and vendors - of Common Language. He says that it takes standards to a whole new level by providing a unique global implementation that no individual systems integrator or internal IT department can achieve. And that's pretty powerful.

The last couple of decades have seen an explosion in the complexity of an already complex industry. What was once a largely closed community of national operators and vendors now includes members from the broadcasting, IT and consumer electronics sectors - each with their own specific ways of identifying and managing component equipments. If the industry ‘previously known' as telecoms doesn't look to put its house in order soon, a lot of the power of new technologies and business strategies will remain mired in the complexities of managing increasingly heterogeneous networks and systems, creating its own internal Tower of Babel that does little for its customers' own needs to communicate.

Allen Seidman is Vice President, Business Development and Marketing, Telcordia, and can be contacted via: aseidman@telcordia.com

Comment on this article

Printed from http://www.eurocomms.com/features/112188/DATA_MANAGEMENT%252FCOMMON_LANGUAGE_-_Singing_from_the_same_song-sheet.html