Integrating applications is not a new idea. In fact, organisations have struggled with the need to share data between applications for some time. But as enterprises have grown more complex, so too have their integration goals and requirements. Enterprise application integration (EAI) puts a formal name to today's integration efforts.
Although application integration began at the data level - moving or replicating data between databases - EAI is focused squarely on business-process automation. EAI, in its present form, is defined as sharing business processes and data among connected applications. EAI solutions are the connectors in this integration equation.
The business case for EAI is strong. For many years, companies built or bought specific applications that served users within specific workgroups. These types of workgroups might include human resources, sales automation, and inventory systems. Many of these "business-process islands" use proprietary technology or non-standard methods of data storage.
More recently, many companies have adopted packaged applications, such as SAP, Baan, and PeopleSoft, in an effort to streamline business processes. However, companies implementing these packages are still finding it crucial to integrate them with other portions of their computing environment.
A relatively new consideration is the need for business processes to adapt to Web technology with increasingly shortened development cycles. A higher number of corporate acquisitions and mergers also fuel the need for a greater amount of integration. EAI can act as the glue that addresses all of these issues.
Rewards of EAI
Measuring the return on investment from EAI will be different for every organisation. EAI should be viewed not in the sense of singular application integration returns, but as a larger framework that exists at an application-infrastructure level, linking all corporate business processes. A business-process analysis will be needed to determine the cost savings, increased revenue, and competitive advantages of implementing EAI.
Those considering EAI should note that this technology is undergoing a transformation. In particular, mid-tier and Web technologies are merging with traditional EAI solutions.
Four ways it works
As you examine your business processes, you must be aware of the different dimensions that EAI can take. There are four types of integration supported by EAI.
The first is an expansion of traditional data integration inside a common framework. Data is extracted from a data source, transformed, processed, and subsequently used to update a target data store. EAI solutions in this vein should offer a wide array of data connectors as well as manage- ability and scalability options.
The second type of EAI links business processes and data at the application-interface layer. Developers implement EAI using the exposed application interfaces of custom or packaged applica-tions. This approach is common at sites using enterprise resource planning applications although the integration is limited to the interface available. Manageability may also become problematic.
A third EAI approach is to share business logic throughout the enterprise at the component level. Application services, such as an amortisation routine, are shared, thereby eliminating duplicate logic and streamlining processes. This is perhaps the most flexible and manageable form of EAI although it does take considerable effort to implement across an enterprise.
The fourth EAI approach leverages the user interface as the basis for integration. Many consider this method of EAI more primitive than other integration mechanisms. Business processes are tied together by programmatic access to user interfaces, which subsequently enables composite applications. This form of EAI can be easily managed, and existing logic is reused.
Five framework options
To make EAI work in your unique environment, you may need to implement one or more types of integration as part of your EAI framework. There are five ways integration can flow through your organisation, and most companies will need to use more than one of these topologies.
These topologies are hub, bus, point-to-point, pipeline, and network.
An EAI hub acts as the focal point that links varied business processes and data across disparate platforms. This type of EAI flow is most commonly found at sites that implement message-oriented middleware. Solutions that leverage a hub type of flow should be examined carefully for transaction and event support as well as scalability.
Administrators that want to implement EAI in a publish-and-subscribe fashion will want to leverage bus topology. Certain business processes may produce sharable information while other processes will gain added value by consuming that information.
More traditional EAI implementations leverage point-to-point topologies that directly link two applications together. This type of flow is best in cases where synchronous processing would add value. However, too much point-to-point integration can easily become unmanageable.
Businesses that need to process transactions often rely on the pipeline approach to EAI. Transaction requests flow through one or more pipelines and are integrated with processing applications on a first-in first-out basis.
Finally, network EAI flow is best used for integrating transactions that use asynchronous processing. Most EAI solutions of this type are both manageable and scalable. Customers should examine redundancy plans if considering this flow.
Although far from a panacea, EAI can yield substantial benefits for organisations that can invest the time and effort needed to examine and re-architect business processes and data. EAI frameworks provide a proactive approach to rapidly changing technology requirements.
I see 10 areas to examine before you decide whether EAI will become a part of your core application infrastructure:
1. Business and IT strategies must be joined at the hip. EAI is an ongoing effort driven by business processes. What steps will your IT organisation take to map product development or process re-engineering into the EAI architecture?
2. IT requires a deep understanding of business processes and their data. Before you can think EAI, you need to have detailed knowledge of the business processes and data supported by your systems and applications. Usually, some duplication of effort, process overlaps, and other inconsistencies can be eliminated early in your EAI planning.
3. Plan your EAI architecture. This means mapping business processes to integration requirements - factoring in your current environment and future corporate plans. This mapping process will pin-point the technical solutions that will prove most beneficial.
4. Justify EAI now and later. What will your com-pany gain by implementing EAI as part of your application infrastructure? Will you be able to reuse business logic in expanded ways? Can you improve efficiency or add revenue?
5. Examine EAI vendor offerings, middle-tier adoption, and the changing marketplace. EAI tools and solutions are not only maturing but also undergoing transformation as middle-tier product providers, ERP vendors, and others begin to adopt EAI underpinnings. Seek solutions where you can hook in a wide variety of applications.
Measure vendor stability, partnerships, and support offerings carefully, because the EAI market is evolving.
6. Evaluate the impact of EAI technology on your organisation. Ideally, you should be able to use EAI solutions to implement multiple integration projects; you should gauge potential solutions on this basis. How flexible is the tool? Will subsequent EAI product upgrades cause downtime? What configuration and management tools are available? And most importantly, how easy will it be to customise the solutions to meet your needs?
7. Make sure you have the skills to drive EAI. EAI affects the core of your organisation, and you will need a wide range of skills to successfully support it. Personnel well-versed in business processes, as well as architects, developers, and networking experts, all have a role in EAI.
8. Determine who will lead your EAI efforts. Deciding who owns your EAI initiative can be tricky. Just as EAI solutions provide the technical glue, a designated EAI leader must hold things together from the start.
9. Prioritise what to do first and where to go from there. After defining your EAI strategy, start off with a small pilot project that will provide business benefit but will also measure the effectiveness of your integration planning.
Following the pilot program, fine-tune your EAI strategy and proceed with projects that will yield the greatest benefit.
10. Determine how you will manage EAI. The possibility of performance bottlenecks and potential failure can increase with added integration. Detecting and isolating problems can also become more complex in EAI settings. Your EAI plans should include tools that provide end-to-end monitoring and management of your environment.
EAI is not for everyone, but it does merit investigation, especially at sites with a wide array of distributed business processes.
The bottom line
Enterprise application integration
Summary: Enterprise application integration (EAI) enables the unrestricted sharing of data and business processes between any connected applications.
Sites with widely distributed or largely separate business processes should investigate EAI to improve internal efficiency, more easily reach external business partners, and respond to rapidly changing market conditions.
Streamlines business processes
Promotes application reuse
Provides rapid response to changing marketsCons:
Initially requires significant time investmentRequires tight linkage between IT and business personnelDetailed mapping of business processes to EAI architecture will be needed