架构漫谈(七):不要空设架构师这个职位,给他实权

2021年1月9日   |   by tgcode

  上篇:架构漫谈(六):软件架构到底是要解决什么问题?

  什么是架构师

  在之前的几篇文章中,经常会提到架构师这个词。我们已经定义了什么叫架构,那怎么定义架构师呢,是不是做架构的就叫架构师了? 没有这么简单,本篇尝试讨论一下这个问题。

  架构师的前提条件

  如果一个人在工作中,只是致力于完成自己的工作,以做好自己的工作为主要目标,那么最多只能成为一个工匠,无法成为一个架构师。因为这个过程解决的还是自己的问题,并没有时间的压力,可以随意什么时候做完都可以。

  当我们所做的工作是处于社会的分工的一环,需要帮助别人解决问题,并且按时解决别人的问题成为我们自己的问题的时候,我们就有了时间压力,潜意识里会自然而然的有一种对时间的恐惧。这个恐惧在潜意识里面会想方设法推动我们采用各种手段,以便及时的完成工作,换取报酬。甚至会加班加点,不择手段。

  如果我们还生活在这个恐惧下面,是不可能成为架构师的。要成为架构师,必须要超越这个恐惧才能够看清楚,我们要解决的是别人的问题,不是自己完成工作的问题。因为仅仅是完成了自己的工作,也并不一定就解决了别人的问题。如果别人的问题没有解决——即使我们认为自己的工作完成了——我们的工作实际也没完成,因为我们工作是否完成,是别人说了算的,不是我们自己。

  为什么会有这个对时间的恐惧和压力呢?这是因为我们把完成自己的工作当成了我们的最大利益。如果别人的问题没有真正的解决,必然会觉得付出的报酬不值得,我们的利益实际上是受损失了。这和我们所以为的恰恰相反,因为我们所能得到的工作只会越来越少,别人会越来越不愿意依赖于我们。

  另一方面也说明,我们对自己所从事的工作,还没有足够的自信,我们解决自己的问题还有困难,才会这么在意,并恐惧。如果我们把完成别人工作当成自己的最大利益,这个对时间tgcode的恐惧自然就会消失,这个时候就自然而然的开窍了,就知道怎么去发现问题了。只有做到这一点,才能在自己所服务的领域建立起自信,成为一个合格的架构师。

  其实刚开始一般是硬着头皮去克服对时间的恐惧和压力的,一点自信都没有。但只要做成功了一次(只要真的舍得这么去做了,想不成功也很难!),自信就开始慢慢建立起来了,这个时候就是我们开始慢慢变成架构师的时候。大家就当着上当一回,试试看。

  如何发现“是谁的问题”

  当我们真正专注于别人的问题的时候,我们自己的理想,抱负,对技术的追求都不算什么了。这些tgcode理想,抱负,对技术的最求,不就是要达到自己的利益吗? 只有帮助别人解决了问题,这些理想,抱负,对技术的追求才可能实现,否则这些理想,抱负,对技术的追求有什么意义,能得到什么利益?

  这个时候就会真正的开始思考,别人究竟有什么问题。其实也很简单,和我们自己面临的问题一样,别人的问题也都是如何获取更好更多的利益。我们自己想明白了这一点,自然也就能想明白别人的问题。这个时候就能够问出正确的问题:如果问题不解决,究竟谁会有利益的损失? 如果问题解决了,究竟谁会有收益,谁的收益最大? 回答了这两个问题就找到了问题的主体。只回答一个是没有用的,因为很多时候这个世界的事情,权责是不对等的。明白了这两个问题,我们只要让事情权责对等起来,让每个人为自己的权利产生的结果负有义务,大部分时候我们自己根本就不需要做什么,问题就都解决了。这就是最高明的架构师。

  架构师的权利和义务

  架构师是要去平衡tgcode别人的利益,甚至会调整别人的利益的。一旦架构师是全心全意的为别人的利益服务,自然而然的架构师就拥有了强有力的影响力,肯定会是一个leader。但是只是民意上的leader是没有用的,不能完全发挥架构师的能量。

  架构师必须是一个组织的领导人,有权利调动这个组织的架构,才能够更好的发挥架构师的作用,更好的把利益的调整落到实处。所以很多公司设了很多架构师的职位,但是并不具备调动组织架构的权利,那么这个架构师的职位一定是形同虚设。架构师只能够通过建立某些流程来行使架构师的权利,比如强制架构review,反而会造成很多内部不必要的冲突,最终都会导致这些流程流于形式,得不偿失。相信很多人都已经经历过这些,但似乎很少有人回去探讨这是为什么。

  反过来,具备架构师能力的组织领导人,一定是一个很好的领导,这个组织一定是很健康向上的,因为每个人的权利和义务就是比较均等的。并且这类领导对于组织成员权利和义务的对等状况会非常的敏感,会及时的调整组织架构,在问题发生之前就解决了。这样这个组织就会具备更好的抗压能力,能够更好的为这个组织的客户服务,这个组织的成员内心一定都是比较平衡的,每个人的能力都能够得到比较好的发展。当然读者可能又会说,这不是管理学的东西吗? 是的,但也是架构的问题。所有架构的核心就是组织架构。或者也可以这样说,一个合格的组织领导人,一定必须是一个合格的架构师。

  架构师的义务似乎不用说了,大家提的要求可能比我提的都高 —— 当然是发现问题并且解决问题。架构师必须能够超越对时间的恐惧 —— 也就是说必须具备了一定程度的自信,哪怕是装的,去真正的发现问题的主体,识别真正的问题,并把这个行为变成为自己面对问题的第一反应。架构师还必须要明白,所给出的解决方案 —— 架构的分拆、合并方案,只有让问题的主体的权责对等,才能够真正的解决别人的问题。一般明白了问题的主体,以及主体的利益所在,做到这一点也没有问题。

  架构师和技术

  很多人会问,特别是做软件行业的,架构师是不是需要学习技术,甚至是学习语言? 如果一个架构师还有这个困扰——就如问这个问题的人,说明目前还不具备做架构师的能力,或者说还不具备对自己领域——哪怕是技术领域——的自信,更别谈业务领域了。

  因为技术和语言,都是用来识别和解决所服务的主体的权责,保护并提升所服务的主体的权利的。特别对于软件领域来说,必须明白软件本身是怎么回事,解决什么问题,还要解决软件所服务的对象的领域本身是怎么回事,解决什么问题,这就要求更高了。语言和技术应该是随手拈来才对,对于架构师这些都是工具。学习技术和语言,如果明白了这些技术和语言要解决的是谁的问题,什么问题,学起来是非常快,非常容易的。

  同样,采用哪个技术或者语言,只要某个技术或语言所解决的问题的主体,以及所解决的问题,和自己所面对的问题的主体和这个主体要解决的问题,这两者是匹配的,那么这个方案的成本是最低的,所采用的技术或者语言就是靠谱的。没有趁手的工具或语言的情况下,自己设计一个也不难,因为很清楚自己要什么。要不要自己做,无非是一个成本问题,也就是利益问题。并且从这个思路下去,选择的工具和语言肯定都是最简单的,成本是最低的。因为架构毕竟解决的还是人的利益问题,成本越低越好,这个成本当然是长期总体成本,不是眼前的短期成本。

  下篇:架构漫谈(八):从架构的角度看如何写好代码

相关推荐: 架构漫谈(八):从架构的角度看如何写好代码

  上篇:架构漫谈(七):不要空设架构师这个职位,给他实权   在第六篇文章中,我们得出一个结论,软件架构实际上包括了:代码架构,以及承载代码运行的硬件部署架构。实际上,硬件部署架构最终还是由代码的架构来决定。因为代码架构不合理,是无法把一个运行单元分拆出多个…

Tags: ,