Pay a visit to your local art museum and you might come across a mosaic – an art form that integrates many little pieces into a larger whole.
If only it were that simple to create such harmony between enterprise applications. The task to connect all those IT pieces can be daunting, even if the individual components are designed for integration in the first place, and is still near the top of the list of priorities for many enterprises.
“(Integration) is becoming increasingly important as organizations want to expose more information and more functionality out over the Internet,” said David Senf, senior analyst and manager of e-business operations at IDC Canada in Toronto.
Acting much like the glue that holds a mosaic together, middleware is software that links applications, allowing them to exchange data without putting the onus on customers to write the connecting code themselves.
However, unlike the mosaic, there is an added layer of complexity with IT integration: different vendors approach middleware from different angles.
IDC Canada’s software analyst Warren Shiau said middleware vendors can be put into three categories: enterprise application vendors that offer proprietary integration platforms with their suites; the more traditional middleware vendors which offer an infrastructure layer to tie things together; and the pure-play standalone middleware players.
The existence of these three approaches is creating a “very interesting three-way tug of war – the fight over which is the real enterprise strategy for integration,” said Roy Schulte, vice-president and research fellow with Gartner in Stamford, Conn.
Suite vendors wet their feet
Traditionally, ERP and CRM suite vendors included an application programming interface (API) with their software, leaving customers the task of adding custom code, investing in the help of a systems integrator, or using middleware to facilitate the connections.
But in recognition of the headaches do-it-yourself integration can cause, application vendors over the last couple of years have made their offerings more open and integration-friendly.
Vendors like Oracle, PeopleSoft, J.D. Edwards, Siebel Systems and SAP have added support to their suites for standard technology, including Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and Java 2 Platform Enterprise Edition Connector Architecture (JCA).
Some ERP and CRM vendors have also built their own messaging brokers into their suites to handle the transfer of data among disparate applications.
In January SAP unveiled NetWeaver, an integration and application platform based on Web services standards that is designed to interoperate with other platforms, such as Microsoft .Net and IBM WebSphere.
As part of its J.D. Edwards 5 collaborative enterprise solution, J. D. Edwards offers XPI, its middleware product, and XBPs, pre-built business processes that, according to the firm, enable multiple applications to share data in real time.
Siebel in April upgraded its own out-of-the-box application integration platform, Universal Application Network (UAN) to version 2.0, with the addition of 50 new industry-specific integration applications.
And during a leadership conference in May, PeopleSoft Inc. announced plans to ship out-of-the-box integration with software from Oracle Corp. and SAP AG. It’s a plan PeopleSoft president and CEO Craig Conway said will save his customers millions – and it’s a sign of “the beginning of the end of middleware.”
Gartner’s Schulte said that it probably makes sense for companies to use a suite vendor’s integration offerings for some of their requirements if that vendor’s application package – for example, mySAP ERP – is at the centre of their information architecture. However, “in most cases very few companies will use that as a backbone for enterprise integration – it’ll be used mostly for just the integration that comes in and out of the package, but not as a general purpose enterprise nervous system.” Most enterprises will then face the additional challenges of handling at least two or more types of middleware.
That’s a strategy Lily Liu, director of information technology at Vancouver distance learning centre Open Learning Agency (OLA), and J.D. Edwards user, has toyed with. “When you have to integrate outwards, other tools come into play – and J. D. Edwards has an integration tool that looks quite interesting.”
Liu said she hasn’t had a chance to seriously evaluate XPI, but even if OLA were to choose it, it wouldn’t be anytime soon, and it would not be to replace its main integration tool, Oracle Application Server, which “makes more sense in the short term.”
The suite vendors’ integration promises are great, said Shiau – but the bigger question is: “What if you want to use something else? What sort of middleware or integration software do you need to make SAP work with Oracle?” For some enterprises, going with the application vendor’s middleware might not be the right choice, “unless you want to buy into the vision of one vendor and become a sole-source shop,” Shiau said.
Adds Senf, “This can work for some smaller organizations – a single solution can offer lower total cost of ownership in some cases. But in larger organizations with multiple departments and needs, heterogeneity will continue to exist, and organizations will buy into multiple technologies.”
The app server choice
With the infrastructure vendor’s approach to middleware, the customer chooses the integration middleware that comes with the platform they’re using, such as IBM WebSphere, BEA WebLogic or Microsoft .Net. Going with such a strategy has a number of advantages, said Schulte. “It’s semi-one-stop shopping because it’s all pre-integrated; you have less tools to deal with and fewer moving parts.”
BEA Systems said version 8.1 of its WebLogic Enterprise platform is a major upgrade from 7.0 because it’s the first time WebLogic’s portal, application server and development tool have been so fully integrated.
Oracle, rather uniquely, competes as both an infrastructure vendor and an application vendor. The Redwood Shores, Calif. firm turned up the competitive heat in March when it released a new version of its 9iAS application server, Java edition.
Before OLA tried out Oracle Application Server, it was using an integration product called Campus Pipeline by Malvern, Penn.-based vendor SCT. Liu said OLA implemented the first few versions of Campus Pipeline, and was hoping SCT would release an application programming interface (API) so OLA could add some functionality to its portal, but “that didn’t come to fruition.” After running Campus Pipeline for about a year, OLA decided that it needed something else.
Oracle Application Server was the final choice because both OLA’s delivery and student systems were on an Oracle database – a “good fit, being all from the same vendor,” Liu said. “With Oracle, since we already have a licence…it’s easy to transition that way.” The disadvantage is that the organization is now “stuck with Oracle,” said OLA’s senior database architect Wade Ho. Still, support is now “just one phone call away,” and OLA has “a bit more time to troubleshoot and solve issues,” he said.
IBM has its own integration platform under the umbrella of Websphere. Ken Ontko, director of technical delivery for the British Columbia Automobile Association (BCAA), said the Burnaby, B.C., automotive services firm faced many problems when it started integrating the different databases it had acquired during its Y2K-instigated replacement of more than 30 systems. The firm dabbled with writing its own custom APIs, but that was a huge task that could potentially “cause upgrade problems when the systems changed,” Ontko said.
BCAA chose to implement IBM’s WebSphere MQ as the messaging backbone that all of its systems – membership, travel and insurance – could talk to. Whenever a customer is added to the database, or someone has renewed a product, the database formats an XML message that goes on the MQ backbone, he explains. The message then goes out to the other systems that have to be updated.
Although BCAA runs on Oracle databases, it chose IBM because if it decided to switch over to or add another application vendor, “we know that we can connect anything to (WebSphere).”
Playing it pure
Then there are the vendor-neutral middleware vendors like webMethods, Tibco, Vitria and SeeBeyond. Their big trend is Web services and other standards-based initiatives, said Schulte.
Palo Alto, Calif.-based Tibco in May inked an agreement with HP to develop a Web services-based process management solution, enabling the two firms’ customers to integrate and optimize infrastructure and business process management alerts.
The same month, SeeBeyond Technology Corp. of Los Angeles announced that its Integrated Composite Application Network (ICAN) Suite v5.0 is now compatible with Java 2 Platform, Enterprise Edition 1.3.
As of February, the BusinessWare platform from Sunnyvale, Calif.-based Vitria, which focuses on business process integration, supports RosettaNet’s standard, the RosettaNet Implementation Framework (RNIF 2.0).
And webMethods Inc. of Fairfax, Va., said its webMethods Integration Platform continues to support the Web services standard SOAP version 1.2, and in June announced support for Apple’s Mac OS X.
Kevin Sullivan, who is in charge of webMethods integration in the information and computing department at Shell Canada Ltd. in Calgary, said although Shell is a very big user of J. D. Edwards, the compatibility with a variety of technologies is what sold the firm on webMethods. “We actually have a variety of systems, and flexibility is what appeals to us,” he said. “We have to look at potential changes down the road….If one of our back-end systems changes, we can just pull (it) out, and put in another.”
The big downside to middleware has always been the upfront cost of buying the software and starting up the infrastructure, Sullivan said, adding that webMethods has made a point of working with application vendors like Oracle, J.D. Edwards and SAP to provide adapters and packaged, joint ERP/EAI solutions that better match customer budgets.
As time goes on, said Shiau, the standalone pure-play integration players will “have a harder time surviving” because it’s “difficult to add margin to something that’s based upon an across-industry standard.” Vendors in this category “will really have to make their margins around providing services around their integration platforms.”
The neutrality these vendors offer is a big plus, said Schulte, but the tradeoff is dealing with more vendors. “There may be support and development issues, and more seams may be visible to developers,” he said. However, for a larger organizations that already use a few different application servers, Schulte said “these independent vendors have a much stronger case.”
Weighing your options
So in the end, how do you decide which vendor’s middleware is best for you? Jonathan Eunice, a Nashua, N.H.-based Illuminata analyst, said there’s “no particular magic bullet,” but recommends going through a planning and evaluation project to figure out what the business processes and needs are – then evaluate products from different vendors.
Also make sure you consider your firm’s future technology plans. “A lot of what you’re getting into is long-term commitment,” Eunice said. “Often it’s the strategic entanglements that cost you the most, and the strategic choices are what make you able to respond or not respond to change.” Which vendor you ultimately choose will depend on what environment you’re running on – .Net or J2EE – and how many legacy applications you have, said IDC Canada’s Senf.
One budget-conscious option, said Senf, is for developers to build their own adapters: software components that connect non-communicating applications. “There are times when the cost to expose won’t reap any dividends for years to come – if that’s the case, it might behoove that organization to potentially gain functionality somewhere else, or simply carry on with whatever method they’re using.”
Schulte said larger enterprises might want to consider using more than one integration broker for their needs. “I think a small company has a better chance of having one integration technology across board, but it’s already too late for large companies to stop at just one,” he said. Sticking to a single middleware vendor is like trying to stop a horse that’s already escaped from the barn, he said. “It’s too late to close the door.”
