对aimingoo"架构师能力模型"一文的读后感

在 csdn上看到了 aimingoo的

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

一文，觉得写得很好，但是原文写得有些艰深，读起来颇费了些劲，(可能aimingoo从业多年，个人积累

太厚，说事述理更多是基于自己的能力背景和阅历经验来考虑， 而我这种积累得还是半瓶不满，一瓶更

欠的小葱，没有那样坚实的背景，想要从字里行间，领悟aimingoo背后的意图自然是要费些劲了^-^)

于是花了一些时间，把文章中自己觉得精彩的内容摘了出来， 附上自己的读后感，遂成此帖。原文请看

这里的链接（ 要求csdn会员帐户）。

http://vipnews.csdn.net/newscontent.aspx?pointid=2008_05_30_150239242


原文摘录：架构师不是界定一个技术高下的职位名称，而是一个职务。所谓职务，包括职——职位，务

——工作。前者决定了你具备哪些资源，可以影响到怎样的范围，以及面向的机构，后者则简单地是你需

要完成的工作列表。所以我说“架构师”不是指“一个能做架构的人”。前者是把架构师当职能，后者是当

工人。能做一份工作列表中的事，并不等于就成为相应职位上的人。在管理体系里面，你的个人特性决定

了你在哪个位置，而技术技能只是做事实施的必需。架构师这个职务，同时要求较高的个人素质和技术能

力，因此它的进取之路总结起来就是：做人、做事，做架构师。


读后感：我的理解是，一名合格的架构师，不能局限在技术里，还要能够站起来，学会观察自己

身边的资源，环境的状态并进行思考，基于自己对这些非技术的因素的观察，思考来调整自身工

作的步调。

比如说软件设计的基本原则之一就是高内聚，低耦合，但是在项目进度很tough，市场竞争白热

化的情况下，为了设计一个高聚低耦的软件架构，而丧失了市场先机，是否智慧呢？ 作为一名架

构师，要能够对技术以外的因素(比如市场，再比如customer的视角)保持一定的敏感度。概括

来说，就是不能唯技术论。

因此“模型”由“个人特性”和“技术技能”两个方面构成，“个人特性”既包括人际关系的能力，也包括（具

体）业务能力；“技术技能”也是如此。所以个人特性主要与“做人”有关，部分地也包含“做事”的要素。

“有效沟通”以及“学会谈判”与做具体的事无关，是个人能力特性的公共方面。前者是过程，后者是知道

如何定目标与求结果。而“风险与防备”是做事过程控制的关键，与前面两项正好构成了一个做事基本能

力的完整体系。基本上，这三项个人特性都是一个“普通程序员”所不具备的，甚至在大多数情况

下，普通程序员并不愿意去具备这样的个人特性，因为在许多陷于技术泥淖的开发人员看来：沟通总

是会使事情变得更加麻烦，谈判则徒耗时间而无济于事。然而事实上，在整个的架构决策过程中，架

构师需要不停地沟通与谈判。将“架构”变成“决策”的过程，其实就是对各个技术角色（及其思

想）兼容并包的过程，你需要不断地协调需求、实现之间的各种问题，也需要面对各种投资者

（时间、资金、人才等方面的决策者）进行谈判，以确定项目的规模——没有规模也就没有范围，没

有范围如何展开设计呢？

一部分开发人员会认为上述过程是“项目经理”的事情，但真的如此吗？当你作为一个更高级别的架构

师，以至于要影响到多个项目的决策时，你就全然不会有这种感受了。因为这种情况下，你的决策将先于

项目的启动，或者说你已经不单单是一个技术角色了。

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

职业生涯的第一步。


纯粹的技术人员，只要能够作好手上的一摊活，比如说设计好一个数据结构或是实现出一个高效

的算法就okay了。而一个架构师，则经常要面对自己的team之内以及自己team与其他team之

间的合作，竞争，甚至冲突关系。除此之外，站在架构师的级别，往往需要考虑资源整合的问

题，自己team所具备的资源可以承担什么样规格的事情？怎样为自己的team争取到最大力度的

资源支持？这些看似已经是管理职能的东西实际上也是一个架构师需要考虑的内容。

所以说架构师已经"不单单是一个技术角色"了。

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

个人特性中另一个非常重要的方面是“抽象思维”，而这是与架构师角色直接相关的一种能力。这种能力

既有职业技能特征，又是普遍性的能力。

用现有的成熟语汇去描述你的系统时，大多数人会理解你所表达的含义，例如我们说“这个系统设计为一

个三层结构”。然而架构师面临的系统在许多细节上并不见得能够用成熟的语汇去描述，因此必须

自已构建一个抽象系统，这就需要概念抽象能力、概念表达能力和基于概念的逻辑表达能力。

概念抽象能力是一种思维能力。简单地说，就是“把目标分解或概括清楚”：你要么概而言之“它是什么

”，要么详细地说明“它包括什么”。必须使用大量的语汇来陈述这个“什么”，这不单单是表达为文字，也

表达为你在思想过程中的一个完整系统。通常用的方法是“映射系统”。例如你可以用数学中的“数轴”来

映射“实数域”。将目标系统形式化为一个概念化的、可讨论的结构系统后，你的抽象过程就基本结束

了。

然而这个“抽象系统”可能只构建在你的思维意识里，还必须把它描绘出来。因为不能只是你自己思考清

楚，系统就能设计完成。这个“描绘”就依赖于后面两种表达能力，一种是描绘概念实体，一种是描绘实

体上的逻辑——有趣的是，这似乎又回到了“程序＝结构＋算法”。

现在大家回过头来看看UML，或者更多种类的ML（建模语言），他们就用于表达这两个方面的东西：要

么是概念实体（例如用一个框表明系统边界），要么是实体上的逻辑（例如用箭头表明逻辑时序）。

所以大家应该清楚，我们再如何称赞UML，它也只是一种对模型化系统的“表达能力”，你只能把它当一

种辅助表达的工具去使用，它本身既不能帮助思考，也不见得能作为抽象过程中的或抽象思维环境中的参

考。

概念抽象能力考察的是一个人能不能透过表象看到本质，是一针见血的穿透性思考分析能力。

而模型化则是具体化，生动化的表达能力。 关于模型化能力的一个例子就是＜＜非诚勿扰＞＞里

秦奋打过的一个比方：“这就好比，买了辆宝马车，却给它插了个奔驰的标，开是能开，但出了问

题怎么修啊？宝马人家不认，奔驰的件儿吧又不能用”。:)

一个团队里，是不能严苛的要求每个人都能具有穿透性的思考，分析能力的，退一步讲，考虑到

不同人的工作背景，以及知识结构的差异，也不大可能要求不同部门，不同team的人，能够对互

相从事的工作具备强大的抽象能力，比如说要求市场人员对软件技术范畴的东西具有高超的抽象

理解能力就有些夸张。

这种场景下，对于架构师来说，怎样通过模型化的手段来促进不同个体，不同 team之间的沟

通，协调，就显得很有意义了。

一个技术问题，一味从纯技术的角度，用偏技术化的语言去向市场部门解释，可能收效甚微，而

通过具体化的例子，以受众更熟悉的语言，更容易接受的形式进行表达，则会有更好的效果。

推动： 设计做大，实施做小
   
    架构师首先是把问题的真正目标确定下来，然后变成系统设计、平台设计或架构设计。而在此之后设

计输出将会有两个方向的发展，一是被忠实地贯彻下来，二是被变形地发展下去。两个方向都存在致

命的危险：架构最终能否被完整实现。对前者来说，可能是架构设计过度，或设计本身出现了错

误；后者则是对架构直接的伤害。

    所以架构师必须参与实施的全程——尤其是在架构被映射为目标系统的前期。在这个阶段中，架构师

的任务就是推动架构实施，以保证在项目全程的设计／架构／体系的一致性。除了直接跟设计师或设计团

队沟通，以保证他们的设计在你可以控制的范围之内以外，架构师还必须有阶段化设计的能力。这

种能力用于将一个原本规模宏大的架构设计，变成较小的、易于实施的、对开发团队来说可控的关键点。

例如在体系层次的规划上，设计可能是独立、异质的、可迁移的存储框架来实现数据层，但在（前期的）

实施上，这里可能被表达为本地数据库，并要求前端开发人员必须通过一个清晰的数据交互层来访问

——例如一组数据存取接口，或一个独立数据服务组件。开发人员可能在这里遇到障碍：因为要通

过这些中间层来访问本地数据库，纯粹是多余的。

然而，正是这“ 多余的工作”提供了系统弹性，为并行团队开发公共存储服务争取了周期，也为将来的灵

活部署与数据迁移提供了可能。

    这里的关键就在于，无论原始系统设定有多大，实施时总是在“做小”。每一个局部的实施块都是可控

的，并为它在整个体系空间中留下了位置和接口，这样才可能由“小的部分”做大。一个大系统的架构师

可能同时在考虑许多个项目中的、不同位置的架构，并且清楚这些项目最终的总体规模。而这，就

是平台架构师和体系架构师所涉的领域。


    说得很精辟。在架构设计的过程中，要能站得高，望得远，即所谓运筹帷幄。

    而实施过程中，则要能身先士卒，决胜千里了。

    项目实施过程中，存在哪些具体的技术瓶颈？在实施过程中，架构设计过程中所预期的足够的

相关资源是否都能够得到落实?随着项目实施过程的进展，原有的设计中是否有一些构成因为需求

的变动，进度的开展，市场形势的变化，已经不再适应当前的场景，应当及时从架构层面上作出

调整了？

    再有经验，再nb的架构师，也不大可能在项目启动的初始设计阶段就预计到整个系统的所有

可能问题，更多的场景下，是给出一个相对正确的方案和设计，并且保证这个方案，架构的可扩

展性，可修改性，接下来则需要在项目实施的具体过程中，根据实施过程的反馈对架构进行调配

了。

    初始架构设计得再好，架构师不参与进实施过程，或者说即使参与到实施过程中，却不能有意

识到调动起自己的实施积极性，以至于实施不到位，或者实施太拘泥于初始设计，最终的产出结

果，很可能离预期的相去甚远。

架构真的是“好不好”的问题吗？如同我对工程的理解一样，架构问题的根本，也并不在于它是否完美或

漂亮，而是在于是否合用。因此架构师必须对实施架构的团队以及实施过程有充分了解，知道他们的能力

缺陷，知道实现过程要消耗的资源，清楚每个环节可能的故障以及先兆。只有这样，架构师才能设

计一个让这个团队能实现，而且在实现过程中能受控的架构。

要知道，你作为架构师被请来，不是画几张图纸交给项目经理，说：你们去做吧，做不出来是你们不会

做。即使你可以身体力行，在这个团队中教大家、培养大家，那么公司的开销呢？风险呢？这些东西难道

就不考虑了？项目的周期因为实现的复杂程度而无法控制时，项目就死掉了。那么，追根究底来说

，是不是架构师的问题？是啊，你为什么会做了一份“不合用”的架构呢？——你都不知道项目如何开

发、由谁实施、如何管理等等，又如何能面对这些实际环境去设计架构呢？

所以这一部分能力，是要在你的开发经验、团队经验以及用人识人的经验中去找的。参考模型图的“实现

能力”下的“设计能力→了解你的主要沟通对象”和“架构推行”等分支，对你或有一些可用的提示。

    "架构问题的根本，不在于完美和漂亮，而在于是否合用"，个人感觉，这句话，只有经历过大

量的工程洗礼，以及经历过多次成功，失败的项目经验的人才能有感而发的。

    教科书上会告诉我们设计软件要保证高内聚，低耦合；教科书上还会告诉我们，要保证软件模

块之间的正交性。但是教科书上通常不会告诉我们，在tough的进度下，在市场竞争的压力下，

应当设计什么样的架构。

    能够接受不完美但可用的架构，对一名架构师来说，是一道必须能够迈过的心理门坎。

    技术上来看再完美的架构，不能适时，有效地整合进公司的整体战略，不能为公司的战略执行

作出实际的贡献，对公司来说都谈不上是有用的架构。(当然，在纯粹的技术层面或是学术层面还

是会有一定的价值的)

局部与全局

架构是从全局到局部

实施是从局部到全局

设计大才可以见到全局，才知道此全局对彼全局的影响；实施小才可能关注细节，才谈得上品质与控制

事实上，大多数情况下架构是在为“当前项目之外”去考虑，这可以看成全局关注的一个组成部分。因此

我们需要界定所谓“全局”的范围：超出公司或整个产品系列、产品线或规划的范围才是多余的。

所以当架构决策谈及“全局”时，其目标并不见得是“保障当前项目”，而又必须由当前项目去完成。

一个经常被用到的例子是：如果仅为当前项目考虑，那么只需要做成DLL模块；如果为产品线考虑，可能

会是“管道＋插件”的结构形式。而“管道＋插件”的形式显然比做成DLL模块更费时，这个时间成本（以及

其它成本）就变成了当前项目的无谓开销。

这种全局策略对局部计划的影响是大多数公司不能忍受的，也被很多团队所垢病。然而这却是架构师角色

对体系的“近乎必然 ”的影响——如果你试图在体系中引用架构师这个角色的话。一些情况下，体系能够

容纳这种影响，例如“技术架构师”试图推动某种插件框架，而正好开发人员对这项技术感兴趣，那

就顺其自然地花点工夫去实现了。但如果不是这样，实施者或实施团队看不到“多余的部分”对他们的价

值时，来自局部的抵触就产生了。

这种情况下，平衡这些抵触就成了架构推行的实务之一。在我看来，“平衡”是全局的艺术和局部的技

术。也就是说，一方面架构师要学会游说，另一方面也要寻求更为简洁的、成本更小的实现技术。只有当

整个体系都意识到（你所推行的）架构的重要性，而且实施成本在他们可以接受的范围之内时，他们才会

积极行动起来。

所以所谓平衡，其实也是折衷的过程。构架师只有眼中见大，才知道哪些折衷可以做，而哪些不能。所谓

设计评估（模型图中的实现能力->设计能力->设计评估分支）并不是去分析一个设计结果好或不好，而

是从中看到原始的需求，看到体系全局的意图，然后知道在将设计变得更为

“适当”时可以做哪些折衷。同样的原因，架构师也必须知道自己的决策会产生的影响，才能控制它们，

以防它们变成团队的灾难。有些时候，架构师甚至需要抛弃一些特性，以使得项目能够持续下去。因为产

品的阶段性产出只是整个战略中的一个环节，而不是全部。


    架构师往往要考虑到，在产品如期deliver的前提下，这个产品的的可扩展性，可维护性如

何？ 它与未来可能上线的其他产品的接口性如何？而这些事物， 通常来说，是被架构师以外的人

视为跟当前项目无关的，以至于他们不愿意在这些事物上面投入太大的资源和精力。怎样确保这

些事物能够获得其他人员的支持，从而确保可以获得所需的相应资源？这就要求架构师能够去平

衡参考不同方面的意见，适当地作出妥协，而又知道哪些是必须坚持的，通过不断的沟通，协

调，游说，来获得所需的资源。

    纯粹的完美主义型的架构师，在这样的场景下，往往会发现自己遇到巨大的压力，而不能前进

了。

    而实际上，矛盾产生的地方，往往也会分化为主要矛盾和次要矛盾，也许你关注的主要矛盾对

其他人来说反而是次要矛盾，而其他人关注的主要矛盾在你来说又不值一晒，了解到整个团队里

不同人员，不同team的考虑出发点，作出相应的权衡，适当的让步，从而为自己争取更多的资

源，这就需要靠架构师的智慧来进行把握了。

“怎么做一个架构师”这个问题得分成两个部分来看，一个是“做到”，一个是“做好”。由于架构师本身不

过是一个技术职位，所以时机成熟了自然会做得到。但问题是，真有一天你被放在这个位置上了，你能做

得好吗？

我浏览过几套所谓培训机构的有关架构师的教程，也翻阅过一些讲架构的书。我发现他们普遍地是将架构

作为一种“职业技术”来讲，就像培养程序员或者缝纫工一样来教育。但就我的经验来说，架构并不是一

件纯粹表现技术能力的工作，所以并不是翻几本书学几种方法就可以投入“实战

”的。更深层的问题是，架构师其实不是“战”出来的。昨天跟同事讨论这个话题，他把我们这几年来的一

些思考用了三句话来概括，非常精彩：从无到有的，是架构；从表到里的，是抽象；从粗到细的，是设

计。

那么到底什么是架构呢？从上面的概括中你是看不到答案的。到底如何做架构呢？从本文中你也是看不到

答案的。然而我说，“你看不到答案”的根源其实是在于你的眼光与心性——后面这个词换成现代白话，

就是“思想”。真正阻碍了你成为优秀架构师的，也许正是你既有的知识与思想方法，扔掉它们，接受一

些全然有别的信息，也许正是良好的开端。

或许你现在正愤愤然：这篇文章怎么空洞无物？——我甚至能想象到一些读者的表情。然而请在问题面前

停下来，不要急于给出答案。正如你将“?”稍微变下形，它就成为了“!”一样，问题的本身，就是答案。

按我的理解，架构师的能力模型由两部分组成，一部分是有形的具体技能，另一部分则是无形的

软技能。

架构师能力模型中，有形的那部分东西（软件实现的技巧，设计模式的运用，软件设计的能力）

是时机成熟以后自然会得到的。这个时候，我们就说某个人在技能上已经可以作架构师了。

但架构师能力模型中，还有一部分不那么有形的东西，这部分东西看起来甚至有点虚无飘渺。比

如说，作为架构师，是不是能够结合市场来考虑技术方案的实现难度和成本？ 是不是能对整个团

队资源的配备建立起一个清晰的认识？ 是不是对公司决策层的想法有一个清晰的把握和认

识?。。。而恰恰是这部分东西，决定了一个架构师能不能作好。具备了这些无形的软能力之后，

才能在具体的架构设计工作中更有效地应用你积累起来的技术能力，而不会让那些技能成为别人

眼中的屠龙之技，曲高和寡。这个时候，离一个优秀的架构师也就为时不远了。