如何开始 

让团队和关键涉众理解什么是软件架构，以及使用单独工件描述架构的价值。参见概念：软件架构。

在对“应该描述架构信息”达成共识后，需要对期望描述什么架构信息以及其描述的形式达成一致。回顾 Artifact：架构备忘录 及其相关指南。对希望文档化的内容达成一致。

下一步，回顾 Concept：架构视图与视点 和 Concept：架构机制。两者对如何定义和沟通架构至关重要。

现在，可以将团队的注意力转移到如何以及何时执行架构任务。

• 如果是新项目，并且处于生命周期的起点，回顾 Task：拟制架构。
• 如果是正在进行中的项目，花些时间记录那些已经制定的决策，并随着开发进展持续完善架构。参见 Task：完善架构。

常见误区

架构工作不应该被孤立的进行，隔着墙将某份架构规范抛给开发人员。这需要过多的文档，并使团队成员难以理解架构为何需要按某种方式工作。成功构建架构是一项需要协作的活动。

对敏捷项目来说，应避免创建巨细的文档。不要被卷入定义正确的架构备忘录格式应该是什么的陷阱。聚焦于描述关键决策以及这些决策的基本原理。在需要的地方引用更详细的文档，而不要重复描述。保持文档的清晰和简洁。保证那些使用架构的人（开发团队）对架构的形式和内容感到舒适。他们是否还需要看到更多或困难的信息？或是相反，他们需要看到的更少？

记录重要的决策。 团队成员可能就在附近，你可以定期和他们沟通，但是团队会变化、软件架构会转移到其它的项目。未能记录的重要决策将在以后引起失败的风险，因为将来的团队成员并无法从当前参与协作的决策中获益。想象一下，作为合作者的未来团队成员，你根本没有机会和他们面对面的交流。