|
||
|
http://www.intelligententerprise.com/010507/cio1_1.jhtml
|
||
Enterprise application integration (EAI) can be a challenging project: Not only must you deal with the myriad people issues, but the number of different subject areas and business functions involved can seem overwhelming. You must have executive business direction and involvement in the definition of key business rules for effective EAI. With these criteria in place, you can determine the initial integration areas that will have the most value for your organization.
My previous column ("We, the People," May 7, 2001) used a hypothetical design session to show why effective EAI requires a common customer definition and the challenge of reconciling the various customer views used by the organization. This design session produced a conceptual model of the Customer subject area (see Resources). The same should be done for the other major subject areas your integration effort will address, such as Bills, Products, and Suppliers. In addition, you must identify the affected business functions, which may include sales, accounts receivable, and marketing.
Let's take our hypothetical design session a little further: The project team has now received full support from executive management. The well-enunciated vision and strategy have been communicated to the enterprise. And with incentives in place, managers across the company are eager to cooperate.
The question remains, "Where do you start?" The temptation is to take all the systems, with all their customer name, address, and contact data, and start integrating. Set up meetings. Schedule deliverables. Get the job done.
Not so fast.
An amateur rugby match played on a muddy, rain-drenched field would look less chaotic. And is about as productive.
You must take an incremental approach to attacking integration issues; you must divide the processes into manageable chunks. First, determine the scope of the project: Are you integrating one location or several locations? Which business functions are you addressing? Which systems need to share information?
Next, you have to plan the effort: On the one hand, you could argue for a horizontal analysis. That is, taking a subject area such as Customers and analyzing it completely across all the business functions in scope. On the other hand, it might make sense to take on a business function such as sales, marketing, or accounting and analyze all the subject areas in question vertically. This approach lets you fully understand a business function's integration and business rules. But each approach is inadequate on its own. (See Figure 1.)
A purely horizontal approach will likely be hamstrung by the lack of perspective that other subject areas provide. A purely vertical approach will be blind to considerations made obvious by other business functions. Therefore, you need a hybrid approach.
This approach starts with prioritizing which business function and subject areas to examine first. You should choose the first business function to analyze based on one or more of the following criteria:
Then, you choose the first subject area using similar criteria. (For my example, I'll choose Customers for its strategic impact.)
Finally, you should decide on another business function that can provide contrast for the chosen subject area. You now have two business functions (say sales and billing) and one subject area (Customers) to integrate. These will become the core of your analysis from which the rest will grow.
Because you will probably not get very far examining Customers without supporting data such as addresses and contacts, you need to start a subproject that will initially analyze these subject areas from the point of view of how they support Customers. In this initial project, you will only examine these subject areas to the degree necessary to help define the primary subject area, Customers, and determine business rules and integration criteria. Completing the task of defining the rules and integration criteria for addresses and contacts will be left for a subsequent project.
The deliverable of this first activity includes:
Once you have completed this project, you can continue this analysis to other business functions, expanding the business definitions and matching rules. You can then analyze the pilot project for lessons learned and develop an integration project methodology for the enterprise. As the program begins to expand, you can launch subsequent projects, building on your initial results. At the same time, the technical team can take over the deliverables of the pilot project to begin the actual integration development and implementation.
Their tasks will not be simple, but at least the undertaking can now proceed without the culture-induced confusion that impedes many integration projects.
moshe japha [mjapha@net2phone.com] is manager of data administration at Net2Phone Inc., a leading provider of voice-enhanced Internet communications services to individuals and businesses. He has worked extensively in data and process modeling, data integration, data quality, and business intelligence applications for more than 15 years.
Raju Kocharekar (rkocharekar@worldbank.org) is business manager of the enterprise computing unit in The World Bank's information solutions group. He has 19 years of professional experience in IT infrastructure management and support.