How Conway’s Law can explain a messy IT system

All too often, IT workers are handed a messy and mysterious IT system devised by someone else, a system with no rational structure, little documentation and no explanation of how it got so bad. Conway’s Law can help explain how the system got to that point and help to avoid making similar mistakes in the future.

CIOs, architects and managers responsible for IT systems often wonder - how did we end up with this mess? There’s no decent documentation. No one seems to be responsible for the apparent lack of any rational architecture. A lot of stuff is “due to historical reasons”. Of course, this would never have happened under your watch, but now it’s your responsibility to make some sense out of it. If your system represents a substantial investment, it stands to reason that you’ll want to understand why it was designed the way it is before you take any radical action to change it.

If you’ve ever been in this predicament, give a thought to Conway’s Law. Nine times out of ten it will give you some very useful clues. The law might sound abstract, but it’s actually quite simple and well worth understanding.

Melvin Conway said in 1968 that “organisations which design systems … are constrained to produce designs which are copies of the communication structures of these organisations”.

This ‘law’ has practically unlimited application. In terms of ‘enterprise systems’ (business, applications, information or technology), here is how it can help:

1. Find out what the organisation structure of the design team was. Did separate teams or individuals design different components or facets?
2. What were the boundaries or bottlenecks in the communication processes involved in design?

The clues to the design rationale will often become clear at this point.

Were five specialists responsible, each designing one aspect or component of the system? Then you will likely find five subsystems or components each with a set of responsibilities and minimal dependence on the other components. Each designer was responsible for making his or her own part of the system work.

It’s likely that no one consciously made a decision to break the design into five components, but that’s the result. It may be that the five people involved were the established experts or they may have been given management responsibility for discrete service delivery areas. Whatever the reason, it probably doesn’t make sense when the people have moved on or the organisation has restructured.

Apply Conway’s Law next time you get stuck with a problem like this. Understanding the rationale for the system design will ensure that you don’t repeat the mistakes and means you have a whole new insight into how it can be improved, maintained and managed. It provides you with the ability to learn from the mistakes of others, which is always better than repeating them.

As Einstein said: “We can’t solve problems by using the same kind of thinking we used when we created them.”

*Justin Butcher, Analyst at IBRS, is an advisor specialising in enterprise architecture, solution architecture, business systems analysis and complex systems procurement. He is an experienced enterprise architect and technology architect with more than 10 years’ experience in federal government. Butcher provides insights into the practical application of enterprise architecture to address real issues that face modern enterprises. He focuses on the strategic alignment of technology to business goals and objectives, drawing on experience in software engineering, infrastructure solution design, data architecture and large project architecture leadership.