架构师应该知道的37件事

是企业的负担还是救星

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

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

架构师不是什么

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

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

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

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

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

衡量架构师的价值

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

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

• 定义IT战略，比如，定义系统（无论是打算自己构建还是从外部购买）的必要IT特性，或者识别为了支撑业务战略还需要补充到现有IT配置组合中的组件。战略也包括“退休”系统（电影《银翼杀手》中的特色词语）以免你被僵尸系统包围。

• 落实对IT蓝图的管控，以实现协调一致，降低复杂度，以及确保所有系统集成为一个有效整体。架构评审委员会需要自始至终担起管控的责任。

• 脚踏实地地关注项目的实际情况，从实际项目实施中获得有关决策的反馈。否则，控制依然是假象。

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

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

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

架构师名人堂

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

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

1.2.1　黑客帝国——规划大师

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

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

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

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

1.2.2　剪刀手爱德华——园丁

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

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

1.2.3　粉身碎骨——导游

ThoughtWorks的欧洲技术主管Erik Dnenburg给我介绍了另外一个非常恰当的比喻。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　企业架构师与企业里的架构师

象牙塔里的上下层

三脚凳不会摇晃

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　决策
三思而后行

爱提问题的架构师

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

1.6.1　五问法

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

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

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

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

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

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

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

1.6.3　处理所有问题的研讨会

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

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

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

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

1.6.4　不存在自由通过

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

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