The architect needs to stop designing the system for everybody else
For now, the architect is the only person who really understands what's going on; by allowing the architect to continue to provide designs to everybody else, this problem can only get worse. Documentation isn't going to change this - the architect will always be a bottleneck as long as they are the only one involved in the design process.
Suggest to the architect that s/he should slip back to an advisory role whereby they are no longer responsible for taking these decisions, but instead spending their time mentoring the team, answering questions, reviewing requirements, providing feedback on design proposals and making time to talk other members of the team through the codebase.
Focus on the problem of knowledge sharing, not on documentation
The team may decide that some documentation is useful for their future reference, however this should be motivated by their needs in understanding the system. Keep an open mind about the format of any technical documentation - the team may find find that it's more beneficial to maintain some kind of Wiki or Notes repository where anybody can add useful snippets of information, rather than trying to work around formal design documents.
Avoid taking a simplistic approach of assigning documentation tasks; you're more likely to end up with a large quantity of rather useless documents that nobody will ever read, until somebody digs it up one day and finds that it's heavily outdated, filled with obsolete information, and ends up being deleted.
Instead, put an emphasis on collaboration across the whole team (including the architect) for any matters involving design and architecture - no single person should be responsible for unilaterally taking such decisions, as this is how "silos" of knowledge are created in the first place. Documentation can be a by-product of this approach, wherever it feels appropriate; for example, the team may spend time in a meeting room with a Whiteboard, and may decide that the information on the whiteboard deserves being transcribed into a document (or maybe just a photo of the whiteboard will be enough.)
Open up the system design process to the whole team
Ideally, everybody in the team should be able to have the opportunity to be involved in any discussions or decisions about design/architecture. Not everybody needs to be an expert at everything, but it works best when everybody stays in-the-loop and is encouraged to get involved or provide feedback when new requirements emerge.
When new work is assigned, choose another member of the team to be propose a design, and ask other members of the team to be involved in the review and feedback process. The more people in the team who are actively responsible for continued growth/evolution of the system, the easier it will be for everybody to work on the project.
Reset the architect's role in the team
While the architect will always have the loudest voice, their position should be about enabling the team to make the right decisions, rather than making a decision for the team. For example, the architect may step in when the team can't agree on something. The architect also needs to guard against flawed designs which might risk the stability of the system (the architect is still ultimately responsible for the integrity of the design, so they always have the power to say "no", although it's important that the team understand the reason why something is bad/wrong).
By opening up the design process to the whole team, there are more opportunities for knowledge and ideas about the design and architecture of the system to spread and 'cross-pollinate' to the rest of the team. Over time there should be fewer issues; spreading knowledge means the team and the architect should start to align, and are more likely to converge on these decisions.
This will naturally lead to everybody in the team asking a lot more questions to the architect at first; the architect will always remain a key player in the whole process, but in time the number of questions will decrease and they will cease to be a bottleneck
Some documentation is nearly always valuable
Documents filled with class diagrams, flow diagrams and other such banalities are unlikely to do anything other than burn a whole load of time for something that nobody will ever read, but projects often rely heavily on other kinds of documentation which sit at a higher level than the codebase.
For example:
- Requirements and user/stakeholder expectations - Everybody involved in a project needs to be in mutual agreement about this; it's hugely important for requirements to be captured and agreed somewhere, otherwise you can easily end up with misunderstandings between the team and the end user or stakeholders.
- Acceptance Criteria - developers need to fully understand the bar against which their solutions will be measured. Acceptance criteria should be agreed with stakeholders, so it needs to be documented so that developers have something unambiguous to refer to when testing their solution
- System architecture - it's often useful to have a high-level view which shows relationships between the top-level system components such as databases, web services, 3rd-party APIs, hardware modules, etc. It's also useful to describe the interfaces between those components, as well as describing the function of the main system modules.
- Functional Specification - This should describe of the main features of the system, and enough detail that somebody unfamiliar with the system can understand what those features are for and how to use them. Also consider information such as how to deploy and configure the system, how to start troubleshooting user problems, where to find diagnostic logs, how to backup the system, etc.
