EAI developers acquired scores of customers with promises of out-of-the-box functionality. Now, they are sidestepping criticism for overselling their products and looking for ways to increase their business value.
Having invested heavily in enterprise application integration (EAI) over the last few years, carriers are impatient to achieve the efficiencies they were promised. Large-scale projects surrounding provisioning, network activation, flow-through activation and catalog access have either failed, been somewhat successful or loitered so long in the deployment stage that no one is clear how to rate their success.
Carriers are losing faith in the software and are frustrated by unexpected custom development work and cost overruns.
The EAI providers are partially to blame for the backlash. Their sales and marketing teams pledged out-of-the-box performance that is only now beginning to appear with the onset of extensive adapter libraries-a collection of adapters, or connectors, that aid connectivity by providing services such as handling events, notifications, and transaction and delivery mechanisms.
"EAI providers guaranteed point-and-click, out-of-the-box functionality and minimal implementation efforts," says Renee Domhoff, vice president of OSS technologies at Cap Gemini Ernst & Young (CGE&Y). "They have since realized that carrier integration demands are much more stringent."
The carriers should also shoulder some of the blame. System integration within telcos has never been easy, and the community had no reason to believe a magic formula had just been discovered. "Many of the products were presented as silver-bullet solutions, but the fact of the matter is that silver bullets don't exist," says Brian Highfield, EAI program manager at Alltel Information Services. "Integration has always been difficult. EAI tools just make it less difficult."
Much of EAI's additional integration requirements and custom development work surround data mapping, translation and workflow. This development work comprises a wide range of tasks, including developing the data model, process model and the business process workflow; defining a common infrastructure for error-handling, error management and a common information model; and designing the data migration and synchronization.
On the carrier side, these efforts require considerable front-end design work either from in-house staff or, more typically, from a systems integrator. During this phase all data, as well as the systems where the information resides, and every aspect of both, such as the data structures and system translation method, must be defined so that they can be described to the EAI tool. Once all data sets are defined to the EAI software, it can present the disparate data as one set.
"The design phase usually takes much longer than expected, because carriers have a difficult time defining their business processes and technical issues," says Robert Smallwood, senior OSS architect at CGE&Y. "They don't know what they want their workflow to look like."
These initial design efforts, however, don't address the necessary development work that connects the multiple systems. Although all the EAI providers claim extensive adapter libraries to a slew of applications, none of these adapters include inherent system customization. Because every software installation is unique due to mutations and evolutions, the adapters must be modified to reflect the intricacies of the specific environment.
"Robust business processes and business decisions have to be embedded in the code," says Todd Beilis, manager of telecom media networks at CGE&Y. "A toolset doesn't do that work; a developer does."
EAI v. Application Servers
Distinguishing the various players in the EAI space is difficult. Business process management providers, platforms such as Compaq TeMIP, HP's OpenView and Agilent's NETeXPERT, and application servers are all vying to prove their EAI capabilities and take away market share from the EAI players. A relative newcomer, the application servers are offering serious competition. They provide some of the same services as EAI toolsets, but their offerings are usually less robust and need enhancement, according to Domhoff.
At times, though, the distinction between the two products blurs. Both attempt to connect multiple interfaces and inconsistent information, but EAI entails bolting two systems together, whereas application servers help build the new system from the ground up. "EAI approaches integration as a data-to-data transmission," says Avi Hoffer, CEO of Metastorm. "Application servers build an application to read and feed."
Or more simply, application servers offer application development technology, and the EAI players offer application integration technology. In many instances, carriers use both.
BEA Systems' application server, WebLogic, and Tuxedo, its middleware, are regularly found in the financial and government markets, as well as telecommunications. "We see ourselves as a complement to the EAI tools," says Chris King, director of worldwide communications markets at BEA. "The EAI providers have a narrower niche than we do."
EAI vendors Tibco, Vitria, WebMethods and IBM MQSeries view BEA as a partner, not a competitor. CGE&Y's analysis of the integration market, though, may cause them to take a closer look at application servers. In her white paper "Heterogeneous Integration Architectures to support Next Generation OSS," Domhoff writes that application servers, although newer to the market, "may be poised to be the leader within this space shortly."
They are strengthening their integration capabilities by developing framework services and relying on strong development languages such as J2EE. BEA, for example, is a passionate proponent of J2EE. But for current projects, Domhoff recommends that providers first standardize on an existing EAI toolset, which will provide the common framework services of connectivity, delivery services and persistence, message and system monitoring, technical and business process workflow, error handling, and message transformation and translation. Once the EAI toolset is established, then service providers should add an application server to the solution when the architecture is required.
The Contenders
Tibco, an older EAI company that grew out of the middleware world, has gained a formidable reputation from its success with Tier 1 carriers. "Tibco is a sleeping giant," says Metastorm's Hoffer. "It has put a lot of emphasis on connectors, but it has a lot of cash and credibility. Its biggest challenge will be positioning itself against newer, faster growing companies."
Tibco first gained its reputation in the financial services market as a fault-tolerant platform with high availability. CGE&Y's Beilis describes Tibco as a broadcast publish-and-subscribe system with greater throughput in messaging but less capability in process management, which can have implications for the network if not deployed correctly. Of all the EAI players, Beilis says, Tibco has the most robust messaging and data broker tool.
Of its competitors, Tibco is most concerned about IBM MQSeries because of its large installed base, says John Lloyd, director of communications and media industry at Tibco. MQSeries has been used for years within telcos to connect AS/400 and mainframe systems. IBM has added MQSeries Integrator as its EAI tool.
To further beef up its integration offerings, IBM purchased CrossWorlds Software, which had a broad adapter library, increasing out-of-the-box functionality. Other tools, such as MQ Workflow and its application server, WebSphere, provide customers with wide-ranging capabilities.
"MQ Workflow provides process orientation and can automate applications or human intervention requirements," says Vivek Khosla, market segment manager for IBM's MQSeries. "We offer high-speed messaging and queuing for publish-and-subscribe environments."
The MQSeries has taken some heat for its process management. Critics claim that it is not especially robust, but Khosla says that the CrossWorlds technology strengthens its process management.
"CrossWorlds has prebuilt connectors to Siebel, Portal and other applications that are pervasive in the telco market," Khosla says. "Now customers have the flexibility to do process management using CrossWorlds, Workflow or MQ Series Integrator."
While IBM's MQSeries has a strong showing in legacy environments, Vitria made a name for itself within CLECs. The company gained early experience with many off-the-shelf applications, which contributed to its early lead in adapter development.
Vitria, however, wants to emphasize its business value. "We don't want to fight it out at the feature functionality level-we want our benefits to be apparent at the business level," says Conor Keane, vice president of global solutions, communications.
CGE&Y's Beilis credits Vitria with having the most robust process and lots of functionality that can be driven through its Java code. Vitria takes a hit, though, when it comes to its publish-and-subscribe method that queues messages, which requires more overhead and slows the message transfers, Beilis says.
Competitors Tibco and IBM try to characterize Vitria as having success only in limited integration efforts within smaller carriers. "Vitria has simple, highly repeatable solutions for the CLEC market," says Lloyd. "They are integrating no more than three or four applications and standardizing only four or five business processes."
Keane quickly rebuffs these comments, with assertions that Vitria has projects with a long-distance carrier, a large IXC and all the RBOCs. "We have done fairly extensive development for legacy environments and are adding functionality at the process layer," says Keane.
The last company on the EAI list, WebMethods, may be the least recognized. Having established itself in B2B integration, WebMethods is less known for its internal integration. Carriers are using WebMethods to connect to third-party companies, ASPs, equipment manufacturers, partners and suppliers. The company names Cable and Wireless, Bouygues Telecom and France Telecom as customers, and promotes itself for integration work done "beyond the firewall."
"We're moving beyond EAI and middleware, which are early terms that don't define the scope of work we do," says Eddie Amos, vice president of business technology. "We are about total integration-from behind the firewall and across."
In late 2000, WebMethods purchased Active Software to strengthen its EAI offering. Active Software added many internal integration capabilities that WebMethods lacked, but WebMethods has had limited success capitalizing on them.
Adapter Libraries No Longer an Advantage
A couple of years ago, the number of off-the-shelf adapters was a strong selling point for an EAI player. Now all the players have developed adapter libraries, or purchased companies with deep adapter knowledge.
The playing field has been leveled mainly because generic connectors are relatively easy to build and maintain. They don't require extensive coding, especially with the increased use of Java, J2EE and Web Services (see "Will Web Services Transform EAI?"). The difficulty, however, is in keeping up with the new version releases. For CGE&Y, the mainstay OSS packages sometimes cause the biggest integration problems.
"We run into difficulties with packages that were designed to stand alone or not to interface with EAI software," says Domhoff. "We spend a lot of time trying to get around the packaged vendors' APIs. Off-the-shelf packages need to be more accessible and evolve toward an open structure."
Due to these inherent difficulties and the recognition that building adapters is no longer a deal clincher, BEA Systems is pushing its development work to its partners or customers. "We learned from our experience with EarthLink that adapters are a no-win proposition," King says. "Adapters must always be modified for special needs."
To increase efficiencies and focus on core strengths, BEA has created a toolset that allows partners and customers to build and maintain their own adapters. "It didn't make sense for us to develop the adapters when the customers have intimate knowledge of their application," King says. PeopleSoft is already using BEA's toolset.
Not everyone agrees that such an approach will be successful. Susan Bevere, iCelerate's regional sales manager, says that companies don't want to build their own adapter. "It ties up lots of resources and is costly and time-consuming," she says.
Others in the industry still see the adapters as a valuable in-house service. "Part of our business is maintaining and building new adapters. We want to provide quality assurance, and be sure they are the highest quality available," says WebMethods' Amos. "If we have partners or customers that want to build adapters, we will give them a toolkit. But we will always provide adapters for core components." IBM also plans to continue to supplement its library of adapters.
Tibco's Lloyd, however, is hesitant to place too much importance on building adapters. "We've never lost a deal because of adapters," he says. "Customers value other things." However, the company does plan to continue adding to and maintaining its library.
EAI's Next Development Stage
While most EAI providers will continue to support and expand their adapter libraries, they are searching for other means to strengthen their value proposition. The next two years will be especially challenging for the sector, says CGE&Y's Domhoff.
"Pre-built adapters won't play a big part in the Tier 1 providers' legacy environments," she says. "EAI developers will have to look outside their current customer base, think through their strategies, try to prove their capabilities are open architectures and focus more on basic functionalities."
Already, the EAI players are looking to increase their market share internationally. Carriers in the Asia-Pacific region and Latin America are primary targets for the providers. EAI companies are also attempting to widen their reach by broadening their integration focus. Vitria and IBM, known mainly for internal integration, will seek more B2B opportunities. B2B leader WebMethods, conversely, will look for more internal projects.
The players will also need to work harder at proving their worth for total cost of ownership (TCO) and return on investment (ROI). EAI companies are quick to state that error rates can be decreased from 50 percent to 5 percent and then translate those numbers to ROIs that can run into many times the licensing fees.
These numbers, though, don't transfer neatly to another carrier's environment. "The EAI providers could do a better job educating customers about ROI and TCO," says Alltel's Highfield. "Customers need total numbers and hard data about their specific project, not theoretical examples or specifics from a completely different environment."
And of course, the EAI providers will have to keep adding to their adapter libraries to stay up to date with new features and versions. Valaran CTO Michael Ogg states that mixing business logic into the connector code is the main reason it now takes so long to implement new business processes (see "On the EAI Sideline", for more information on Valaran's integration approach.)
"It is extremely important to push all the business logic into rules services for rule flow and remove business logic from the connector, where it quite definitely doesn't belong," he explains. "Connectors are low-level and should be used for session management, protocol specifics, data mapping details, reconnection logic, and so on. They should not contain any business logic that is changeable."
Lloyd adds that the business logic should reside in the business process management or automation tool. "In rare cases where it is unavoidable, the business logic may find its way into the adapter," he says. "In these situations, it should be implemented through configuration rules, not code, or though a 'call out' or exit routing from a standard off-the-shelf adapter."
Keane at Vitria takes the stance that application-specific business logic should reside in the application, and that inter-system business logic-such as sequencing, conditionality, cross-reference checking and updating-should reside in the EAI tool. "Hiding business logic in the connector makes the testing and modification work a nightmare, it prevents the re-use of the business code when the application is replaced, and it hampers performance," he says.
EAI Expectations
Even with the shrinking customer base and the demands that EAI partners and carriers are making on the developers-and in spite of growing criticism-the EAI sector is still expecting growth.
"By examining EAI's cost management and efficiencies, carriers will find some unexpected funds in their budgets this year," says CGE&Y's Domhoff. "EAI will be a major factor for integrating next-generation services."
Going forward, carriers will most likely have lower expectations for their EAI toolsets, but they accept that integration tools are a necessity. Integration has always been a part of the telco environment, and it will prove to be more important as providers launch next-generation services. Having invested in these toolsets, carriers will stick with their platforms, hope for increased feature functionality and-as always-be on the lookout for new, improved integration technologies.
With Microsoft and Sun prepping their Web Services technology—business function programs that can be used by multiple developers and deployed over the Internet—some industry experts claim the new architectures will make EAI obsolete. Developers will be able to reuse these business processes as part of their applications rather than rewriting the logic. Currency translation is one example of how Web Services could be used. Many financial service applications require translation between currencies, and each application builds the logic into its code. A Web Services architecture would encapsulate this function and deploy it over the Internet to many different business applications.
“Web Services will cause the current EAI providers to go away,” Metastorm CEO Avi Hoffer says bluntly. “EAI providers natively, and narrowly, bolt in how applications talk to one another. Upgrades and changes easily destroy these integration efforts. Once we agree on Web Services, these EAI products won’t be important.”
Gaining industry consensus for protocols, architectures—actually anything—has always been a sticking point. A couple of years ago, the industry standardized CORBA after hearing raves that it would solve integration problems. Disappointingly, though, the standard proved too complex. Now, industry support seems to fall unequivocally behind Web Services, mainly because of its ease of use. Described as having a toolset that programmers can typically begin using after an afternoon of training, many software companies are bound to adopt the architecture. What’s more, Web Services could become the core technology for EAI, says Russ Freen, co-founder and vice president of R&D and operations at Bridgewater Systems.
“EAI with Web Services will be a simpler proposition,” Freen explains. “It’s more open and will allow service providers to do integration with partners. With Web Services, all partners won’t have to buy into one EAI solution.” Large and small enterprises are expected to be experimenting with Web Services in mid-2002, when Microsoft and Sun’s toolsets are expected to be ready. Early projects could commence as soon as the end of this year.
For the short term, though, EAI providers don’t expect Web Services to encroach on their business. “EAI and Web Services will be joined at the hip for many years. The ideas are getting lots of attention, but Web Services is a long way from maturity,” says Conor Keane, vice president of global solutions, communications, at Vitria.
Likewise, IBM doesn’t see Web Services as a threat to its MQSeries. “Web Services doesn’t decrease the need for middleware,” says Vivek Khosla, MQSeries market segment manager. “Companies will still need middleware for integration and to collect the data.” All the same, Bridgewater’s Freen believes it’s easy to predict who will win the EAI space. “Things that are simple succeed,” he says. “Things that are complicated struggle.”
Connecting one application to another is only one aspect of the overall integration effort. Integrating human behavior and intelligence into the business functions and exposing more aspects of the network are other important areas targeted by a different set of integration players. Metastorm claims that dealing with data is a lot easier than dealing with humans. “How people work in the real world is complicated,” says Avi Hoffer, CEO at Metastorm. “We look at transactions that are exceptions or require intervention from people or systems that exist outside the internal environment.”
“When EAI encounters an error, it can’t support the transaction,” says Hoffer. “We add a digital backbone to handle exceptions and wrap that back to the EAI software or other back-end system.”
Valaran, another integration company, is experiencing success extending the business processes into network areas where other integration products couldn’t go because they used the wrong schematic or the carrier didn’t want to extend a particular process logic. The company has taken a more top-down approach to integration and is focusing on increasing the visibility of business processes out to network management, network elements and even field technicians.
“We’ve been careful not to put ourselves into the EAI box, because our process is more abstract,” says CTO Michael Ogg. “The EAI view is one application flushing data to another application via a bus. Our view of the world is to construct a more abstract business process.” In a TeleManagement World catalyst project, Valaran enabled Portal to integrate with other applications. The technology was used to separate Infranet’s billing function from its product catalog. This approach is different from an EAI tool, which Ogg says would combine Infranet’s two features under a single “billing box” in its architecture.
“Our view is that Infranet has two logical roles, one as biller and another as product catalog,” says Ogg. “By mapping to both biller and catalog separately, changes can be made to either function without destroying the interface. Unlike EAI, we don’t hard-wire the connection to the product. Carriers can preserve the interface and change the application behind it. This method is a clear distinction between business model and business process.”
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article