The Interoperability Gridiron: New Integration Technologies Tackle Old OSS Problems

Interoperability is hard to find, but it's in demand. Though operations support system (OSS) vendors will trumpet phrases like "plug and play" and "telco in a box," these marketing terms are little more than spin doctor sorcery. New systems or applications are never just "dropped in." Resulting integration projects can be extremely costly, time consuming and prone to failure. It's generally agreed, however, that a seamless back-office network that ultimately provides a company with operational flexibility and adaptability, along with the ability to roll out new services rapidly, has become a prerequisite to success in most industries. For the telecommunications industry, a single technology or approach has yet to emerge as the standard for building a modular, scalable, adaptable back office.

Several approaches to interoperability have been taken with varying degrees of success. For example, Telecommunications Management Network (TMN) standards were developed to create industry consensus for application interface design and network management protocols. Today, true TMN implementations are hard to find in practice, but the guidelines have provided the industry with a common way to discuss and conceptualize applications and back-office networks. Transaction processing and message-oriented middleware also have been applied to integration projects, but these technologies seem to be interim fixes at best.

One way or another, a carrier must choose a core technology that, if nothing else, can help minimize integration costs and provide a uniform approach to OSS management. Between shrinking margins and precious venture capital, however, carriers "are looking for as much functionality with as much flexibility provided out of the box as possible," says Peter Gibson, executive vice president of communications and utilities industries at DMR Consulting Group. The challenge is picking the right technology, much of which is relatively new and unproven from a telecom industry perspective.

Companies like Microsoft and ObjectSwitch have taken object approaches based on different object request broker (ORB) technologies, one using the Component Object Model (COM), the other the Common Object Request Broker Architecture(CORBA). On the other hand, companies like Linguateq, a growing, start-up technology shop, have focused on creating interoperability between different interface types and data formats with home-grown, patented data conversion technology. While acquisitions continue, new carriers build out their networks, and established carriers work to get their operations in order, Gibson says, "they've got to have [systems] that are quickly installable and can integrate [easily] because they don't have the patience nor can they afford a long turn up for new OSSs."

Microsoft, Active OSS, and COM

Microsoft made an aggressive entrance into the OSS space in June with the release of its Active OSS product suite. The company maintains that current OSS technologies can't keep up with requirements to support new network services, self-provisioning capabilities and direct access to service level agreement monitoring systems. As a result, Microsoft says, carriers are "looking to commercial information technologies" for improved integration, adaptability and price/performance. In response to this perceived demand, Active OSS is based on Microsoft's Windows DNA architecture, NT server technology and COM, systems Microsoft has been marketing outside of telecom for some time. The overall architecture of the product also incorporates NMF's SMART TMN business process model and related work by TINA-C.

At the heart of Active OSS is a Microsoft Transaction Server running COM, or D-COM as it is also known (the D for distributed). Basically, COM is an integration infrastructure designed to facilitate communication between software components operating on the same host, or with D-COM, on multiple networked hosts. COM was originally developed to create interoperability between components, potentially within the same application, running on Windows 3.1. COM thus was not originally developed for enterprise integration and is sometimes criticized as being an overly complex, fragile technology that has succeeded more because of Microsoft's desktop and operating systems dominance than because of the technology's own merits. At the same time, COM is arguably the most widely deployed component object model in the world, depending on how one looks at it, with a broad base of development tools and vendor support.

Essentially, Active OSS, using COM and Microsoft's Data Translation Services technology, acts as a centralized management and translation point for an OSS network. Conceptually, applications ride on top of the framework, but communicate through it. COM abstracts various application interfaces into objects, basically mapping the functions of the application into a common model that can be stored in a database. A common model allows the various applications to communicate in a uniform manner within the Active OSS platform or across multiple, networked platforms. By abstracting interfaces into software objects, applications theoretically can be upgraded and/or changed without affecting surrounding systems because integration is based upon independent software components that communicate, not applications that are heavily modified to fit together one-to-one. In this sense, changing or upgrading an application generally means mapping a new interface into the framework, or modifying an existing one, with tools that are provided with the system. The framework only needs to work with the interface, it doesn't need to affect the guts of an application. The platform also provides fundamental application services, such as security and data persistence, which can be managed from a central point. Interfaces and application services tend to be buried in application source code and differ from vendor to vendor. Inconsistency among vendors can make application management difficult because each application's characteristics and behavior are unique. In addition, integration is tricky, dangerous and expensive any time source code must be manipulated. The framework is intended to create uniformity among application services without any modifications to source code. Application services are built into and managed by the framework.

One of Microsoft's main focus areas is provisioning, which--as opposed to ordering--DMR's Gibson explains, is "the challenge, so that financials aren't adversely impacted because [a carrier] can't turn-up customers fast enough." Microsoft appears to be leveraging its broad base of Internet technologies to dominate, ultimately, the customer self-service space. "We're making sure that the applications we develop for the telecom market have process pipelines such that a carrier can put in place methods of provisioning a service very quickly and efficiently," says Jonathan Usher, telecom marketing manager for Microsoft. Deloitte Consulting has adopted the Active OSS Framework to support its own OSS initiative, called OSS Transformation, which focuses on web-based self-service and wholesale ordering applications.

ObjectSwitch and CORBA

ObjectSwitch's base product, also called ObjectSwitch, is conceptually similar to the Active OSS Framework, but uses different technology and is marketed from a different angle. As opposed to COM, ObjectSwitch uses CORBA for its component integration technology. CORBA has been evolving steadily since the late `80s. Developed by the Object Management Group (OMG), a consortium of more than 800 technology companies, CORBA was designed to manage and integrate distributed systems.

CORBA has matured more slowly than has COM, following a more traditional standards process, and has perhaps lost some early market share as a result. CORBA is becoming widely accepted in many industries, however, and Microsoft, which generally looks to control technologies, especially those that tie into its operating systems, has even announced an interoperability initiative for CORBA support in COM.

Because CORBA has been developed by a wide range of companies, some of the specifications have been left open, which has led to several versions of CORBA, offered by a number of vendors, that may not be entirely interoperable. Because the technology was designed specifically for distributed computing, however, it is implemented more than COM for enterprise integration.

CORBA not only supports more languages than COM (in other words, common mappings between CORBA's Interface Definition Language and C, C++, Smalltalk, Ada95, Visual Basic, Cobol and others) but it is reportedly supported on more Microsoft platforms than COM, including Windows 3.1, Windows 95, Windows NT 3.5, Windows NT 4.0, and DOS. ObjectSwitch follows the CORBA 2.0 specification and the company asserts that it will stay current with all future OMG releases, including new Unified Modeling Language (UML) guidelines. UML is a language for specifying, visualizing, constructing, and documenting application development and non-software business process models.

ObjectSwitch's approach is to try and change the way telecom providers look at and architect their systems. As Doug Ehrenreich, vice president of marketing, explains, "the more traditional companies that are building applications for a carrier are looking at the application requirements and the user requirements at a certain point in time. Typically they have to make trade-offs and implement their business processes with the technology [already in place]." He argues that with a product like ObjectSwitch, business processes and application services are uniformly defined on the platform, not buried in application code, and thus become more flexible. In more practical terms, as Ehrenreich explains, a carrier can offer on-line provisioning to a customer, but tie the new application into an existing provisioning process without any disruption to the other applications involved. Once a new interface is established, CORBA handles the integration, thus shielding applications from changes in each other. The established application services and business processes shield the developer from worrying about the implementation details. The developer should be able to focus on the application, while the platform deals with, for example, communication between Oracle and Sybase databases, or conversion of SS7 TCAP messages into readable data for a service management application.

One of the big differences between ObjectSwitch and Active OSS is that while Active OSS is definitely intended as an application platform, ObjectSwitch is broader. ObjectSwitch was designed not only as an application platform, but as what can be called an "intelligent mediation" system. In other words, ObjectSwitch also could be used as an OSS gateway or a data collection and conversion, or billing mediation, system.

Active OSS is more focused on customer facing systems--but keep Microsoft's motives in mind. With this offering, the software giant is marketing Windows NT Server, Windows DNA, Microsoft TPS, the Commercial Internet System and other base products. The company still is trying to drive acceptance of NT as a telecom quality system. It also is developing a version of COM, currently running on NT Server, for Unix platforms.

Problems With Object Approaches and Interface Mapping

Object technology has gained broad acceptance in many industries and seems to be the way of the future, but the telecom industry isn't convinced just yet. Object technology still is considered new and unproven and there aren't many examples of high-volume, ultra-reliable telecom systems based on objects. In the context of OSS platforms and component technologies, the issue at hand involves a major infrastructure and architectural shift.

Moving to a platform like Active OSS or ObjectSwitch means committing to an object environment as the basis for operations. This is a good idea if objects become common or standard in telecom environments. An object-based platform that can keep a carrier systems environment open will provide technical flexibility and potentially improve both software development time and time to market for new services.

Objects also can be a limiting factor. Depending on future technological developments, objects could be proven unsuitable for high volume, reliable, complex systems. So far, object technology has been most successful for specialty projects managed by highly experienced developers. A telecommunications environment will ask object technologies to do things they've never done before. Even if a carrier chooses to go the object route, there's a decision to make as to which ORB to select: CORBA or COM. Currently, virtual religious wars are being fought over which technology is better, and/or how they can co-exist.

The interface enigma

Another question that must come to mind with systems like ObjectSwitch and Active OSS is about interfaces. Both CORBA and COM are designed to map specific languages to their own code structure, but plenty of odd, proprietary languages and versions of languages run in carrier operating environments. If one asks the vendors, they'll say it's a simple matter of mapping in a new interface and it's no problem. This is an area that warrants extreme caution. The vendors can say what they will, but the fact is they haven't done this work yet so they can't truly know what is involved or the problems that might arise. Working with a new, C++ based application should be simple. Dealing with a 20-year-old CABS or TIRKS system, for example, is likely to raise some challenges. Many proprietary telecom data formats are extremely complex and relatively unique, so simple mapping is not really possible. As Tim Clifford, vice president of engineering at Linguateq, points out, converting 50-byte network status messages coming from network elements is relatively simple. Managing data exchange between, for example, a billing system and a financial auditing package is far more complex, with detailed files often measured in megabytes.

Linguateq's Interface Management System

Linguateq takes an entirely different approach to systems integration. Rather than pushing a core technology, Linguateq's approach is to be as transparent as possible to the overall systems infrastructure. Its product, the Interface Management System (IMS), maps data records from source to destination formats as required by the applications involved. In the process of this mapping or conversion, the system takes data and maps it to Linguateq's universal data model and then reformats it for delivery.

This intermediate step is intended to bring several advantages. First, the process provides a uniform method of interface management. "You're dealing with all of the interfaces exactly the same way. It's not CORBA over here and some middleware product over there and some third party black box. Our system is sort of the common glue around all of those different components," says Clifford. Second, mapping between the Linguateq model and a specific interface type can be reused in other implementations. Third, the intermediate step can provide insulation for applications. In other words, if the application on one side of the interface is replaced, the new system being installed is mapped into the IMS, but existing applications and interfaces on the same platform are unaffected by the change because they only communicate with the IMS. They aren't dependent on the specific characteristics of the new application or interface.

Conceptually, these functions aren't all that different from what ObjectSwitch or Active OSS perform. Clifford notes the major difference is that IMS only deals with interfaces and data. Moving to the IMS to some extent commits the user to Linguateq's interface management methodology, but it doesn't commit them to any specific core technology like CORBA or COM. He also says, however, that IMS doesn't necessarily replace or compete with something like ObjectSwitch or Active OSS. "You can take that technology and apply it to those elements where it's mature, proven and it works," he says. At the same time, IMS can create interfaces between a growing object environment and business critical legacy systems that it's best not to disturb.

Clifford admits that IMS is a young product still being developed. So far, Linguateq has found a niche mainly in interfacing billing systems to other financial packages that involve highly complex data formats. The company looks to move this technology into other areas of OSS. Aside from billing formats like EDI 811 and CABS, IMS has worked with provisioning systems, some wireless management systems, and Cisco TACACS. Linguateq is just beginning to build up its ready-made interface portfolio and is looking possibly to partner with other vendors that can utilize its core translation technology. When asked if Linguateq planned to move this product toward something like a message queuing server or transaction processor Clifford says, "There's certainly a message flow engine that picks up messages, knows where to pass them and how to have them translated. We're more focused on taking any generic type of information being written out by one system and modifying it into a format that can be read by another. That general problem, we're finding, is really challenging."

Some Facts About Objects

Because telecommunications systems are so complex and require the highest levels of reliability, it's difficult to accept technology examples from other industries. Even if all of Wall Street was running on a CORBA architecture, for example, it still probably wouldn't be a strong enough case. A recent report by Cutter Information Corporation (Arlington, Mass.) outlines some of the uses and results of objects in corporate environments.

( Most companies that have adopted object technologies have done so to increase software development productivity and reuse, but find it takes at least three to five years time to change software development practices and create a real object-oriented infrastructure. About 75 percent of companies surveyed reported at least one noteworthy success with object technology at a departmental level.

( Most adopters have had to make major investments either in consultants or staff training to build a core of skilled object developers. Such people are in great demand, difficult to find and more difficult to keep. Further, many organizations have experienced at least one failure in trying to implement object-oriented applications, the cause of which was most often lack of experience on the part of the developers. ( Microsoft is the largest source of object classes with its Microsoft C++ Foundation Classes, but CORBA is the preferred ORB with DCOM at about half the implementations. The UML notation system is rapidly becoming the de facto standard for object notation.

( Object databases are lagging in acceptance behind other object technologies. Most companies store object data in relational databases.