Conway’s law is named after Melvin Conway. In a work not solely related to IT systems, Conway observed that
organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations
If you are interested in more background and context this is a good article.
The way Conway’s law is often applied to IT systems is that when you examine the systems implemented at an organisation then the boundaries that exist in the organisation are reflected in the software. An organisation that has a clear boundary between Sales and New Product development departments for example, is likely to have separate systems supporting those business units. The implication is that organisation structures have an implicit influence on enterprise architectures. Another interpretation is that an architecture is more likely to be successful if it complements an organisation’s structure as opposed to one that works against it.
Conway’s observations also support why there is often significant IT impact when an organisation restructures or during acquisitions and mergers. A previously successful enterprise architecture can cause friction as the organisation it worked best for is no longer present. As structural changes in modern organisations are common, Conway’s law should act as a reminder to ensure that architectures are adaptable.
Conway’s law is more than an observation – it can be used as an architectural tool in a couple of ways. Firstly, you can assess your architecture or design against the structure of the business it is intended to support. System interfaces should loosely map to organisational and communication boundaries. If a component spans organisational units, you can ask yourself whether it is appropriate. Each business unit may have a different set of often conflicting requirements and priorities and they may change at different rates. Is sharing the same component still a good idea? Secondly you can use Conway’s Law as a guide to structuring your development team. A decomposed architecture could be split into features or components and teams can be aligned around particular features.
However, you look at it Conway’s law implies that the architecture of a distributed system and the organisation structure in which it is deployed are linked. For example, if there is an organisational imperative to deliver a Service Oriented Architecture the topology of the services should be aligned to the organisation’s structure. If you have the perfect service topology which doesn’t fit the organisation structure, then the organisation needs to go through a business transformation. However, it is more likely that your project cannot drive such a large change to the business so your architecture should align around business boundaries. You can use the organisation structure to define boundaries and inter dependencies. You can also use it to determine potential service owners.
You can use Conway’s law to find potential problems in an architecture or to understand why there is a certain degree of friction between your IT and the business. Recently I was involved in a SOA approach where the services were focused around key enterprise data entities. However, the organization business units tended to use lots of different data entities and in some areas there wasn’t clear ownership for them. The service topology was not aligned with the business. This was demonstrated when business owners didn’t want to take on full ownership of particular Enterprise services – they only wanted to deliver the bits they cared about and not consider any wider requirements. What resulted were services customised to the particular needs of a single business unit, making it not reusable across the organisation. Conway’s law should have told the organisation that if they wanted to have a suite of common services then they needed clearly identified parts of the business to own those services rather than try to find an owner within the existing structure.
So Conway’s Law has a role as an Architectural tool, but does it have other uses?
When organisations are starting on an Agile transformation, they often start with projects. A candidate project is chosen that become an exemplar, a model for how Agile is done in the business. However, many large organisations still have a least one foot firmly in the Waterfall camp, they have PMO’s and service gates and governance, ergh!
So soon the Agile exemplar is asked to fit a fixed scope within a fixed time window. The wider organisation starts to set expectations about what will be delivered when, well before the delivery date. The project has to jump through service gates. What do you mean you have started coding? Where is your Business Requirement Specification? You haven’t had architectural sign-off yet! Service Gate X demands it.
Conway’s law predicts this friction, because the project delivery methodology does not fit the way the organisation is set up. Programme management has to work in a different way, project governance changes as project don’t have a define start middle and end any more. In a highly transformed Agile environment there isn’t a concept of a project any more, isn’t is more likely continuous streams of change.
The key message is that Conway’s law says that you are not going to become an Agile organisation by simply trying to deliver projects using Agile Methodologies. Instead you need an organisational change. The organisation needs to think Agile to be Agile.