在企业购并后的“混合”环境中，系统集成成为关键

Systems integration is key to the blended environment

Tim Landgrave

Jan 31, 2002


One of the most frustrating things about being the CIO of a company is not being the CIO of the company.

In a recent talk I had with the CFO of a public company, the discussion migrated to issues facing “blended companies”—enterprises where IT management (and many once-centralized functions) is split between a number of “sister companies.” It's a common scenario given all of the recent merger-and-acquisition activities coupled with the purchases of failed dot coms.

These blended companies are more likely to include systems that are “nonstandard” but not necessarily incompatible. (Of course, the term “incompatible system” is inherently flawed to begin with, because you can make almost any two systems work seamlessly by mapping the processes together using an XML messaging engine, a.k.a. a data pump.)

In this article, we’ll look into the frustrations associated with working in a blended company, and we’ll also discuss why a systems integration approach, as opposed to a consolidation effort, can create more manageable blended systems.

Ignore conventional wisdom
When the above-mentioned CFO talked with consultants about the blended-company approach, they all gave him the same advice: Centralize everything. But the attempt to build the classical systems “ivory tower” failed miserably.

A big complaint from local CIOs was that the centralized CIO didn't know their businesses, and after a six-month tryst with centralization, the central CIO became a company CIO, as “that’s where all of the decisions are made.”

The experiment, shepherded by a highly paid consulting firm, was doomed to fail from the start. Why? Because anytime you consider a centralization strategy, you must consider the costs of both technology and human integration (process).

Each of the companies serves a unique market and has its own way of doing business. The move to consolidate for technological efficiency—which actually creates process inefficiencies—is foolhardy. So is there a way to live with distributed IT?

Centralize where tech efficiency equals process efficiency
Whether a distributed team is built of company CIOs or IT managers, the theory is the same. Decide, as a group, on the things that can and should be optimized and managed centrally. These include the following:

• Network topology and protocols: Implementing company-wide policies regarding management of IP addresses, machine names, and domain name service (DNS) should be the first priority. For machines to communicate at an applications level, the underlying systems should be as well defined and standard as possible. This doesn’t mean that implementation has to be centralized, for example. It makes sense to move name resolution and dynamic IP address management as close as possible to the systems using these services.
• Messaging: What almost all blended companies eventually discover is that the human cost of managing and integrating disparate electronic mail and scheduling systems far outweighs the political and implementation costs of standardizing on a single system. The stakes are even higher now that companies need not only to consider mail and calendaring functions but also to have a long-term strategy for implementing secure instant messaging applications and for laying the foundation for reliable application sharing and video conferencing.
• Core financials: No matter what they say, downstream CIOs don’t really want to be in the business of managing their own AP/AR/GL. What they do want is the ability to give users control over divisional reporting (downstream GL), sales and invoicing management (downstream AR), and purchasing management (downstream AP). In the past, it would have been cost-prohibitive to have best-of-breed operational and downstream systems that integrated with best-of-breed centralized core financials. Not so anymore. The emergence of XML and the enterprise application integration (EAI) platform makes installing and configuring such an underlying architecture possible and affordable.

Building the core architectural fabric
Defining the core functions of each business unit and mapping them to a central set of core financials is no doubt a long-term project, although today’s tools have made the process easier.

Yet, the work associated with such a project is nothing compared to the centralized scenario: force-fitting sister companies into a single set of applications; the costs of maintaining separate systems, plus building and maintaining the interfaces; and the operating costs of a single system that creates a massive loss of productivity due to missing or munged functionality.

By the time you’ve developed extensions to the common system to support the business functionality required by each company, you could have built the interfaces required to create the core architectural fabric.

And building this fabric has another important, long-term strategic advantage. Once you’ve defined how your companies operate together and have mapped both the core processes (e.g. invoice creation and management) and how the individual systems map their implementation of the core processes (e.g. System 1 maps its customer name field to the Core Financials AR Customer Name field), you’re much less dependent on any software manufacturers.

For example, say you’re using a specialized manufacturing system at a facility and the software manufacturer goes out of business. You can replace the software locally, but by simply remapping the new software to the core fabric, no other systems have to change the way they operate.

This kind of continual move toward systems integration, as opposed to systems consolidation, will mean that both companies with disparate IT staffs and centralized IT units that have departments with specialized operational software needs (or demands) will consider this approach.