Adaptability of Large Systems

As I was tweeting the other day, I came upon a tweet from Noel Dickover about large systems being less adaptable than small systems. This began a tweet exchange that I thought brought up some important issues about adaptability.

Many people believe that large systems are harder to adapt than smaller systems. And, in genera, this is true. But system adaptability is not a function of size, it is a function of architecture. When a large system is partitioned correctly so that it is composed of a number of smaller, autonomous systems, then it MAY be more adaptable than a single smaller system.

I say "may", because its adaptability depends on how well it has been partitioned. The key is not whether the partitioning is good technically (say, mapping well to an SOA), but how well the technical partitions overlay on top of the business partitions of the organizations.

In other words, when a large system is built of autonomous smaller systems AND those smaller systems map well to the autonomous processes that occur naturally within the business, then, and only then you have a large system which is highly adaptable.

The reason so many systems fail to achieve this (even when they do manage a reasonable technical partitioning) is that the technical partitioning MUST BE driven by the business partitioning. This requires a partitioning analysis of the business that is completed before the technical architecture of the system is even begun.

This business partitioning analysis is best done by representatives of both the business and the IT organization. The business group has the best understanding of how functions relate to each other and the technical group has the best understanding of how this business partitioning analysis will eventually drive the technical partitioning architecture.

Since both business and technical experts are involved in this exercise, I place this work in the common ground between business and technology, the watering hole that we call enterprise architecture. But it is enterprise architecture with a very specific focus: driving technical partitioning from business partitioning analysis with the eventual goal of highly flexible systems that are pegged closely to the business need and mirror closely the business organization.

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.