圆满的建筑师
在这篇博客中，我探讨了在伦敦O'Reilly软件体系结构会议上名为“ The Well Rounded Architect ”的六个方面。
全面的建筑师的要素
担任领导者
优秀的软件架构师知道，他们作为领导者的角色并不一定会告诉开发人员该怎么做。 相反，优秀的建筑师就像一个指南，将一组开发人员引导到相同的技术构想，并利用诸如讲故事，影响，解决冲突以及与个人建立信任等领导技能，将其构想变为现实。
一个好的领导者，进而一个好的建筑师，将认真听取每个贡献者的意见，并根据团队的反馈意见来调整他们的愿景。 这很好地指向了下一点。
作为开发者
做出正确的架构选择是为了平衡理想的目标架构状态与软件系统的当前状态。 举例来说，即使问题域更适合关系数据库，即使很无聊，也没有必要将文档数据库添加到系统中。 建筑师可能会倾向于不考虑问题空间的适合性而采用技术或架构选择，即“象牙塔建筑师”的AKA行为。
架构师减轻这种情况的最佳方法是花时间与开发人员联系，并花一些时间在代码中。 了解系统是如何构建的以及当前系统的局限性，将为架构师提供有关当今环境的正确选择的更多信息。
以系统为重点
经验丰富的开发人员知道代码只是工作软件的一个方面。 为了使代码运行，经验丰富的开发人员会了解代码在其生产环境中正常运行还需要其他重要的质量属性。 他们考虑了部署流程，自动化测试，性能，安全性和可支持性等方面。 在开发人员可以临时使用这些质量属性的地方，架构师不仅要理解代码，还要着重满足不同利益相关者（例如支持，安全和操作人员）的许多需求所必需的质量属性。
优秀的架构师专注于寻找可以满足众多不同利益相关者需求的解决方案，而不是选择针对单个贡献者的偏好或风格进行优化的工具或方法。
像企业家一样思考
所有技术选择都有成本和收益，优秀的架构师将从这两个角度考虑新技术的选择。 成功的企业家愿意冒险，但是会寻求快速学习和快速失败的方法。 架构师可以采用类似的方法来选择技术，寻找有关短期和长期成本及其可能实现的收益的真实信息。
一个很好的例子是架构师避免基于阅读新文章或在会议上听说过新工具而致力于使用新工具。 相反，他们试图通过运行架构峰值来收集更多信息，以了解该工具在其环境中的相关性。 他们不会根据销售的好坏来选择工具，而是根据他们的系统需求来提供什么价值。 他们还寻找工具的隐性成本，例如，工具的支持程度（例如文档级别，社区采用程度），工具的锁定程度或长期带来的额外风险。
战略与战术思想的平衡
许多团队与个别开发人员反应性地构建软件，他们选择了最熟悉或经验最丰富的工具和技术。
优秀的架构师会密切关注哪些新技术，工具或方法可能有用，但不一定立即使用它们。 技术的采用要求考虑周到的方法。 架构师将在团队和组织层面上寻求敏捷性（允许团队快速移动）和一致性（保持足够的一致性）之间的良好平衡。
诸如构建自己的技术雷达之类的练习是一个有用的工具，可以在考虑策略的情况下探索技术。
沟通良好
架构师知道，有效的沟通是建立信任和影响团队以外人员的关键技能。 他们知道不同的人群使用不同的词汇，并且与商务人士一起使用技术术语和说明会使交流更加困难。 架构师不用谈论模式，工具和编程概念，而是使用他们的听众会熟悉的单词。 用风险，回报，成本和收益等词语向业务人员传达技术选择，将比他们在开发团队中使用的词语更好地为建筑师服务。
架构师还意识到，团队内部的沟通与团队内部的沟通同样重要，他将使用图表和小组讨论来建立和完善技术构想，并使用诸如建筑决策日志或Wiki之类的书面日志来为团队提供历史线索。后人。
结论
做一个全面的建筑师并不容易。 有很多要素可以吸引我们关注，每种要素都可以利用开发人员通常不注重练习的许多技能。 最重要的不一定是架构师具有的能力，而是他们在各个不同领域中都有足够的专业知识才能有效。 仅在上述六个领域之一中熟练的建筑师将不如在所有这方面都具有良好专业知识的建筑师那样有效。
翻译自: https://www.javacodegeeks.com/2016/11/well-rounded-architect.html