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.

A MODEL CUSTOMER

Figure 1 shows a high-level conceptual data model that describes the intricacies of the Customer subject area. Here is a description of each subject area:

Organization. The first main point is that your customer is really just a type of organization, and the same organization may be your customer and vendor at the same time. The information pertinent to the organization will be kept distinct from customer-specific information about that organization, such as purchase amounts, number of accounts, and so forth.

Organization relationship. Organizations are not monolithic islands; they have multiple relationships with themselves and other organizations, as modeled in the Organization Relationship entity.

This construct supports information about an organization's internal hierarchy and the relationships between various levels of that organization and their counterparts (for example, the relationship between your billing department and your customer's accounts receivable department).

Contact, contact role, and contact method. An organization may have many contacts, each for a given role. The relationship between Contact and Contact Role is many to many, because one contact may play multiple roles (new accounts and billing issues). Each contact may be reached in multiple ways (contact method) such as cell phone, fax, office phone, email address, and mailing address.

Location and address. Organizations often operate multiple locations (stores in a retail chain, buildings in a manufacturing campus, distribution centers, and the like). All of an organization's facilities in a given city may also be considered as one location. Therefore, each location may have multiple addresses, and an address may house multiple locations.

Customer and account. By the time you finally reach Customer, most of the peripheral information has been handled. Your integration effort will let you define your organization's various customer views to the levels needed.

Dealing with customer granularity is partially handled by realizing that the accounts the customers maintain are distinct from the customers themselves. Each account may service multiple customer locations, and vice versa.

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.

What Is a Customer?

Once an EAI project has organizational momentum, one of the first inevitable questions is "where do you start?" Most organizations, trying to reach the ideal of customer orientation and CRM, will respond, "The customer, of course!"

But just what is a customer? If you ask someone from accounts receivable, you may hear, "Every account I send a bill to is a customer." To which the marketing folks may reply, "But Conglomo Enterprises Inc. has 25 different accounts with us in 10 states and a few more in Canada. As far as I'm concerned, it's one customer, not 25!"

Then the vice president of Sales pipes up, "But I need to keep track of Conglomo as different customers because I have 10 different sales reps calling on it, each in their own territory. I'd love to be able to treat it as one customer, but my sales system won't pay commissions to sales reps in different territories if it's entered that way. In fact, I'd really love to have an organizational cross-section of such a large company, so I can sell to each area appropriately."

You and the whole team of very rational business people have become hamstrung by the suddenly enigmatic question, "Just what is a customer?"

Now assume that through generous use of your world-class facilitation skills, by the time the team breaks for lunch, you have arrived at a consensus for defining a customer. You've all agreed to define the customer at the most granular level, with all of the hierarchical relationships applicable in the real world somehow tracked and managed by the systems integration folks.

Business Decisions

Everyone is feeling very accomplished until your IT representative speaks up, "Fine. We're up to the challenge. But how are we going to match billing customers to marketing, sales, and call center customers?" As the glassy-eyed faces around the room echo in unspoken incredulity, one voice ventures, "I thought you had tools that can do that automatically?"

The IT representative replies, "Oh, some spiffy tools are available, but they can't make business decisions. Depending on how tight you want the matching parameters, you still need a decent amount of manual matching."

Similar names may actually be different spellings of the same company (Ford and Ford Motor Company) or different companies altogether (Ford may refer to Ford Street Garage and Diner). Addresses, phone numbers, and contact names all help, but still are not perfectly analyzed by automated tools. The IT department needs help understanding the business rules governing how to define the same customer, which returns the ball squarely to the business' court. The sidebar, "A Model Customer," illustrates the complexity of the customer structure.

By the end of the afternoon session, everyone realizes that the original question - "Where do we start?" - remains unanswered. You can't just integrate customers; you need to pull in addresses and contact information just to match customers. That means reconciling different spellings of names and addresses and inconsistently updated data, and dealing with some very old systems to boot.

The IT representative sheepishly mentions, "Those systems probably have some pretty dirty data. Determining what's right and what needs correction will need a lot of analysis. Even what's right may need adjustment to fit the new business processes. Some of this change can be automated, but many require a business decision."

Facing the Consequences

The realization sets in that an enterprise-level, soul-searching exercise is in store. The many short-term, timesaving decisions collectively made over the last few decades are coming home to roost. By not addressing cross-functional data needs, most organizations have taken the relatively simple approach to data management for many years. Continuing to look for short-term solutions to an increasingly complex situation will just mean more fingers in the dike.

People need to sit down and really understand how they view their customers differently from other parts of the organization. They will then need to reconcile their view with others to come up with a single enterprise view of the customer. Only then can the technical team take the ball and run with it.

This painful realization must be globally reached before EAI can be more than an academic exercise. Customer orientation implies changes to business processes. These are then followed by technical changes to support them. The technology only enables implementation of the business plan.

Here again, the success of the EAI effort rests with executive management. It goes beyond realigning incentives to encourage cooperation with the EAI effort: The executive suite must develop and communicate the strategic and long-term vision of the new customer-centric enterprise before the rest of the organization can make the myriad detail decisions that depend on them.

This column has discussed the need for decisive executive direction in tackling the organizational issues on which successful EAI depends. My next column will explore an approach to actually tackling the integration effort "in the trenches."

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.

Return to Article