有了愿景之后，还需要确保组织中的技术领导者能够理解它

有了愿景之后，还需要确保组织中的技术领导者能够理解它。这就需要向关键的开发者介绍愿景，获取他们的反馈。通常，他们比你更清楚某些事情的来龙去脉，也更能帮助你更好地理解架构。你需要愿意并且渴望基于这些反馈调整愿景。如果要对整体架构或者某个特定区域做出革命性的改变，尽量让团队认可这种转变，因为这会让愿景更容易实现。尽量不要让架构成为一种任务，而应该将其看做是一种能够让开发团队建立共识的工具。要让开发团队成为你的合作者或者同盟。因为他们积极地参与远比完全按照自己的想法推进愿景更有价值。

在达成某种程度的共识之后，一定要让所有人都知道当前的架构和将来的架构分别是什么样子。这并不是说要将它们放到磁盘上的某个文件夹、SharePoint 网站或者 Wiki 上，而是要制作海报或者一整面墙的涂鸦，在很多地方展示它们，确保每个人都能够了解该愿景，并激励他们不断地向该目标努力。在架构演进的过程中，这些图画也需要随之改变以反映当前的工作进展。要展示出那些正在提升的地方并认可为之付出的团队。如果其他人对一起构建伟大架构的工作感到自豪，那么他们就会支持你的工作。

建立桥梁

有了愿景之后，你就想它成为现实。但是既然你或者你的团队并不开发或者管理项目，这又如何实现呢？最好的方法就是成为开发团队的合作者和资源。你的目标并不是限制或者阻碍工作的进展，而是促进它。当某个团队开始开发的时候，与他们的技术经理和项目经理沟通，向他们展示更新后的企业架构图，讨论如何让他们的项目实现这一愿景。通常情况下，团队从事的工作与企业正在进行或者已完成的项目相似。架构师应该确保团队负责人了解这些项目，以便于能够在实际的代码和产品中利用共享的经验。尽量不要关注实现细节，不要关心使用的类库及其版本，要关注高层目标和项目设计以及它们与整体愿景的对齐方法。