Conway’s law comes argued that one of the reasons so many information systems (IS) development projects fail is the way they share prescribed information flows within the structure of the organization, which in practice may be far from what is obtainable in reality.
In this article, thelawaroundhere discusses how Conway’s Law impacts on the operations of an organization.
Knowledgeable managers and developers are aware of how difficult meeting expectations can be when faced with change and glitches. Formal structures bring about consistency and a means of measuring the profitability of a business but are less reliable when it comes to designing and implementing information systems.
According to Elliott Jaques, a Canadian social scientist, there are two distinct types of organization structure, viz “formal and extent structures”. Jaques argued that when the formal structure fails, people device an alternate means to work and this gives rise to what the “extent structure”. Today, the extent structure is what operates and is often implicit in the reality of the decision-maker, and the owner of a process.
According to Jaques, there is a third way which is rooted in what is termed requisite structure. Requisite structure, otherwise known as “what could be” is specifically what system developers intend to build (applying logical and physical design). Unfortunately, they end up delivering a copy of the current system structure (with all its flaws), and that is where Conway’s law comes in.
What is Conway’s Law?
Back in 1968, Melvin Conway developed a hypothesis based on the way organizations structure their internal departments and lines of communication.
Conway posited that “any organization that designs a system will unavoidably produce a design whose structure is a copy of the organization’s communication structure.”
Conway’s law is based on the consideration that the definition of the interfaces between separate software modules requires interpersonal communication. Therefore, the communication structures of the organizations have a great influence on the structures of these interfaces.
This observation led Conway to believe that organizational structures and their channels of communication should be designed with flexibility which is the key to effective design.
Is Conway’s Law right?
A Harvard Business School study concluded that there was strong evidence to support the correctness of Conway’s Law. In all of the examined 12 products from 5 different application areas (financial management, word processing, spreadsheet, operating system, database system), the coupling of the organizations developing them correlated with the modularity of the products.
Further studies could also prove a relationship between the architecture of a product and the characteristics of the organization implementing it:
- Research by Microsoft calculated the complexity and error volume of Windows Vista from the complexity of the organizational units responsible for the development of Microsoft Windows Vista.
- Rebecca M. Henderson and Kim B. Clark were able to show that product innovations that change the architecture of the product require a change in the knowledge architecture and company structure.
- James D. Herbsleb and Rebecca E. Grinter stated that the work on a modularized system should be distributed so that the separation of the development rhymes with the division of the modules. Hence, duties should only be divided when the parts of the products to be developed are clearly understood and have stable plans, processes and interfaces established.
How does Conway’s Law work?
When a company is implementing a large software system, and has a contracted company with three developer groups, G1, G2 and G3, working together on the project. Conway’s law now states that the developed software system will probably consist of three large subsystems X1, X2 and X3, which are implemented in a different developer group. More importantly, the quality and type of interfaces between the subsystems (X1 – X2, X1 – X3, X2 – X3) are dependent on the quality and type of interpersonal communication between the corresponding developer groups (G1 – G2, G1 – G3, G2 – G3) correspond.
The same also applies on a smaller scale: Assume that software developer G1 has implemented class CL1 for functionality Fu1. Functionality Fu1 is to be expanded later to include a similar functionality Fu2. If the software developer G1 implements this functionality, he will simply add this functionality to class CL1. If a software developer G2 from another group implements this functionality, he will probably fear that the existing functionality will be impaired and therefore implement functionality Fu2 in a (sub) class CL2. The design of the application is therefore highly dependent on who is implementing the functionality.
Example of system failure
The crashing of Mars Climate Orbiter was caused by the fact that the Lockheed Martin development team used the Anglo-American measuring system in the navigation software, while the NASA development group used the international system of units for the calculations of the control of the probe to achieve the desired orbit around Mars. From NASA’s end, however, the crash was less attributed to the error itself than to the failure of the control mechanisms.
The book The Mythical Man-Month by Frederick P. Brooks revealed why the (mythical) Tower of Babel Fail. Brooks notes that a lack of, or poor communication between teams in software development results in functional or scheduling failures.
According to James O. Coplien and Neil B. Harrison in the book Organizational Patterns of Agile Software Development, a project is difficult to enforce if the section of the organization enforcing it fails to meet expected requirements, and the relationships between the organizational parts do not correspond to the relationships between the product parts. It is therefore important to make the organization compatible with the product architecture.
How can an Organization Implement Conway’s Law?
For a firm to get suitable communication structures for the product to be implemented, and thus to get suitable product modules according to Conway’s law, Melvin Conway suggests the following approach:
- Define the corporate mission statement.
- Identify the business processes.
- Adapt the business processes so that they fit the company’s mission statement.
- Structure the IT organization in such a way that it supports the adapted business processes.
whilst Conway acknowledges the point that large system applications can be successful; he also acknowledges a manager will be vulnerable to the charge of mismanagement if he misses his targets without having applied all available resources. This awareness generates a high pressured environment where managers take unnecessary risks as the team strives to adjust to the realities of the situation.
Conway’s original hypothesis as applied to systems that a design effort should be organized according to the need for information sharing between groups and sub-groups does in the main hold true. Having a high-quality, modular design and using it as the basis for assigning work to different groups is good practice. Conway does not claim to understand or have answers to the constraints within information system development. He does, however; highlight the need for flexibility of organization as an important requirement to effective design. The more robust the architecture, the more likely the organization can successfully develop for different applications.