Subtitle: Design Organization Criteria

Conway M E. How DO COMMISSIONS Invent [J]. Datamation, 1968, 14(4): 28-31.

Download address: hashingit.com/elements/re…

In this paper, Marvin Conway proposes “Conway’s Law”. This document is a study and understanding of the paper.

Since this paper is about management, there may be some mistakes in understanding, so I have to try my best to translate and understand this paper based on my own work experience.

In addition, the paper is not “AIMRD” structure, so the document is translated in the order of the paper, and there is no comparison with other papers.

introduction

“The design of a system” refers to the intellectual act of creating a useful whole from discrete parts, whether the act is creating a weapons system, making a proposal to solve a social problem, or programming a computer, The general activity is largely the same. In general, the goal of a design organization is to create and summarize a document that contains a coherent, structured body of information called system Design, which is called a System design document. Typically, the Sponsor wants to use the system design document to guide his design activities. For example, a government official who wants to pass legislation to prevent a disaster from happening again appoints a team to explain it. Or if the factory needs a new product, specify a “product planning activity” to determine what product should be introduced.

The author gives a definition of “designing a system” and points out that different design behaviors are broadly similar. The rest of the discussion should focus on common or common problems in “designing a system”.

  • From the point of view of the goal of the design organization, the commonality is: to produce a design document, the content of the design document is the information related to “system design”.

  • From the perspective of the role of design documents, the commonality is that “sponsors” can guide their own design production activities according to the design documents.

The subtext is: the design document must be able to solve the sponsors’ problems and meet their needs. In reference to read “1”, pointed out the “system architecture’s goal is to solve the concerns of stakeholders”, the “sponsor” is “stakeholders”, their design and production activities is “concerns, demand”, the output of a system or design document is in order to solve the “sponsors” “focus”.

The paper gives two examples “explaining social issues and product planning activities”, both of which are the needs of “sponsors”. The documents they need are the corresponding “design documents”, the former is the disaster principle explanation document, and the latter is the activity planning case. They look different, but at the level of abstraction of “designing a system”, they are the same in that they take discrete parts and organize them into a whole.

The process of “designing a system” so far is as follows:

The Sponsor presents the requirements -> designates the design organization -> produces the design document -> designs the system according to the design document

Design organizations are not necessarily involved in the implementation of the systems they design. Generally speaking, in the public sector there are policies that prohibit an organization from implementing its own recommendations, and in the private sector the opposite is true. It is reasonable to assume that there is a “consensus” that a design organization implementing its own design or delegating the task to another organization will affect the “design choices” made by designers (in design documents). Most design activities require continuous choices. Many of these choices are not just design decisions. They may affect the future of the individual designer. As we will see later, in some traditional management environments, there are incentives that encourage designers to make decisions that violate the “sponsor’s intent.”

From the perspective of “implementation process”, the commonalities are:

  • Implementing a design document requires a continuous choice between being implemented by the document’s design organization and being implemented by others, and the difference between the two affects the “design choices” in the document.
  • The choice is not only about “design”, but also about the future of the individual designer, and this is related to the management environment in which he works.

Personal Understanding:

The meaning of “choice” here should refer to the decision made by the designer when writing the design document after weighing the pros and cons of some issues, such as why a feature is designed this way rather than that, why a feature is made for this team rather than another team. Obviously, if Organization A presents A design document and Organization B implements it, then during the implementation process, Organization B will not implement it 100% according to the document. It will make changes according to the specific situation and interests.

stages of design

In this section, the author introduces the early steps of designing the system and the whole design life cycle.

The initial stages of design work focus on The structuring of The design activity rather than The system itself. A complete design activity cannot be implemented until some identified, preliminary milestones (early steps) have been passed. The initial design steps are as follows: 1. Understand the boundaries imposed by sponsors and the real world on design activities and systems. Arrive at (form) an initial concept of the system’s organizational work so that task groups can be meaningfully assigned/configured.

There is some upfront work to be done before implementing a design document, which is more about “design activity composition.” The preliminary work includes:

1. Understand the boundaries imposed on the system by the sponsors and the real world.

Sponsor “boundaries” are well understood: Sponsor requirements are the business boundaries of the system, such as domain boundaries in DDD.

Why does the real world impose boundaries on the system?

Personal Understanding:

  • The objective conditions of the real world determine whether the demand boundary of sponsors can be realized.
  • For example, in the system, service A depends on service B. However, in the real world, there may be no dependency or even hostile relationship between the organization providing service A and the organization providing service B, which will affect the design of the system boundary.

2. Arrive at a preliminary idea of how the system is organized so that task groups can be meaningfully divided.

The organization of the system, such as assignment of tasks, requires consensus on some concepts in the system, such as unified terminology, unified task priority, etc., on this basis, the work can be subdivided and then assigned to different groups to participate in the preparation of design documents.

What is the meaning of the term design activity?

Personal Understanding:

Here, the “design activity” should mainly be the behavior of “writing design document”, excluding the behavior of “implementing design Document”. It can be seen from the subtitle of the paper that the focus of the paper is not “implementation” but “design”.

Explicitly or otherwise, we will see later, that the act of “organizing a design team” is itself an indication that some design decision has been explicitly or otherwise made. For any design team organization, there are always some design options that cannot be effectively promoted by the organization because there are no necessary communication channels. Therefore, there is no such thing as a design group that is both organized and free of “bias.” Once you have determined how the design team is organized, you can assign design activities to subgroups of the organization. 4. With each assignment, somebody’s scope of inquiry is 3. The class of design alternatives can be crowded out with 4. Once the scope of activity is defined, a coordination problem occurs. While collaboration between task groups reduces the productivity of individuals in small teams, collaboration offers the only possibility that independent task groups can integrate their work into a unified system design.

As mentioned earlier, you need to do some initial work before you organize the design team.

Thus, when “putting together a design team”, you have already done the initial work, such as understanding boundaries and agreeing on concepts. This means that some “design choices” have been made and these “design choices” are biased, for example, as to why boundaries are understood this way and why consensus is reached. Organizing the design team to comply with these design alternatives will only advance the alternatives that apply to those design choices. A class of Design alternatives that do not apply to that design choice are difficult to advance in the team because the team organized without leaving communication channels for alternatives.

Therefore, there is no such thing as an organized and unbiased team.

The author goes on to point out that once the design team is organized, it is possible to assign tasks to subgroups within the team, and each assignment results in fewer and fewer alternative designs and problems with collaboration between task groups.

Personal Understanding:

When we follow certain “design choices” to organize teams and assign tasks, the system becomes less and less scalable as the task progresses, leading to the exclusion of other alternatives. For example, when we write a design document, each function is limited by its interdependence. As the progress progresses, we will find that even if there are some good schemes, they cannot be used. Because the overall system design framework has been determined, we must choose according to the overall system design, otherwise it will conflict with other functions.

Accordingly, the design of a system life cycle goes through the following steps: 1, 2, according to the basic rules of boundary system preliminary choice 3, according to the concept of the concept of organizational activities and collaboration between the assigned task 4 and task 5, traverse to the child into a unified design a design activity may not directly be carried out in accordance with the steps in this list. Once it discovers a new, superior design concept, it may reorganize (redesign design). This uncertainty is unpopular, and every abandonment of creativity — the creative work that precedes it — is painful and costly. From a historian’s point of view, of course, this process is repeated over and over again, resulting in the phenomenon that there is never enough time to do things right, but there is always time to do them over.

Summarizes the general steps of a system design life cycle with an important conclusion: There is never enough time to do things right, but there is always time to redo them.

The general steps of the system design life cycle are as follows:

Personal Understanding:

Conform to the original design options “to implement the system design, work can advance in accordance with the established plan, fewer and fewer options, combined with the communication problem, can find some better work in advance in the process of the concept of (in order to solve the problem of the front and put forward or use), and then think of refactoring (re organization, planning and design) design activities.

You’ll find that the process repeats itself, implementing one feature, refactoring it later, and so on. From a historical point of view (longer timelines, more sample cases), this is an interesting phenomenon: you never have time to get things right (always better concepts and designs), but always have time to do them all over again (refactoring).

the designed system

This section describes how to describe a system that has been designed.

Any system of consequence is made up of interconnected subsystems. If you want to describe the inside of a system, you need to describe how the system relates to the outside world and how the subsystems within the system relate to each other. One level down (describing subsystems), we can do the same, treating each subsystem as a system and then describing its subsystems. This process can go on and on, narrowing down the scope of the system to be described until the scope is small enough to be understood without further subdivision.

After completing the “preliminary steps”, a system can be designed. It is necessary to describe the system that has been designed. The description ideas are as follows:

  • How does the system interact with the outside world
  • What are the subsystems that make up the system
  • How are subsystems related to each other

The same idea can be used to describe subsystems. The author gave an example of the transportation system, saying, “This is a very heterogeneous system; That is, Subsystems are quite diverse.” That is, a system can be composed of heterogeneous subsystems, as long as they can interact with each other. For example, a microservice application can be heterogeneous.

It may be less obvious that a theory is a system in the same sense. A theory is concerned with the external world of the events it observes, and it must explain the events or at least not contradict them. A theory is made up of sub-theories that relate to each other in the same way. The investigation of a plane crash, for example, tries to produce a theory to explain complex events. It can consist of sub-theories that describe the aircraft’s path, radio communications, modes of damage, and the relationship of events to nearby objects. In turn, each of these sub-theories can be further subdivided into finer details, down to the level of a single unit of evidence. Figure 1 represents a system (theoretically) in the form of “branches” and “nodes”. Each node represents a system, and branches represent interfaces through which the system communicates with the outside and subsystems communicate and communicate with each other.

The author thinks that a theory can be described by describing a system, and a theory can also be regarded as composed of sub-theories, which are also interrelated.

Here suddenly say to “theory” the feeling is very abrupt, if you remember at the beginning of the article, the author has mentioned “a government officials hope to pass legislation to avoid some kind of disaster happening again, then he appointed a team to explain the disaster”, design document contains “coherent structured information body” to associate the theory and system. Design documents contain a “structured” body of information that can be used to guide design activities. This structured body of information is the theory (system design), which explains the cause and treatment of an event (designing a system). To design a system from such a document, the structure of the system should correspond to the structure of the theory.

Then, according to the idea of describing the system, the author describes a system and its theory by using a “linear graph”, in which there are mainly two parts: nodes and branches.

relating the two

Systems are designed by organizations, and this section describes how to relate systems to organizations.

The “linear graph” provides the same abstract form for the two entities we are considering (the design organization and the system it designs), which can be illustrated in Figure 1 by substituting the following words: 1. 2. Replace “subsystem” with “subcommittee”. 3. Replace Interface with Coordinator.

As with systems, we found that design organizations can be viewed at multiple levels of complexity. For example, the federal government is a good example of a design organization… Demonstrates the similarity of the two concepts studied here, since the federal government is both a designing organization (designing laws, treaties, and policies) and a designing system (the Constitution is the primary preliminary designing document).

We can now address the basic question of this article: Is there some predictable relationship between the graphical structure of a design organization and the graphical structure of the system it designs? The answer is: yes, the relationship is very simple, and in some cases it is consistent. Consider the following “evidence” : We randomly select a system and its design organization, and then randomly select the same complexity to graph both. (The purpose of randomness is that if we successfully demonstrate anything of value, it will apply to any combination and to any level of complexity). Figure 2 shows the structure associated with the following states.

For any node X (subsystem) in the system, we can find its design group node X (design team) from the design organization. Generally speaking, each node (subsystem) in the system can be corresponding to a “design node” (a design team) in the design organization through certain rules. It is important to note that this rule is not one-to-one; two or more subsystems can work for the same design team. We can make similar statements about branches. Take any two nodes x and y in the system. They are either connected by a branch or they are not (they either communicate with each other in some way that makes sense for the operation of the system, or they do not). If there is a branch between nodes X and Y, the design teams (not necessarily different) corresponding to the two nodes x and Y must also negotiate a communication specification to allow the two design teams to communicate. On the other hand, if there are no branches between nodes X and Y (subsystems don’t talk to each other), there is correspondingly nothing for the two design groups to negotiate, and therefore no branches between X and Y.

What did we just show you? Roughly speaking, we demonstrate that there is a very close relationship between the structure of the system and the organizational structure that designed it. Often, each subsystem has its own design team, and we find that the linear graph of the design organization and system is the same. In some unusual cases, where design teams design multiple subsystems, we find that the structure of the design organization is a folded version of the system structure: subsystem nodes with the same design team fold into a single node to represent that design team. This “a structure-preserving relationship” between two groups of things is called a “homomorphism.” Like mathematicians, we say that there is a “homomorphism” between the linear picture of the system and that of its designed organization.

Linear figure in this part, the author put the “system” and “design organization linear map”, established the connection between the two there is a “homomorphism” relationship between: system node “subsystem” in “the son of linear graph design team” instead of after, becomes the design of the linear graph, that is to say, the design of the organization’s structure and its design system structure of the linear graph is the same.

systems image their design groups

The previous section pointed out that the “structure diagram of the system” is the same as the “structure diagram of the design organization.” This section continues this topic. As can be seen from the subtitle, the author thinks the system reflects its design team.

It is an article of faith among experienced system designers: any system design, one day someone will find a better way to do the same thing. In other words, it is misleading and wrong to talk about the design of a particular job unless it is in a particular “space, time, knowledge, and technology” context. Maintaining this humility are those who learn from history and experience (system designers), The humility which this belief should impose on system designers is The only appropriate posture for those Who read history or consult their memories?

Example: Omitted.

The author first points out that “any system design will be optimized by future generations” and then gives the example of “compilers for FORTRAN and COBOL”. The authors attribute the leap to the emergence of two groups: small university research teams and independent software companies.

There is an implicit content here: the optimization of system design is not only related to the iterative progress of technology, but also related to the change of design organization, that is to say, the new implementation of the system itself reflects the change of organization.

Therefore, it is reasonable to assume that for any requirement, there exists a family of system designs that satisfy it. We need to know, does the choice of design organization affect the process of selecting from a range of alternatives? If we believe in the “homomorphism” we proposed earlier, we must admit that the choice of design organization affects the selection process of system design solution. To the extent that the communication structure of an organization is inflexible, the organization will eliminate its image in every design product it produces. The larger and less flexible an organization is, the more pronounced this phenomenon is.

There is always a better choice for system design. Choosing different design organizations will affect the selection process for different system designs. According to the “homomorphism” proposed above, the structure of each system design is the same as that of the design organization, so different organizations will choose the system design scheme that meets their own structure. (For example, capitalist countries and socialist countries will choose different solutions to solve the same social problem, because the organizational structure of the two countries is different.)

What is the extent of this influence?

The author believes that the more inflexible and larger the communication structure of an organization is, the more its influence will stamp out an image of itself in the products it designs. After that, the author gave two examples to prove his point of view, as shown in Figure 2.

Personal Understanding:

If the internal communication of the organization is not flexible, the sub-design teams are independent, and the designed subsystems are isolated from each other, the design organization will lose its influence and control over the whole system. The outward manifestation is that this organization has designed a system that doesn’t look like this organization. System of the structure and organization structure is the same, but premise condition is there effective communication within the organization path (branch), linear in the figure, if there is no effective communication path in the organization, so each team design subsystem is isolated and scattered, integration of the system can’t reflect the organization’s overall structure (fragmented and is not the same like the other heap).

system management

In this section, the author applies the previous “homomorphism” theory to the field of systems management.

The structures of large systems tend to disintegrate more during development than those of small systems, and this phenomenon is most obvious when looking at the large military information systems of the past few decades (some of the most complex objects ever designed by man). The rise of an activity called “systems management” is partly a response to this tendency for systems to break down. Let’s examine the utility to System Management of the concepts we present here. Why do large systems break up? The process appears to be divided into three steps, the first two of which are controllable and the third a direct result of our homomorphism. First, the initial designers realized that the system would be big, and some of the pressures in their organization made it irresistible to assign too many people to the design. Second, applying traditional management wisdom to a large design organization can lead to the breakdown of its communication structure. Third, homomorphism ensures that the structure of the system will reflect the disintegration that occurs in the design organization.

The author applies “homomorphism” theory to “systems management” to explain why large systems tend to break up.

The author believes that homomorphism mainly plays a role in the third step: when the tissue disintegrates, it will synchronize into the system and lead to the disintegration of the system.

First, let’s look at the tendency for overstaffing in design.

When the apparent complexity of the system approaches his limits of comprehension, Initial designers (whose design concepts influence the organization of the design effort) are naturally tempted to “assign more people to it.” This is actually a turning point in the design process, where either he can try to reduce the system to an understandable one and win, or he loses control of the system. If there is also external schedule pressure and budget management, the results are almost predictable and the loss of control of the system is inevitable. A manager knows that if he misses his schedule by not using all his resources, he will be accused of mismanagement. This perception puts a lot of pressure on the designer, who prefers to fight “design” (by adding people) rather than delegate tasks in pieces (he feels the cost of risk is too high to take). So, in order to bring in more resources, he was forced to delegate more people to design.

According to the author, one of the causes of “overstaffing” is that designers (managers) dare not split the design due to the complexity, risk and schedule pressure of system design, but can only invest more human resources to ensure the schedule.

Do you still remember that at the beginning of the article, the author pointed out that “design is a continuous process of choice, and some choices are made out of designers’ consideration for their future”. Obviously, when making design choices, you’re more likely to choose what works right now (even if it crashes later) than what’s better.

The following example illustrates another, related approach, in which the environment of administrators (designers, managers) may conflict with the integrity of the system being designed.

The manager (designer manager) must subcontract a crucial and difficult design task to a work team. He could choose two contractors:

  • A small, newly formed organization that comes up with an intuitive and attractive approach that requires a smaller budget;
  • One is an established but traditional organization that demands more “realistic” fees.

He knew that if the young new organization failed, he would be accused of mismanagement, while if the traditional organization failed, it only proved that the task was indeed a difficult one.

What is the difficulty here? A large part of them is related to the way of resource measurement in traditional accounting theory. According to this theory… If the resource is manpower, the unit of measurement is the number of hours each person works multiplied by their cost per hour, The number of hours worked by each man times his hourly cost, summed up for the whole working force.

One fallacy behind this calculation is the “linear” nature of the calculation, which implies that it takes the same resources of equal value for two people to work for a year or 100 people to work for a week (each costing the same per hour). Assuming that two people and a hundred people cannot work in organizations with the same structure (which is obvious), our “homomorphism” theory says that they will not design similar systems; As a result, the value of their work may not be comparable. . The assumption that works in “peel the potato and cut the brick” (traditional resource metering), Testing in systems does not apply to Assumptions which may be adequate for Peeling potatoes and erecting brick walls fail for designing systems.

Parkinson’s Third Law reference Reading 2 plays an important role in the overall design of design work. As long as the manager has the prestige and power to match the size of his budget, he will expand his organizational staff. In the management of system design activities, this is a perverse incentive. But as long as organisations exist, they will be used.

The biggest common factor behind many poorly designed systems today is the usability of the design organization.

The author believes that there are two other causes of “overstaffing” :

  • There are problems with the traditional way of measuring human resources
  • Parkinson’s third law

Traditional human resources measure the complexity of a job according to the linear sum of “people and nature”. As a result, managers choose mature traditional organizations instead of new-generation design teams in order to avoid accusations of mismanagement when selecting teams. The personnel organization mode of mature traditional organizations conforms to the traditional human resource measurement mode, while the new organizations do not. Therefore, under the thinking inertia of traditional measurement theory, managers are more inclined to choose traditional organizations.

In fact, we know that a team of two people has a completely different organizational structure than a team of 100 people. According to the “homomorphism” theory, even if they spend the same amount of human resources, they design different systems. Therefore, the two systems designed by the new organization and the traditional organization are necessarily different and not comparable. It is concluded that the traditional manpower measurement method is ineffective in the field of system design.

In addition, under the influence of “traditional human resource measurement” and “Parkinson’s Third Law,” managers tend to increase the number of team members within their authority (managers believe that if they increase the number of people linearly, they will increase output).

These two reasons lead to the overstaffing of the design organization, which further leads to the usability problems of the organization. (According to the “homomorphism” theory) When the usability of the organization is in question, the designed systems are necessarily fragile.

When tasks are delegated, the second step in the system design breakdown — the breakdown of the design organization’s communication structure — begins. The basics of probability theory tell us that the number of possible communication paths in an organization is about half the square of the number of people in the organization. Even in small and medium-sized organizations, it is necessary to limit communication so that employees can get some work done effectively. In system management, technical research that enables designers to communicate more effectively will play an extremely important role. Common management practices impose numerical limits on the complexity of linear graphs of military organizations. Specifically, each soldier had at most one superior and at most seven subordinates. Because the organizational regulations restrict that organizational protocol restricts communication along lines of command, the communication structure of the organization retains the management structure of the organization. This is one of the reasons why militarized organizations design systems that look like their organizational structures.

In the first step of system disintegration, designers’ pressure and managers’ wrong perception of human resource measurement lead to excessive personnel in the design organization. Overstaffing leads to the disintegration of the second step: the disintegration of the communication structure. Because communication styles in an organization are approximately equal to N22\frac{N^2}{2}2N2, where NNN is the number of people in the organization, overstaffing can lead to exponential growth in communication styles (** Personal understanding: ** The communication mode here is not only the communication channel, but also the understanding and expression of some concepts, etc. Everyone’s expression and understanding of the same concept are different, which leads to the increase of communication cost. Therefore, the concept should be unified before designing the system, which leads to the disintegration of communication mode.

conclusion

The basic argument of this paper is that an organization that designs a system (broadly defined) is limited to producing a system design that replicates the communication structure of that organization. As we have seen, this fact has important implications for the management of system design. We found a preliminary criterion for designing an organizational structure: the design effort should be organized according to the need for communication.

This standard creates problems because the need to communicate at any time depends on the concept of the system at the time, whereas the design chosen first is usually not optimal, so the concept of the system changes over time. Therefore, organizational (communication) flexibility is important for effective design.

An effective incentive system needs to be found that allows managers to keep the organization lean and flexible. A new system design management philosophy is needed that does not assume that simply adding manpower adds to productivity. The development of this new concept will hopefully unearth some fundamental questions about “resource value and communication techniques” that need to be answered before we move on to systems building techniques.

Refer to the reading

1. Every architect should study Conway’s Law

2, Baidu Encyclopedia: Parkinson’s Law

The original address: mp.weixin.qq.com/s/uwNVenflk…