Architects always tell me that their stakeholders don't care about their architecture. So I asked: Did you really explain your structure to them? The answer I got was: I discussed with them a year ago. Because of the importance of architecture, architects hope that architecture knowledge can spread by itself. But the problem is that this kind of spontaneous transmission does not happen. Maybe it's because "important things" are often overwhelmed by "urgent things", maybe because there are some complexities in the architecture itself. Therefore, it is an architect's task to carry out proper architecture communication, but this matter is often overlooked.
1 How much time should an architect spend on communication
This raises the question: How much time should an architect spend on communication? Philippe Kruchten (a well-known researcher) gave the answer in the article " What do software architects do ".
To be successful, an architect or architecture team must strike a delicate balance between external and internal concerns. External concerns include: listening to the voices of customers and users, paying attention to the development of technology, planning a long-term vision, and pushing the development team forward. Internal concerns include taking time to make correct design decisions, verifying and documenting them. Teams that deviate too far from this balance will fall into some traps, which we call anti-patterns of software architecture teams.
Kruchten summarized the three working modes of architects, which can roughly be mapped to the input, processing and output of information.
- Internal work: This is the deep work of the architect, which is essentially thinking and processing information. If you are in a team of architects, this may involve communication.
- Internal communication: The architect must understand a wide range of knowledge, including listening, reading, and asking questions.
- External communication: After establishing new information, the architect needs to disseminate it, including presentations, documentation, and support.
Kruchten believes that the ideal ratio between the three should be 50:25:25. So architects only need to spend half of the time on the architecture, and the other half is spent on understanding the current state and propagating the target state.
If this balance is broken, various problems will arise.
For example, a perfectionist often ignores external communication. Kruchten refers to this architecture as a "gold-plated" architecture. Although the products made are great, they may be outdated as soon as they come out.
Architects who ignore internal and external communication are like being locked in an "ivory tower." Although the finished product may be consistent internally and beautiful enough to make the product owner complacent, it is divorced from reality. The academics are especially prone to fall into this trap.
If the architect ignores the internal work, then the lack of architectural consistency will manifest itself in the entire product. The components of the architecture may be carefully crafted, but they do not fit together well.
Too much attention to external communication turns architects into consultants. Although the developers appreciate the support provided by the architects, there is a lack of cohesive thinking behind the architecture.
In practice, architects don't seem to pay too much attention to internal communication. Such an architect may neither write architecture documents nor provide support to the team. Therefore, they cannot provide any products with surface value, nor can they survive for a long time.
2 effectively spread the architecture
Let's go back to the original question: Why don't people understand the architecture enough? Suppose there is an architecture in which the architect is either "gilded" or in the "ivory tower". In both cases, there is a lack of external communication, so more attention should be paid here. Here are some ideas that are more applicable to me.
Asynchronous propagation
I like asynchronous propagation, and so does Elon Musk, so I am sure that this method is effective.
A major advantage of asynchronous propagation is that it has better propagation. For example, for emails, you can quickly copy and paste or forward information. In fact, written information has good dissemination in general. Other media formats, such as podcasts or videos, are also communicative, but I rarely see them being used in software architecture.
The most commonly used is the chart, but unfortunately, the focus of the chart is too extreme. I have seen many architecture diagrams, which are difficult to understand because of the lack of textual explanations. Some architecture diagrams are actually bad (for example, using inconsistent symbols), but even good architecture diagrams need contextual information.
Good presentation slides have similarities, they are all designed for presentations. For example, Jobs' speech is quite legendary.
There are three icons on this slide, representing three related technologies. In the next few seconds, Jobs announced the integration of these three technologies into the iPhone. The slide is part of the narrative background, but it is meaningless by itself. If the slides you design can be used as handouts, your presentation will be affected.
If you remember what you want to present, you can use the slide as a reminder. Similarly, I assume that most architecture diagrams are only for memory aid purposes. To become an effective communication medium, they need to be given more content.
One way to propagate asynchronously is to use architectural decision records, which I have introduced before. The decision record itself should be understandable, so you can provide people with links to them and let them understand the architecture themselves without explaining to them. Of course, this is not to say that you have to spend more time on external communication, but to use this time more effectively.
Regular briefing
For the past two years, I have sent a briefing to the project members (about 250 people) every week. In addition, dozens of other people will also receive the briefing because they clearly stated that they need a briefing. This shows that at least half of the people are not my target audience because they are not developers. However, even managers like this very much, because the briefing gave them a certain impression of the technology used in the project. My head of department said: "Please don't stop writing newsletters!"
The briefing contains all the things I dealt with in a week. This may be a small tool that I think is not enough for people to understand. It contains a record of new architectural decisions and upcoming or ongoing activities.
The experience of blogging helps to write good newsletters. The first blog post I published on this site was written in 2009, but I had blogged a few years before that. The most important thing in writing a briefing is to be consistent.
I will use some interesting pictures, they play an unusual role in the presentation. Many people told me that they just wanted to see these interesting pictures at first, but in the end they read the entire email unknowingly. In addition, some people told me that watching the newsletter is the most important thing for them during the week.
Writing scientific papers is also very helpful to you. If you can get the correct evaluation from your colleagues, you can train yourself to write a concise and correct briefing. My newsletter only contains a short summary, but also provides a large number of links for further reading of more detailed information. Sometimes I even secretly do some self-promotion, such as adding a link to my blog in the newsletter.
Concretization is a universal language
The book "Made to Stick" introduces many ways to make information easier to remember, one of which is visualization. The book tells about the conflict between the two roles of the worker working in the workshop and the engineer drawing the drawings, which is very similar to the conflict between the architect and the developer.
The workers are thinking, why don’t you come directly to the workshop and tell me how the parts should be installed? The engineer is thinking, what should I do to make the drawing better? Should both parties have more empathy and reach a consensus somewhere in the middle? In fact, this is not the case. The solution should be for engineers to change their behavior. why? As Bechky pointed out, physical machines are the most effective area of communication, and everyone can understand machines proficiently. Therefore, the problem should be solved at the machine level. The moral of this story is not to "simplify things". Workers face complex problems and they need smart answers. The moral of this story is to find a "universal language", a language that everyone can express fluently. This universal language is concretization.
This sounds very similar to our original question. Developers may ignore the architecture because it is not concrete enough for the problem they are trying to solve. The solution proposed in this book is not to allow developers to receive better training, but to allow architects to take on the responsibility of explaining the architecture for specific scenarios.
My briefing also emphasized this point. Because I need to select some details to put in the newsletter every week. Even though these things are not relevant to everyone, they will prompt me to explain the broader architectural background.
Abstraction is an "exclusive product" of experts, a generalization of a concrete concept that has been widely known. However, if the concept is not well understood, there is no point in abstracting it. Therefore, architects should reduce talking about big overviews, at least keep them short.
To communicate concretely, architects need to do a lot of work. But remember, this should only take up 25% of your time. You can use a more propagating asynchronous propagation method, as I made the first suggestion.
3 summary
If there is a lack of communication, the architect should assume this responsibility. If architects notice that people do not understand the architecture, they must improve their external communication methods. In this regard, I have three suggestions:
- Write a well-written record of architectural decisions
- Write a briefing regularly
- Explain the architecture for specific scenarios
At last
I also compiled a set of materials specifically for architects here with the big guys. It is the architecture learning outline of Tencent T3.3. Those who want to get the outline can get the outline and Android learning PDF + architecture video + interview document for free. +Source code notes, advanced architecture technology advanced mind map, Android development interview topic materials, advanced advanced architecture materials**
As the saying goes, a lone tree does not become a forest, keeping an empty cup mentality, stepping out of the comfort zone, and looking in line with the big technology guys. Only in this way can we always have our own core values.
Friends who need it can [join here to get it in a package] .