架构师电梯 - 访问高层

架构师电梯

为了说明架构师除了指导软件开发人员之外还有更多工作要做，我使用了“架构师电梯”的隐喻。这台电梯从公司的发动机室一直延伸到顶层，在那里高层管理人员制定战略。虽然数字公司利用技术来开拓新的商业机会，但传统组织往往仍然将他们的 IT 视为一种纯粹的成本因素，与业务战略相去甚远：无数层管理层将高层与低层隔开。信息通过从一层到一层地走楼梯来传递，从而导致众所周知的“传话游戏”效应：当一条消息经过许多站时，它不仅需要时间，而且它的含义也可能完全改变。

对于架构师和开发人员来说，这意味着两个主要问题：首先，由于高层人士没有看到投资的必要性，因此可能难以获得创新项目的支持或资金。但即使新技术已经推出，现有的流程和政治也可能阻止它们实现预期的效益。在这两种情况下，架构师都必须访问高层以解除障碍或触发组织变革。

由于组织不太可能很快就会崩溃他们的管理层 - 太多的周末住宅和孩子的教育岌岌可危 - 架构师需要在楼层之间快速移动，以将业务战略与 IT 架构和技术实施相一致。从发动机室到顶层的电梯之旅突出了现代架构师在每一层等待着什么！

云就绪应用程序需要运行时架构

鉴于现代应用程序的架构需求，架构师仍然需要在发动机室中，我们过去认为分布式系统是不同寻常且相当复杂的，最好避免。如今，构建非分布式应用程序的情况很少见：几乎所有有意义的应用程序都公开服务 API、调用其他服务并在云中进行全球分布式运行。最重要的是，它们有望在零停机时间的情况下更新、水平扩展，并能抵御硬件和软件故障以及 混沌猴子 为了好玩而杀死其进程。实现这一切需要相当多的架构！

几年前，似乎大多数主要的架构决策已经在 Java EE 或 Spring 等应用程序框架内部做出，让开发人员专注于编写功能和用户界面。虽然这种承诺在设计时决策方面部分实现了，例如是否使用 MVC，但现代应用程序通常会带来与其运行时相关的重大架构需求。这种趋势也反映在开源社区中：无论是 Docker、Kubernetes、Mesos、CloudFoundry、Prometheus、Hystrix、Vizceral 还是 Kibana，项目名称不仅越来越难拼写，而且越来越专注于应用程序运行时管理和监控。

因此，现代架构师必须精通运行时架构方面的考虑，包括部署和配置自动化、可扩展性、监控等。他们可能会用部署图来代替类图！

自动化软件制造以缩短价值实现时间

人们一直认为，将软件开发工业化将降低项目成本和风险。这项工作最初主要集中在软件的设计方面 - 如何编写坚如磐石的需求并像流水线一样管理项目团队。其中大部分最多只能取得适度的成功。Jack Reeves 早在 25 年前就得出结论，编码实际上是设计工作，而不是生产工作。因此，试图将设计工业化，这本质上是一项创造性的工作，是一项值得怀疑的努力。相反，应该工业化的是软件的生产：组装和分发软件工件以形成一个运行的系统。

制造业在半个多世纪前就开始大幅度地自动化生产，使大多数工厂几乎没有人类参与。具有讽刺意味的是，许多软件项目，其最终目的可能是自动化繁琐的手动任务，仍然以“手工匠”的方式交付软件：手动复制文件，这里一个小补丁，那里另一个配置更改，以及一些更新的权限，仅为了良好的品味。哦，还有一个被遗忘的文件副本。就像鞋匠的孩子光着脚一样，软件交付过程讽刺地缺乏软件为业务带来的那种自动化。

幸运的是，持续集成 (CI) 和持续交付 (CD) 通过云计算和软件定义的基础设施支持的无情自动化，对软件交付进行了工业化，从而提供了重大改进。它们使将服务器视为一次性物品成为可能：如果服务器出现任何问题，您不会修复它，而是实例化一个新的服务器（参见 牛群与宠物类比）。自动化软件交付的主要驱动力不是经济效益，即节省执行部署任务的人员。相反，它是对速度和可重复性的需求 - 人类不够快，也不够可靠。

因此，现代架构师不仅应该关注设计，还应该关注软件的“制造”。改进发动机室的这一方面对顶层有重大影响：快速且可重复的交付缩短了软件交付业务价值所需的时间。这是一个访问高层的绝佳理由。

最大程度减少前期决策

许多架构师认为自己应该做出“难以逆转”的决策，而且他们也应该做出这些决策。这种架构师的原型可能让人想起电影“黑客帝国”中那位白发苍苍的绅士：一位经验丰富、无所不知的人，他做出所有决定。这种愿望有一个主要的陷阱：黑客帝国中的架构师是一个计算机程序，而不是一个人。

在项目开始时做出关键决策实际上是最糟糕的时机，因为这是最不了解的时候。随着项目的进展，更多信息变得可用，从而可以做出更明智、更有效的决策。因此，与其将所有关键决策委托给一个人，不如通过 最大程度地减少不可逆转的决策数量 来降低项目风险。例如，可以通过选择灵活的设计或使用模块化来实现这一点，模块化可以将后期更改的范围局部化。

通常，希望提前做出决策是由现有的结构和流程驱动的，而不是技术需求。例如，团队被迫在开发甚至开始之前做出产品决策，以满足耗时的预算审批流程。因此，可以通过抵御那些通常出于好意要求提前做出决策的官僚主义者来避免或减少不可逆转的决策。

供应商也倾向于推动早期的工具决策，承诺管理层取得惊人的成果，包括减少或消除对昂贵程序员的需求，只要选择他们的工具。你不能责怪他们这样做 - 这是他们的工作。但你需要反制 - 一辆更快的汽车并不能造就更好的司机。更糟糕的是，在某些情况下，汽车甚至可能并不更快，只是更贵，或者它可能最终陷入沟渠，因为它太难操控。

这些例子表明，为了提高 IT 发动机室的效率，你可能必须改变组织的运作方式。这就是为什么架构师必须乘坐电梯到高层。

销售架构选项

向高管解释什么是架构可能是一个挑战。在最近的一次高级管理会议上，一位架构师在这个话题上支支吾吾了几分钟，导致人们眼睛发直，挠头。我决定插话：“架构就是销售选项。”这句话立即引起了高管们的注意：金融期权赋予期权持有者在未来以已知条件购买或出售金融工具的权利：期权赋予购买权，但没有义务，在某个未来的日期以设定的价格（例如 100 美元）购买股票。当那一天到来时，很容易决定是否行使期权：如果股票价格高于 100 美元，我将使用我的期权以 100 美元的价格购买并赚钱。如果不是，我将放弃期权。

期权是一种将决策推迟到未来某个时间点，同时锁定关键参数（如价格）的方法。金融行业非常清楚这种期权具有价值，因此也具有价格。将架构呈现为出售期权，立即就能让精通金融术语的高管们理解：你投资于架构，以便以后能够以已知成本改变主意。例如，如果你的应用程序可扩展且可自动部署，你就不需要预先承诺硬件购买，而可以在未来需要时添加硬件。能够做到这一点会产生具体的节省，并证明对架构的投资是合理的。

就像金融期权一样，架构期权也允许我们对冲风险：我们期望某种结果，但希望在结果没有实现时限制损失，从而降低风险情景的影响。

使架构适合目的

通常，我们希望架构师为我们提供“好的”架构。问题在于，架构很少是好或坏的——它要么适合目的，要么不适合目的。目的通常取决于系统将要运行的上下文，而不是特定的用户需求。因此，架构师的工作是在更广泛的上下文中考虑架构选项，这可能涉及各种因素，例如商业和法律协议、技能可用性或已安装的基数。

找到合适的上下文需要架构师访问组织的各个层级。特别是需要广泛协调的决策，通常由管理团队做出，他们远离软件交付团队，基于财务、流程合规性或 PowerPoint 幻灯片。架构师的工作包括创建透明度，说明后果，并让所有层级参与架构权衡。卢克·霍曼的**《超越软件架构》**很好地说明了架构考虑的广度。

即使经过所有考虑，做出架构决策仍然很困难，并且存在出错的风险。因此，最好由那些必须承担后果的人做出决策。这个想法将我们带到了下一层……

通过反馈循环验证决策

一个众所周知的架构部门反模式是“象牙塔”：架构师坐在顶层，定义开发人员如何设计和构建软件，而他们自己不开发任何软件。这种设置有一个致命缺陷：它不会向架构师提供有关其决策的有效性或成本的反馈。更糟糕的是：有些架构师很享受不必承担这些后果。

大多数复杂系统只能通过反馈回路来运作：无论是你的手臂伸出去直到你的手指感觉到键盘，你的加热器恒温器在房间温度达到后关闭炉子，还是司机不断调整方向盘以保持汽车在车道内。在 IT 中，反馈回路适用于项目管理和架构：一旦知道团队速度，预测项目成本和时间表就会变得容易得多，并允许在整个过程中进行必要的调整。架构师应该弄清楚“可重用”的 API 是否真的促进了重用，通用框架是否加速了开发，或者监控框架是否减少了计划外停机时间。了解反馈需要识别明确的指标和目标，这本身就是一个有用的练习。

架构师获得反馈的一个好方法是直接参与项目交付并对其负责。反馈周期越短越及时，效果就越好，这使得授权开发团队在一般原则或已发布的 IT 策略的范围内做出架构决策变得更具吸引力。

与技术发展一起构建组织架构

最近的许多软件创新，例如 DevOps、云或大数据，只有在组织结构随着技术发展而演变时才能发挥其全部价值。如果你的全自动化工具链可以在几秒钟内部署软件，但你必须经过为期 3 个月的纸质审批流程才能获得授权，那么这对你没有帮助。因此，在加快软件交付速度时，不仅要关注技术方面。现代架构师还必须考虑组织的设置——这是在高层需要做的事情。

例如，许多 IT 组织将“变更”（开发软件）与“运行”（操作软件）分开。在数字世界中，这已经没有多大意义，因为运行软件的反馈是公司通过所谓的**构建-衡量-学习循环**改进其产品的关键机制。

有趣的是，组织系统的行为通常受制于与影响技术系统相同的力。例如，分布式系统中最大的吞吐量杀手之一是同步点——这也是我们偏爱**异步消息传递**的原因之一。组织中同步点的等效物是会议——众所周知，它也会降低吞吐量！

分层是另一个众所周知的概念，它可以帮助管理复杂性并获得灵活性，但由于层之间存在许多转换，也会增加延迟。这种逻辑适用于技术系统和组织系统结构：分层组织使层外包成为可能，因为依赖关系是明确定义的。但是，每层都会在“设计时”带来转换工作——必须协商合同和服务级别协议——以及在“运行时”带来转换工作——编写冗长的需求文档并进行许多“协调会议”。

许多架构师害怕触及组织方面，因为它们充满了“人际关系”和政治。但是，复杂系统行为的相似性使架构师能够很好地参与高层并消除组织系统中的瓶颈。

在正确的“楼层”上消除障碍

许多开发人员、架构师和项目经理可能会感到沮丧，因为他们没有得到组织的足够支持：很难获得创新、重要项目或关键任务（如重构）的员工或资金。通常，这种阻力是由于组织与开发团队共享不同的信念体系。例如，许多传统公司重视可预测性胜过速度。因此，他们实施了一系列“检查点”和“质量关口”，导致了繁琐且耗时的流程。在这样的组织中，很难实施敏捷或 DevOps 工作方式。

改变这种组织的行为需要改变其信念。否则，你将不断地撞墙。例如，迷恋可预测性的组织通常专注于通过规模经济和一致性来优化现有流程。为了在数字世界中竞争，他们需要了解**速度经济学**，即通过利用新的市场机会来创造价值。这种态度的改变必须发生在顶层附近——你需要乘坐电梯到达合适的楼层才能取得进展。

汇报线可以作为 IT 组织信念体系的有用指标。例如，如果 CIO 向 CFO（首席财务官）汇报，那么 IT 很可能被视为一个纯粹的成本因素，而不是市场机会的创新者和推动者。在这样的组织中，任何试图推销技术创新的尝试，都会很快在管理层脑海中转化为“我之前也听过关于客户机-服务器、Web 等等的类似说法。它们只是让我损失了钱。”改变顶层对这些事物的看法是启动成功的 IT 创新的必要先决条件。

ArchOps：构建垂直架构团队

刚刚从引擎室快速乘坐电梯到达顶层，突出了架构师需要在楼层之间移动的必要性。这种洞察也应该反映在架构团队的设置中。通常，一个中央架构团队由位于顶层附近但与技术创新和项目交付脱节的“高级”架构师组成。

由于单个架构师不太可能覆盖所有楼层，因此构建一个“垂直”架构团队是有意义的，该团队由来自不同层级的架构师组成：企业架构师、战略架构师、解决方案架构师和技术专家。这就像在只有一层楼梯的摩天大楼上安装电梯：突然之间，事情开始变得更快了。

管理这样一个团队并不容易，但它确保单个团队可以覆盖组织的所有层级，并且架构师拥有必要的反馈回路。它还为架构团队提供了执行能力，如果组织缺乏执行所需的技能或设置，则可以执行。

继续乘坐电梯

我将自己将大型 IT 组织转型方面的经验汇编成了一本书，书名很俏皮，叫做**《一位架构师知道的关于 IT 转型的 37 件事》**。这本书通过 37 个引人入胜但发人深省的轶事，讨论了在高层进行沟通所需的技能。这本书可以在**Leanpub 上以无 DRM 的电子书形式**或从**亚马逊购买纸质版**。

在高层发生这么多事情的情况下，一些架构师可能会想知道他们是否应该成为组织设计师而不是技术架构师。但这将是舍本逐末。设计和影响组织取决于对软件交付和技术创新的透彻理解。正是技术能力和组织能力的结合，使现代架构师变得有价值，并使 IT 转型取得成功。

你可能见过架构师乘坐电梯到顶层，只是为了享受顶层的美丽景色，而再也没有下来。在一个技术快速发展的时代，这种态度注定会很快使一个人的技术技能变得无关紧要。因此，关键是要不断地乘坐电梯上下——这是保持顶层和引擎室连接的唯一途径。

反之，许多架构师认为高层是他们无法触及的。首席执行官或副总裁真的会想和他们谈话吗？令人惊讶的是，大多数情况下，他们确实会。许多顶层人士感到与组织的现实脱节，并对快速的技术进步感到困惑。因此，如果有人主动联系他们，用他们的语言与他们交谈，但同时又脚踏实地地站在引擎室，他们会很感激。

所以，继续乘坐架构师电梯，更频繁地访问高层，别忘了回来！