Technical decisions, project goals, specifications, and restrictions frequently are communicated in large Microsoft Word documents, extensive paragraphs, and many tables with change control.
I regard it is not the best approach to share knowledge, decisions, and establish a convenient work environment around a project and their members, I have two reasons that support my thoughts:
No one on your team is going to read and memorize a 50-page architecture document.
We are living in an environment that demands cross participation or cooperation instead of accepting a lot of instructions ruled by the architects or technical leaders.
According to that, I recommend a few ideas to be agile, have effective communication, leadership, and simplicity in complex scenarios.
Tools to transmit thoughts
Use diagram modelers in order to communicate your ideas and workflows. Often this method promotes a better scope understanding and allows identifying several restrictions at first sight.
Options: Visio or Enterprise Architect, and so forth.
Post-it notes or whiteboarding
Architects, leaders, developers into a room in order to draw, divulge, and share technical considerations. At the end of the session, you could want to snap some pictures and share them with the team in order to provide valuable stuff for reviews or future discussions.
Expose details about architectural decisions
After taking all the conclusions, concerns, concepts, or opinions, it is time to expose the framework or approach, involve the technical people in the architecture process, and validate if we are in a good shape regarding the needs of the project. A collaborative environment will improve communication inside the team.
Repeat the process. Architectures do not have to be rigid.
Medium
Top comments (0)