在顶层套间和发动机房之间往返
高楼需要乘坐电梯上下
1.1.1 缺失的一环
架构师所扮演的承上启下的角色非常关键，尤其是在大型组织里，部门之间业务语言不同、观点不同、目标不同甚至冲突。而很多管理层在企业内部的沟通中还大玩“电话游戏”①，让沟通问题变得更加严重。最糟糕的情况是，掌握相关信息或专业技能的人没有权力做出决策，而决策者却缺乏相关信息。这对于企业IT 部门来说不是个好兆头，特别是在当前这个技术已经成为大多数业务驱动力的时代。
1.1.2 架构师电梯
在大型企业里，架构师能填补一项重要的空白：他们既能在项目上和技术人员密切地工作和沟通，也能在不丢失信息本意的前提下，向上层管理者传达和解释技术主题。换句话说，架构师能理解公司的经营战略，并且能将其转化为技术决策。
如果把组织内的不同层级看作大楼的不同楼层，架构师就能乘坐我所说的架构师电梯：在大型企业里，他们搭乘这种电梯，在董事会会议室和负责构建软件的发动机房（工程师团队）之间往返。在IT 快速变革和数字化颠覆的时代，这种不同层级之间的直接联系已经变得前所未有地重要了。
我们再用大型船舶的场景做个比喻。大家都知道，如果油轮上的舰桥发现了障碍物，为了调转船头，游轮需要反转发动机并且尽力向右转舵。但是，如果所有发动机实际上都在全速向前运转，灾难迟早会发生。这就是为什么老旧的蒸汽船也会有一个直接连接船长室和锅炉房的管道，这样船长就能直接发号施令并得到及时反馈。在大型企业里，架构师就必须扮演这个管道的角色。
1.1.3 有些组织的层级比其他组织要多
回到楼层的比喻上，架构师搭乘电梯上下几层楼取决于组织的类型。扁平的组织结构可能根本不需要电梯，只需几阶楼梯即可。这也意味着架构师这个上下沟通的角色不是很重要了：如果管理层能敏锐地了解必要的技术实现细节，并且技术人员能与高层管理者直接沟通，就不需要那么多的“企业”架构师了。可以说，数字化公司就像是一座单层平房，压根就不需要电梯。
然而，大型组织里，典型的IT 部门之上往往有很多楼层。他们位于高耸的摩天大楼里，因此，单部架构师电梯可能无法直达所有楼层。这种情况下，技术架构师和企业架构师可以在中间的楼层会面，各自覆盖“一半”楼层。这种场景里，架构师的价值不应该按照他访问的楼层高度来衡量，而应该根据他们覆盖的楼层数目衡量。大型组织中，一个常见的错误是，住在顶层豪华套间里的管理者只看见并重视位于楼层上半部分的架构师。相反，很多开发人员或者技术架构师都认为所谓的“企业”架构师没多大作用，因为他们压根就不写代码。在某些情况下，这可能是真的，这样的架构师往往很享受在上半部分楼层的惬意生活，因此没有意愿再搭乘电梯前往下半部分楼层。但是，经常前往下半部分楼层和技术架构师分享战略愿景的“企业”架构师还是有重要价值的。
1.1.4 不是单行道
你肯定会遇到搭乘电梯到顶层后就再没下来的家伙。他们非常享受从顶层豪华套间往下看的美景，而且觉得自己辛苦工作不是为了继续去脏兮兮的发动机房。你经常会听到这些家伙说：“我过去可是搞技术的。”听到他们这样说，我会情不自禁地反驳：“我曾经还是经理呢！”（这是事实）或者“你们为什么不接着做了呢？是不是做得不好？”如果你想反驳得更委婉一些（并且更富有深度），可以参考Fritz Lang 的电影《大都会》。在这部电影里，顶层豪华套间和发动机房之间的隔阂几乎彻底地毁灭了整个城市，后来人们才认识到“头和手之间需要一个调停者”。任何情况下，电梯都是用来在楼层间上下往返的。顶层人士享受着山珍海味，而底层劳动者却奄奄一息，这显然不是企业IT 转型的正确方式。
乘坐电梯上下对架构师而言也是一个很重要的机制，他们可以获取别人对决策的反馈，并理解这些决策的实现结果。过长的项目实现周期无法提供好的学习循环，会导致出现架构师的夙愿，开发者的梦魇这样的场景。允许架构师只在高层享受美好风光，一定会导致有权无责，这是一种遭人唾弃的反模式。只有架构师必须承受或至少观察他们决策的后果，才能打破这种模式。为此，他们必须不断地搭乘电梯上下奔波。
1.1.5 高速电梯
过去，IT 决策和经营战略几乎没有关系：IT 只被看作附加品，它的主要参数（或KPI）是成本。因此，由于新信息稀少，搭乘电梯上下并不是很关键。但是，如今的业务目标和技术选择之间的联系已经变得越来越直接了，即使对“传统”的业务也一样。比如，想要通过更快地将产品投放市场来应对竞争压力，就需要灵活的云计算方式，而这又需要支持横向扩展的无状态应用程序。要获得客户渠道相关的内容，就需要分析模型，而优化模型则需要通过Hadoop 集群收集大量的数据，但是Hadoop 适合使用本地磁盘存储而不是共享的网络存储。用一两句话，就将业务需求转换成了应用程序和基础设施设计，这一事实凸显了架构师搭乘电梯上下沟通的必要性。而且，他们必须搭乘更快的电梯，这样才可以跟上业务和IT 交织发展的节奏。
在传统的IT 部门，较低的楼层可以仅供外部顾问使用，这样企业架构师就不必处理方案具体落地的事宜。然而，这样只聚焦在效率上，而忽略了速度经济②，在技术快速变革的时代，这是一种糟糕的选择。长期处于这种环境中的架构师必须扩展其角色职责，不能只是全盘接收供应商的技术路线图，而是要主动地定义它。为此，他们必须要形成自己的IT 世界观。
1.1.6 其他乘客
作为成功的架构师，当你搭乘电梯上下往返时，可以能会遇到其他一些乘客与你同行。比如，你可会能遇到一些业务人员或非技术人员，他们明白深入地理解IT 对业务发展至关重要。对这些人友善些，带他们到处看看。让他们参与到对话中，可以让你更好地理解业务需求和目标。此外，他们还可能会带你前往你从未去过的更高的楼层。
你还可能遇到另外一些人，他们乘坐电梯下楼只是为了“索要”时髦用语，以便到顶层豪华套间卖弄自己的想法。我们不把这些人称作架构师。搭乘电梯却很少出来的人通常会被称为电梯服务生。受益于顶层人士的无知，这些人可以追求到一种从不真正接触实际技术的所谓的“技术”职业生涯。你也可以尝试去改变一些人，让他们真的对发动机房的真实运作细节感兴趣。但是，如果尝试不成功，你最好保持沉默，比如，一直看着电梯天花板以避免和这些人发生眼神接触。等到和高管同乘一梯时再进行“电梯游说”，而不要和普通传话人浪费唇舌。
1.1.7 搭乘电梯的危险
你可能以为雇主肯定非常欣赏搭乘电梯上下忙忙碌碌的架构师。毕竟，架构师能给那些希望通过IT 转型在数字时代获得更强竞争力的企业带来很大的价值。令人惊讶的是，这些架构师可能会遇到意想不到的阻力。顶层豪华套间里的决策层和底层发动机房里的实施团队可能都会对彼此“失联”的现状很满意：公司领导层看到的是数字化转型进展顺利的假象，而发动机房里的员工则可以不管业务需求，随心所欲地“摆弄”新技术。这样的情景就像是一艘巨轮全速撞向前面的冰山。当领导层意识到现状时，很可能为时已晚。有时候，我会把这样的组织结构比喻为顶层和底部并非垂直对齐的比萨斜塔，在这种倾斜的建筑里搭乘电梯上下肯定更有挑战性。
当架构师步入这样的环境时，必须在搭乘电梯时准备好面对来自高层和底层的双向阻力。我就曾经被“发动机房”的员工们批评过，他们嫌我违背开发人员的意愿单方面推行公司计划，同时，企业的领导层又批评我单纯为了乐趣而尝试新的技术方案。做一名改革者很难，特别是当系统抗拒改变的时候。一种非常好的策略是，从一开始就小心翼翼地把各个层级连接起来，然后等待合适的时机向大家分享信息。比如，你可以向管理层解释发动机房里的员工们的工作有多棒，这可以让管理层进一步了解和认可他们，同时你也有机会获取更详细的技术信息。
其他对你搭乘电梯上下忙碌不满的企业人员是中间楼层的占有者：他们看见你总是在决策层和发动机房之间往返，感觉自己被无视了。我把这称为欣赏的“沙漏”曲线：高层管理者把你看作转型的关键推动者，而发动机房的员工也很开心有人真的理解和欣赏他们的工作，但中间层的员工则把你视为威胁，你害他们无法负担子女的教育支出，无法购买山景房。这是一件很微妙的事情。有些人主动在半路上拦你：他们会在每一层拦停电梯并要求你给个解释，如此这般，搭乘电梯还不如爬楼梯快。
1.1.8 将大楼扁平化
与其无休止地搭乘电梯上下，何不直接消除那些不必要的楼层呢？毕竟，你试图与之竞争的数字化公司并没有这么多楼层。不幸的是，除非将整栋楼炸成一堆瓦砾，否则你根本无法让这些楼层消失。无论如何，消除中间楼层的那些人也不现实，因为他们往往是组织和IT 蓝图信息的主要持有者，特别是在幕后还有一个大黑市的时候。
将大楼逐步扁平化也许是个合理的长远战略，但这需要改动企业文化的根基，因而会耗费太长的时间。除此之外，还需要改变或消除中间楼层员工的角色，而这势必会遭到强烈的抵抗。所以，这不是一场架构师能打赢的仗。不过，架构师可以逐步瓦解阻力，比如，让顶层管理者对来自发动机房的信息感兴趣，提供更快的反馈回路，以及减少中层管理者做状态更新汇报的次数。
——————————
① 电话游戏里，小孩们围成一圈，逐个向下传递从上个小朋友听到的消息。当消息返回第一个说出消息的小孩时，他们会发现消息在传递一圈后完全改变了。
②速度经济是指企业因为快速满足顾客的各种需求而带来超额利润的经济。——译者注
