The Perils of Integration

Thinking more about mini-microsoft and what has been posted by him and his readers, I wonder how much a company's downfall has to do with integration. When a company decides to integrate its systems into one mammoth system, it seems to spell doom. I think the process goes like this:

First, some senior executive decides that everything needs to be "integrated." This could mean that everything needs to work together, run on the same box, or in the same environment, who knows the exact definition?

This decision spawns a massive project and a few reorgs. The massive project introduces hundreds, if not thousands, of dependencies between teams. Managing these dependencies becomes too much for the teams and therefore process has to take over. The system is fragile and buggy, but any change to the system has to be approved by everyone else, and may cause everyone else to recompile or recode their part. Therefore, changes are to be avoided at all cost. It begins to take longer and longer to put out a release.

At this point, the individual teams have lost all power. The power is centralized into a few leadership individuals who make decisions, but don't know the technical details of those decisions and therefore can't understand the ramifications. It's not their fault, there are too many dependencies for ANYONE to understand all the ramifications. The teams can no longer respond to customer needs; they'd like to, but their hands are tied because if they change the Foo widget then it will cause a recompile of 5 other libraries and 2 months of testing - and the testers are already running on empty.

The best programmer's get frustrated. They can see the problem, but they can't put their finger on what exactly is wrong, plus they spend more time filling out forms and "communicating" then they do programming. They get disgruntled and leave for greener pastures. Those who remain are left maintaining systems that they didn't build and changes to the system are slower and more painful than before.

Finally, one of two things can happen, either the company can fold, or some spark occurs and the old, integrated system is left for dead and a project is started to build a new system that relies on customer teams and independence. The best programmers are hired to create the system and it becomes a success. Then the cycle repeats itself again.

Integrated systems are the hardest things to do correctly. As I've mentioned before it is our job to manage dependencies. The best way to manage a dependency is to eliminate it. With an integrated system, you have the potential to create an exponential number of dependencies, thus ensuring the demise of your company. Now, the question remains: how do you create an integrated system correctly? I'm not sure, but I'm going to think on it, so keep checking back here for the/an answer.