When to stay redundant

Jack Van Hoof asked, in the reply to yesterday's post, if it is always a good idea to reduce redundancy.  His question centered around business flexibility: if the business wants to grant independence to a division, or sell it off, doesn't it make sense to keep things seperate?

As Jack correctly points out, this is a business concern.  Rightly so.  There are excellent business reasons for both redundancy and simplification. 

I would add, however, my humble opinion.  (it is my blog, after all).  The majority of duplication and overlap is not in place because IT was so well aligned with the needs of the business that it intentionally kept the systems seperate.  Redundancy is usually a function of either organizational boundaries or funding sources or both.  Granted, this could end up serving the needs of the business, but sometimes it does not.

Microsoft has not been broken up.  We are still growing in revenue and expanding into new markets.  In the markets we compete in, we are usually pretty successful, although not always, and we are far from 'number one' in a wide array of competitive spaces.  We need to innovate and succeed in each one to serve the stockholders.  So we need flexibility.

But to Innovate and Succeed, we need to know more about who our customers are, why they buy our products, what they think about them, and what we can do to better meet their needs.  A great deal of 'information' is encoded as 'data' in literally hundreds of incompatible systems.  If Microsoft IT wants to do the company a favor, we should start by getting the heck out of the way.

That means reducing redundancy in information about out customers, partners, products, services, and programs.  That's our big fight.  But that isn't the big fight of every corporation.

If your company makes bread mix and grain-based industrial additives (I know one that does), it makes sense to keep the divisions seperate.  Customers are different, marketing is different, future of each division is likely to be different. 

To be fair, in this organization, I'd expect to see different IT teams reporting to different company presidents or vice presidents that literally don't speak to one another very much (except in the financial integration needed to be a public company).

On the other hand, if you are working at the Government of a State or Province (like Washington State or Manitoba), you have a single set of customers (your residents and taxpayers) that you need to reach out to.  I'd expect to see a good bit more integration and a good but less redundancy.  That is rarely the case.  Normally, entities at the provincial government level are extremely independent and share only basic financial systems, not 'customer' data, 'service' data, or even 'location' data.  I'd say that this situation is ripe for simplification.

Another thing often overlooked: I'd like to see less redundancy between federated systems between local and state government.  Integration should allow a local government agency to access data from state databases in real-time, message oriented, transactional service interfaces.  Basic data.  Primary key kinds of stuff.  I'm not saying to make this data 'public' but I am saying that our governments act so independently that it increases costs to us, the taxpayer.  This has happened in the USA in Justice-oriented data streams, and is happening in health-related areas to a limited extent, but not in other areas like revenue collection and social services.   It's a mess, and it costs money to keep it broken.

The same goes for IT in a large corporation.  The balanced scorecard needs to reflect a balance that makes sense for each company.  There is no "universal" balanced scorecard.

So, Jack, I agree.  Each company needs to make strategic choices about how to keep their marketing, sales, support, services, and customers data.  The point is to make sure that the choices are actually strategic, and not just a function of organizational structure or funding sources.  Sometimes, organizational structure works against the strategies, not in favor of them.  As long as we are aware of this possibility, and keep our eyes open for it, we can make good decisions on when to consolodate functions, systems, and data.