|
Enterprise data most often resides in “silos”— applications that can’t easily talk to each other or the rest of the world. Enterprise application integration (EAI) means putting wrappers around, or connectors into, these silos, extending their useful lives, allowing the data to be re-used by a variety of new applications such as Web sites, portals, and e-commerce. Sound complicated? It is.
EAI is “one of the ongoing, never ending, moving targets in corporate Australia,” according to Bruce McCabe, technology analyst at S2 Intelligence.
CIOs tell him that two of the main areas of activity are putting Web front ends on older systems, and leveraging applications into new areas, such as linking ERP systems to customer or supplier management.
“EAI will be on the Top Ten list for CIOs for the next ten years,” he predicts.
To Stephen Williams, CEO of consultancy TurnAround Solutions, “EAI is [about] bringing together a diverse set of products and plugging them all together.” Most commonly, this involves connecting ERP systems to decision support systems, business intelligence software, and Internet or intranet applications.
Jeffrey Gosper, group leader, software architecture and component technologies at CSIRO has another perspective: “EAI is a strategy more than a technology,” he says. For Gosper, an important characteristic of EAI is the provision of a common framework to which each application can connect—from his perspective, a pair of applications talking directly to each other does not constitute EAI; connecting multiple applications on a point-to-point basis creates unwanted and unmanageable complexity.
Business issues
Quantifying the benefits of EAI projects is difficult, McCabe says. Improvements to employee productivity and customer service are “all good stuff, but hard to put dollars against” and boards are looking for a quick return on their investment. Consequently, most CIOs build a priority list and address customer service and sales first, then supply chain issues, then everything else, he says.
EAI and other major projects that affect the day-to-day operation of a company “need to be managed from not only a technology perspective, but a people perspective. Too often a project is completed by the IT department and declared a success, and the business spends the next nine to 24 months trying to recover,” says John Englaro, principal of Systems Integration Services International (Si2).
Englaro—who was known as “the man who gets things fixed” during his time at Compaq—says: “Our experience at Si2 has shown that the application of formal project planning, risk, and management practices can significantly reduce the cost and time of implementing a business-changing project, but also significantly reduce the pain the business feels as a result of the change.”
That pain can be manifested in several ways. Englaro points to problems arising from large-scale projects, including an inability to bill customers (apart from the immediate cashflow implications, this can play havoc with a listed company’s share price), billing customers twice or for incorrect amounts (which can be a PR disaster), and having to take on large numbers of extra call centre agents to handle the volume of complaints and other problems arising from the project.
“Any enterprise-wide project usually represents a significant investment of time, money, and resources, so the primary goal has to be creating successful business outcomes . . . there has to be a tight and disciplined approach toward maintaining the smallest possible gap between the promises people make and what technology can deliver.”
Gerard van Gore, Australia and New Zealand sales manager for Interstage at Fujitsu concurs. He believes it is important to start with a business perspective, align the project with internal change management practices and changes in business processes, and to look for the value the project can deliver rather than merely adopting a technology perspective.
Hands off, it’s mine!
With traditional silo applications, ownership is usually clear-cut. But by its nature, EAI cuts across functional boundaries. This raises several questions, including:
- Where is the information?
- Who owns it?
- Who is going to get the value from the project?
- Who is going to pay to make the information available?
William Scheer, TurnAround Solutions’ practice principal for EAI, says a project should be sponsored by the group that will get the value from it. After all, if the group running the ERP system is given responsibility for feeding data to an EAI project, all they are getting is more work.
High-level buy-in from all the groups involved is essential, says Williams, because “different parts of the business have different priorities.”
Sponsors should also keep a project as simple as possible—that is, it should be designed to deliver what is required and no more. If “function creep” occurs, there is a risk that the sponsor will not get the functionality required, at least not in the planned timeframe.
EAI “doesn’t have to be expensive . . . you can do simple things with simple tools,” says Scheer. “You don’t have to go from 0 to 100 in one step.” But he warns that the technology itself isn’t the only expense: the cost of reengineering processes and training staff are often omitted from the business case put up for a project.
McCabe warns against relying on gurus—the technology and methodology must be repeatable and maintainable. He says it is also important to consider the performance implications of different products and methodologies.
A related problem is that there are relatively few sites in Australia running large scale ERP systems, and according to Scheer, this leads to the risk that consultancies that claim experience in a particular aspect of EAI may deliver people without that specific experience. It’s also important to use people who will focus on the overall system, not the individual products from which it is built.
Making connections
Thorough data analysis is the key to a successful EAI project, according to Eddy Knochs, customer services operations manager (and former professional services consultant) with Compuware. For example, one program might store an address as unstructured lines of text, while another might have distinct fields for the suburb, state, and so on. If corresponding data is represented differently in applications that are to be integrated, you’ll need a way of creating rules to handle the transformations.
The interaction between applications need not be tightly coupled, Knochs suggests. “Looser seems to be better,” he says. Workflow models such as business process descriptions can make the development task easier. For example, it can be difficult to combine a (stateful) client/server application with a (stateless) Web or S/390 application. Knochs recommends reviewing the real requirements in such circumstances—less development effort will be required if the task really only needs an asynchronous link between the two systems, freeing developers to work on data transformation.
Ray Kloss, director of industry and product marketing at PeopleSoft Asia/Pacific, refers to this workflow-centred approach as “the third way” of EAI. Most IT systems are currently aligned by geography or function, but the customer experience cuts across these dimensions. For example, when a bank processes an application for a credit card, the credit system is obviously involved, but information would also be drawn from the customer information system and perhaps the deposits system to check the applicant’s current assets.
Kloss promotes the idea of using a repository to manage these processes, and then when any particular process is triggered (possibly via a portal), EAI technologies are used to work through the steps.
