We, the People

Before you can tackle the technical aspects of EAI, you must unite the people involved

By Moshe Japha

Much has been written about the glamorous and technically elegant aspects of enterprise application integration (EAI), middleware, supply chains, APIs, and CRM. A naive reader would wonder why getting these applications hooked up has taken so long. In fact, as has been the case with every much-touted silver bullet since the IBM 360, the stickiest issues have more to do with people than technology.

As challenging as it may be to make automated processes talk to each other, guarantee that every message published reaches the desired subscribers, and synchronize different vendors' standards and protocols, these issues pale compared to the age-old issue of getting human beings to line up and work together.

Because the "e" in EAI stands for enterprise, the people issues are magnified. A significant EAI effort can rarely succeed without redesigning key business processes. Such a major change must be well managed in order to counter the inevitable resistance from the players affected.

This column will discuss some of these people issues. By considering the points raised, you may be able to save your EAI projects from a host of pitfalls waiting to snare the eager, but unwary integrator.

Business Manager Resistance

For those who deal with the technical problems of sharing data and processes between applications on a daily basis, making significant investments of money and people in an EAI project may seem like a no-brainer. However, a business manager may have some reasons to hesitate.

The trust issue. Few people, whether on the business or technical side of the organization, will argue with the need for EAI. Duplicate customers, inaccurate addresses, and inconsistent account balances - all under ubiquitous Web scrutiny - are strong motivators for a solution. However, in many organizations, the IT department's reputation for effective solutions to sticky problems is less than stellar. Whether or not it deserves this reputation is irrelevant. Impressions govern more management decisions than facts do.

With the financial markets' recent epiphany that profitability is indeed an important measure of value, business managers are being held more accountable for their ROI and expenditures. As a result, they have an incentive not to invest in what they see as an unproven technology with uncertain chances of success. Technology for its own sake has lost its attractiveness. Being first is no longer seen as being best. (See Jim Collins' article, "Best Beats First," Inc., August 2000, where he convincingly proves that being last but best is still preferable to being first at all costs.)

The enterprise is a hard nut to crack. Overcoming this resistance requires direction and support from the top levels of management. However, selling enterprisewide efforts has always been hard. When James Martin first introduced Information Engineering Methodology in the 1980s, it was envisioned as a "waterfall" approach. The entire enterprise would be analyzed to build the information strategy plan, which was then broken down into multiple business area analyses (BAAs). A BAA would analyze a defined business area's data requirements, business processes, and their interactions. After this, each BAA would be broken down further into business system design (BSD) projects. BSDs were then implemented as individual systems.

As originally conceived, this method had no feedback loop to previous levels. Organizations quickly learned that too much was learned from the downstream processes to freeze uphill decisions. Eventually, the enterprise scope of the methodology deteriorated in all but the best-run organizations. Often, the CASE tools spawned to support the methodology were used only at the departmental level. The enterprisewide data model is still an ideal that few organizations realize.

This fact of organizational life illustrates the difficulty of selling and implementing enterprisewide efforts. Good change-management technique dictates a gradual approach, with numerous mid-course corrections based on the lessons learned along the way. Localized successes by early adopter departments are publicized, emboldening other departments to take the plunge.

This creates a catch-22 for EAI. By its very nature, its scope runs across the enterprise. But on the other hand, cross-organization collaboration is inherently risky and hard to implement. Herein lies our challenge.

The incentive issue. Even if executive management believes in EAI's merits and dictates cooperation with EAI efforts, the organization's incentives have to be tuned properly. If along with this directive, managers must still meet aggressive performance measures against their other objectives, a conflict arises.

Managers tend to focus their attention on those projects that single them out for their results. A major EAI effort will inevitably affect a department's short-term effectiveness. It will distract key people with the research and decision-making required, data cleansing efforts will have unanticipated effects, and systems may be unavailable at critical times. On the other hand, characteristic of joint efforts and directives to cooperate with others is that fixing blame for failures is hard to do. "Success has many fathers, failure is an orphan" applies most appropriately here.

Politics at work. Managers trying to maximize their most sensitive measures will be able to hide their lack of dedication to the joint effort with little risk of taking the blame. Politics will begin to affect the project. Senseless delays and excuses will impede progress. Resources will suddenly become unavailable. Disagreements will break out over previously agreed-upon issues.

Political activity in an organization is not inherently bad. Politics balance the myriad agendas of all the individuals in an organization. Without effective politics, any sizable organization would have a hard time accomplishing anything of value. Effective managers understand what's important to their peers, managers, and subordinates, and provide incentives for them to follow the manager's lead. They tailor their programs to enable these incentives to do their job.

However, politics turn negative when a player's goals are counter to the organization's, or a player uses dishonest or deceptive means to accomplish those goals. Politics are often blamed for project failures and delays, when in fact, they are merely the symptom. The organization's incentive system is usually the cause. (See Figure 1).

Therefore, to avoid the catch-22, executive management must not only dictate business involvement with the project but also devise appropriate incentives and measures to encourage it. Once these are set, the political machine will do the rest.