Architecture Review

I’m going to roll into architecture review all major systems and tools changes that the team may wish to make. The goal of architecture review is to help socialize big changes to the appropriate group, and to make the risks for those changes clear. Some questions that you may ask people to come prepared to answer include:

• How many people on the team are comfortable using this new system/writing this new language?
• Do we have production standards in place for this new thing?
• What is the process for rolling this out and training people to use it?
• Are there new operational considerations for using this?

And here are some guidelines:

• Be specific about the kinds of changes that need architecture review. Usually these include new languages, new frameworks, new storage systems, and new developer tooling. People often want to have architecture review to prevent teams from designing new features poorly, but it is usually unrealistic to try to catch new feature design early enough in a small company, and it’s hard even in a large company. It also slows things down a lot, and as to our earlier point, you probably don’t want to put a heavy process in front of a common activity like feature design.
• The value of architecture review is in preparing for the review. Asking for review of big changes or additions to the systems forces people to think about why they want to make these changes. Again, one value of these processes is to help make people aware of risks that they may not have considered. You may or may not choose to have the team answer the question of why you should make this change in the first place. I have found that when people are willing and able to get through the requirements for making the change at all, the why is obvious.
• Choose the review board wisely. You want the review board to include the people who will be most affected by the change, not just a static chosen group of gurus. Part of the goal is to get yourself out of the hot seat for making every technical decision, and part of the goal is to make sure that those who will need to deal with the outcome of the decision are part of evaluating it. You want these decisions to consider the wider team, and for the wider team to be bought in on them. There is no reason this needs to be company-wide. The scope of the deciding group is best kept to the people who will be closely impacted by the decision. There’s nothing more demoralizing than having someone from a completely unrelated area veto a project.