For years, management consultants have railed about business stovepipes ę rigid, functionally organized departments, each self-contained. Customers, however, prefer to view a business as a single entity, not as a collection of discrete functions. They want the customer service, sales, billing, and order fulfillment departments to share the same information as part of a single, seamless business process focused on delivering whatever it is they came to the business for in the first place.
Business stovepipes prevent the organization from acting as a single entity, and information systems are a key part of the problem. Necessary information fails to flow across multiple stovepipe functions because most applications are designed to serve a specific function. They take orders, schedule production, or manage inventory. Information flow and linkage ę integration ę among the functions is limited at best. As a result, organizations that need to deploy cross-functional business processes have to scramble at the boundaries of each process to move information back and forth. This usually takes the form of manual intervention and handoffs.
The emergence of commercial, tightly integrated core business applications, such as SAP, Baan, or a number of others, helps to some extent, but no single application can do it all. SAP, for example, may integrate the resource planning, production, distribution, and financials, but another system is still handling the customer service, decision support, or human resources. While there is tight integration among the SAP modules, these other applications remain left out, preventing the organization from efficiently implementing the cross-function business processes required to act as a single entity.
IS managers, who have been incessantly harangued over the need to break down stovepipe systems and align the information systems with the business, recognize the problem. But breaking through the stovepipes is a lot easier said than done. When I visit companies, I see evidence of near-heroic efforts to link and integrate systems ę home-grown batch jobs combined with manual interventions that attempt to move information from one system to another. Maintaining these rapidly multiplying programs over time becomes a nightmare as any change or upgrade of one application means changing the home-grown program that handles the linking. Pretty soon, inordinate amounts of effort and resources must be expended just to keep such a patchwork integration edifice functioning.
As organizations move to business models that rely on the cooperation of outside partners, the concept of cross-functional application integration becomes both more attractive and more complex. Now we have to support business processes that not only span functions but span independent enterprises. It might be very advantageous for the forecasting or production scheduling systems of your suppliers to be updated automatically by your order entry system. This, however, is difficult enough to achieve within one organization, let alone across multiple organizations with different systems, platforms, and IT cultures and capabilities.
Middleware tools promise some relief, but alone they do only part of the job. The middleware tools automate the low- and even midlevel connections between systems and applications, but they donęt address the business process. IS managers need something that provides a much higher level of business abstraction so they can establish connections from one business function to another across the stovepipes. Simply moving rows and columns of data from one application to another, for example, doesnęt help nearly as much as being able to specify that the results of certain transactions on this side must go into these processes at this point on the other side.
Within the last year, a set of tools, often incorporating middleware, has emerged that provides the kind of high-level business process abstraction required to integrate applications. These solutions typically provide integration at the business process level for packaged applications such as SAP and PeopleSoft, as well as connectivity to legacy systems. Although the vendors refer to their products as off the shelf, these arenęt shrink-wrapped solutions. They usually require substantial consulting services as part of any purchase and deployment.
Offerings in this space range from near-complete solutions for specific problems to high-level toolkits for building the integration among a wide variety of applications. Some packages include graphically configured data transformation capabilities and visual programming environments, similar to workflow, that allow business processes between applications to be specified and maintained graphically.
This application integration middleware ę one vendor, CrossRoads, calls it processware ę sits between the two applications being linked and takes changes in data or requests for information from one and triggers the appropriate actions in the other. So when orders are entered into SAP or products are shipped, the information is reflected in the linked customer service application. This is quite different from, say, a batch job in which the information is dumped into the new system, but you still have to figure out where and how it goes. Vendors include Active Software Inc., CrossRoads Software Inc., CrossRoute Software, Fuego Technology Corp., New Era of Networks Inc. (NEON), Oberon Software Inc., Vitria Technology Inc., and others. (See David Linthicumęs column "Crossing the Streams" in DBMS, February 1998, for details on CrossRoads.)
The IS benefits are twofold. First, you get faster, easier integration because you have eliminated the need to create custom code to perform all the low-level work. The tool understands the APIs and mappings on each end of integration and translates the necessary calls back and forth. Second, when one or another application is upgraded, the IS organization doesnęt have to go back to rewrite the various integration programs. Because these tools are packaged and sold as ready-to-use solutions, the solution vendor upgrades the affected components.
Fueling the need for integration is the componentization of packaged applications, legacy applications, and data, which is now a common practice. The packaged application vendors are breaking their monolithic systems into individual components and publishing the APIs. IS organizations are increasingly componentizing their legacy applications. While componentization should make integration and linking easier, it will also foster a best-of-breed approach as organizations try to mix and match functionality from different vendors as well as legacy applications. This, in turn, will create a need for yet more integration.
Early adopters of application integration products, which come primarily from the computer industry itself, such as Adaptec Inc. and Bay Networks Inc., report initial enthusiasm and early success with pilots, although we have not seen full production rollouts yet. The enthusiastic response has attracted still more vendors, who are rushing into this nascent market. Many of the traditional middleware vendors are also scrambling to raise the low level of their current tools to address higher-level business process abstraction or partner with some of the new vendors.
Hurwitz Group has been following the emergence of this niche for more than a year, and we view it as the natural and necessary evolution of middleware to higher levels of business abstraction. However, we believe organizations have to be careful as they explore these tools. The application integration tools market is very immature. A number of critical issues, such as management, data and transaction integrity, recoverability, scalability, and security, must be addressed more completely.
Here are some of my greatest concerns:
We bring up these issues not to discourage you from pursuing application integration tools; on the contrary, we believe these tools represent an important advance and will enable organizations to link and integrate their systems at higher levels more quickly than ever before and maintain the linkage much more easily. The easier maintenance alone should result in significant savings. However, IS managers who are considering these tools must consider all the ramifications in terms of security, management, integrity, and other IS practices.
These products are new; in most cases, the products are in their first commercial release. The vendors will likely address and resolve these issues in subsequent releases.
In the end, IS organizations need tools like these to enable them to integrate systems at the business process level. Only then can companies finally dismantle the stovepipes that have long hindered organizational effectiveness.
Steven Foote is vice president of research strategy and director of systems and applications management service with Hurwitz Group. He directs the research approach used by Hurwitz group analysts and consultants and manages research in system, database, application, and network management. You can email Steven at sfoote@hurwitz.com.
| Company Contact Information |
|---|
|