关于架构师:作为一个架构师我是不是应该有很多职责

7次阅读

共计 1490 个字符，预计需要花费 4 分钟才能阅读完成。

每一个程序员都有一个架构梦。

下面其实实质上是一句富裕事实哲理的废话，要不然也不会有这么多人关注你的公众号。这些年随着“企业数字化”转型的口号，一大批企业奔跑在转型的路上，心愿当先一步对手将企业 IT 部门从单纯的老本核心转变为业务驱动者，而这个过程中，企业的架构师起着无足轻重的作用。架构师的工作在很多撸码的开发者眼中是很一项很神圣的工作，而且富裕挑战性。

然而事物都有两面性，很多管理者和技术人员都认为架构师的薪酬不符合实际，有很多架构师的确只会用 PPT 和大幅海报来应酬了事，而且会依仗着在公司位置把本人的一些想法强加给公司其余共事，有的架构师甚至会谋求一些无关紧要的概念，在高层和底层灌输一些谬误的思维，从而导致做出一些不可逆转的蹩脚决策，使公司陷入危险顺境。

很多时候，公司给予架构师这个角色太多的责任，管理者心愿他们能在突发性能问题时能疾速解决问题，还能推动企业疾速转型，甚至能帮忙企业文化的疾速建设，作为一个架构师是不是要抗下这些职责呢？

架构师的日常工作常常会面临并行处理多个不同维度的问题，这些问题可能是不同的主题，甚至在做决策的时候也须要思考人员的调配，我的项目时间表的排期，须要用的核心技术以及组件等。有很多高层领导喜爱间接在架构师这里获取我的项目的详细信息以及技术计划，尽管架构师角色波及这些信息并且很理解这些信息，然而这并不是架构师的职责所在，甚至很多状况下令架构师处于项目经理的难堪角色。

我想很多人看过那篇文章：作为架构师该不该写代码？很多架构师是出身于开发人员，这也难怪会呈现这样的疑难。然而，架构师其实和资深开发是两条不同的职业路线，我认为两者没有高下之分。杰出的开发人员须要很深的开发功力，须要最终交付出可运行的软件。而架构师则须要更广大的知识面，更好的组织战略思想，更好的沟通能力。在一个产品的开发流水线上，架构师可能会负责一部分外围代码的编写，然而最次要的工作还是保障这条流水线的失常运行。

因为架构师这个角色在公司的位置，很多管理者认为架构师要随时随地的能剖析并解决任何突发的问题，不瞒各位，这种景象在很多大厂仍然存在，包含我司（尽管只是一个四线小厂）。如果一个架构师每天都忙着“救火”这种工作，基本没有工夫去做真正的架构工作，真正的架构设计须要思考，是不可能在短短工夫内实现的。然而架构师必须承受呈现的产品问题，因为这些问题的产生有可能和架构有着间接关系，在很大水平上能反馈架构的缺点或者问题。

架构师作为企业中很重要的一环，在很多重大技术问题中都作为决策者而存在。很难用代码的多少或者品质来掂量一个架构师的好坏，如果一个零碎在失常运行 5 年后仍然能良好运行并且能够接受肯定的变更能力，阐明这个零碎的架构师的工作是很杰出的。如果非要给架构师定义一个 KPI 规范的话，以下这些工作兴许能成为一个参考

定义 IT 策略。小到一个零碎的组件列表可行性的确定，大到公司技术的倒退方向，乃至将来 10 年公司技术的预测与大胆尝试。这些技术策略都须要架构师依据本身教训来制订。
落实对 IT 蓝图的管控，以实现协调一致，升高复杂度，保障公司所有零碎井井有条的失常工作，架构师的工作之一就是要把复杂度升高，化繁为简，这须要架构师很强的形象能力。
关注我的项目的理论落地状况，并依据我的项目施行中反馈的问题进行策略的适当调整。一个合格的架构师从来不会疏忽来自理论我的项目中的问题反馈。