Cures for Complexity Lacking

A recent IT Business Canada discussed four approaches used by CIOs to reduce architectural complexity. According to the article, these approaches are:

• Business Process-Driven Architecture
• Good Governance
• Defaulting to Simplicity
• Continuous Improvement

These ideas all sound good and they might be. But we can't tell what, if anything, they have to do with reducing complexity because the article never defines complexity. There is no model, either explicit or implicit for what complexity looks like in an enterprise architecture, how we might measure it, or how we would know we had eliminated it. How can we eliminate something unless we know what that something is?

Imagine this dialogue:

Sam: My house has way too much wazine.

Dan: What's wazine?

Sam: Wazine is wazine. Everybody knows what wazine is.

Dan: How much wazine is in your house?

Sam: I have no idea.

Dan: How much is a good amount?

Sam: Beats me.

Dan: How do you measure wazine?

Sam: Don't know.

Dan: If you don't know what wazine is and you don't know how much of it you want and you don't know how to measure it, how are you going to get rid of it?

Sam: Simple. I'm going to exercise more, eat a better diet, call my mother twice a week, and balance my checkbook every month.

Dan: That all sounds great. What does that have to do with wazine?

Sam: What's wazine?

Silly, isn't it? And using a word that sounds impressive, like "complexity", doesn't make the conversation any less silly.

Now don't get me wrong. I am all for controlling complexity in enterprise architectures and IT systems. I just believe that you can't eliminate something until you understand what that something is.