如何做一个技术全面的架构师

本文从六个方面讨论一个良好架构师所必须具备的专业水准。

作为领导

好的软件架构师必须知道,他们作为领导者的作用不一定是告诉开发人员做什么。 相反,好的架构师的行为本身就像一个指导,管理一个开发团队向同一个技术愿景前进,利用领导技能,如讲故事,影响,导引冲突和建立个人的信任等方式,把他们的架构愿景变成现实。

一个好的领导者,同时也是一个好的架构师,将仔细听取每个参与者的意见,通过与团队反馈互动微调他们的愿景。 很好地引导到下一个点。

作为开发人员

在理想的目标架构与软件系统的当前状态之间平衡才能做出良好架构选择。比如,如果关系数据库更适合问题域,即使很无聊,如果再将文档数据库添加到系统中也没有意义。架构师如果不首先考虑是否适合业务问题领域,会被各种技术诱惑而进行架构选择。

架构师减轻这一点的最好方法是花费时间与开发人员泡在代码中。了解系统如何建立,以及系统的约束,这些将为架构师提供关于当今环境的正确选择的更多信息。

具有系统焦点

经验丰富的开发人员知道,代码只是工作软件的一个方面。为了使代码运行,经验丰富的开发人员需要理解其他重要的质量属性,代码才能在其生产环境中运行良好。他们需要考虑部署过程,自动测试,性能,安全性和可支持性等方面质量属性。 开发人员才能可以根据这些质量属性进行编码实施,架构师不仅专注于理解代码,而且需要了解并满足不同利益相关者(如支持,安全和操作人员)的需求。

好的架构师需要专注于寻找能够满足这些不同利益相关者需求的解决方案,而不是根据某一个参与者的偏好或风格选择进行优化的工具或方法。

像一个企业家思考

所有的技术选择都有成本和效益,一个好的架构师将从两个角度考虑新的技术选择。成功的企业家会愿意承担风险,但是会寻求快速学习和快速失败的方法。 架构师可以以类似的方式处理技术选择,寻求现实世界中有关短期和长期成本的信息,意识到他们的可能好处。

一个很好的例子是,当架构师避免承诺立即使用从新文章读过的或在会议上听说过的新工具。相反,他们应当设法了解该工具的相关性,并在他们的环境中运行的架构样本以收集更多的信息。他们不会基于多好的销售额而选择一个工具,,而是依据它提供了什么价值,是否提供给他们的系统所需要的。 他们还会寻找工具的隐性成本,例如支持的工具是否足够好(例如文档级别,社区采用情况),工具带来多少锁定或长期引入的额外风险。

用战术思维平衡策略

许多团队与各个开发人员都是倾向于选择他们最舒适或最有经验的工具和技术构建他们的系统。

好的架构师需要注意什么是更新的技术,哪些工具或方法可能是有用的,但不一定立即采用他们。技术采用需要一个考虑长期前景的方法。 架构师将在团队和组织层面寻求敏捷性(允许团队快速移动)和调整(保持足够的一致性)之间的良好平衡。

建立自己的技术雷达是在探索有用的工具。

良好沟通

架构师需要知道有效的沟通是建立在信任基础上,需要在团队外影响队员,这些都是架构师的关键技能。 他们知道不同群体的人使用不同的词汇,使用技术术语与生意或管理人士交流会变得困难。架构师不会使用模式、工具和编程概念与他们交流,而是使用受众熟悉的词语与之交流。 使用诸如风险回报,成本和收益等词汇向商业人士传达技术选择,将比与开发团队一起使用的技术词汇更适合。

架构师也意识到团队内部沟通和外部沟通一样重要,可以利用图表和小组讨论,建立和完善技术愿景,并使用编写写日志的方式,如维基,能够为将来提供为历史发展轨迹。

结论

做一个全面的架构师不容易。有这么多的元素需要我们关注,每个都利用许多开发人员往往不具备的技能。 最重要的不一定是架构师具有什么能力,而是他们在这些不同领域有足够的专业知识才能有效。只有熟练掌握上述六个领域之一的架构师,才会成为具有良好专业知识水平的架构师。

The Well Rounded Architect |