架构师应该知道的37件事

是企业的负担还是救星

在企业IT环境里，架构师的工作既令人兴奋，又富有挑战性。很多管理人员和技术人员都认为架构师拿的报酬太高，认为他们活在象牙塔里，脱离实际，只知道用幻灯片和大幅海报来把自己的想法强加给公司里的其他人。此外，他们还会追求一些无关紧要的理想，从而导致做出糟糕的决策，使项目无法按时间表进行。

尽管如此，IT架构师近年来却变成最炙手可热的IT专业人士之一，因为传统企业迫于压力，需要将企业IT部门从单纯的成本中心转变为业务驱动者。这是个好消息，但企业对架构师的期望很高：他们希望架构师能在上午解决突发的性能问题，下午还能继续推动企业文化的转型。与此形成鲜明对比的是，很多数字化企业巨头拥有世界级的软件和系统架构，但根本没有架构师。IT架构师的时日屈指可数了吗？

架构师不是什么

有时候，和明确定义某个事物是什么相比，定义它不是什么更容易。通过这个方法，我发现架构师经常扮演下面4种角色，而这些角色要做的事情根本就不是架构师的职责。

消防员：很多管理人员都期望，架构师能随时分析并解决任何突发的危机，因为他们对当前系统有足够全面的了解。然而，架构师不应该无视产品的问题，因为这些问题很可能反映出架构上的设计缺陷。但是时刻都在忙着“救火”的架构师根本就没有时间去做真正的架构。架构设计需要思考，只给30分钟肯定无法完成。

资深开发人员：开发人员常常觉得他们需要把架构师这个角色作为其职业生涯（和薪资水平）的下一个目标。但是，成为架构师和成为明星工程师完全是两条不同的路线，两者没有高低之分。架构师需要有更广的知识面，包括组织和战略方面的能力，工程师则需要专攻可运行软件的交付。理想情况下，大型组织的首席IT架构师和资深开发人员的关系都很好。

项目经理：架构师必须能够并行处理多个不同但相关的主题，他们在做决策时也需要考虑项目时间表、人员配备以及所需技能。因此，上层管理者经常会通过架构师获取有关项目的信息和决策，尤其是在项目经理忙于准备项目状态报告模板的时候。这会让架构师陷于更糟糕的境地，因为虽然为管理层提供项目信息和决策也是有价值的工作，但它毕竟不是架构师的主要职责。

科学家：架构师要才思敏捷，要能够从系统和模型的角度进行思考，还需要为具体项目和业务计划制定决策。这常常将首席架构师的角色与首席科学家的角色区分开来，尽管这两个角色的界限很模糊——我知道一些首席科学家就是喜欢亲力亲为。我个人更喜欢首席工程师这个头衔，它强调了架构师除了撰写文档外还需要做其他事情。最后，科学家常常把事物理论化和复杂化，而架构师的工作则是化繁为简。

衡量架构师的价值

曾经有人问我用什么关键业绩指标（KPI）来衡量自己作为架构师的价值。他们觉得应该是做出决策的数量。这个提议让我有些惊讶，我确信这不是我要寻求的KPI。做出决策固然重要，但必须要避免做出不可逆的重大决策，在这一点上我十分认同Martin Fowler的观点：“架构师最重要的任务之一就是消除软件设计中那些不可逆的决策。”

在别人问我作为架构师的价值时，我有两个“标准”答案。首先，我会解释说，如果我们的系统在5年后还能良好运行，并且依然可以承受合理水平的变更，那么我的工作就做得很好。如果大家希望我更具体地描述一下我的工作，我会解释说企业里资深架构师的工作分为以下3个层面。

定义IT战略，比如，定义系统（无论是打算自己构建还是从外部购买）的必要IT特性，或者识别为了支撑业务战略还需要补充到现有IT配置组合中的组件。战略也包括“退休”系统（电影《银翼杀手》中的特色词语）以免你被僵尸系统包围。
落实对IT蓝图的管控，以实现协调一致，降低复杂度，以及确保所有系统集成为一个有效整体。架构评审委员会需要自始至终担起管控的责任。
脚踏实地地关注项目的实际情况，从实际项目实施中获得有关决策的反馈。否则，控制依然是假象。

架构师是变革促进者
架构师是大型企业IT转型中至关重要的一员。为此，他们必须具备一系列特殊的技能：

能够通过乘坐架构师电梯上下，与组织中的不同层级合作；
具备著名电影角色的一些特点，尽管有不止一种角色模型；
明白自己在企业中的位置；
具备专业技能，但这只是架构师立足的“三条腿”之一；
是优秀的决策者；
刨根问底以找到问题的根源。

1.1　架构师电梯
在顶层套间和发动机房之间往返

高楼需要乘坐电梯上下

1.1.1　缺失的一环

架构师所扮演的承上启下的角色非常关键，尤其是在大型组织里，部门之间业务语言不同、观点不同、目标不同甚至冲突。而很多管理层在企业内部的沟通中还大玩“电话游戏”1，让沟通问题变得更加严重。最糟糕的情况是，掌握相关信息或专业技能的人没有权力做出决策，而决策者却缺乏相关信息。这对于企业IT部门来说不是个好兆头，特别是在当前这个技术已经成为大多数业务驱动力的时代。

1 电话游戏里，小孩们围成一圈，逐个向下传递从上个小朋友听到的消息。当消息返回第一个说出消息的小孩时，他们会发现消息在传递一圈后完全改变了。

1.1.2　架构师电梯

在大型企业里，架构师能填补一项重要的空白：他们既能在项目上和技术人员密切地工作和沟通，也能在不丢失信息本意的前提下，向上层管理者传达和解释技术主题。换句话说，架构师能理解公司的经营战略，并且能将其转化为技术决策。

如果把组织内的不同层级看作大楼的不同楼层，架构师就能乘坐我所说的架构师电梯：在大型企业里，他们搭乘这种电梯，在董事会会议室和负责构建软件的发动机房（工程师团队）之间往返。在IT快速变革和数字化颠覆的时代，这种不同层级之间的直接联系已经变得前所未有地重要了。

我们再用大型船舶的场景做个比喻。大家都知道，如果油轮上的舰桥发现了障碍物，为了调转船头，游轮需要反转发动机并且尽力向右转舵。但是，如果所有发动机实际上都在全速向前运转，灾难迟早会发生。这就是为什么老旧的蒸汽船也会有一个直接连接船长室和锅炉房的管道，这样船长就能直接发号施令并得到及时反馈。在大型企业里，架构师就必须扮演这个管道的角色。

1.1.3　有些组织的层级比其他组织要多

回到楼层的比喻上，架构师搭乘电梯上下几层楼取决于组织的类型。扁平的组织结构可能根本不需要电梯，只需几阶楼梯即可。这也意味着架构师这个上下沟通的角色不是很重要了：如果管理层能敏锐地了解必要的技术实现细节，并且技术人员能与高层管理者直接沟通，就不需要那么多的“企业”架构师了。可以说，数字化公司就像是一座单层平房，压根就不需要电梯。

然而，大型组织里，典型的IT部门之上往往有很多楼层。他们位于高耸的摩天大楼里，因此，单部架构师电梯可能无法直达所有楼层。这种情况下，技术架构师和企业架构师可以在中间的楼层会面，各自覆盖“一半”楼层。这种场景里，架构师的价值不应该按照他访问的楼层高度来衡量，而应该根据他们覆盖的楼层数目衡量。大型组织中，一个常见的错误是，住在顶层豪华套间里的管理者只看见并重视位于楼层上半部分的架构师。相反，很多开发人员或者技术架构师都认为所谓的“企业”架构师没多大作用，因为他们压根就不写代码。在某些情况下，这可能是真的，这样的架构师往往很享受在上半部分楼层的惬意生活，因此没有意愿再搭乘电梯前往下半部分楼层。但是，经常前往下半部分楼层和技术架构师分享战略愿景的“企业”架构师还是有重要价值的。

1.1.4　不是单行道

你肯定会遇到搭乘电梯到顶层后就再没下来的家伙。他们非常享受从顶层豪华套间往下看的美景，而且觉得自己辛苦工作不是为了继续去脏兮兮的发动机房。你经常会听到这些家伙说：“我过去可是搞技术的。”听到他们这样说，我会情不自禁地反驳：“我曾经还是经理呢！”（这是事实）或者“你们为什么不接着做了呢？是不是做得不好？”如果你想反驳得更委婉一些（并且更富有深度），可以参考Fritz Lang的电影《大都会》。在这部电影里，顶层豪华套间和发动机房之间的隔阂几乎彻底地毁灭了整个城市，后来人们才认识到“头和手之间需要一个调停者”。任何情况下，电梯都是用来在楼层间上下往返的。顶层人士享受着山珍海味，而底层劳动者却奄奄一息，这显然不是企业IT转型的正确方式。

乘坐电梯上下对架构师而言也是一个很重要的机制，他们可以获取别人对决策的反馈，并理解这些决策的实现结果。过长的项目实现周期无法提供好的学习循环，会导致出现架构师的夙愿，开发者的梦魇这样的场景。允许架构师只在高层享受美好风光，一定会导致有权无责，这是一种遭人唾弃的反模式。只有架构师必须承受或至少观察他们决策的后果，才能打破这种模式。为此，他们必须不断地搭乘电梯上下奔波。

1.1.5　高速电梯

过去，IT决策和经营战略几乎没有关系：IT只被看作附加品，它的主要参数（或KPI）是成本。因此，由于新信息稀少，搭乘电梯上下并不是很关键。但是，如今的业务目标和技术选择之间的联系已经变得越来越直接了，即使对“传统”的业务也一样。比如，想要通过更快地将产品投放市场来应对竞争压力，就需要灵活的云计算方式，而这又需要支持横向扩展的无状态应用程序。要获得客户渠道相关的内容，就需要分析模型，而优化模型则需要通过Hadoop集群收集大量的数据，但是Hadoop适合使用本地磁盘存储而不是共享的网络存储。用一两句话，就将业务需求转换成了应用程序和基础设施设计，这一事实凸显了架构师搭乘电梯上下沟通的必要性。而且，他们必须搭乘更快的电梯，这样才可以跟上业务和IT交织发展的节奏。

在传统的IT部门，较低的楼层可以仅供外部顾问使用，这样企业架构师就不必处理方案具体落地的事宜。然而，这样只聚焦在效率上，而忽略了速度经济2，在技术快速变革的时代，这是一种糟糕的选择。长期处于这种环境中的架构师必须扩展其角色职责，不能只是全盘接收供应商的技术路线图，而是要主动地定义它。为此，他们必须要形成自己的IT世界观。

2 速度经济是指企业因为快速满足顾客的各种需求而带来超额利润的经济。——译者注

1.1.6　其他乘客

作为成功的架构师，当你搭乘电梯上下往返时，可以能会遇到其他一些乘客与你同行。比如，你可会能遇到一些业务人员或非技术人员，他们明白深入地理解IT对业务发展至关重要。对这些人友善些，带他们到处看看。让他们参与到对话中，可以让你更好地理解业务需求和目标。此外，他们还可能会带你前往你从未去过的更高的楼层。

你还可能遇到另外一些人，他们乘坐电梯下楼只是为了“索要”时髦用语，以便到顶层豪华套间卖弄自己的想法。我们不把这些人称作架构师。搭乘电梯却很少出来的人通常会被称为电梯服务生。受益于顶层人士的无知，这些人可以追求到一种从不真正接触实际技术的所谓的“技术”职业生涯。你也可以尝试去改变一些人，让他们真的对发动机房的真实运作细节感兴趣。但是，如果尝试不成功，你最好保持沉默，比如，一直看着电梯天花板以避免和这些人发生眼神接触。等到和高管同乘一梯时再进行“电梯游说”，而不要和普通传话人浪费唇舌。

1.1.7　搭乘电梯的危险

你可能以为雇主肯定非常欣赏搭乘电梯上下忙忙碌碌的架构师。毕竟，架构师能给那些希望通过IT转型在数字时代获得更强竞争力的企业带来很大的价值。令人惊讶的是，这些架构师可能会遇到意想不到的阻力。顶层豪华套间里的决策层和底层发动机房里的实施团队可能都会对彼此“失联”的现状很满意：公司领导层看到的是数字化转型进展顺利的假象，而发动机房里的员工则可以不管业务需求，随心所欲地“摆弄”新技术。这样的情景就像是一艘巨轮全速撞向前面的冰山。当领导层意识到现状时，很可能为时已晚。有时候，我会把这样的组织结构比喻为顶层和底部并非垂直对齐的比萨斜塔，在这种倾斜的建筑里搭乘电梯上下肯定更有挑战性。

当架构师步入这样的环境时，必须在搭乘电梯时准备好面对来自高层和底层的双向阻力。我就曾经被“发动机房”的员工们批评过，他们嫌我违背开发人员的意愿单方面推行公司计划，同时，企业的领导层又批评我单纯为了乐趣而尝试新的技术方案。做一名改革者很难，特别是当系统抗拒改变的时候。一种非常好的策略是，从一开始就小心翼翼地把各个层级连接起来，然后等待合适的时机向大家分享信息。比如，你可以向管理层解释发动机房里的员工们的工作有多棒，这可以让管理层进一步了解和认可他们，同时你也有机会获取更详细的技术信息。

其他对你搭乘电梯上下忙碌不满的企业人员是中间楼层的占有者：他们看见你总是在决策层和发动机房之间往返，感觉自己被无视了。我把这称为欣赏的“沙漏”曲线：高层管理者把你看作转型的关键推动者，而发动机房的员工也很开心有人真的理解和欣赏他们的工作，但中间层的员工则把你视为威胁，你害他们无法负担子女的教育支出，无法购买山景房。这是一件很微妙的事情。有些人主动在半路上拦你：他们会在每一层拦停电梯并要求你给个解释，如此这般，搭乘电梯还不如爬楼梯快。

1.1.8　将大楼扁平化

与其无休止地搭乘电梯上下，何不直接消除那些不必要的楼层呢？毕竟，你试图与之竞争的数字化公司并没有这么多楼层。不幸的是，除非将整栋楼炸成一堆瓦砾，否则你根本无法让这些楼层消失。无论如何，消除中间楼层的那些人也不现实，因为他们往往是组织和IT蓝图信息的主要持有者，特别是在幕后还有一个大黑市的时候。

将大楼逐步扁平化也许是个合理的长远战略，但这需要改动企业文化的根基，因而会耗费太长的时间。除此之外，还需要改变或消除中间楼层员工的角色，而这势必会遭到强烈的抵抗。所以，这不是一场架构师能打赢的仗。不过，架构师可以逐步瓦解阻力，比如，让顶层管理者对来自发动机房的信息感兴趣，提供更快的反馈回路，以及减少中层管理者做状态更新汇报的次数。

1.2　电影明星架构师

企业架构师的4个角色

架构师名人堂

除了搭乘电梯上下外，架构师还需要做些什么？让我们试着用另一个比喻来解释：电影明星。

通常在电影正式开始播放前，你会看到一些商业广告或短片。这里要说的是一个有关“架构师”这个词起源的短片：它派生自希腊语单词ἀρχιτέκτων，简单翻译过来就是“首席建筑师”。记住，这个单词就是指那些建造房屋和结构的人，而不是构建IT系统的人。我们应该注意到这个单词隐含的意思是“构建者”，而不是“设计者”——架构师应该是真正参与构建的人，而不是只画些漂亮图纸的人。人们也期望架构师技艺精湛，这样才配得上“大师”这个标签。下面我们进入正题……

1.2.1　黑客帝国——规划大师

如果让技术宅给出电影中经典架构师的名字，你很可能会听到他们提到电影《黑客帝国》三部曲。黑客帝国的架构师是一个“冷酷、毫无幽默感、身着浅灰色西装的白发男人”（参见维基百科），这个人实际上就是一个计算机程序。维基百科里也描述说，这个架构师“长话连篇但头头是道”，这也是很多IT架构师的讲话方式。所以，也许这个类比挺贴切？

黑客帝国架构师同时也有最终的决定权：他设计了黑客帝国（一个用来模拟现实的计算机程序，人类在其中被机器作为能量源圈养）并且知晓和掌控其中的一切。企业架构师有时候也会被看成这种人——无所不知的决策者。有些架构师甚至希望自己能成为这样的人，因为无所不知会让自己的工作有条不紊，还会为自己赢得更多的尊重。当然，这种角色模型也有一些问题：无所不知对人类来说几乎是不可能的，这也意味着，我们会不可避免地看到一些糟糕的决策和其他各种问题。即使架构师超级聪明，他也只能基于自己了解的事实做出决策。在大型企业里，这就意味着要依赖来自中间管理层的幻灯片报告或陈述，因为无论你多么频繁地搭乘电梯前往发动机房，都不可能接触到所有可用的技术。这个通往最高决策者的信息渠道往往会被某些人严密保护起来，因为他们会意识到该渠道是个很有影响力的信息传达手段，因此，架构师往往间接收到信息，而且信息经常有偏差。所以说，基于这个角色模型做决策是很危险的。

总而言之，企业IT不是电影，它的作用不是为了给被当作能量源圈养的人类创建幻象。我们应该警惕这种角色模型。

很有意思的是，现实中的Vint Cerf，作为互联网的主要架构师之一，和黑客帝国架构师极其相似。考虑到Vint设计了我们所处的黑客帝国（互联网）的很多部分，因此，这也许并不是单纯的巧合。

1.2.2　剪刀手爱德华——园丁

对于企业架构师，园丁是一个更加贴合的比喻。我喜欢把企业架构师比作电影《剪刀手爱德华》（我最喜欢的电影之一）中的园丁。大型IT部门像是一个花园：各种植物按照各自的方式生长，其中杂草总是长得最快。园丁需要修剪那些长得太快或者凸出的部分，保持整个花园的平衡与和谐，同时考虑到各种植物的具体需求——比如，喜阴植物应该种植在大树或灌木丛旁——这些都是园丁的职责。好的园丁不会一意孤行，也不会去决定像青草应该朝哪个方向生长这样的细节——日本园丁可能是个例外。更准确地说，园丁把自己看作生态系统的守护者。有些园丁，像爱德华，已经成为了真正的艺术家。

我之所以喜欢这个比喻，是因为它很贴切。复杂的企业IT部门是个有机体，因此优秀的架构师都有很好的平衡意识，这也是好园丁所具备的素质。使用除草剂进行自顶而下的治理不可能产生持久的效果，而且通常弊大于利。这样的思考是不是能使《秩序的本质》这本书得到新的应用，我还不确定。我想自己应该先读读这本书。

1.2.3　粉身碎骨——导游

ThoughtWorks的欧洲技术主管Erik Dörnenburg给我介绍了另外一个非常恰当的比喻。Erik密切参与过很多的软件项目，他非常讨厌那些表面上无所不知，实际上专断独行又脱离实际的架构师。Erik甚至还创造了一个术语：无架构师架构。这可能会让一些架构师担心自己的职业生涯。

Erik把架构师比作导游。导游去过某个地方很多次，能讲关于这个地方的好故事，还能热心地引导游客注意重要事项，避免无谓的风险。旅游业有条行规是，导游不能强迫游客采纳他们的建议，当然，那些敢把一车游客丢在荒无人烟的黑店的导游除外。

导游类型的架构师必须“运用自己的影响力来引导他人”，也就是说，他们必须有真材实料才能赢得尊重。导游需要和游客一路同行，而不能像某些咨询架构师那样只给游客提供一份地图。但导游类型的架构师通常依赖于管理层的强大支持，因为没有明确的证据能够证明是他的指导带来了好的结果。在纯粹的“业务驱动”环境下，这会限制“导游”架构师自身的影响力或职业生涯。

《粉身碎骨》，这部1971年上映的公路电影，也是我最喜欢的电影之一。其中的角色盲人DJ Super Soul是一个不同寻常的导游。像很多IT项目一样，这部电影的主角Kowalski踏上了一场死亡之旅，沿途障碍重重，他很难在约定时间内完成任务。不同的是，Kowalski要交付的不是代码，而是要在15小时内把一辆1970年生产的道奇挑战者R/T 440 Magnum从丹佛开到旧金山。Kowalski由Super Soul引导，后者利用警察网络获取关键信息，就好像架构师接入管理网络一样。一路上，Super Soul追踪着Kowalski的进展，并为他清除警察（即管理层）设置的各种陷阱。然而，在Super Soul向“管理层”妥协后，交付道奇车这个“项目”就变成了无头苍蝇，最终像很多IT项目一样功亏一篑。

1.2.4　绿野仙踪——魔法师

架构师有时候会被看作可以解决任何技术难题的魔法师。虽然这可以作为一个短期的自我吹捧，但不是一个合适的工作描述，也不是一个为之奋斗的合理目标。这里所说的“魔法师”并不是指那种挥动魔法棒的真正魔法师，而是电影《绿野仙踪》里那个“强大的奥兹”—— 一个看起来很强大的投影，但实际上只不过是由一个人类“魔法师”控制的，而人类魔法师只是通过大型机械来制造魔术效果并以此赢得尊重的普通人。

在那些“普通”开发人员很少参与管理层讨论和重大决策的大型组织里，这种精心设计的欺骗可以起到一定的作用。这种情境下，“架构师”这个头衔可以让开发人员显得更加“了不起”：这种放大的投影效果能够赢得企业普通人员的尊重，甚至可以成为搭乘电梯前往顶层的前提条件。这是欺骗吗？我会说“不是”，只要你不要过于迷恋这种魔幻效果而忘记自己作为开发人员的技术根基就行。

1.2.5　超级英雄还是强力胶

和魔法师类似，对架构师的另一个期望就是超级英雄：如果你相信某些职位描述，那么企业架构师是这样的：能易如反掌地让公司进入数字时代，能够解决任何技术问题，并且总是对最新技术了如指掌。要达到这些期望很难，所以我要提醒所有架构师，不要对这些常见的误解信以为真。

英特尔公司的Amir Shenhav恰当地指出：我们需要的是“强力胶”架构师，而不是超级英雄。“强力胶”架构师既懂得架构，又了解技术细节，还明白业务需求，而且能将大型组织和复杂项目中的人员团结起来。我喜欢这个比喻，因为它类似于把架构师比作催化剂。只不过，我们必须小心一些：强力胶或者催化剂，意味着你要相当了解要去“黏合”的东西。架构师不单单是个牵线搭桥的角色。

1.2.6　做决定

究竟要做哪种类型的架构师呢？除了上述架构师类型，还有更多的架构师类型以及可类比的电影角色。你可以像电影《盗梦空间》里那样，通过（危险的）意识潜入来创建架构的理想世界；或者像电影《我为玛丽狂》里的两个骗子那样就智利建筑争辩不休；抑或像乌托邦剧《摩天大楼》中的（令人毛骨悚然的）Anthony Royal 那样制定规则。总之，你可以选择的架构类型有很多。

最终，大多数架构师是这些经典形象的结合体，有时是强力胶，有时是园丁，有时又是导游，有时又展现出一种无所不知的高大形象。按照需要扮演不同的角色，就可以成为一个优秀的架构师。

1.3　企业架构师与企业里的架构师

象牙塔里的上下层

出自象牙塔的架构

当我被聘为企业架构师时——更准确的头衔是企业架构主管（Head of Enterprise Architecture），我还不太清楚企业架构师到底需要承担什么责任。我也想知道，如果我是企业架构的“头”（Head），我的团队是不是就应该被称为企业架构的脚3，但团队成员并不喜欢这个称谓。现在，这种加上“主管”后缀的头衔很流行。下面是我偶然在某个在线论坛看到的对这种现象的恰当解释。

3 用来讽刺头衔设置得不合理。——译者注

这个头衔通常表示候选人本想成为总监、副总裁或者执行官，但是组织不允许再增加这些岗位的人员数量了。通过授予这种模棱两可的头衔，在组织外部看来，候选人已经处于较高的级别，但在组织内部，候选人并没有获得相应的权力配备。

我特别不喜欢“某某主管”之类的头衔，因为它强调的是带领团队，而不是实现具体的职能。我更愿意用一个岗位要达成的目标来命名它，并且要体现出履行该职能需要团队支持。幸运的是，我现在是个“首席”，不再是个“主管”了，用一个在政治上不那么正确的比喻来说，当我还是个“主管”时，偶尔会以“打哈哈”的官僚方式和人打招呼。

抛开所有的头衔后缀不提，当IT人员遇到企业架构师时，他们最初的反应是要把这个人放到顶层豪华套间去，在那里，他们可以绘制漂亮却没什么实际作用的架构图。因此，要想受到IT人员的热情欢迎，就应该慎用企业架构这样的标签。然而，又该如何称呼那些完成企业级架构工作的架构师呢？

1.3.1　企业架构
“企业架构师”这个称谓的问题是，它既可以描述一个构建整个企业架构（包括业务策略层级）的人，又可以描述一个在企业层级（比如，相对于部门的架构）构建IT架构的人。

为了消除歧义，我们来看看书上的定义。Jeanne Ross和Peter Weill的《企业架构战略》一书是这样定义企业架构的：

企业架构是业务流程和IT基础设施的组织逻辑，二者共同反映了企业运营模式的集成和标准化需求。

按照这个定义，企业架构不止包含IT职能，也需要考虑业务流程，后者是企业运营模型的一部分。实际上，这本书中最为人熟知的是一张四象限图，这张图用不同水平的流程标准化（各业务线一致）和流程集成（数据共享和流程互连），描述了业务运营模型。通过给出每个象限的行业实例，该图把每个模型映射到相应的IT架构策略。比如，如果业务运营模型是高度多样化的业务单元之一，且共享客户很少，那么数据和流程集成程序可能没有什么价值。这种情况下，IT部门应该致力于提供公共基础设施，然后每个部门都可以在其基础上实现自己特有的流程。这个象限图完美地揭示了业务和IT架构必须保持一致才能为业务提供价值。

1.3.2　业务和IT是平等的
无论如何，我认为把IT跟业务剥离是有问题的。我喜欢开玩笑说，在公司所有业务信息系统运行在计算机上之前，也没看见单独在“纸”上的部门啊。在数字化公司，IT就是业务，业务就是IT——二者不可分割。因此，我认为企业架构应该定义如下：

企业架构是业务和IT架构之间的黏合剂。

这个定义意味着共有两个“企业级别”的架构，一个是业务架构，另一个是IT架构。虽然两者的侧重点稍有不同，但需要紧密配合。比如，业务架构定义公司的运营模型，而IT架构则构建相应的IT能力。如果两者能够无缝合作、齐头并进，就不需要其他东西了。如果它们没能紧密联系，就需要企业架构部门来把两者协调联系起来。这就好像新加了一部中层电梯，它可以把顶楼豪华套间的管理决策层和底部发动机房的开发人员联系起来，因为已有的电梯无法直接把大楼顶部和底部连通起来。这种企业架构部门的长远目标必须是淘汰自己，或者至少让自己的规模变小。

我认为这是期望的状态，因为它能平等对待IT架构和业务架构。虽然在企业中支持业务依然是所有职能的目标，但只把IT看作以尽可能低成本管理商品资源的简单命令执行者的时代已经结束了。在数字时代，IT已成为一种竞争力，并且能带来机遇，而不是像电一样的简单必需品。这种改变必须要反映在架构职能的建设中：业务驱动IT，但是IT也能驱动新的业务。

这个模型需要业务架构和IT架构一样成熟，要做到这一点是有一定难度的，因为业务架构是一个比IT架构更新、更不明确的领域。这也体现在商界中架构化思考（比如，合理的系统化思考）的不足上，这可能是因为相关课程在这一点上强调得不够。因此，作为一个成功的首席架构师，你还需要帮助组织强化业务架构。

1.3.3　企业里的架构师
我的定义也意味着，至少某些架构师是在企业范围内工作的。我在谈到“企业架构师”或“IT架构师”时，指的就是这些人。他们通常是技术人员，已经学会搭乘电梯前往上半部楼层和管理层以及业务架构师打交道。他们就是本书的主要读者，也是IT转型中的关键元素。

那么，“企业级架构师”和“普通的”IT架构师有什么区别呢？首先，企业级架构师要处理的所有事项规模都更大。很多大型企业都是拥有不同业务单元和部门的企业集团，其中每个业务单元和部门都有着数十亿美元级别的业务和特有的业务模型。因为规模变大了，所以你会发现更多的遗留物——业务会随着时间推移或通过并购增长，而这两种情况都会产生遗留物。这种遗留物不只局限于系统中，也存在于人们的观念和工作方式中。因此，企业级架构师必须能够引导组织并处理其中复杂的政治局势。

1.3.4　哪些楼层
传统的企业架构通常被搁置在象牙塔里，而且被认为没什么价值。导致这种情况的一个原因是反馈周期过长：评判某人是否完成了优秀的企业架构经常比评判优秀的IT架构需要更长的时间。因此，企业架构部门会成为一些人的藏身之地，这些人只想成为象牙塔里的绘图员，而不是为公司打造业务并创造价值的真正架构师。这就是为什么企业架构师需要展现影响力，比如，维护一幅精准又详细的IT世界地图。这幅地图不能是那种典型的“职能地图”，它必须要包含真正有用的信息。

如果企业认真对待架构，它会为企业的所有层级提供重大价值。这让我想起了1977年由Charles和Ray Eames为IBM制作的短片《10的次方》。该短片把芝加哥的一份野餐每10秒缩小一级，一直缩小到10的24次方，此时，大家看到了无数个星系。随后，它又把同样的野餐每10秒放大一级，一直放大到10的负18次方，此时，大家看到的是夸克的世界。有趣的是，这两种视角看待同一个事物的结果并没有太大的不同。我觉得在更大的企业中也是如此：从远处看到的复杂度与从近处看到的是类似的。它几乎就像个分形结构：你越放大或越缩小，它看起来就越相同。因此，完成重大的企业架构和修复一个Java并发缺陷的复杂度和价值是一样的。但这需要企业架构师从顶楼象牙塔里走出来，至少搭乘电梯下几层楼，去完成有实际价值的工作。

1.4　架构师用三条腿立足
架构师需要横向扩展

三脚凳不会摇晃

IT架构师是做什么的呢？答案是，IT架构师是打造IT架构的人。这就需要定义架构是什么。假设我们知道这个答案，那么一个优秀的架构师在经过多年的成功后会成为什么？在顶楼豪华套间中占有一席之地？希望不是。成为首席技术官？这是个不错的选择。或者依然是一个（资深的）架构师？这也是很多著名的建筑大师所做的。然而，我们需要明白初级和高级IT架构师的区别在哪里。

1.4.1　技能、影响力、领导力
当被问到资深架构师具有哪些特征时，我会使用下面这个简单的框架，而且相信它也适于大多数高端职业。一个成功的架构师必须有“三条腿”才能立足。

(1) 技能是实践架构的基础。它需要知识以及应用知识的能力。

(2) 影响力用来衡量架构师在项目中应用技能后能给项目或公司带来多大的效益。

(3) 领导力确保了架构实践的状态能稳步向前推进，同时培养更多的架构师。

这个分类也可以很好地应用于其他专业领域，比如医学：医生在学习并获得技能后，开始实践并治疗病患，然后再通过在医学期刊上发布经验成果，把自身所学传授给下一代医生。

技能

技能是应用相关知识的能力，比如关于特定技术（如Docker）或架构（如云架构）的知识。知识通常可以通过上课、读书或者研读在线材料等方式获取。大多数（不是所有）认证重点考核知识，部分原因是知识点很容易以一组多选题的方式呈现在试卷上。知识就像是一组装满了工具的抽屉柜，技能则意味着知道何时打开哪个抽屉以及使用哪个工具。

影响力

影响力是通过架构实践给业务带来的效益来度量的，通常是指增加的利润或者降低的成本。更快地将产品推向市场，或者在产品周期的后期无须做很大改动就可以适配那些无法预见的需求，这些都能够增加收益，因此都可以算作影响力。对于架构师而言，专注于提升影响力是个很好的锻炼，这样可以避免他们陷入只有幻灯片的虚幻世界。当我和同事谈论优秀架构师有什么特点时，我们经常都把理智、自律的决策能力看作从“技能”向“影响力”转化的一个关键因素。但是，这并不意味着优秀的决策者就可以成为优秀的架构师。你依然需要具备扎实的技能基础。

领导力

有领导力要求经验丰富的架构师不能只局限于做本职架构工作。比如，他们应该通过传授知识和经验来指导初级架构师，还应该通过出版著作、公开授课、公开演讲、发布研究成果或者撰写博客等方式，促进所在领域的整体发展。

1.4.2　良性循环
虽然这个模型相当简单，但就像只有两条腿的凳子站不稳一样，平衡技能、影响力、领导力这三方面非常重要。作为学生或学徒的新生代架构师只具备技能却没有影响力，但是，他们迟早会通过实践获得影响力。无法产生影响的架构师在任何盈利性业务中都没有立足之地。

早早就加入项目的方案架构师通常只具备影响力却没有领导力。然而，没有领导力的架构师一定会遇到职业生涯的瓶颈，也不会成为所在领域的思想领袖。很多公司不注意培养或者帮助他们的架构师达到这个层次，因为这些公司害怕项目之外的任何事宜都会增加成本。反过来，这种公司里的架构师也会始终高不成低不就，因而也无法带领公司创新或转型。这些公司最终会错失机会，因小失大。相反，诸如IBM等公司有意以“回馈”的方式培养领导力：他们期望杰出的工程师和研究人员回馈公司内外的社区。

同样，只具备领导力却没有影响力的架构师，很可能缺乏相应的技能基础。这可能是一个警告信号，它表明你已经变成了一个几乎脱离实际的象牙塔架构师。如果架构师的影响力依然停留在多年前甚至数十年前的水平，同样会产生这种结果，因为架构师所宣讲的方法和思想在当前的技术场景下已经不适用了。虽然某些架构思想永不过时，但是其余的都会随着技术的发展被淘汰，比如，为了提高处理速度而把尽可能多的逻辑以存储子程序的方式放入数据库，这种方法已经不再是明智的选择了，因为数据库是大多数现代网络架构中的瓶颈。此外，夜晚自动重复运行批量脚本的方法也落伍了，因为现在的24/7实时处理根本就没有所谓的夜晚。

资深架构师指导初级架构师时，这个良性循环就结束了。因为（软件）架构中的反馈周期很慢，所以这个指导的过程能让新架构师节省很多时间，他们无须自己从实践和错误中学习。10个受过良好指导的初级架构师会比1个资深架构师更有影响力。每个架构师都应该知道，纵向扩展能力（变得更聪明）到一定程度就不起作用了，而且存在单点（就是你）失败的隐患，因此，你需要通过传授知识和经验给多个架构师来横向扩展。我一直在努力招募架构师，并且意识到其他大型企业也有同样的需求，因为增加技能永远都非常重要。

另外，指导的过程不仅仅对被指导者有利，对指导者同样有益。老话说得好：只有在给其他人讲解某个东西时，你才能真正地理解它。这句话同样非常适用于架构。做一场演讲或者撰写一篇文章需要你整理和重新思考，这通常也会催生新的见解。

1.4.3　重复良性循环
经验丰富的架构师能够正确地解释自20世纪80年代以来的各种技术，这意味着架构师在其职业生涯里不只要完成一次良性循环。重复这个良性循环的一个原因是，技术和架构风格的变革永不停歇。虽然一个人很可能已经是关系型数据库领域的思想领袖，但他依然需要学习非关系型数据库相关的技能。在第二次循环中，获取技能的速度通常明显更快，因为第一次循环提供了基础。在经历多次良性循环之后，我们也会慢慢理解架构大师们经常说的话：软件架构领域里真的没有多少新东西，我们以前全都见过了。

重复这个良性循环的另外一个原因是，在第二次循环中，我们可能会理解得更深刻。第一次我们可能只学会了如何完成某件事情，但是第二次才可能明白为什么要这样做。比如，我们撰写《企业集成模式》这本书就是体现思想领导力的一种形式，这样说可能没错。然而，在书中的章节介绍里，我们对模式图标、决策树和决策表等元素的选择都是随意的，而不是经过深思熟虑的。现在回过头来看，我们才理解这些元素实际上就是视觉模式语言或者模式辅助的决策方法的实例。因此，重复这个良性循环总是值得的。

1.4.4　要当一辈子架构师吗
虽然架构工作是现在最令人激动的工作之一，但有些人还是会感到悲伤，因为作为架构师就意味着你职业生涯的大多数时间可能会做这份工作。然而，我并没有这样的担心。首先，作为架构师，你能够和CEO、总裁、医生、律师以及其他高端专业人士相提并论。其次，在注重技术的组织里，软件工程师应该和架构师有同感：职业生涯的下一步应该是成为资深软件工程师或者高级工程师。因此，我们的目标就是将软件工程师或者IT架构师这样的职位头衔同具体的资历水平分离。在很多数字化组织中，软件工程师的职业阶梯可以一直到达高级副总裁级别，享有同等地位和薪酬。有些组织甚至有首席工程师这一职位，如果你思考一下，可能会觉得这个头衔比首席架构师更好。我个人更喜欢把自己喜欢的事情做好，而不是去追求别的东西。因此，生命不息，架构不止！

1.5　决策
三思而后行

做决定

你买了一张彩票，然后中了大奖。这是一次多么英明的决定啊！大半夜，在热闹的街道上，醉醺醺的你闭着眼睛闯红灯横穿马路，最后竟然安全地到达了马路对面。这个决定也很棒吗？并不是。两个决定都有积极的结果，但是这两者的区别在哪里？我们用风险来判断第二个决定，而用结果来判断第一个决定，忽略了票价和中奖概率。但是，你不能只通过结果来判断决定的好坏，因为你在做决定的时候根本就不知道结果是什么。你需要基于当时自身的知识储备做决策。

另外一个实验：你面前的桌子上有一个很大的瓶子，里面装有100万颗药丸，它们看起来一样，都无毒无味，但其中有一颗能让你立即无痛死亡。如果有人让你从这个瓶子中随机拿出一颗药丸服用，给你多少钱你才会同意？大多数人会说100万美元、1000万美元，抑或直接拒绝。然而，这同一群人却非常愿意（睁着眼睛）闯红灯，或者滑一整天雪，而事实上，这两种行为和吞药丸打赌有着同等的风险。但是，人们很难将闯红灯之后幸存的结果和挣好几百万美元等同起来。

人类天生就是很糟糕的决策者，在涉及小概率事件以及死亡和金钱等问题时尤其如此。我们以为自己是很聪明甚至是狡猾的决策者，但这并非事实。丹尼尔·卡尼曼（Daniel Kahneman）在《思考，快与慢》一书中用大量的例子展示了人类的大脑是如何被欺骗的。比如，有一种现象叫作启动效应，它可以让我们在面对巨大不确定性的时候，无意识地选择一个我们最近听到或看到的数字，即使该数字和发生的事情毫无关联。很多人在听到100万颗药丸时会脱口而出“100万美元”，这一效应就发挥了作用。

决策是企业级架构师工作中的关键部分，因此，要想成为优秀的架构师，必须首先努力成为更好的决策者。

1.5.1　我们真的那么容易上当吗
面对简单的决定或编造的例子时，我们似乎很容易分辨出其中怪诞或不合理的行为。但是当面对现实生活或商业环境中的复杂决定时，我们的决策自制力真是出乎意料地糟糕。比如，运营周会竟然经常根据关键基础设施服务中断时间的长短来判定该周的“好坏”。任何学过统计学入门课程的人都知道，真正的判定标准应该是从长远来看降低事故发生的次数，而不是看你在过去的一周是否足够幸运。这就等同于企业IT部门猜测“5次黑色后肯定变红”。另一个能突出这种思维缺陷的例子是让人震惊的俄罗斯轮盘赌，几轮之后就会有人中枪身亡：“扣扳机，我是个天才！——嘣。”

IT产品的采购决策通常更严格一些，因为它会使用详细的需求列表。最终，“赢家”的得分是82.1，而“输家”的得分是79.8，这是我们经常看到的结果，然而，我们很难证明这种得分在统计学上有什么意义。但是，这种在决策过程中引入数值计算的方式已经比流行的交通灯对比图有所进步了，后者只是使用“红”“黄”“绿”三色来进行粗略的等级评估。试想，某款产品因为允许时空旅行而获评为“绿色”，而另一款产品因为需要按照计划停机而被评为“红色”，这种红绿两色的对比，会让人以为这两款产品的特性是截然相反的4。其实不需要这样对比，因为我知道我会选择哪个。在有些案例里，这种对比图的结论甚至是从想要的结果或者从不想改变的现状反推得到的，其中的一些IT需求会被转化为奇怪的需求。比如，新车必须以每小时60英里5的速度摇摇晃晃地前进，而且车门也要嘎吱作响，这样它就可以完美地替代旧车了。

4 作者这里的例子是用来突出对两个风马牛不相及的特性做红绿对比评判的不合理性。——译者注

5 1英里约合1.6093千米。——编者注

1.5.2　小数法则
《思考，快与慢》一书里列举了很多示例，说明人类在决策过程中如何受影响，它会让你觉得自己没有为日常生活做好准备。人类怎么会是如此糟糕的决策者呢？我猜我们已经尝试过很多次了。

让我们来看一个被卡尼曼称为“小数法则”的现象——人们往往会根据不够显著的小样本数据得出结论。比如，大型企业没有理由把连续7天没有中断服务看作值得庆祝的成绩。

当我还在谷歌移动广告团队工作时，我们为改变广告出现次数和设置的A/B测试实验使用了严格的度量标准。仪表盘上包括了如点击率（点击率越高，收费越多）等指标，也包括了用来标识广告是否让用户从搜索结果分心（谷歌是搜索引擎，而不是广告引擎）的指标。另外一个重要的指标是置信区间，它用来表示95%的样本集合将随机落入的范围。对于正态分布，我们使用了样本点数的平方根来缩小置信区间，这就意味着需要4倍的数据点，也就是需要4倍的时间来运行实验，才能达到置信区间减半的效果6。如果实验落入了当前设置的置信区间里，你必须去争抢额外的“实验空间”，该空间定义了可以分配给实验的流量占比。整个流程的设计就是为了克服证实性偏见，即我们倾向于将数据解释为支持自己的观点。

6 置信区间（confidence interval）是指由样本统计量所构造的总体参数的估计区间。——译者注

1.5.3　偏见
《思考，快与慢》一书中列出了人类思维产生偏见的诸多方式。这本书真的值得一读。这里，为了列举出所有方式，我不得不对原书内容做了重新编排。其中一个众人皆知又非常重要的偏见是前景理论：为了换取小但有保障的收获，人们会情愿放弃获得更多金钱（或幸福等）的机会——“一鸟在手好过百鸟在林”。然而，当涉及损失时，人们更可能彻底规避可能发生的损失，而不是抓住有保障的小收入。当我们希望规避某个负面事件时，往往会“感觉很幸运”，这种效应被称为损失厌恶。

研究表明，人们通常会为了赌一个正向结果而索要1.5~2倍的合理回报。如果有人发起一个抛硬币游戏，硬币正面朝上就跟你要100美元，但反面朝上的话会给你120美元，你愿意参加吗？虽然可以预见的结果是获得10美元的收入（0.5×(-100) + 0.5×120 = 10），但是大多数人还是会友好地拒绝，当反面朝上可以得到150~200美元时，他们才会参加这个游戏。

1.5.4　启动效应
当你去买毛衣时，店员几乎肯定会先挑一件超级贵的毛衣给你看，很可能超出了你的预算。一件毛衣就要399美元？这也太贵了。但它用的可是山羊绒哦，手感柔软舒服，很吸引人，就是价格过高。相比之下，199美元一件几乎一样好的毛衣似乎很便宜，你会很乐意买下它。但在隔壁，花59美元就能买件像样的毛衣。你成了启动效应的受害者，因为你设定了足以影响你决定的环境。启动效应不一定都像这个例子一样直接。如果你是老年人的心态，那么即便身边没有老年人，你也会走得更慢。7

7 参见Bargh、Chen和Burrows的文章，Automaticity of Social Behavior: Direct Effects of Trait Construct and Stereotype Activation on Action，刊载于Journal of Personality and Social Psychology，1996年8月，第71卷，第2期，第230~244页。

William Poundstone的《无价：洞悉大众心理玩转价格游戏》一书中提供了另外一个有关启动效应的经典示例。将两种啤酒摆在受试者面前，其中的“优质品”标价2.60美元，而旁边的“便宜货”标价1.80美元，大约2/3的受试者（学生）选择了“优质品”。再增加第三种啤酒“超优品”，标价3.40美元。结果，90%的学生选择了“优质品”，而剩余10%的人则选择了“超优品”。利用启动效应，即使是没人买的商品，也能影响人们的购买行为。如果你想销售一款比较便宜的啤酒，最好能放一瓶更便宜的在旁边做衬托，即便根本没人会买它。

1.5.5　决策分析

如果我们是非常糟糕的决策者，那么该如何改进呢？首先，要意识到我们的确是糟糕的决策者，这是最重要的；然后，要理解为什么我们是糟糕的决策者，这样才能尽量避免这些因素或者至少尝试补救。如果想做得更好（你应该这样做），你应该去看一本很棒的有关使用数学方法辅助决策的书，就是Ron Howard和Ali Abba撰写的《决策分析基础》。Ron的课是我在斯坦福大学上过的最棒的课程之一：有趣、发人深思，又充满挑战。不过，他的书可不便宜，标价将近200美元。你是否应该花200美元买本书来提升自己的决策水平？好好考虑一下……

1.5.6　微亡率
Ron和Ali还帮助我们思考了上面那个装有百万颗药丸的瓶子的故事。他们把百万分之一的死亡率称为1个微亡率（micromort）。从那个装有百万颗药丸的瓶子中拿出1个药丸服用恰好就是1个微亡率。为了避免冒这个险，你愿意付出的代价称为你的微亡率价值。微亡率能帮助我们推断那些可能产生小概率但很严重的后果的决策，比如决定是否做手术，该手术可以消除长期病痛，但有1%的概率失败，进而导致患者当场死亡。

校准微亡率价值有助于我们思考日常生活中的风险。滑雪一整天会有1~9个微亡率，而摩托车事故大概是每天0.5个微亡率。所以一次滑雪之旅可能会让你承担5个左右的微亡率风险8，等同于服用5颗从那个瓶子中取出的药丸。那么一天的滑雪之旅值得吗？这时候，你就需要比较滑雪带给你的娱乐价值和这趟滑雪之旅的花费以及要承担的微亡率风险。

8 一整天的滑雪会有1~9个微亡率，所以微亡率的平均值是5个左右。——译者注

那么，让你服用1颗那个瓶子中的药丸需要给你多少钱？大多数人的微亡率价值在1~20美元，下面的讨论中我们假设每个人都取平均值10美元。进行一次滑雪之旅，你不仅需要支付100美元的燃油费用和缆车费用，还需要承担50美元的死亡风险。现在，你需要决定为了在山上滑雪一天是否值得花费150美元。这也可以说明100万美元的微亡率价值没有多大意义，因为你很难为自己一天的滑雪之旅支付500万美元，除非你富得流油！这个微亡率价值模型也能帮助你决定，花100美元买个头盔，让死亡风险减半是否值得。

微亡率价值会随着收入（更准确地说是消费）增加而增加，也会随着年龄增长而降低。它的期望值9就是你为自己余生定义的货币价值，也会随着收入增加而增加。因此，有钱人应该会很容易决定去买个100美元的头盔，而收入只够维持生计的人则倾向于接受这种风险。随着年龄的增长，你自然死亡的可能性也会不可逆转地增加，到80岁时，你的微亡率达到每年约10万个，即每天近300个。到那个时候，付出很大代价来降低2个微亡率已经没有什么意义了。

9 期望值是概率论和统计学中的一个概念，在经济学中有应用，它是对不确定事件的所有可能结果的加权平均，但要注意，它并不等于实际值，只是用来衡量所有结果的总体趋势。——译者注

1.5.7　模型思维

即使是很简单的模型，也能帮助我们成为更好的决策者。George Box有一句名言，“所有模型都不对，但总有一些是有用的”。所以，不要仅仅因为一个模型做了简化的假设就放弃它。它帮助你做的决定可能比你仅仅根据直觉做的决定要好。

斯坦福大学Scott Page教授的模型思维课是我上过的最好的介绍模型及其应用的课程。决策树是一个能帮助你做出理性决策的简单模型。假设你要买辆车，但是有40%的概率经销商会在下个月做1000美元的返现活动。然而你现在就需要一辆车，因此，如果你推迟购买，就需要在接下来的一个月里花500美元来租辆车。你应该怎么做呢？如果你现在购买，就需要支付现有的标价。为了简单起见，我们把这个标价定为0美元。如果先租车，你就需要先花500美元，然后才有40%的概率获得1000美元的返现，那么期望值就是负的100美元（0.4×1000 - 500 = -100），因此你应该现在就买这辆车。

假设有位内部人士能告诉你下个月是否真的有返现活动，他标价150美元来出售这个确切的消息。你应该购买这个消息吗？有了这个消息，决策树可以让你在没有返现活动时（60%的概率）决定现在就买，有返现时（40%的概率）就一个月后买。这个消息产生的期望值是正的200美元（0.6×0 + 0.4×(1000 - 500) = 200）。而这是你现在最好的选择，因为不购买内部消息而直接购买只会产生0美元的期望值，所以花费150美元去买这个消息是值得的。

1.5.8　避免决策

你已经看了这么多决策背后的科学原理，那什么才是最好的决策呢？对了，就是那个你不需要做的决定。这就是为什么Martin Fowler会说“架构师最重要的任务之一就是从设计中消除那些不可逆的决策”10。这些决策是根本不需要做的，或者可以快速做的，因为后面可以轻易改变。在良好设计的软件系统里，决策并不像从那个瓶子中取出致命药丸那样不可改变。

10 参见Fowler的文章，Who Needs an Architect?。

但是，如果你必须要做一个重大的架构决策，请务必三思而后行。

1.6　刨根问底

问则进，不问则退

爱提问题的架构师

一个很常见的误解是，首席架构师对任何事情都比“普通”架构师精通——不然他们怎么会是“首席架构师”呢？实际上并非如此。因此，在自我介绍时，我经常会说自己只是一个知道问正确问题的人。再次引用电影《黑客帝国》中的场景，拜访首席架构师就有点像拜访先知：你不会直接得到答案，但会听到所需要的东西。

1.6.1　五问法

提问并不是一个新技能，并且已经因为五问法而被广泛应用。五问法是由丰田佐吉（Sakichi Toyoda）提出的，是丰田产品系统的组成部分。这是一种反复追问某些事情为什么会发生以便探究根本原因的方法。如果汽车启动不了，你应该一直追问“为什么”来找出根本原因：启动器无法点火，因为电池没电了；电池没电是因为车灯一直开着；车灯一直开着，是因为警告车灯一直开着的蜂鸣器没有发声；蜂鸣器没有发声，是因为一个电子设备出了问题。所以，你应该做的是修复这个电子设备，而不是去尝试通过跨接引线来启动汽车。在日语里，这个方法读作“naze-naze-bunseki”（なぜなぜ分析），大致上可以翻译为“为什么，为什么分析”。这里，我认为数字“五”只是为了提醒我们不要过早地放弃。如果你只问了四次“为什么”就发现了问题的根本原因，我也不会认为你作弊了。

这种方法非常有用，但是需要自律，因为人们往往会在答案中插入自己认同的方案或假设。我见过有人在分析产品故障的根本原因时，反复使用“因为我们监控得不够”和“因为我们没有足够的预算”来回答第二个和第三个为什么。对应汽车无法启动的例子，这些答案就相当于反复说“因为车旧了”。这不是在做根本原因分析，而是典型的机会主义或借口主义（excuseism）。借口主义这个词在城市词典中有收录，但韦氏词典还没有收录它。

反复提问会让回答者有些恼火，所以你最好先介绍一下丰田产品系统，好让大家明白这是一种被广泛采用且非常有用的方法，而不是你在故意刁难他们。还有，要先提醒你的同行，你不是在质疑他们的工作或者能力，而是你需要详细地了解系统和问题，只有这样，你才能发现潜在的缺失或偏差。

1.6.2　反复追问才可以揭示出决策和假设

在实施架构评审时，“为什么”是一个非常有用的问题，它可以帮你将注意力吸引到已经做出的决策上，以及促成这些决策的假设和原则上。回答的人常常会说，这是“上帝赐予我们的”，实际上就是“从天上掉下来的”，或者从任何你认为主宰一切的神圣造物主（真正的首席架构师！）居住的地方掉下来的。揭示出促成最终决策的假设能够提供更多关于决策的深刻见解，还有助于提升架构评审的价值。架构评审不仅仅要验证结果，也要验证结果背后的思考和决策。为了强调这个事实，评审团队应该要求任何提交架构评审申请的团队先提交一个架构决策记录。

如果做出假设的环境发生改变，这些未明说的假设就会成为很多问题的根源。比如，传统的IT部门经常会编写一些精致的图形用户界面配置工具，但它们可以被几行代码和标准的软件开发工具链替代。他们当时的决策是基于编写代码既慢又容易出错的假设，但这已经不再是必然的了，因为我们可以通过学习克服自己的代码恐惧症。如果要改变组织行为，你往往需要首先识别和解决那些过时的假设。

回到电影《黑客帝国》中，先知给出的解释是“……你不需要来这里做选择，你已经做出了选择。你来这里只是为了弄清楚自己为什么做出这样的选择”。这听起来有些戏剧化，但不失为架构评审的一个非常合适的开场白。

1.6.3　处理所有问题的研讨会

在大型企业里提问的一个显而易见的问题就是，企业人员通常不知道、不会表达或者不愿意回答。对此，他们提出的建议通常是开会，而且很可能是个冗长的、贴着“研讨会”标签、打着要“分享和记录问题答案”旗号的会议。然而，在实际会议中，你会反复发现答案都是“不知道”，最终就是你需要回答自己的问题。团队还可能会从外部获取支持来防止你问出很多他们不想听的问题。

很快，你的日程表会被一大堆研讨会的邀请塞满，然后你会变成所有团队口中的“瓶颈”，因为你无法参加他们的重要会议才导致他们的进度变慢。他们甚至没有说谎！这种组织化的抵触行为就是系统抗拒改变的典型例子。

如果你的目标不只是评审架构提案，还包括改变组织行为，你就必须接受挑战，改变系统。比如，你可以重新定义架构文档的标准，并取得管理层对诸如提高透明度等的支持。如果团队在会议前无法提供合格的文档，会议就必须取消。如果团队不能完成这种文档，你可以为他们提供架构师，以便帮助他们根据实际项目制作文档。当你缓和一下，并列出一系列具体的问题时，实际的研讨会将变得更加高效。把会议的时间减半还可以让评审过程更有针对性。

从好的方面来看，组织架构文档研讨会并且给银行劫匪画像（参见3.5节）可以为你提供一组宝贵的系统文档，以便以后引用参考。我也正在计划系统地进行这种架构评审和记录会议，并创建一份架构手册，收集IT领域所有系统的重要架构决策。但这需要良好的写作技巧和足够的人力资源，而你只有搭乘架构师电梯前往顶层，向管理层清晰阐述系统架构文档的价值，才能获得这些支持。比如，这种文档可以让员工快速了解系统，发现架构的不一致之处，并且可以基于事实做出理性的决策，而这反过来又能促进向和谐的IT环境方向发展。在自顶向下的组织里，有时候你必须努力把这些信息传递给顶层管理者，这样他们才能慢慢地理解并给予你相应的支持。

1.6.4　不存在自由通过

有些时候，参加架构评审会议的团队只是想要得到你对他们完成事项的认可，他们对你问的问题根本不感兴趣。他们通常就是故意等待到最后一刻才申请架构评审，对你的“为什么”总是回答“因为我们没有时间”的那批人。对于这种情况，我有一个原则，那就是“你可以避开我的评审，但你不可能自由通过评审”。如果管理层认为架构并不重要，因此架构评审没有必要，那我宁愿完全不做评审，而不是走个形式。

我认为这与我的职业声誉密切相关：我们很严格，但也很公平，而且能出色地完成工作。我的老板曾用一句赞美的话总结了这一点，她说，她喜欢有架构团队参与进来，因为“我们没有什么可以私下交易的，没有人可以欺骗我们，而且我们能花时间把事情解释得很清楚”。这对于任何架构团队而言都是一个很好的授权声明。

架构师应该知道的37件事相关推荐

顶级架构师应该知道的99件事
经常有人问我,比如"我是 xx 年 xx 行业工作经验,我现在要去创业公司做技术总监还是去大公司做架构师?" 我发现我都无法回答这个问题.因为 XX 年 XX 行业工作经验,并不能 ...
【架构设计】软件架构师应该知道的97件事
摘要:软件架构师是 IT 行业里独一无二的职业,既要精通软件开发技术,又要掌握业务知识,还要周旋于公司不同部门之间,协调各种予盾.做到这些绝非易事, 博文视点即将翻译出版的新软件架构师是IT 行业 ...
[密码学基础][每个信息安全博士生应该知道的52件事][Bristol Cryptography][第37篇]The Number Field Sieve
这是一系列博客文章中最新的一篇,该文章列举了"每个博士生在做密码学时应该知道的52件事":一系列问题的汇编是为了让博士生们在第一年结束时知道些什么. 转载链接:https://ww ...
软件架构师应该知道的 97 件事
软件架构师应该知道的 97 件事 1.客户需求重于个人简历(Nitin Borwankar) 客户需求至上.为了自己的简历更炫而采用新技术是沽名钓誉,往往事与愿违. ...
软件架构师应该知道的97件事
原文出处:http://blog.csdn.net/seanbv/article/details/5451705 软件架构师是个让人羡慕的职业,在市场经济成熟的国家,其薪酬已经达到医生.律师.注册会计 ...
(转)软件架构师应该知道的97件事
软件架构师是IT 行业里独一无二的职业,既要精通软件开发技术,又要掌握业务知识,还要周旋于公司不同部门之间,协调各种予盾.做到这些绝非易事, 博文视点即将翻译出版的新书<软件架构师应该知道的9 ...
读软件架构师应该知道的97件事的自己理解
今天在Fenng的blog上看到了这个介绍,感觉不错,就找了看了.书还没出来,先看看列举的97条,感觉话虽然很简短但是说的还是很有道理的....自己的理解也写出来,虽然负责过几个项目,但是自感离架构师 ...
大规模运行MongoDB应该知道的10件事
MongoDB的首席解决方案架构师Asya Kamsky 最近发表了一篇文章,概括了大规模运行MongoDB需要知道的10件事. MongoDB也需要DevOps.MongoDB是一个数据库.和任何其 ...
Java架构师必须知道的 6 大设计原则
转载自 Java架构师必须知道的 6 大设计原则在软件开发中,前人对软件系统的设计和开发总结了一些原则和模式, 不管用什么语言做开发,都将对我们系统设计和开发提供指导意义.本文主要将总结这些常见 ...
[密码学基础][信息安全][每个信息安全博士生应该知道的52件事][Bristol Cryptography][第一篇]不同类型的处理器
这是每个密码学博士生应该知道的52件事系列的第一篇文章.PhD研究生在第一年结束的时候应该掌握这些问题.并且尽可能早的在他们能放弃的时候放弃(23333)无论怎样,我们会将这些问题在接下来的一年里表达 ...

架构师应该知道的37件事

架构师应该知道的37件事相关推荐

最新文章

热门文章