一直以来,作为一名软件工程师,都十分向往“架构师”的名号,也一直奋斗在通往“架构师”的路上。但如果要是问他们:什么是架构师?往往每个人回答的都千奇百怪,也就是说在每一个人的心里对架构师的认识都互不相同。有的人说,架构师要掌握很多的技术。也有的人说,架构师不必到细节,要宏观把控。还有的人说,架构师要有超强的预知能力。等等。就如同盲人摸象,“架构师”一词太大、太笼统了,如果仅是站在自己认为的角度来看,很难准确定义出“什么是架构师”。
其实“架构”不是软件行业的专有名词,在软件行业很早之前,架构就已经存在了,比如:建筑行业等。所以“架构”并不是局限在某一行业中,反而它存在于整个人类社会的高效协作之中。要真正的去理解架构,并不能局限于软件行业之中,当然了后续会重点讲述软件行业中的架构。
面对“架构”一词,空杯心态,从起源开始分析“架构”的诞生。为何空杯心态,暂时放弃之前自己认为对架构的认知,从“架构”由无到有的诞生角度来认知,之后再和自己之前的认知,进行碰撞纠正吧。
本文将先从“人”、“组织”、“社会”三个方面来讨论架构为何产生、架构为何物、应该如何去做架构?最终会在“软件”行业方面,根据对架构的认知,来实施架构的落地。
从远古谈起
-
在远古早期,每个人都完全独立生活,衣、食、住、行等等全部都自己搞定,整个人类都是独立的个体,不相往来。为了解决人类的延续的问题,自然而然就有男女群居出现,这个时候就出现了分工了,男性和女性所做的事情就会有一定的分工,比如:男性身体强壮擅于捕猎、女性性情温和善于孕育等。可是人每天生活的基本需求没有发生变化,还是衣食住行等生活必须品。
面对问题:人类延续;
架构形成:男女群居、男女分工;
-
然而面对自然灾害,生活遭受灾害不确定性,所以多人分工配合作为生存的整体,力量就显得强大多了,所以也自然的形成了族群:有些人种田厉害,有些人制作工具厉害,有些地方适合产出粮食,有些地方适合产出棉花等,就自然形成了人的分群,地域的分群。当分工发生后,实际上每个人的生产力都得到了提高,因为做的都是每个人擅长的事情。
面对问题:自然灾害、个人生产效率低,生活遭受灾害不确定性;
架构形成:多人族群,角色分工;
-
整个人群的生产力和抵抗环境的能力都得到了增强。为什么呢?因为每个人的能力和时间都是有限的,并且因为人的结构的限制,人同时只能专心做好一件事情,这样不得已就导致了分工的产生。既然分工发生了,原来由一个人干生存所必需的所有的事情,就变成了很多不同分工的角色合作完成这些事情,这些人必须要通过某些机制合在一起,让每个人完成生存所必需的事情,这实际上也导致了交易的发生。
面对问题:由于角色分工导致,个人不能生产出生活所有必须品;
架构形成:交易系统、交易货币;
-
在每个人都必须自己完成所有生活必须品的生产的时候,是没有架构的(当然在个人来讲,同一时刻只能做有限的事情,在时间上还是可能会产生架构的)。一旦产生的分工,就把所有的事情,切分成由不同角色的人来完成,最后再通过交易,使得每个个体都拥有生活必须品,而不需要每个个体做所有的事情,只需要每个个体做好自己擅长的事情,并具备一定的交易能力即可。
角色分工产生,生产力提高,更需要具备的是交易沟通能力。只有交易沟通,才能使每个个体拥有生活各方面的必须品。
经过上面四步,这实际上就形成了社会的架构。那么怎么定义架构呢?以上面这个例子为例,把一个整体(完成人类生存的所有工作)切分成不同的部分(分工),由不同角色来完成这些分工,并通过建立不同部分相互沟通的机制,使得这些部分能够有机的结合为一个整体,并完成这个整体所需要的所有活动,这就是架构。
五个动力条件,通过以上的例子,可以归纳出产生架构的五个动力条件:
- 必须由人执行的工作(不需要人介入,就意味着不需要改造,也就不需要架构了);
- 每个人的能力有限(每个人都有自己的强项,个人的产出受限于最短板,并且由于人的结构限制,同时只能专注于做好一件事情,比如虽然有两只眼睛,但是只能同时专注于一件事物,有两只手,无法同时做不同的事情。ps. 虽然有少部分人可以左手画圆右手画框,但是不是普遍现象);
- 每个人的时间有限(为了减少时间的投入,必然会导致把工作分解出去,给擅长于这些工作的角色来完成,见2,从而缩短时间);
- 人对目标系统有更高的要求(如果满足于现状,也就不需要进行架构了);
- 目标系统的复杂性使得个人无法完成这个系统,满足条件2,3(如果个人就可以完成系统的提高,也不需要别的人参与,也就不需要架构的涉及,只是工匠,并且一般这个工作对时间的要求也不迫切。当足够熟练之后,也会有一定的架构思考,但考虑更多的是如何提高质量,提高个人的时间效率);
有人可能会挑战说,如果一个人对目标系统进行分解,比如某人建一栋房子,自己采购材料,自己搭建,难道也不算架构嘛?如果对于时间不敏感的话,是会出现这个情况的,但是在这种情况下,并不必然导致架构的发生。如果有足够的自觉,以及足够的熟练的话,也会产生架构的思考,因为这样对于提高生产力是有帮助的,可以缩短建造的时间,并会提高房子的质量。
当这5个条件同时成立,一定会产生架构。从这个层面上来说,架构是人类发展过程中,由懵懵懂懂的,被动的去认识这个世界,变成主动的去认识,并以更高的效率去改造这个世界的方法。
架构本质是什么
- 根据要解决谁的问题,对目标系统的边界进行界定。
- 并对目标系统按某个原则的进行切分。切分的原则,要便于不同的角色,对切分出来的部分,并行或串行开展工作,一般并行才能减少时间。并对这些切分出来的部分,设立沟通机制。
- 根据3,使得这些部分之间能够进行有机的联系,合并组装成为一个整体,完成目标系统的所有工作。
同样这个思考可以运用到其他行业架构,比如:企业架构、组织架构、软件架构等等。每一次架构的变革,都是主动对现有问题的解决,对现有环境的适应。
架构实际上就是指人们根据自己对世界的认识,为解决某个问题,主动地、有目的地去识别问题,并进行分解、合并,解决这个问题的实践活动。
架构的产出物,自然就是对问题的分析,以及解决问题的方案:包括拆分的原则以及理由,沟通合并的原则以及理由,以及拆分,拆分出来的各个部分和合并所对应的角色和所需要的核心能力等。
概念认知
架构实际上是解决人的问题,而概念是人认识并沟通这个世界的基础,自然概念的认识就非常的重要。
举个栗子:
比如说“什么是桌子?”其实每个人对其的理解描述都是千奇百怪的,这实际上就导致了做架构的时候,不同角色的沟通会出很多问题,那么结果也就可想而知了。
所以,在架构中对概念的认知,其实是很关键的。那为什么每个人对概念的理解会千奇百怪呢?其实大部分人对于每天都习以为常的概念,都自以为明白了,实际上都是下意识的认识,并不是主动的认识。所以,对于概念,作为架构师应该主动地进行思考认识。
在古代,概念不叫“概念”,称之为“名相”。
何为相?
一般我们认为:看到一个东西,比方说杯子,“杯子”就是一个名字,指代的看到的东西就是相,就是事物的相状。我们一听到“杯子”这个词,脑海里就会浮现出一个杯子的形象。而“杯子”这个词,是用来指代的是这个相状的,叫做名。合起来就叫做“名相”。
可是当我们把杯子打碎了的时候,我们还会称这个碎了的东西叫杯子吗? 肯定不会,一般会叫“碎瓦片”,如果我们把碎瓦片磨碎了呢,名字又变了,叫做“沙子”。这就奇怪了,同样一个东西,怎么会变出这么多的名字出来?
实际上“相“表达的不是一个具体的东西,如上面所提的一个瓷器杯子,并不是指这个瓷器,而是这个瓷器所起的一个作用:一手可握,敞口(一般不超过底的大小,太大口就叫碗了),并且内部有一个空间可乘东西的这么一个作用。并不是指这个瓷器本身。这也是为什么我们从电视上看到一个人拿杯子的时候,我们知道这个是杯子。但是实际上我们看到的都是光影而已。所以说相实际上代表的是这个作用,并不是具体的某个东西,而名是用来标识这个作用的,用来交流的。
所以,其实杯子在打碎、磨碎的过程中,其实作用也被改变、破坏了,自然相也就被改变了,随之而来,名也就发生了改变。
那为何需要这个作用?
这个作用其实是为了解决人的问题:“人需要一个可单手持握,但是希望避免直接接触所盛物体”。
所以说,每个概念实际上背后所解决的,还是人遇到的某个特定的问题,我们把解决问题的解决方案,给定了一个名字,这个名字就是对应的某个特定的概念。对于概念这个词本身,为了统一指代这些名字,我们称起这类作用的名字称为“概念”。
同理,为何我们可以在不同的语言间进行翻译,是因为虽然语言不同,但是人类所面临的的问题是一样的,所使用的名不同而已。对于不同的动物之间的翻译也是同理。
何为抽象?
抽象这个词代表的含义,实际上是把不同的概念的相似的部分合并在一起,形成一个新的概念。
这个里面问题很多:首先“相似的部分”在不同的人看来,并不一定那么相似;其次,抽象之后形成的是一个新的概念,和原来那个概念并不一样,所解决的问题也不一样。所以我们不能用抽象来定义一个事物,抽象实际上是一个分类的过程,完全是另一码事。
再举一个例子,杯子和容器,很多人认为容器是杯子的抽象,但是实际上杯子是杯子,容器是容器,它们所解决的问题是不一样的。当我们需要解决装东西的问题的时候,会说容器;当我们需要解决单手持握要装东西的时候,会说要一个杯子。
回过头来,根据架构的定义,要做好架构所首先必须具备的能力,就是能够正确的认识概念,能够发现概念背后所代表的问题,进而才能够认识目标领域所需要解决的问题,这样才能够为做好架构打好基础。
对上述内容,总结一下:
相是一个具体物体的状态和作用,是来解决具体人的问题。而为了人之间的交流,便根据相有了名,名其实就是一个标记,或理解为简单的概念。所以概念的背后其实是代表解决人的问题。
而抽象则是对概念或名相似之处的归类、分类的过程,不同角度来看会得出不同的相似之处,从而会有不同的抽象出来,所以抽象也会产生不同的新的概念。但抽象出来的概念不能够指具体的事物,而只能做到泛指一类具有相似之处的事物。其实抽象本身也是一个概念,其背后也在解决归类,分类的问题,但抽象并不是架构的必然产物。
而在解决问题的工程中,会首先有简单名相(意指解决问题的最原始工具或物体),遇到更高级问题,会有更高级的名相或概念,通过抽象,对名相进行归类、分类,抽象出新的概念,或者再有更高级的抽象,产生更高级的概念,最后由这些概念会组成架构。
问题识别
按照上面的架构定义,架构就是要不断解决人遇到的问题,然而做好架构首先需要做的就是识别出需要解决的真实问题。一般来说,如果把真正的问题能够找到,那么问题就已经解决了80%。这个能力基本上就决定了架构师的水平。
那么如何识别出需要解决的真实问题呢?
- 识别问题主体
- 识别问题边界
如何识别问题主体呢?
所有的概念基本都有一个很大的问题,就是缺乏主语。而我们大家都心照不宣的忽略这个主语,沟通的时候也都以为大家都懂得对方说的主语是谁,结果大家都一起犯错误。识别问题的一个最大的前提就是要搞清楚:是谁的问题。这个搞清楚了,问题的边界也就跟着确定了,再去讨论问题才有意义。
当我们处理问题的时候,如果发现自己正在致力于把自己的工作完成,要马上警惕起来,因为这样下去会演变成没有ownership的工作态度。在面对概念的时候,也会不求甚解,最终会导致没有真正的理解概念。
作为软件工程师或者架构师,我们大部分时候是要去解决别人的问题,“别人”是谁,是值得好好思考的。应该问的第一个正确的问题就是:目标问题是谁的问题。
如何识别问题边界呢?
明白了问题的主体,这个主体就自然会带来很多边界约束。我们一定要明白,任何找上架构师的问题,绝对都不是真正的问题。为什么呢? 因为如果是真正的问题的话,提问题过来的人肯定都能够自己解决了,不需要找架构师。架构师都要有这个自觉:发现问题永远都比解决问题来的更加重要。
当明白了问题的主体,我们才可能真正的认识问题是什么。因为问题的主体是问题的隐含边界,边界不确定下来,问题就是不确定的。一旦确定了主体,剩下的就是去搞明白主体有哪些问题。
一般来说,从问题暴露的点,一点点去溯源查找,一定会找出来谁的问题,以及是什么问题。当问题的主体离架构师越远,就会让找出问题主体的过程越加困难。最坏情况就是当我们时间或者能力有限,实在是无法定位出是谁的问题的时候,比如系统出故障,也就意味着我们无法根本解决问题。这时最好的办法就是去降低问题发生所带来的成本,尽量去隔离问题影响的范围。给我们留出时间和空间去识别真正的问题。
总结一下,要正确的认识问题,需要问两个问题:
- 这是谁的问题?
- 这有什么问题?
当得到的回答是支支吾吾的时候,我们就知道正确的方向在哪儿,以及需要做哪些事了。问题1会花比较多的时间,也是支支吾吾最多的地方,因为架构要解决的问题都是人的问题。但是一旦确定了答案,问题2就会变得非常容易。可以这样说,架构师的能力大部分会体现在问题1的识别上。
在实际工作中存在很多的情况,都只是在完成自己的问题或任务,而忽略了问题或任务的根本:谁的问题、什么问题。作为架构师,不仅是架构师,在面对问题时,而要更多的找出问题是什么,问题的主体是什么,从而只有有了主体,才能够确定问题的边界,最终才会确定出真正的问题所在。
架构切分
既然现状存在问题,识别到真正问题之后,需要面临的就是要解决问题。需要做现状的调整,那么就必须要有所动作,做相应的调整。这个调整就是架构的切分。
要非常的清楚,所有的切分调整,都是对相关人的利益的调整。我们已经知道,随着社会的发展,分工是必然的,为什么呢?这个背后的动力就是每个人自己的利益。每个人都希望能够把自己的利益最大化,比如:生活的更舒适,更轻松,更安全,占用并享有更多的东西。但是每个人的能力和时间都非常的有限,不可能什么都懂,所以自然需要舍掉一些自己不擅长的东西,用自己擅长的东西去换取别人擅长的东西。
对比一个人干所有的事情,结果就是大家都能够得到更多,当然也产生了一个互相依赖的社会,互相谁都离不开谁。这就是自然而然而产生的架构切分,背后的原动力就是人们对自己利益的渴望。人们对自己利益的渴望也是推动社会物质发展的原动力。
在这个模式下,比较有意思的是,每个人必须要舍掉自己的东西,才能够得到更多的东西。有些人不愿意和别人进行交换,不想去依赖于别人,这些人的生活就很明显的差很多,也辛苦很多,自然而然的就被社会淘汰了。如果需要在这个社会上立足,判断标准就变成了:如何给这个社会提供更好更有质量的服务。提供更好的更多的服务,自然就能够换取更多的更好的生活必需品。实际上这就是我们做人的道理。
那么现状中一般会存在什么问题?
当人们认识到要主动的去切分一个系统的时候,毫无疑问,我们不能忘掉利益这个原动力。所有的切分决策都不能够违背这一点,这是大方向。结合上一篇“识别问题”,一旦确定了问题的主体,那么系统的利益相关人(用现代管理学语言叫:stakeholder)就确定了下来。所发现的问题,会有几种情况:
- 某个或者某些利益相关人负载太重。
- 时间上的负载太重。
- 空间上的负载太重,本质上还是时间上的负载太重。
- 某个或者某些利益相关人的权利和义务不对等。
架构切分的原则
情况1是切分的原因,情况2是切分不合理而导致的新的问题,最终还是要回到情况1。对于情况1,本质上都是时间上的负载。因为每个人的时间是有限的,怎么在有限的时间内做出更多的事情?那么只有把时间上连续的动作,切分成时间上可以并行的动作,在空间上横向扩展。所以切分就要有几个原则:
- 必须在连续时间内发生的一个活动,不能切分。比如孕妇怀孕,必须要10月怀胎,不能够切成10个人一个月完成。
- 切分出来的部分的负责人,对这个部分的权利和义务必须是对等的。比方说妈妈10月怀胎,妈妈有权利处置小孩的出生和抚养,同样也对小孩的出生和抚养负责。为什么必须是这样呢? 因为如果权利和义务是不对等的话,会伤害每个个体的利益,分出来执行的效率会比没有分出来还要低,实际上也损害了整体的利益,这违背了提升整体利益的初衷。
- 切分出来的部分,不应该超出一个自然人的负载。当然对于每个人的能力不同,负载能力也不一样,需要不断的根据实际情况调整,这实际上就是运营。
- 切分是内部活动,内部无论怎么切,对整个系统的外部应该是透明的。如果因为切分导致整个系统解决的问题发生了变化,那么这个变化不属于架构的活动。当然很多时候当我们把问题分析的比较清楚的时候,整个系统的边界会进一步的完善,这就会形成螺旋式的进化。但这不属于架构所应该解决的问题。进化的发生,也会导致新的架构的切分。
原则2是确保我们不能违反人性,因为维护自己的利益,是每个人的本性。只有权利和义务对等才能做到这一点。从原则2的也可以推理,所有的架构分拆,都应该是形成树状的结果,不应该变成有向图,更不应该是无向图。很多人一谈架构,必谈分层,但是基本上都没意识到,是因为把一个整体分拆为了一棵树,因为有了树,才有层。
从某种意义上来说,谈架构就是谈分层,似乎也没有错,但是还是知道为什么比较好。从根节点下来,深度相同的是同一层。
当然如果某个节点的能力很强,也可以达到减小树的高度的结果。技术的提升,也是可以提升每个节点的能力,降低树的层数。
架构切分的输出实际上就是一个系统的模型,对于一个整体问题,有多少的相关方,每个相关方需要承担哪些权利和义务,不同的相关方是如何结合起来完成系统的整体任务的。有的时候是从上往下切(企业),有的时候是从下往上合并,有的时候两者皆有之(人类社会的发展)。而切分的结果最终都会体现在组织架构上,因为我们切分的实际上就是人的利益。
对架构切分,总结一下:
架构切分=利益调整,利益调整代表了以人为中心,进行的利益在分配。从时间负载、空间负载触发架构切分,而架构切分的原则就是以人的利益为本,也可以说不违背人的本性,切分的过程其实就是分层建模的过程,分层建模就是概念划分的过程,每个概念背后都代表一个问题,最终会形成树状的组织结构,而这种组织结构的调整会涉及到人的组织架构,从而要切实要考虑到人的利益。
架构其实就是在解决人的问题,如上文所述,人的问题会有很多种,比如:生活生存问题、人类延续问题、生产高效问题等等。在面对这些问题时,人逐渐主动会对自然界进行认识,从而产生最初的基本技术、男女分工、角色分工、群居等一些社会架构的形成。
然而在社会架构的形成过程中,通过概念认知、问题识别、架构切分等方式,以人的利益最大化为基础原则,进行一步步的分解、组合,达到并解决人的问题。
最终,对架构的认知,总结一下:
架构实际上就是指人们根据自己对世界的认识,为解决某个问题,主动地、有目的地去识别问题,总结得出概念,通过概念作为认识沟通的桥梁,对相关事物进行分解、合并,如:人、利益、问题、组织架构等等,解决这个问题的实践活动。
作者:猿码道
链接:https://juejin.im/post/5b3709a0f265da59a1173599
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。