Conway's law was proposed by Malvern Conway in 1967:
"The architecture of the design system is constrained by the communication structure of the organization that produced these designs."
In layman's terms: a product must be a microcosm of its (personnel) organization and communication structure .
Inter-departmental communication is very difficult, and the interfaces of the various modules of the system also reflect the flow of information and the way of cooperation between them.
Conway's law can be described as the first law in software architecture design. At first, it was only published in magazines, and then it was quoted in the software bible of "The Myth of Man-Month" and named Conway's law (Conway's law), so it was promoted. .
It may not be possible to understand the essence of Conway's law only through a simple description. Conway's law in the original text can be summarized into four laws:
The first law of organizational communication will be expressed through system design.
The second law of time can’t be perfect for one more thing, but there is always time to finish one thing.
The third law of linear system and linear organizational structure has potential heterogeneity and homomorphism.
The Fourth Law: Large system organizations are always more inclined to decompose than small systems.
The first law
Communication dictates design.
The way of organization and communication determines the system design.
This law focuses on the impact of organizational structure and communication on system design. Organizational communication and system design are closely linked, especially for complex systems. Only by solving the communication between people can there be a better system design.
"The Myth of Man-Month" summed up the law of exponential growth in communication cost with the increase of personnel: communication cost = n(n-1)/2. To illustrate:
For a 5-person project team, the channel for communication is 5*(5–1)/2 = 10 For a
15-person project team, the channel for communication is 15*(15–1)/2 = 105 For a
50-person project team, communication is required The channel is 50*(50–1)/2 = 1,225 The
150-person project team, the channel that needs to be communicated is 150*(150–1)/2 = 11,175
This is one of the reasons why Internet companies are pursuing small teams.
Communication problems will bring system design problems, which in turn will affect the development efficiency of the entire system and the final product results.
The second law
There is never enough time to do something right, but there is always enough time to do it over.
No matter how much time there is, one thing cannot be done perfectly, but there is always time to finish one thing.
There is never enough manpower, and things can never be done, but they can be done one by one. Isn't this the problem solved by the "agile development" model in the software industry. Faced with such a situation, agile development can achieve continuous iteration, continuous delivery, rapid verification and feedback, and continuous improvement.
No matter how great the development is, bugs will be written, and no matter how comprehensive test coverage is, not all problems can be detected. The solution is not to eliminate these problems, but to tolerate the existence of some problems, and then through appropriate design (redundancy, monitoring, high-availability design) when the problem occurs can be quickly resolved.
A few small developer companies are pursuing microservices and mid-office architecture. Is this the pursuit of perfection? No, it's looking for death.
A good architecture is not bought or designed, but evolved over a long period of time based on the grounding of the business.
Before the system is actually put into production and use, no matter how good the architecture is, it is only an assumption. The later the product is used by users, the higher the cost and risk of failure. However, small steps, rapid experiments through MVP, customer feedback, and iterative evolution Products can effectively reduce the cost and risk of failure.
In addition, many years of experience have taught me that the architecture and platform are not bought, nor can they be obtained with an open source, nor are they designed, but long-term evolution can take root.
The third law
There is a homomorphism from the linear graph of a system to the
linear graph of its design organization. There is a potential heterogeneity and homomorphism between the linear system and the linear organizational structure.
This law is a specific application of the first law. Imagine if the company's organizational structure is like this: the team is distributed, and each team contains roles such as product, research and development, testing, operation and maintenance. At this time, the system is monolithic, and the cost of project communication and coordination is huge.
If the monolithic system is split into microservices, each team is responsible for its own part and provides corresponding interfaces externally without interfering with each other. System efficiency will be improved. This is connected with the high cohesion and low coupling in software design.
**To put it bluntly, you can build a team for whatever system you want, and build a system for what team you have. **If you need a separate front-end and back-end system, you can build a separate front-end and back-end team. Conversely, if you have a front-end and back-end separation team, you can design a front-end and back-end separation system. Of course, it would be great if you can coordinate the management and have the right to reorganize the team or design the system architecture. Under normal circumstances, let the two form a 1:1 mapping relationship, which is more efficient.
The fourth law
The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems.
Large system organizations always tend to decompose more than small systems.
"Speaking of the general trend of the world, the long-term division must be combined, and the long-term cooperation must be divided." The
more complex the system, the more manpower needs to be added, and the more manpower there is, the cost of communication also increases exponentially. Divide and conquer is the solution chosen by most companies. Divided into different levels, divided into different small teams, let the team complete self-governance within the team, and then unified external communication.
Architecture requires more than technology. In large companies, politics is especially needed, the so-called politics of architecture.
Teacher Yang Bo once mentioned in his article "Every Architect Should Study Conway's Law":
"Politics refers to the art of collaborating with others to get things done. Architecture is a social activity. In the world of technology, individualism can easily be defeated, even if your goal is that good technology is the best, and technical decision-making is Political decisions (technical decisions are political decisions), a technological product, one wave of people can do it, another wave of people can also do it, it’s hard to say who does it well, no matter who makes it, it’s all about the business. Handcuffs."
When I first entered the software development industry, the architecture I talked about was mainly performance, high availability, and so on. Now, I have seen countless legacy systems, especially the status quo of domestic enterprise IT, countless highly-coupled legacy systems, and poor architectures that firmly restrict business like handcuffs. The cost of upgrading and replacement is very huge, so I pay more attention to understandable. Maintainability, scalability, cost. I would like to add that it is very important for a startup to get a good architect or technical CTO at the beginning of its business.
to sum up
- The structure is determined by the organizational relationship.
- Architecture must not only serve technology, but also serve people.
- There is no best architecture, only the most suitable architecture.
reference:
https://www.infoq.cn/article/every-architect-should-study-conway-law
https://www.cnblogs.com/still-smile/p/11646609.html