在这篇文章中，我想根据我的经验，解释一些关于企业和他们的软件的事情，同时也描述一下，要实现变革需要具备哪些条件。你有没有发现自己说过这样的话：
- 为什么企业这么慢？
- 他们是如何决定购买什么的？
- 为什么在企业中交付东西这么难？
我在一家大型 "企业 "组织工作了几年，试图交付基础设施软件变革，发现自己不得不向在那里工作的开发人员、销售人员、外部开源工程师、企业供应商的软件工程师，以及组织内许多其他人员解释这些事情。其中有几个人建议我把这些解释写出来，这样他们就可以把它传递给他们的销售人员/工程师同事等。
背景
在进入企业之前，我在一家创业公司工作，该公司在15年中从一个房间发展到700多人。在拒绝我们的软件时，"企业 "这个词经常被抛向我们，通常是在 "你的软件还不够企业化 "这句话中。我当时不知道那是什么意思，但现在我有了更好的想法。说这句话的人通常对软件工程一窍不通，这也没有什么帮助。像其他许多在不规范的创业环境中工作过的软件开发人员一样，我对企业软件的概念不怎么尊重。
当我终于厌倦了创业公司的生活时，我在一家规模超过200倍的金融服务机构找到了工作。没有什么比这更 "企业 "的了。但即使在这种情况下，我也是在 "基础设施团队 "工作，这部分人因为（据说）交付速度慢而被殴打，然后交付的软件可用性比预期的要差。所以，这就像在企业里一样，是一个平方。
在那里工作的这段时间里，我对导致客户失望的交付限制有了深刻的认识，而且--更糟糕的是--我还负责帮助在其中实现变革。
这是一篇相当长的文章，所以我把它分成了几个部分，以使它更容易消化：
1.思想实验- 如果一个企业像一个初创企业那样行动，会发生什么？
- 企业降低风险的一些方法
- 这些方法的基本原则
- 减少风险文化的后果
- 可以做什么？
1）思想实验
在开始之前，让我们想象一个反事实的情况--想象一个企业像一个初创企业那样行事。说明这种情况是如何不起作用的（以及为什么它通常不会发生）将有助于说明为什么存在一些导致我们在大型组织中看到的减速的限制因素。
首先，让我们看看一个小团队可能做什么来改变一些软件。我们将把它作为一个非常简单的例子，而且是一个你在家里可能经常做的例子--升级一个Linux发行版。在这两种情况下，关系都是：
- IT人员
- 经理
下面是一个真正的小公司的对话情况：
"精益 "操作系统升级--小公司
- 我们要不要升级操作系统？
- 是的，好的。
- 哦，我遇到了一个问题。
- 好的，做一些工作来修复转发器。
- 可能要花几个小时
- ，好的..
- 好的，完成。你能测试一下吗？
- 是的，看起来不错，
- 很好。
"精益 "操作系统升级--企业
- 我们要升级操作系统吗？
- 是的，
- 好的，完成。
- 嗯，你把支付系统弄坏了，
- 哎呀，
- 我会回滚的
-
- ，好
- 完成。
-
- 嗨，监管机构打电话来了。他们在新闻上看到了关于支付系统瘫痪的消息，他们想知道发生了什么。他们想知道发生了什么
- 。
- 他们看了你的文章，要求提供谁在什么时候决定什么的证据。他们想要一个时间表。
- 我会检查电子邮件。
- 顺便说一下，你将在几个月内被审计。在那之前，我们必须取消所有的项目
- 但我们有这么多的技术债务！
- 如果我们不把它弄好，他们会关闭我们，我们会被解雇。
-
- .
-
- 好的，我们有审计的结果。
- 审计发现了59个其他问题，你需要解决。
- 好的...
-
- 我们必须放弃其他项目，也许会失去一些人。
- 嗯，好的...
-
- 哦，我的老板会被拉到监管机构面前，为所发生的事情辩护。
-
- 他就会被解雇，如果他们认为有猫腻，他的老板可能会进监狱。
现在，这是一个糟糕的发布......这是一个最坏的情况，但让我们来分析一下这些被监管的企业是如何减轻上述情况的风险和后果的。具体来说：
- "谁拥有这个？
- ""如何维护？
- ""谁买的？"
- "谁签署了部署？
2）减少风险
"谁拥有这个？/ '一喉之隔'
这是一个大问题。在企业内构建解决方案时，最常被问到的问题之一是："谁对这个组件/服务/系统负责？ 在我们上面的企业 "精益操作系统升级 "方案中，首先会被问到的问题是："谁拥有这个操作系统？这个小组将通过一些跟踪工具和技术所有权的内部系统来识别。那些被确定为负责的人将负责该技术的部分或全部生命周期管理。这可能包括：
- 升级管理
- 支持（直接或通过供应商）
- 安全补丁
- 决定谁能和谁不能使用它
- 关于使用的总体政策（扩大/废除/继续使用）
这种所有权导致审计功能的 "一刀切"。就像警察会去找毒贩子而不是普通用户一样，企业的审计职能部门会去找正式负责的人或团队，而不是使用某项技术的过时版本的（可能是成千上万的）团队。这里有更多的收获。所有权带来了责任。企业中的很多政治工作都是围绕着不拥有技术而进行的。谁愿意为几万名员工的技术职能部门的Java使用负责呢，他们中的任何一个都可能在做疯狂的事情。
企业和供应商
这也解释了企业对供应商软件的喜爱，而不是纯粹的开放源代码。如果你花钱请人维护和支持一个技术栈，那么他们就会对整个技术栈负责。这并不能解决你所有的问题（你仍然需要把他们的软件和你的IT基础设施整合起来，而且你越是仔细看，事情就越模糊），但从治理的角度来看，你已经成功地把责任推给了别人。
| 什么是治理？IT治理是一个术语，它涵盖了所有的流程和结构，以确保IT得到适当的管理，以满足那些管理组织的人。脱离治理"（即不符合标准）被认为是一个危险的地方，因为你可能被迫花钱重新 "进入 "治理。 |
如何维护？"
在企业环境中管理软件的另一个方面是维护。在我们上述理想化的创业公司中，"开发 "和 "运营 "是同一件事（即，一个人）。看吧，你有了DevOps!不幸的是，DevOps的口号 "由你来建，由你来管 "在企业环境中通常是行不通的，原因有几个。部分原因是历史原因，即 "这是几十年来一直在做的事情"，所以有一种强烈的机构倾向于不改变这一点。工作和大量投资的过程取决于它的持久性。但进一步支持这种保守主义的是管理软件的监管框架。
监管
监管是由监管者制定的规则，而监管者又是一群人，其权力最终来自政府或其他控制机构。因此，就你的业务而言，他们实际上具有法律的效力。监管机构并不倾向于接受时髦的新的软件部署方法，他们的范式根植于过去几十年的软件建设经验中。这意味着什么呢？如果你的软件是受监管的，那么你的工程（开发）和运营（OPS）团队很可能是由专门从事这些工作的人组成的独立小组。法规要求分离，以确保变化处于某种控制和监督之下。现在，这里（可以说）有一个漏洞被一些人利用了：法规经常谈到工程和运营之间的 "角色分离"，而没有明确说这些角色需要由不同的人来完成。但如果你是一个真正的大企业，这在技术上可能是正确的，但实际上是不相关的。为什么呢？因为，为了 "简化 "事情，这些大企业往往建立一套规则，涵盖所有可能适用于其业务的所有管辖区的法规。而这些规则通常是你能想象到的最严格的规则。此外，这些规则在组织内形成了自己的生命和文化--独立于监管机构--以至于它们不容易被质疑。
反抗是徒劳的。开发和运营必须分开，因为那是我们多年前写下的。
因此，你可能会陷入这样的境地：你被迫以多年前的内部规定的方式工作，而这些规定又是基于对多年前写下的规定的解释！
如果你想改变这种情况，就必须改变。如果你想改变这一点，这本身就可能需要几年的时间，需要多方的同意，而这些人不可能想冒着失去工作的风险来让你的应用交付得更快。
显然，这种分离会使事情变慢，因为工程部门必须使代码对错误和失败的容忍度更高，这样另一个团队才能把它捡起来并带到生产。或者你只是把它扔到墙上，希望得到最好的结果。无论哪种方式，各方都会变得更加抗拒变化。
变化控制
这并不是企业中降低变化速度的唯一方式。为了确保系统的变化可以归因于负责任的个人，通常有某种系统来跟踪和审计变化。一个人将提出一个 "变更记录"，这通常需要填写一个巨大的表格，然后这个变更必须由一个或多个其他人 "签字"，以确保变更不会在没有适当监督的情况下发生。理论上说，签字的人必须仔细检查变更，以确保它是合理和有效的。
在现实中，大多数时候，变更提出者和变更确认者之间建立了信任关系，这可以加快事情的进展。如果变化是大的和重要的，那么它就更有可能被严格审查。也可能存在 "标准变更 "或 "模板化变更"，它们将更多的常规和低风险的更新编入法典，并得到预先授权。但这些也必须在部署前被签署（通常是在更高的责任级别，使其更难实现）。虽然在理论上，变更可以在几分钟内被签署，但在现实中，变更请求可能需要几个月的时间，因为表格中模糊的字段被填错了（"你在字段44B中填错了代码！重新开始。"），签署的最后期限过了，变更冻结了又过，等等。所有这些都使得修改的努力比其他地方要繁重得多。
安全 "签收
"
如果你正在做一些重要的事情，比如一个新产品，或者一个大型产品的主要版本，那么可能需要得到大多数人非正式地称之为 "安全签收 "的东西。这方面的程序因地而异，但基本上，一个或多个安全专家会在某个时候来到你的项目，对其进行审核。我曾想象这种审查是一个非常科学的过程，但实际上它更像是一个中世纪的神明审判。你被以各种方式刺探，同时提出问题以确定你的故事中的弱点。这可能涉及渗透测试，查看你的代码和文档，或与工程师面谈。
这可能会提到各种 "安全标准"，你可能读过，也可能没读过，而这些标准又是以不同的严重程度来执行的。
这样做的结果通常是某种报告和一组已经确定的风险。这些风险（取决于其严重程度--我从未听说过没有风险的情况）可能需要由某个高层人士 "签字"，以便在出现违规情况时由他们负责。这个过程本身就很艰巨（尤其是当高层不完全了解风险时），而且可以定期重复，直到通过进一步的工程努力或流程控制充分 "缓解"。之后，再重新进行审查。这一切都不是快速的。
总结：企业，而不是个人的责任
如果这些减少风险的因素有一个共同点，那就是把责任和权力从个人转移到企业实体。如果你是一个受监管的、具有系统重要性的企业，那么你或公众最不希望看到的就是一个人掌握过多的权力，无论是通过对系统的了解，还是通过改变系统的能力来满足自己的利益。这方面的推论是，一个人很难自己做出改变。而且，我们都知道，如果一项任务被交给多人共同完成，那么事情就会变得很复杂，变化的速度也会很快，因为每个人都必须让对方知道其他人在做什么。
一旦理解了企业责任的这一原则，那么许多其他过程就开始变得有意义了。其中一个例子是采购（又称采购：购买软件或其他IT服务的过程）。
例子--采购
为这样的企业工作，在我停止回答之前，我经常接到销售人员的电话，他们似乎认为我已经准备好了支票簿，可以为我喜欢的任何技术签字。实际情况与事实相差无几。许多人没有想到的是，为了防止一个人获得过多的权力，技术人员往往对谈判（或 "采购过程"）完全没有直接的控制。通常发生的情况是这样的：
- 你去找高层人士，以获得对X目的预算的批准
- ，他们同意了
- ，你就满足该目的的产品提出至少两个选择
- "采购团队 "拿着这份文件与供应商谈判
- 一些神奇的事情发生了
- ，你被告知哪个供应商 "赢了"
。 你可以看到为什么这个过程有助于减少有人受贿以推动特定供应商解决方案的风险（在接受潜在供应商的咖啡方面也通常有严格规定），这是一件好事。另一方面，这个过程可能需要几个月甚至几年的时间......而且，如果这个过程耗时太长，以至于资金消失或团队解散，可能还需要重复进行。使问题进一步复杂化的是，采购部门可能有自己的 "首选供应商名单"，这些公司在过去曾被审查和审计过。如果你的首选供应商不在该名单上（并且没有与名单上的供应商达成交易），这个过程可能需要更长的时间。
3) 累积的限制
我们到目前为止所了解到的是，企业从根本上被试图减少个人权力和责任以支持企业责任的做法所拖累。这通常会导致：
- 更繁琐的变更控制
- 更高的变更规划门槛
- 更高的购买解决方案
- 门槛 更高的安全要求
- 工程和运营职能的分离
这就像熵。你可以对抗它，但最终物理学会赢。现在，我们要跳出这些单独的限制，看看当你构建一个大规模的企业组织时发生了什么，在这个组织中，它的组成小组都在与这些同样的挑战作斗争。
依赖性限制
当你试图在一个企业中交付时，你会发现你的团队依赖其他团队为你提供IT服务。这方面的典型例子是防火墙的变化。你，作为一个开发者，决定--以典型的敏捷微服务/"所有闪亮 "的方式--创建一个新的服务，在一组主机的特定端口上运行。你通宵达旦地喝着零度可乐，把代码涂抹在一起，得到一个工作原型。为了允许连接，你需要打开防火墙上的一些端口。你提出了一个变更，发现这个过程需要手工更新电子表格，然后提出一个变更请求，这至少需要一周的时间。你一晚上的开发工作在你可以试运行之前要挂上一个星期。而这是假设你正确地填写了一切，没有错过任何东西。如果你做到了，那么你必须再来一次
......在一个不受管制的创业公司工作的一个快乐的事情是，如果你发现你的一个依赖的问题，你可以选择接管它并自己运行它。不喜欢你的云服务提供商？那就换吧。认为你的应用程序在Erlang中运行得更好？重写吧。厌倦了防火墙的过程？
那就写一个脚本，然后转到GitOps。
那么，为什么不在企业中做同样的事情呢？为什么不直接 "找到你的依赖性并消除它们"？有些人确实采取了这种方法，但这让他们付出了沉重的代价。要么他们不得不花大笔的钱来管理他们决定拥有的技术的维护和保持 "治理范围 "所需的流程，要么他们迟早会被审计发现。在这一点上，他们可能会去找基础设施团队，他们对他们的困境的同情与基础设施提供的资金数额成正比，以解决他们的问题
......现实是，正如我上面所说的，承担责任并拥有一项技术或你的堆栈的层，带来真正的成本和风险，你可能无法承担并保持业务。因此，无论你作为一个团队是多么伟大，你的交付周期都会被限制在一个基于你的外部依赖性的局部最大值，而这些依赖性（实际上）是不可谈判的。这是对个人的同样限制的扩大，有利于企业的权力和责任。就像你很难做出那么大的改变一样，由于同样的结构性原因，你的团队也很难做出很大的改变。
文化约束
现在，从静态的、结构性的角度来看，缓慢交付的因素已经存在，让我们来看看当你把这种结构在几十年后 "烘烤 "到组织中，然后试图在其中做出改变时会发生什么。
僵化的范式
由于大规模的协调和沟通的困难，在企业规模上推理技术是很困难的。因此，只有在有共同的范式的情况下，企业内部的变革管理才有可能发挥作用，围绕着这些范式的流程和功能可以推理。这些范式变得根深蒂固，如果你想成功地进行变革，就需要在整个组织内反复地浮现和重塑这些概念框架的努力。我所意识到的两个大的例子是 "机器范式 "和收费模式，但也可以加上 "秘密是人工使用的 "或其他许多可能在我的意识中涌现的例子。
机器范式"
自从冯-诺伊曼勾勒出计算机的架构以来，计算的基本单位是一个单一的离散物理实体的观点一直占据着主导。是的，你可以在一台机器上共享工作负载（例如，主机仍然存在，两个应用程序可能使用相同的物理设备），但对于广大的应用程序来说，需要一个单独的物理机器来运行的想法（出于性能或安全原因）一直支撑着应用程序的设计、构建、测试和部署阶段的假设。
最近（主要是在过去10年），这种范式已经被虚拟机所改变，多个虚拟机位于一个运行管理程序的大型机器上。具有讽刺意味的是，这加强了 "机器范式"，因为为了向后兼容，每个虚拟机都有物理机器的所有特征，如网络接口、Mac地址、CPU数量等等。无论你是填写表格并等待物理机还是虚拟机被配置，都没有什么区别--你仍然在机器范式中。最近，PaaSs、Kubernetes和云计算已经推翻了应用程序需要坐在 "机器 "上的想法，但这种新奇（或重新发现，如果你使用大型机）想法的渗透，就像未来一样，分布不均。
收费模式
另一个很难得到改变的范式是收费模式。资金如何在企业内部流动本身就是一个巨大的课题，并且有各种次要的影响，而这些影响对IT部门来说是不小的兴趣。笼统地说，IT正在从"资本支出 "模式转向 "运营成本 "模式。新的模式是租用软件和服务，这些软件和服务可以根据业务需求很容易地增加和减少。
如果你认为企业的IT部门很保守，那就准备和那些管理和处理资金的人打交道吧！
他们有很好的理由。有很好的理由，他们通常不愿意改变组织内的支付模式，因为任何流程的改变都会导致错误（新旧）的浮现，机构的动荡，以及谁知道还有什么。最终的结果是，向这些新模式的转变可能是痛苦的。试图在任何规模的组织内进行交叉收费，可能会导致关于 "木钱"（即用不存在的钱来代替真实的钱）的超现实对话，或将服务收费给企业的其他部分，但由于可能是或可能不是在你控制范围内的对话而从未支付。
习得性无助
经过几十年的这些思维习惯，你最终会产生几个后果：
- 那些不喜欢这种工作方式的人离开了
- 那些留下来的人则会煅烧成整整几代的员工
- 那些留下来的人倾向于奖励和喜欢那些同意他们观点的人
建议对这些群体进行变革，结果是整整几代人，甚至是抵制变革的员工军队。讽刺的是，他们是完全正确的。大多数改变的努力确实是失败的，因此大多数改变的努力也是浪费的。原因可以说是循环的，也就是说，变革被抵制是因为它不起作用，而它不起作用是因为它被抵制。但这也是相当理性的，因为它行不通的原因是基于上面所讨论的存在的外部约束。但按照这个逻辑，这只是简单的博弈论。这在以前被描述为 "绝望的平方"：
虽然我更愿意称之为 "绝望的多边形"，因为这四个是相当随意的。你可以在这个列表中加上，例如：
- 内部收费模式
- 变革控制
- 机构惯性
- 审计
- 监管
- 过时的范式
所有这些都已经在上面讨论过了。
4）新的希望？
这一切是一个失败的事业吗？真的没有改变的希望吗？它最终是否总是看起来，充其量是大量的妥协，感觉像是失败？
嗯，不是。但它是血腥的困难。以下是我认为会对你有利的事情：
高级领导的支持
我认为这是一个大问题。如果你想违背思维习惯，那么就需要有坚定的决心。如果高级管理层不愿意为变革做出任何牺牲，并且/或者没有团结起来支持变革，那么各种决定都不会被做出。这包括由领导层做出的主要决定，以及由来自管理树的不同分支的下属做出的、目标相冲突的次要决定。几乎没有人喜欢谈论这个问题，但如果人们因为没有建设性地配合变革而被解雇，那就会有帮助。这往往会使人集中注意力。这方面的典型先例是Jeff Bezos的 "API任务 "中的第6点：
减少复杂性
说到痛苦，如果你拼命地减少复杂性，你会对自己有利。这可能涉及到承担一些风险，因为你要指出，整个努力可能会因为妥协而毁于一旦，或造成官僚主义或技术流沙，使你的项目以后陷入困境。说出这些危险可能会让你名誉扫地，甚至丢掉工作。正如《餐桌旁的座位
》（我强烈推荐的一本关于这个主题的书）的标题所暗示的，这非常接近于扑克游戏。
跨职能团队
对于那些在小公司工作的人来说，这可能听起来很明显，但是如果你有一个跨越组织职能的团队一起工作，实现变革就会容易得多。协作不仅可以从早期阶段看到事情需要如何设计以满足要求中受益，而且可以通过更好地了解自己职能部门的需求和项目要求的人找到更有创造性的解决方案。
如果你想走小规模工作
的路线，那么其他职能部门的代表可以告诉你，你的MVP捷径会在以后咬你一口。另一种方法--这几乎总是慢得多--是 "先建立，再检查"。因此，你可能会花几个月的时间来建立你的解决方案，然后才发现它从根本上是有缺陷的，是基于一些不能被质疑的企业规则或原则。
利用你的愤世嫉俗的老手
构成我上面描述的 "机构惯性 "的反面是，这些人中有很多人对组织的情况了如指掌。这些人常常对变革失去信心，并不是因为他们不再关心，而是因为他们相信，在迫不得已的情况下，变革不会得到支持。这些人可以成为你最大的资产。关键是要说服他们这是有可能的，而且你需要他们的帮助。这对双方来说都很难，因为你对变革的热情碰到了他们的砖墙，而他们得来不易（或失去）的经验又使他们的砖墙更加牢固。他们可能会给你一些难以启齿的信息，告诉你这将是多么的困难。但不要低估你得到的忠诚和复原力，如果他们被听到了。