做人做事，做架构师架构师能力模型解析

转载:http://blog.sina.com.cn/s/blog_757658ba0100r19k.html

要想从一名普通程序员发展成为优秀的架构师，个人特性与技术技能缺一不可；而技术专业能力人际关系能力和业务能力更是优秀架构师重要的三种能力

 

文 / 周爱民（程序员2008年4月刊）

 

引子

   究竟是什么让你在同一个位置上例如程序员或技术负责人工作了三年五年或者更久，而仍然得不到任何的发展空间？你觉得自己已成为技术圈中的大牛，并信心满满地去拿明天就要颁发的某某大奖，然而却仍然停留在同样的技术职位上，去年到今年涨的薪水甚至填不平物价升幅？于是，你开始对老板不满，对员工不满，对昨天升职的那个同事不满你开始计划明天就要跑单，或者准备考虑提出加薪却又心怀忐忑

如果技术人员有发展的轨迹，那么他要么看透工具的本质，把关注点转移到团队的圈子里去，要么顺着代码铺就的道路，亦步亦趋地成为良匠大师仅以技术方向而言，你大概可以做到架构师总架构师甚至首席架构师；但问题是：你现在还只是一个程序员那要如何才能踏上通往架构师之路呢？本文为你解析一个架构师的能力模型

你能不能做一个好的架构师？

  架构师不是界定一个技术高下的职位名称，而是一个职务所谓职务，包括职职位，务工作前者决定了你具备哪些资源，可以影响到怎样的范围，以及面向的机构，后者则简单地是你需要完成的工作列表

所以我说架构师不是指一个能做架构的人前者是把架构师当职能，后者是当工人能做一份工作列表中的事，并不等于就成为相应职位上的人在管理体系里面，你的个人特性决定了你在哪个位置，而技术技能只是做事实施的必需架构师这个职务，同时要求较高的个人素质和技术能力，因此它的进取之路总结起来就是：做人做事，做架构

因此模型由个人特性和技术技能两个方面构成，在第一张图中，我特别说明个人特性既包括人际关系的能力，也包括（具体）业务能力；技术技能也是如此所以个人特性主要与做人有关，部分地也包含做事的要素

                                           图1 架构师能力模型

   有效沟通以及学会谈判与做具体的事无关，是个人能力特性的公共方面前者是过程，后者是知道如何定目标与求结果而风险与防备是做事过程控制的关键，与前面两项正好构成了一个做事基本能力的完整体系基本上，这三项个人特性都是一个普通程序员所不具备的，甚至在大多数情况下，普通程序员并不愿意去具备这样的个人特性，因为在许多陷于技术泥淖的开发人员看来：沟通总是会使事情变得更加麻烦，谈判则徒耗时间而无济于事然而事实上，在整个的架构决策过程中，架构师需要不停地沟通与谈判将架构变成决策的过程，其实就是对各个技术角色（及其思想）兼容并包的过程，你需要不断地协调需求实现之间的各种问题，也需要面对各种投资者（时间资金人才等方面的决策者）进行谈判，以确定项目的规模没有规模也就没有范围，没有范围如何展开设计呢？

一部分开发人员会认为上述过程是项目经理的事情，但真的如此吗？当你作为一个更高级别的架构师，以至于要影响到多个项目的决策时，你就全然不会有这种感受了因为这种情况下，你的决策将先于项目的启动，或者说你已经不单单是一个技术角色了

设计是架构能力的一部分，但架构师不是设计师看清楚二者之间的不同，你才真正迈出了架构师职业生涯的第一步

抽象是思维能力模型化是表达能力

   个人特性中另一个非常重要的方面是抽象思维，而这是与架构师角色直接相关的一种能力这种能力既有职业技能特征，又是普遍性的能力

所谓普遍性的能力，是指抽象在我们作为人这种个体的生活中无处不在例如我们说花草，说桌椅我们用语言去指称任何一个既已存在的（可以脱离我们的语言而自然存在的）事物时，就用到了抽象说桌子的时候，既没有描述桌子的具体形式，也没有说明它的规格，但我们用这个名词时，所有人都知道桌子是什么所以，名词概念是整个抽象逻辑系统中的主体如果失去了这些名词定义，我们基本上不能说话，也不能描述任何东西那便到了只可意会不可言传的境地

用现有的成熟语汇去描述你的系统时，大多数人会理解你所表达的含义，例如我们说这个系统设计为一个三层结构然而架构师面临的系统在许多细节上并不见得能够用成熟的语汇去描述，因此必须自已构建一个抽象系统，这就需要概念抽象能力概念表达能力和基于概念的逻辑表达能力

概念抽象能力是一种思维能力简单地说，就是把目标分解或概括清楚：你要么概而言之它是什么，要么详细地说明它包括什么必须使用大量的语汇来陈述这个什么，这不单单是表达为文字，也表达为你在思想过程中的一个完整系统通常用的方法是映射系统例如你可以用数学中的数轴来映射实数域将目标系统形式化为一个概念化的可讨论的结构系统后，你的抽象过程就基本结束了

                                  图2能力模型中的个人特性

   然而这个抽象系统可能只构建在你的思维意识里，还必须把它描绘出来因为不能只是你自己思考清楚，系统就能设计完成这个描绘就依赖于后面两种表达能力，一种是描绘概念实体，一种是描绘实体上的逻辑有趣的是，这似乎又回到了程序＝结构＋算法
   现在大家回过头来看看UML，或者更多种类的ML（建模语言），他们就用于表达这两个方面的东西：要么是概念实体（例如用一个框表明系统边界），要么是实体上的逻辑（例如用箭头表明逻辑时序）

所以大家应该清楚，我们再如何称赞UML，它也只是一种对模型化系统的表达能力，你只能把它当一种辅助表达的工具去使用，它本身既不能帮助思考，也不见得能作为抽象过程中的或抽象思维环境中的参考

任何一个优秀的架构师都有自己独特的思考方式，这决定了他如何抽象系统，以及如何创造性地设计与构画这个系统这种独特的思考方式贯彻他从孩童开始的整个成长过程，直至他形成独立的社会观人生观与世界观他认识世界的方式和接受世界的能力决定于他如何思考，也反映了他这种思考方式的独特性但这并不表明他有特立独行的行为特性（我们这里只说他的思考方式），我们不应介意他是否用某种语言（例如UML或者形式化编程语言）来表达他的思考结果

推动：设计做大，实施做小

  架构师首先是把问题的真正目标确定下来，然后变成系统设计平台设计或架构设计而在此之后设计输出将会有两个方向的发展，一是被忠实地贯彻下来，二是被变形地发展下去两个方向都存在致命的危险：架构最终能否被完整实现对前者来说，可能是架构设计过度，或设计本身出现了错误；后者则是对架构直接的伤害

所以架构师必须参与实施的全程尤其是在架构被映射为目标系统的前期在这个阶段中，架构师的任务就是推动架构实施，以保证在项目全程的设计／架构／体系的一致性除了直接跟设计师或设计团队沟通，以保证他们的设计在你可以控制的范围之内以外，架构师还必须有阶段化设计的能力这种能力用于将一个原本规模宏大的架构设计，变成较小的易于实施的对开发团队来说可控的关键点例如在体系层次的规划上，设计可能是独立异质的可迁移的存储框架来实现数据层，但在（前期的）实施上，这里可能被表达为本地数据库，并要求前端开发人员必须通过一个清晰的数据交互层来访问例如一组数据存取接口，或一个独立数据服务组件开发人员可能在这里遇到障碍：因为要通过这些中间层来访问本地数据库，纯粹是多余的然而，正是这多余的工作提供了系统弹性，为并行团队开发公共存储服务争取了周期，也为将来的灵活部署与数据迁移提供了可能

这里的关键就在于，无论原始系统设定有多大，实施时总是在做小每一个局部的实施块都是可控的，并为它在整个体系空间中留下了位置和接口，这样才可能由小的部分做大一个大系统的架构师可能同时在考虑许多个项目中的不同位置的架构，并且清楚这些项目最终的总体规模而这，就是平台架构师和体系架构师所涉的领域

                                  图3架构师模型图中的实现能力

   架构真的是好不好的问题吗？如同我对工程的理解一样，架构问题的根本，也并不在于它是否完美或漂亮，而是在于是否合用因此架构师必须对实施架构的团队以及实施过程有充分了解，知道他们的能力缺陷，知道实现过程要消耗的资源，清楚每个环节可能的故障以及先兆只有这样，架构师才能设计一个让这个团队能实现，而且在实现过程中能受控的架构要知道，你作为架构师被请来，不是画几张图纸交给项目经理，说：你们去做吧，做不出来是你们不会做即使你可以身体力行，在这个团队中教大家培养大家，那么公司的开销呢？风险呢？这些东西难道就不考虑了？项目的周期因为实现的复杂程度而无法控制时，项目就死掉了那么，追根究底来说，是不是架构师的问题？是啊，你为什么会做了一份不合用的架构呢？你都不知道项目如何开发由谁实施如何管理等等，又如何能面对这些实际环境去设计架构呢？

所以这一部分能力，是要在你的开发经验团队经验以及用人识人的经验中去找的参考模型图的实现能力下的设计能力了解你的主要沟通对象和架构推行等分支，对你或有一些可用的提示

局部与全局

   架构是一个从全局到局部的过程，而实施正好反过来，是从局部到全局这也正是设计做大，实施做小的另一个层面的含义设计大才可以见到全局，才知道此全局对彼全局的影响；实施小才可能关注细节，才谈得上品质与控制。

事实上，大多数情况下架构是在为当前项目之外去考虑，这可以看成全局关注的一个组成部分因此我们需要界定所谓全局的范围：超出公司或整个产品系列产品线或规划的范围才是多余的所以当架构决策谈及全局时，其目标并不见得是保障当前项目，而又必须由当前项目去完成一个经常被用到的例子是：如果仅为当前项目考虑，那么只需要做成DLL模块；如果为产品线考虑，可能会是管道＋插件的结构形式而管道＋插件的形式显然比做成DLL模块更费时，这个时间成本（以及其它成本）就变成了当前项目的无谓开销这种全局策略对局部计划的影响是大多数公司不能忍受的，也被很多团队所垢病然而这却是架构师角色对体系的近乎必然的影响如果你试图在体系中引用架构师这个角色的话一些情况下，体系能够容纳这种影响，例如技术架构师试图推动某种插件框架，而正好开发人员对这项技术感兴趣，那就顺其自然地花点工夫去实现了但如果不是这样，实施者或实施团队看不到多余的部分对他们的价值时，来自局部的抵触就产生了这种情况下，平衡这些抵触就成了架构推行的实务之一在我看来，平衡是全局的艺术和局部的技术也就是说，一方面架构师要学会游说，另一方面也要寻求更为简洁的成本更小的实现技术只有当整个体系都意识到（你所推行的）架构的重要性，而且实施成本在他们可以接受的范围之内时，他们才会积极行动起来所以所谓平衡，其实也是折衷的过程构架师只有眼中见大，才知道哪些折衷可以做，而哪些不能所谓设计评估（模型图中的实现能力->设计能力->设计评估分支）并不是去分析一个设计结果好或不好，而是从中看到原始的需求，看到体系全局的意图，然后知道在将设计变得更为适当时可以做哪些折衷同样的原因，架构师也必须知道自己的决策会产生的影响，才能控制它们，以防它们变成团队的灾难有些时候，架构师甚至需要抛弃一些特性，以使得项目能够持续下去因为产品的阶段性产出只是整个战略中的一个环节，而不是全部

其它

  怎么做一个架构师这个问题得分成两个部分来看，一个是做到，一个是做好由于架构师本身不过是一个技术职位，所以时机成熟了自然会做得到但问题是，真有一天你被放在这个位置上了，你能做得好吗？

我浏览过几套所谓培训机构的有关架构师的教程，也翻阅过一些讲架构的书我发现他们普遍地是将架构作为一种职业技术来讲，就像培养程序员或者缝纫工一样来教育但就我的经验来说，架构并不是一件纯粹表现技术能力的工作，所以并不是翻几本书学几种方法就可以投入实战的更深层的问题是，架构师其实不是战出来的昨天跟同事讨论这个话题，他把我们这几年来的一些思考用了三句话来概括，非常精彩：从无到有的，是架构；从表到里的，是抽象；从粗到细的，是设计那么到底什么是架构呢？从上面的概括中你是看不到答案的到底如何做架构呢？从本文中你也是看不到答案的然而我说，你看不到答案的根源其实是在于你的眼光与心性后面这个词换成现代白话，就是思想真正阻碍了你成为优秀架构师的，也许正是你既有的知识与思想方法，扔掉它们，接受一些全然有别的信息，也许正是良好的开端
   也许你现在正愤愤然：这篇文章怎么空洞无物？我甚至能想象到一些读者的表情然而请在问题面前停下来，不要急于给出答案正如你将?稍微变下形，它就成为了!一样，问题的本身，就是答案

作者简介

   周爱民（aimingoo），具有十余年的软件开发项目管理和团队建设的经验，现担任盛大网络的平台架构师，著有大道至简Delphi源代码分析等