For Architects, Developers, there’s an overwhelming tendency to come to a meeting and answer a question verbally.  Once the meeting is over, the answer might be in someones notes, or it might have just drifted across the room and dissipated like smoke against the far wall.

But when you have to answer a question in writing … woah! much different kind of work. You wind up worrying about not just correctness, but completeness.

Correctness

Is what you’re saying about this integration technique, that compatibility of container management software, this method of data movement, the resilience of that batch processing job management tool, etc. etc.. You have to go out and check. Find some references to give a more confident answer than just out of your hat.

Completeness …

Have you answered the entire question? If one does it right, it winds up being like an “Architecture Decision”. Yes, some companies, teams, have a standard template for these (as they should). Templates are good. Checklists are good. Keeps people standardized and elevates quality (if well-managed).

Should list rationale, risks, business functions affected, alternatives, why alternatives were not selected. A reasonably thorough treatment of the subject.

In a checklist about some “how to do this, what to use, which technology to use, etc. etc.” These can be seen as “Design Decisions” if at a low level of detail that is not “architecturally significant”, or they can be seen as Architecture Decisions. Maybe some other flavors. But they have the common need to be of a certain quality, correctness and completeness, and they need to be filed and accessible over time and use by a governance process, so that 12 or 18 months later, a team talking about the same or similar subject again can go back and review some quality information about what was talked about – decided before.

Maturity

As with any standardized process, it gets better and easier with time/experience. The Template/form/checklist matures with time and experience. The culture of the IT Architecture or Implementation teams get better over time. You’ll see this stuff incorporated into many packaged methods (‘methodologies’). It can be developed raw and not rely on being part of some existing method.

It’s good stuff and will help mature your entire organization.