The Law of Conway

The GRAAL project (is.cs.utwente.nl/GRAAL)

University of Twente, the Netherlands

15 November 2004

In a landmark article published in 1968, Conway claimed that the structure of a designed system will be isomorphic to the communication structure of the designing system. This has become known as the law of Conway. The reason is simple: If the system to be designed is too large to be understood by one person, then several persons will be involved in the design. But these must agree a work breakdown among themselves.

This work breakdown will be reflected in the structure of the designed system, because each designer will work on his or her own part.

Consequences for infrastructure management

We see this law at work in the way infrastructure is managed. Infrastructure is partitioned into domains, and for each domain, there are one or more infrastructure domain specialists who follow the technology market, translate business strategy into acquisition decisions for their infrastructure domain, and generally manage that domain. In all organizations studied, we found an isomorphy between the infrastructure domain architecture and the infrastructure management department, which was organized according to the same domains. This has an unexpected consequence for any reorganization of the infrastructure architecture.

Propoposition. A change in infrastructure architecture should be accompanied by a change in the infrastructure management structure.

This can be a hindrance to change, because infrastructure managers tend to derive their status, and also their salary, from the number of domains they manage.

Consequences for the business system design department

In the business system architecture, Conway's law implies that the business system layer will be isomorphic to the business system design department (alignment relationship 1). This means that, say, different application areas and subject areas are designed by different design groups. But we already saw that to align business systems to the business, there must be a structural similarity between the two (alignment relationship 2) as represented by the landscape map. (Landscape maps represent the top level architecture of the business system layer.) As a consequence, in order to achieve alignment, the business system department should structure itself according to the business supported by the systems they design (alignment relationship 3). This leads us to the following generalization.

Proposition. Business system alignment is achieved by aligning the business system design department with the supported business operations.

For example, if the business is structured according to departments, where each department handles a set of business processes, then the business system design group should organize itself in the same way. This has the consequence that business system architects are in fact requirements engineers for particular business departments. They build a relationship with that department in which they build up implicit knowledge of user requirements, and develop an early warning system for impending changes in user requirements long before these changes are ratified officially.

The importance of such a relation was emphasized in one of the case studies we did. The organization in question was divided in a number of departments, all of which served a specific part of the company's market. The IT department was organized according to the company's structure: for each department there was a business unit in the IT department that handled all IT related work for the specific department. Each unit had its account managers, architects, software developers and maintenance personnel. The advantage of structuring the IT department in such a way is that specific knowledge about a department is concentrated in one business unit.

At a certain point in time the IT department was reorganized according to the software development process. All account managers were put in their own business unit, as were all architects, software developers and all maintenance personnel, respectively. The original idea was that each member of a business unit (e.g. an architect) can be assigned to projects of different departments, depending on availability of personnel within the business unit. Note that this is in contrast to Conway's law, and in practice meant that specific knowledge of a department's market was no longer available within projects. This problem was solved informally by forming teams within the business units, each of which (again) serving a specific department. When a project is started from a certain department, personnel from the related team are assigned to this project. Although the teams are informal units (and cannot be found on the organization chart), the relation between the departments and people designing systems for these departments is restored, thereby confirming Conway's law.

References

M.E. Conway. ``How do committees invent?'' Datamation, 14(4):28–31, April 1968.