Like the various nations around the world, the many different systems that co-exist within the service provider infrastructure have their own languages, rules and laws. As a result, it is virtually impossible for a telco to go with one vendor to establish an integrated, end-to-end solution. Vendors are addressing this issue through the concept of middleware, which translates and converts data into a format the varied systems can understand, and routes or brokers information to the appropriate system or application.
When integrating operational support systems (OSS), telcos have typically used the pair-wise or point to point approach, building a direct connection from one system or application to another, says Deborah Strong, principal for BusinessEdge Solutions. However, drawing straight lines between components can become messy to build and maintain.
Confronted with frequent changes within the business environment - whether from the addition of new system components or from mergers and acquisitions - some telcos are now opting for the “hub and spoke model.” Commercial Enterprise Commerce Applications (EAI) tools can help integrate disparate systems and applications. These tools also understand dynamic changes to data and information within an application, which allows translation to recognizable formats.
Not an Easy Task
Carriers are faced with numerous obstacles when implementing middleware. Harry Tse, vice president of Enterprise Commerce Applications for The Yankee Group, compares the challenge to “retrofitting the foundation after already building a house.”
As a result, only a handful of carriers have thus far signed up for the major commitment of a middleware installation, says Tse. Of those working on the concept, only a handful have it in place. Eric Nelson, vice president of Network Technology Solutions for ACSI Network Technology, a subsidiary of e.spire, states that many telcos are trying to cover the entire OSS spectrum with as few packages as possible to limit connectors to the hub.
To optimize the middleware strategy, carrier’s internal business rules should define event and object interaction to direct events to the appropriate objects, providing a common base for communication across the OSS infrastructure. Determined by the customer's business processes and each system's data format requirements, performing data mapping between systems and identifying "meeting points" are major challenges. Furthermore, system performance could be compromised if redundant or unnecessary data are not purged.
It is difficult to get an enterprise view of the data architecture and how the process works. Some companies send all orders through an order management system that feeds the billing system downstream; others allow the billing system to get the order first and feed data into other systems. Still others build a customer care front end that changes everything up front, relaying data to the billing and order management systems. The events and how they are driven will depend on the process chosen by a carrier.
As a start-up telco with an aggressive business plan strategy, Level3 is using EAI packages from Active Software and Vitria Technology, Inc. The challenge has been in figuring out business processes, which are less concrete for a start-up carrier, as well as trying to hit moving targets, says Michael Dalke, senior architect for Customer Support Solutions. For example, Level3 is currently writing integration from its order entry/order management system in the United Kingdom to its customer support system in the United States. But because the U.K. OEOM is not live yet, any changes to the business models and processes require reaction from an integration standpoint, says Dalke. Both systems have to go live at the same time to keep integration static, but this means trying to recover from last-minute changes.
In addition, each of Level3’s COTS applications comes with own data model, so integrating billing and order entry applications from different vendors causes difficulty, says Terri Cooper, director of Revenue Systems for Level3. “This is particularly painful at the pricing level since the sales application has a far different view of pricing than the billing application,” she says. “Using some of the EAI tools has made this easier, but bridging the gap has been and will continue to be one of biggest challenges.”
Role of EAI
A recent report from International Data Corporation (IDC) forecasts middleware revenue worldwide will reach $7 billion by 2002. The Yankee Group predicts the market for EAI products and services will increase 45% per year, reaching $5 billion by 2001. And both Forrester Research Inc. and The Gartner Group estimate that at least one-third of organizations’ IT budgets is spent on application integration projects.
According to Eric Brown, Senior Analyst at Forrester Research Group, middleware is becoming a commodity, and it is important to have a platform that spans multiple businesses and components – a workflow to coordinate across the Internet. The trend and important differentiator for telcos evaluating middleware strategies is to focus more on process integration and workflow engine and tools, and less on EAI, he says.
While an EAI framework allows mapping and translation from one data transport medium to another, as well as communications management (load balancing and protocol conversion), currently there are no standards. For example, it is difficult to determine what the billing system needs to know if the ordering systems data model is changing - and it’s equally challenging if the billing system changes its data or data format.
Processes may depend on how a carrier wants to do business in a QoS environment. With new network technologies such as IP, the billing system, as well as the network, need to know pricing information, because network service measures may be different. To complicate things further, the disparate product catalogs for order management, provisioning and customer care systems need to be integrated.
Future environments aside, currently a billing systems product catalog may have a different format then that of a product catalog for an order management or customer care system. “Data that’s been built into an application doesn’t necessarily follow a common format,” says Chris King, director of telecommunications markets for BEA Systems, Inc. “There’s no reason to expect a billing vendor’s customer name field is going to be exactly the same as the order entry customer name. If one stores (the name) as 32-character field and the other stores as 30 character alpha-numeric field, you have to somehow make them match up.”
Having EAI in the middle can solve this problem, but some rules need to be written to make processes flow smoothly and direct the data, says Strong. For example, says King, the billing system may require certain fields for a billing record to be open, so it must be determined whether the order entry system is also requiring all those fields to be captured. The rules may be more algorithmic in nature, such as “a customer can only have ‘x’ number of lines,” or there could be certain credit limitations.
API Difficulties
Application Programming Interfaces (APIs) are published interfaces that are used to move data between systems. An effective API strategy will allow for the integration and pre-assembly of attributes, which can facilitate the automation of processes between disparate systems and applications.
EAI tools for building billing connectors are based upon the billing system APIs. Billing vendors are being pressured to deliver commercially available APIs into their applications on order to keep them static. This prevents the EAI tool vendors from constantly rewriting connectors. Billing vendors are taking a proactive approach and making their APIs available to EAI vendors. In addition, they are working directly with provisioning and customer care vendors to provide pair-wise interfaces between their applications. While this second approach provides a good short-term solution, it does not provide an optimal long-term integration strategy. However, it does help these vendors sell their products by having an interface to automate the exchange of information.
But many API uncertainties exist; there are no models to use as a basis for full production capabilities. Because so many different APIs exist, there have been problems with compatibility and complexity, as well as problems with updating them to ensure all customer information is addressed, says Eric Nelson of ACSI. And while the relationship with the two vendors has been fairly successful overall, Level3 has had situations where APIs on the end systems didn’t work the same way as their user interfaces, causing difficulties with the de-bugging process, Dalke says.
In the case of Level3, Active and Vitria already have a large number of pre-built connectors and has figured out how to communicate with its vendor partners, Kenan and Clarify. Level3 is writing Java code to its APIs, with the APIs taking care of communications with the end systems, says Dalke.
The main difficulty with APIs is making sure there is true interoperability across systems, says Bob Shelton, director of software customization and integration services for Lightbridge, Inc. Even with some of the new, more popular APIs, he says, companies need to clarify which implementation they are using, which often requires going to the next level of detail. Although companies may have standardized a popular API, they still need to make sure they are using the correct “flavor,” or data won’t match up correctly, he adds.
Standards: Who’s Providing the next Silver Bullet?
An emerging standard for interaction between enterprise and applications, Extensible Markup Language (XML) has been touted as a way to simplify some of the low-level communication aspects of integration, speeding interchange between disparate internal databases. Integration software that provides support for message definition standards such as XML allows companies to focus more energy on high-value EAI activities, such as business process automation, and spend less time on lower-value tasks.
Malcolm Lewis of Vitria forecasts that XML will become the standard language for packaged application vendors over the next two to three years. One XML connector can be used for different billing systems, and if the EAI supports XML, a connector is not even necessary, he says.
But Zach Urlocker of Active sees XML is more of an enabler than a driver, allowing companies to have some degree of standardization in the formatting between systems. There are still many other aspects to integration, but XML does allow some level of communication, he says. XML is just one of the new message standards coming to the table to tie together different integration technologies, agrees Bob Shelton of Lightbridge.
However, since the concept of incorporating XML with integration is still rather new, few XML applications have been shipped and content definition agreement within the industry still needs to be ironed out. Legacy systems must be replaced by XML-enabled data controls, or filtered to provide a solid XML interface.
Java also serves to enhance middleware, having grown from its beginnings as a programming language to a middleware infrastructure. Server-side components and system-level services are now gaining attention. According to Chris King of BEA, although there are no real “e-telcos” yet, middleware provides the foundation for this to happen, because an Internet application can’t be built without a Web application server of some form. King adds that carriers are moving toward enterprise Java beans as the core behind any work in this area, which serves as a standard, productive way of building these types of applications, allowing them to quickly build and modify applications as their needs change.
For any billing system doing its typical job (collecting usage data, rating, pricing and printing bills), a data request mechanism is necessary for e-commerce activities, which requires information to be manipulated and put into a format that is acceptable to other systems. In addition, a business-processing engine is required to ensure workflow and the business processes employed.
These components, along with the middleware transport layer, allow information to be routed to the appropriate destination, which in most cases is the Internet server. The Web application server then manipulates the data into an end user format. Because carriers are trying to create different workable fields based on specific customers and actions, BEA’s WebLogic server allows for a variety of presentment, enabling customers to query the system to get billing data and/or pay bills, says King. BEA is currently working with 25 to 30 carriers of all sizes to provide an e-commerce front end to their billing packages.
Risks and Cautionary Measures
As an emerging concept and an as-yet-to-be-substantiated technology, middleware has its risks. The newness of the EAI space is what prompted Level3 to go with both Active and Vitria as its EAI vendors. “We didn’t want to put all our eggs in one basket,” says Dalke. Using multiple vendors requires different tool sets to learn. Level3 still has separate teams to communicate with each vendor. The biggest downside, says Dalke, is “the lack of ability to transfer skill sets directly. However, I would do it all over again knowing what I know now.”
To protect itself, Level3 is building its own enterprise database to sit in the middle, with application independence as the end goal. Because the company could not find any hub and spoke models to meet its needs, it created its own. “The (EAI) tools have done a pretty good job in figuring out the plumbing end of it, making sure events get to the places they are going and guaranteeing delivery and load balancing,” Dalke says. “From an architecture standpoint, they have taken care of these pieces so that we can focus on business process and rules, making sure we get the right integrations.”
Level 3 feels both Active and Vitria have decent failover and load-balancing capabilities, says Dalke. However, he admits that Level3 is not where it needs to be yet, but the company working toward a hot back up. Their plans for disaster recovery are for an off-site, hot site backup, but the details haven’t been worked out.
Middleware: What’s out there?
There are no complete commercial middleware packages within the telecom industry in production. Instead, vendors are offering a framework that facilitates application integration.
Active Software, Inc. based in Santa Clara, Calif., provides integration software via its ActiveWorks Integration System, which the company describes as a flexible, scalable and secure open platform. In addition to the classic hub and spoke model, Active also utilizes a multi-broker architecture, which is similar to the traditional telephone system in a large city, with numerous switches connecting to other switches to route calls. This enables carriers to connect multiple hubs and spokes together seamlessly without worrying about how routing is handled. Carriers also can add more brokers as needed to achieve overall throughput, says Zack Urlocker, Active’s vice president of marketing.
Based in Sunnyvale, Calif., Vitria Technology, Inc. offers BusinessWare, eBusiness infrastructure software designed to enable companies to conduct business electronically across corporate networks and over the Internet. Its capabilities connect to heterogeneous billing systems, with data sharing and translation using the messaging backbone (the hub and spoke message broker), says Director of Marketing Malcolm Lewis. “It is not just data movement, but a process-centric approach,” he adds. “The process automation capability sits on top of the plumbing.”
For example, if a telco acquires another company with different systems and still wants to have consolidated bills, Vitria can provide the core application layer, integrating the various components (local, long distance, wireless, etc.) that are dissimilar between the platforms, says Lewis. The telco can graphically model the business process step by step, using the EAI component behind the scenes as a blueprint to drive the flow of data, linking each step in the process between the different systems. Because of its process-automation capability, the company tends to work with larger carriers to solve bigger problems, such as determining how to streamline and automate typical business processes like real-time billing.
Located in Cambridge, Mass., InConcert, Inc. offers workflow-based solutions to help companies automate and manage business processes. The company’s telecom workflow manager product, Teoss 2000, manages tasks among different workloads and different systems, working in tandem with middleware components from EAI companies. Its role is to function as a process piece, working with the core, scalable middleware medium to migrate messages from one application to another. According to President and CEO Jeremy Davis, the company has written APIs to more than 500 different systems, and is always writing new ones in conjunction with its customers and their systems.
Lightbridge, Inc. also provides integrated workflow and transaction management processes for carrier business operations. Based in Burlington, Mass., Lightbridge’s Telesto network integrates workflow-enabled middleware with back-end systems, focusing on the provision of services from business distribution channels. With service providers, transactions require the transfer of not only the same information, but also different information between different systems, says Shelton. Telesto’s message-oriented middleware is designed for customer acquisition, retention and risk management in the converged telecom market.
A provider of middleware for enterprise applications, BEA Systems, Inc. is based in San Jose. With a main focus on middleware, its Tuxedo product is already incorporated within many of the major telco billing systems, including Amdocs and Convergys. BEA recently introduced eLink, an adapter product that bundles a variety of different middleware components. Included is a transaction module that provides the ability to transfer data between systems, a data mapping product that allows different data sources to converse via a single language, and a workflow component from InConcert that determines the processing order for the entire application suite from order entry to billing. Providing services behind the scenes, eLink enables carrier system components to talk to each other and determine the processes necessary to move information through the organization using disparate systems.
CrossWorlds Software, Inc., based in Burlingame, Calif., began its enterprise integration strategy by looking at packaged integration among different applications, says product manager Dushyant Pandya. “We want to make sure what we sell at the end of the day is an integration application, not tools,” he says. CrossWorlds provides a pre-built and pre-tested platform for integration based on the hub and spoke model, and carriers buy customer care, billing and order management applications of their choice. In addition, the company has packaged integration solutions for a few vendors in each area that is generic enough for end-customers, but can then be customized to fit specific needs, says Pandya. Because CrossWorlds uses its partner’s APIs, the company must stay current with what they are using and make the necessary updates whenever new APIs are added.
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article