Enterprise Application Integration (EAI) is one of the hottest areas in IT today. However, the name implies an approach to integration that will fail or at best yield less than the hoped-for results. In today’s virtual corporation, what’s needed is enterprise process integration where the enterprise is broadly defined as the corporate entity plus all its constituencies. This is becoming popularly known as Business Community Integration (BCI).

The emphasis needs to be on process integration, data consistency, and flexible configuration for a successful EAI deployment. The tools available today can greatly ease the routine tasks associated with integrating disparate systems, but they run the risk of significantly limiting organizational responsiveness to rapidly changing market conditions. The complexity and attendant knowledge and expertise required to develop and deploy EAI technologies can make for rigid, expensive-to-maintain integration. That’s what these technologies purport to avoid. These tools can deliver on their promises. The solution is to have a solid architectural footing and plan before beginning to deploy such a solution. Without an overall architecture and commitment to EAI infrastructure, the idea that EAI tools can be effectively deployed to solve tactical problems is misleading. For any but the largest projects, the cost and complexity of deploying a comprehensive suite of EAI tools cannot be justified; the expertise needed is out of reach.

EAI Pitfalls

What are some difficulties companies encounter when trying to deploy EAI technologies without a commitment to the concept and a plan for how to deploy it? The pitfalls fall into several categories:
• Development vs. deployment and operations
• Inflexible deployment
• Prohibitive infrastructure costs
• Difficulty in demonstrating Return on Investment (ROI).

Development Tool or Operating Environment?

It’s critical that the use of EAI tools is seen as a decision that crosses many boundaries from an architecture standpoint. This isn’t a decision about developer productivity, though that’s frequently a driver of the decision. It’s about creating a flexible, reusable infrastructure of application services. This services infrastructure has to be designed to promote flexibility and rapid reconfiguration of business processes. It also needs to have, as a core design criterion, interoperability with other infrastructure elements.

This reusable infrastructure needs to support long-term operability and recoverability. These seemingly obvious decision factors frequently get overlooked. What happens later isn’t pretty. The architectural deficiencies usually aren’t discovered until well into the testing phase and remediation is disruptive to both project budgets and timelines.

A good example is the problem of tracing a transaction from source to destination. Good development practices call for using the integration Application Programming Interfaces (APIs) provided by the vendor of the packages being integrated. This ensures that any required processing logic be invoked before populating the application’s database with the data being brought in. Frequently, these APIs will generate data to be stored with this external data, such as serially assigned Purchase Order (PO) numbers. Even if the data coming in already had a PO number, systems such as SAP may require the assignment of a new, unique number. If the API processing fails, the original PO number or other transaction identifier could be already lost and difficult to trace.

In a complex, high-volume environment, these sorts of problems could quickly undermine confidence in the system. Imagine an environment where one front-end Web application server passes information to five different purchasing and accounts payable systems and one of the updates fails. Even if the transaction can be traced and corrected, how can the integration be re-run without double entries or inconsistencies between the original transaction and the corrected transaction? Clearly, tracing ability and recoverability are key capabilities that must be designed into an integration architecture.

Inflexible Deployment

To provide flexible support for processes and reconfiguration, the integration architecture and tools chosen to support it must allow abstraction of business objects and rules. This abstraction requires a clear understanding of the application landscape. Any organization that’s deploying EAI tools faces a heterogeneous application landscape. Reliable, flexible integration cannot be achieved without an abstracted model of the business objects that are updated and the methods for updating them.

Organizations need to define Canonical Business Objects (CBOs) to facilitate integration. This should be independent of creating the integration and should be based on the organization’s data management architecture. A CBO is a superset of the definition of that object in each of the applications within the landscape that requires that type of object to function. A good example is an employee object. The CBO definition would contain a superset of all data elements of all employee data types in all affected applications. It would also contain the rules required to convert the canonical object into the Application-specific Business Object (ABO). These ABO definitions would correspond to the data needed to feed the APIs or other programs required for the integration to succeed.

This abstracted business object model needs to be dosed with a little practical reality, too. Theoretically, it’s fine to create and populate this central business object and it should not matter where the data is coming from or going to as long as object methods are used. However, avoid any design that requires bi-directional synchronization (or even M:N updates). Using front-end or back-end integration should reduce the need for this; otherwise, the issues of tracing ability, recover-ability, and operability will again threaten to undermine process integrity.

For example, simple rules for master file updates must be developed and followed to avoid the need for bi-directional database synchronization. For every master file or type of record within a master file, there needs to be a single source for the master information. That single source would then be responsible for propagating data to all systems requiring that information. This can usually be accomplished using a publish-and-subscribe model. Propagating information from one master file to another system and then from there to a third should be avoided to manage complexity.

Unfortunately, in large, complex environments, there will be multiple places where the same data is needed. Many companies use SAP for financial systems and PeopleSoft for Human Resources (HR) and payroll. SAP requires HR data to drive workflow, messaging, and other aspects of the system. So a successful system needs to state explicitly for each data element the point of origination and when and how updates are made to this HR data.

Sometimes, the master application won’t collect or provide enough information to create a complete ABO in another system. For these cases, front-end integration could be used to gather the additional requisite information from the user or back-end integration could be used in a “request-reply” fashion to elicit the required information from other systems. The front-end integration would require creating a Web page that mimics the look and feel of the master application, but gathers those data elements not needed by that application. It then uses the APIs or application native code to update the master record while simultaneously populating the CBO with all the gathered information.

The choice of using a Lightweight Directory Access Protocol (LDAP) directory, Operational Data Store (ODS), or Random Access Memory (RAM) to store the instantiation of the CBO will depend on the organization’s technical architecture and objectives.