架构师必须要学会倾听，并在给出结论之前做一些探索

在讨论项目的时候，不可避免的会遇到技术选型的问题。大部分情况下，团队会倾向于使用与公司其他项目相似的技术。但是，技术人员偶尔也会学习一些新技术，并想使用它们来解决问题。

此时，不要立即对新技术说不，或者主观地认为技术人员选择新工具的原因仅仅是因为它新或者它非常有趣。虽然这种情况确实存在，但也有可能人们为解决问题而创建的新工具正好恰逢其时。应该与技术团队讨论决定使用新技术的理由是否充分。确保团队理解将新平台带到产品中的成本和困难，以及这些付出的回报。

架构师必须要学会倾听，并在给出结论之前做一些探索，通过实际的测量和边界做一些时间可控的概念验证，以此来确定可行性。如果最终发现新技术并不是正确的选择，那就试着与开发人员或者他们的领导沟通，达成一致意见。尽可能地不要让变化成为一种任务，那样不利于你与开发团队之间良好关系的建立，无法确保他们会在将来做决定时考虑你的意见。在实验新工具或者技术的时候，要限制公司在同一时间段内进行的实验的数量，因为同时进行多种实验很难精确地衡量每一个所产生的影响。

最后，成功的企业架构师只能是那些能够取得开发团队支持的人。如果你将他们当作下属，他们就会找到应付你的方式，将组织愿景和战略至于危险境地，此时你依然需要对结果负责，却几乎没有改变的能力。相反地，如果你将他们当作合作伙伴，那么他们就会帮你实现愿景，所有人都会取得成功。要拥抱变化，衡量变化，确保每一个人都理解变化的价值，同时始终都应该尽量引导团队实现组织架构的愿景。

寻找改变的机会

大的改变需要时间和机遇。一旦确定了将来的愿景，我们就会开始在企业里营造兴奋的氛围，并想立即看到结果。但有一点非常重要，那就是要时刻牢记对架构进行较大的调整需要循序渐进，需要合适的时机。要从已有的项目开始改变，引导新的实现向架构愿景的方向发展。要记住改变代码使之向预定方向发展的机会可能并不会按照期望的速度或者从期望的区域进行。要学会庆祝胜利，无论是多小的胜利，要对能作出积极改变的机会保持警惕。

也就是说，要优先处理组织已有项目中最糟糕的那部分。业务领导几乎不能理解改变技术组件的价值，也不清楚维持现状的成本。当需要纯粹的技术变化时，需要创造机会进行改变。根据改变将来对业务的价值、节约的成本以及降低的风险决定改变的速度。如果有必要，从业务部门寻找一个合作伙伴，创建一个既能增加业务价值，又能改变架构的项目。要寻找机会移除那些拖了预算和运营团队后退的老应用程序和硬件。