Quelle: CIO Asia
APPLICATION INTEGRATION USED to be a back-office, behind-the-scenesactivity for many IS departments, but it has now emerged from its lowlevel status to become a priority. "Internal integration consistentlytops the list of [IT projects] that companies are focusing on," saysMichele Rosen, U.S.-based IDC research manager specialising inapplication development and deployment.
It isn't difficult to understand application integration's rise to ISpre-eminence. Integration projects, by giving end users access tovaluable information, boost productivity and customer satisfaction.For example, when United Airlines Corp. (UAL) redesigned itsarchitecture and built a more integration-friendly one three yearsago, it saw customer satisfaction rise several notches. And when IPCommunications (a data networking services provider in the U.S.)completed two integration projects last year, it harvested a 522percent return on investment.
The success stories of UAL and IP Communications indicate thatapplication integration is increasingly inseparable frominfrastructure and application development. A common platform - BEA'sWebLogic Server - was used by both companies for applicationdevelopment and integration.
"It was last year, when application server vendors announcedintegration solutions, that companies began looking at application andintegration servers melding as foundational components for theire-business platform," says IDC's Rosen. Although the use ofapplication servers for integration remains ad hoc, industry playersexpect this to change. "The lines between application development andintegration are blurring, and Web services are a key part of that.It's eye-opening to see how intertwined integration and applicationdevelopment are becoming," says Greg Olsen, co-founder of Extricity,an integration services firm owned by Peregrine Systems Inc.
Telco of high standard
Two years ago, while planning its applications architecture, IPCommunications standardised on Java 2 Enterprise Edition (J2EE) due topositive experience with it previously. "Our concept was that theapplication server would be core to all our systems, such that anysystem to be built - and any integration to be carried out - would gothrough the application server," says IP's vice president ofInformation Systems Rick Barry. "As we weren't sure what systems weregoing to be implemented over the next year, we selected an applicationserver and integration platform that would allow us to integrate ourvertical applications. Applications will come and go, but thisintegration infrastructure will be maintained for years," headds.
Integration has a strategic focus within IP Communications as thetelecommunications industry has not fully integrated its systems,despite the proliferation of manually intensive business processes fordata management across multiple suppliers, customers and internalresources. Barry believes that 35 percent of an IS budget should bespent on integration. "We constantly challenge ourselves by asking,'As IT leaders in our companies, why aren't we focusing onintegration? Do we have a separate shop focusing onintegration?"
With a manually intensivebusiness that was expanding at a compound annual growth rate of 248percent, IP Communications had to deploy a Telecom Operational SupportSystem infrastructure quickly. It had to be executed with a small IToutfit comprising more generalists than specialists. Technically, theinfrastructure had to be scalable and flexible with reusablecomponents, open and based on industry standards, and easy to deployand use. The solution had to be vertical- and component- based, anddeployed within three months. IP Communications also wantedWeb-enabled thin clients (Java Server Pages), integration via XML(eXtensible Markup Language) and Java Messaging Server (JMS), and alimit on the number of different technologies involved.
In late 2000, the company bought BEA Systems Inc.'s WebLogic Serverand WebLogic Integration to carry out two integration projects. Thefirst - enterprise application integration (EAI) - automates order flowfrom J2EE to its DCOM-based billing system. The second - B2Bintegration with Southwestern Bell, a U.S. telecommunications companywith which it had to connect via EDI - transmits complex transactionsback and forth using EDI (Electronic Data Interchange), JMS and SecureSockets Layer (SSL).
The deployment was done rapidly by a four-man integration teamexperienced in workflow and J2EE. The initial billing application, forinstance, took only 60 days to deploy. BEA's standards-based approachswung IP Communications' choice in its favour. "It means I can hiredevelopers who know the [J2EE] standard. We've been using BEA'sWebLogic Server since 1998, and the experience had been a successfulone, so the progression into the integration suite was natural," Barrysays. The WebLogic Integration product had the capability to translateXML transactions to EDI , and vice versa, through an adapter fromPeregrine Systems Inc.
IP Communications' ROI, in terms of productivity improvement, isstaggering. Before, it needed 13 people to handle 50 to 100 orders aday. With the billing integration, which achieved 99 percent flowthrough, this has been reduced to one person. Before the B2Bintegration with Southwestern Bell, 20 people were required to enterorders. Now, with 98 percent flow through, only one is needed. Thistranslates to a 522 percent return on investment. Payback was attainedin only 10 weeks. Other benefits have accrued: transaction errors havebeen reduced, and so has time to delivery, from 45 to 15days.
Its two projects have taught IP Communications a lesson or two aboutintegration. "Integration never stops. Applications will come and go.I believe my billing system, for instance, will be discarded in fouryears," says Barry. IP Communications overcame this uncertainty byimplementing the J2EE-based integration infrastructure through whichall communications will flow. "Once we've standardised on onetechnology, and gotten it implemented, we can evaluate new techniquesand technologies as we evolve," he adds.
As processes drive people and technology, it is important to definebusiness processes first, prompting IPCommunications to call it"Enterprise Process Integration" instead of EAI. Barry advises:"Always focus on process - rather than application - integration, andwork your way down. If a component is designed well in C++, chancesare, it will operate just as well as if it's designed well in Java. Soalways select technology second." Integration solutions should also beused in multiple ways, ranging from process, application and B2Bintegration to EAI and collaboration. "It is key that developersunderstand the platform's capabilities and work on leveraging it. Forus, we hope every process utilises our integration infrastructure oneday," he says.
For any IT project to work, it is also important for IS to have inmind a project sponsor from the business unit. "I got my sponsor'sattention when I told her how I could reduce operational headcountfrom 20 to one. She realised [the project] was important and herpeople supported it. It takes a lot of communication to make yourbusiness sponsor realise what you are trying to accomplish," saysBarry.
Flying the integrated skies
For UAL, the road to integration began six years ago when itstandardised on BEA's Tuxedo Server as its integration platform. Sincethen, new technologies such as CORBA (Common Object Request BrokerArchitecture) have emerged to compete with Tuxedo. However, UAL heldoff from moving into CORBA, taking the chance with a newer technologyonly when Java and the application server were launched. Says UAL'smanager of architecture technology Denny Lyons: "So far, we've beensuccessful in tying all our backend systems together and having themcommunicate back and forth."
This was not the case three years ago when UAL faced its most seriousIS challenge in its 75-year history: to design a new architecture forits entire IT infrastructure. UAL had a host of legacy systems dealingwith safety, selling tickets, getting information about flights andoperations, and more recently, understanding its customers. Most ofthese systems were built 50 years ago and were inflexible. "They didwhat they were built to do, and coupled with that, all the companiesthat dealt with travel had the same inflexible, difficult-to-adaptsystems. But they ran the airline very well, as they were stable andextremely fast," says Robert Robless, chief technology officer of UAL.These systems, including Apollo (a global distribution system) andCosmo (for getting spare parts to where they need to be), are one-tiersystems built in silos. For instance, the reservation system wouldonly do reservations, and the mileage plus system would only deal withloyalty and frequent flyer information. For some of these systems, UALeven had to train its own programmers in languages such asFortran.
In the early days, UAL attempted to share information internally byputting its systems on multiple terminals. This was inefficient sinceusers had to go to different terminals to get the right data. In orderto drive economy into its systems and get payback from them, in the1980s, UAL installed networks to share data between these systems.Information was, however, never really tied together as differentscreens were used to show information from different systems. Besidesbuilding up specialised networks, that era also saw UAL spending lesson huge mainframes and more on getting greater functionality out ofsmaller machines.
In the 1990s, travel became a commodity, and travellers demanded lesshassle. IP technology also became more prevalent, allowing differentnetworks to be connected, and data to be transferred. "We had theability to make information much more readable from the users'standpoint, as we didn't have to train service agents as heavily. Thecost of delivering that [information] service was drilled downdramatically," says Robless.
Just when it thought that bymarrying inflexible systems, and getting data to its customer servicerepresentatives, it had "done it all", UAL realised that it was wrong."With the Internet, travellers could get services off the Web. Gettinginformation to them became a reality and also something they startedto demand. Travel portals allow customers to buy their own tickets.All they had to do was to get enough information to plan theiritineraries. All these meant that we had to rethink how we selltickets, and how much information we have to give them to make theirtravel experiences hassle-free. It was a true revolution,"he says.
With Sept. 11, customers began to realise that it was important forstringent security checks for air travel to be safe, leading toanother mindset change at UAL. "In the last 10 years, we had beendriving towards building these really cool systems to get people tofly speedier. Now, we still need to make it easy to fly in spite ofthe security measures that have taken place," Robless says.
Three years ago, UAL drew up a road map that detailed how it was goingto pull together its systems onto a flexible and adaptable platform onwhich to build its applications. The architecture had to achieve anumber of objectives: firstly, to get information to customers whoneed it, when they need it; and secondly, to share data andinformation widely and securely.
It decided to buy the infrastructure, preferring to concentrate on itsbusiness rather than technology. Building technology internally wouldalso be too costly. "What we needed was development software thatallowed us to put together systems cheaply, and quickly," Roblesssays.
The first need it recognised was to have a common architecture andplatform to achieve its objectives. So it took a top-down,architecture-based approach, mapping out how it was going to build theinfrastructure and deploy all its systems. "We defined a referencemodel and built against it. We also made sure we had a very strictdiscipline on how we were going to use the technology we were puttingin place. We were dealing with very old and fragile systems and itwasn't worthwhile slapping technology on top of it. Thirdly, we wantedto leverage open standards-based technology. We had to be sure that inthe future we could always leverage what we will buy."
Horizontally, it decided to layer its systems, in terms of apresentation, business logic and data organisation layer. It thenapplied different technologies to each layer. "This is so that ourdevelopers don't have to learn all sorts of technologies, only theones they are best suited for," explains Robless. Vertically, itstarted to break the infrastructure into components. "We built [theinfrastructure] in such a way that we could present them on anypresentation device and take data from any data device," says Robless.Different touchpoints were dealt with, including the Web, telephone,PDAs, PCs, and paper.
UAL also recognised that its legacy systems were still valuable anddidn't discard them. "They ain't broke, so we didn't fix them. We justbuilt around them. They are not going to go away. They have a lot ofdata in them and run just fine," says Robless.
When UAL started building services, it broke them down intoinfrastructure and business services. The former revolves around theapplication standpoint, including services for reservations, flightoperations and maintenance.
In the last three years, UAL has put together a thin client-basedarchitecture, successfully. As it was developed for internal use, thenext step was to build it for external customers. "Customers arebecoming more Web-savvy, and technologies, more feasible. We needed totranslate this architecture into something that is more available forcustomers. Loyalty services, for instance, took this architecture as abasis," says Robless. UAL developed a reference model called "e-travelconcourse" and built its architecture on top of this reference model.BEA provided the application infrastructure through WebLogic, whileVignette provided the content management system that ensures theinformation presented to customers across different touchpoints wasconsistent.
"E-travel concourse" consists of an airport terminal with a storefrontutility underneath. The storefront holds the united.com site andmobile sites. In future, UAL plans to introduce more services, such asairport and phone reservation systems and services for Star Alliancepartners and travel agents, says Robless. "The goal is to have allthese portals or storefronts receive the same type of information andcomputing logic that serve all our systems," he says. These portalsare served through engines built separately for booking tickets,changing itineraries once the tickets are bought, or serving outinformation proactively or on demand. There's also a contentmanagement engine that serves standard words, pictures and ways toreach out in a consistent manner. "These are common services, and wedon't want to have to rebuild them for every portal that we have," headds.
UAL has built a loosely-bound architecture that also allows it toexchange messages back and forth, which is standardised onXML.
Lyons says UAL's future integration challenges are to enable greaterB2B integration with its Star Alliance partners. "The challenges wewill have is to be as ready as we may be in taking out Webservices - or any technology - for integration, and we have to strugglewith how our partners would be ready for all of that. It's one thingto be in control of our own store, and another to have to work withour partners so we can have seat and price sharing. If we aresuccessful, a [Lufthansa] customer could walk up to any Star Alliancepartner's ticket agent with a problem about his travel, and the agentcould help that customer as well as any Lufthansa agent. That would beour goal."
The information that it is working to share with its 12 Star Alliancepartners would include flight data to make sure information on flightsthat customers are booked on is current. UAL uses an event-drivenmodel to share information dynamically with its Star Alliancepartners. Anytime that its partners have a change in their flightinformation, it is published to all alliance partners. This dataintegration is done on Tuxedo.
Another challenge with getting consistent information out to customersis the data integrity problem. UAL uses Extract Transform and Load(ETL) software to get information out of its data warehouses and datamarts consistently. "We are pretty good at getting data integrity fromthe informational side of our house. The operational side of the housecomes from stovepipe applications that have been around for 30 years.The idea is, how do we go in there when they have to have the sameinformation? They each have their own copy of the same informationnow. That's the data integrity challenge for us. So we are using themiddle-tier integration layers with event-driven technology to allowus to have a single event push that information out to our operationalsystems," he says.
Although it is hard to put a value on its integration effort, Lyonssays customer feedback shows they appreciate getting consistentinformation on whether their flights were on time, or cancelled,across all touchpoints. "I can't tell you what this is worth, but wecouldn't afford not to do it," he says.
UAL's integration road is not ending anytime soon. It has embarked ona business process integration project to manage its aircraftmechanicals. Not only do these involve some very expensive objects,they also impinge on customer satisfaction and revenues. When one ofits aircraft goes for a mechanical check-up, decisions have to be madeto avoid disruption to its business, such as finding another gate, orif it should cancel the flight altogether. Today, this process isfairly smooth due to its "experienced and smart" staff. "We rely ontheir knowledge and their ability to apply it, but those processesstill break down, because they rely on mechanical communication suchas phone calls. We are looking at business process integration to tieall those pieces together, so that we can be more complete in doingthat right. I don't think we have a problem with return on investmentand managing our aircraft better."
"The next step to me is knowledge integration. After touching onintegration from systems to processes, and information, the next levelis knowledge. And knowledge management is about capturing informationfrom warehouses and documents and getting that into a knowledge base,"he adds.
Not Integrated Yet
Not every company has acted like UAL and IP Communications inimplementing a standards-based integration infrastructure. "It's tooearly for all but the most forward thinking companies to have gottento the point of leveraging [a standards-based integration backbone],"says IDC's Rosen. "They may have saved money for specific projects butmost integration applications are very narrow in scope, almostdepartmentalised, in terms of the pieces of application that are beingintegrated. If you look at something like SAP and Siebel, which hasclose to 15 common business objects, many companies when going tointegrate are only focusing on the customer and order object," shesays.
Rosen is of the view that it would be very difficult for companies toapproach integration on a case-by-case basis, if they wanted toleverage its advantages, such as business process and productivityoptimisation, and involving applications in business change.
"There is a huge legacy in that type of point-to-point integrationthat's got to be overcome. Firstly, because it is point-to-point,therefore there is no central area of management, and no way to get anoverall view of the integration backbone. You have to look at eachconnection point individually to get an idea of what it is doing andhow it is operating. And then because they are so tightly coupled,application adapters are sort of a necessary evil. It's a long timebefore all of those things will be able to connect to astandards-based integration backbone," she adds.