前情概要
本文是The Flaw at the Heart of Bimodal IT（双模IT的核心缺陷）的导读和翻译。为了更容易被理解，我更改了文章的标题。
Gartner提出的双模IT技术将研发模式分为了两类，一类是传统的顺序模式，强调安全性和准确性；一类是探索性和非线性的，强调敏捷性和速度。
在这篇文章中作者对这种分类作出了反驳。反驳的论据来自于作者合作出版的书《加速：企业数字化转型的24项核心能力》（英文名是《Accelerate: The Science of Lean Software and DevOps》，书是好书，但是中文名真的是糟糕透顶，请不要因为中文名觉得他是写给软件开发外行的书）。这本书基于数据分析解释了研发效能和商业成功上的联系，
需要解释下面中的一个关键概念：“高绩效组织”，英文原文是high performance organization。作者及其团队通过DevOps的前置时间、部署频率、平均恢复时间、变更失败率这四个关键指标，分类出了高、中、低三类绩效组织，并发现DevOps实施的好坏与企业在盈利能力、市场份额、生产力上的成功有显著关系。因此“高绩效组织”可以简单理解为研发能力强，且商业成功的公司。
Gartner的“双模式”IT模型在企业IT领域引起了轰动。Gartner将双模式IT定义为“管理两种独立、相互连贯的IT交付模式的实践，一种专注于稳定性，另一种专注于敏捷性。模式一是传统的顺序模式，强调安全性和准确性。模式二是探索性和非线性的，强调敏捷性和速度。在本文中，我将描述Gartner模型中的三个缺陷，其中最基本的缺陷是高绩效组织实际上并没有在敏捷性和安全性之间进行权衡。事实上，高绩效组织的特点是在敏捷性和安全性水平上持续改进。尽管双模型IT为初次踏上敏捷之旅的企业提供了有价值的指导，但我认为将其视为独立目标是具有误导性的，甚至是危险的。
Gartner的“双模式”的核心在于：我们可以将企业IT的一个大块划分为两种类型的系统：记录系统——用于管理对我们组织最有价值的敏感数据（比如银行账户信息），以及参与系统——一组公开面向用户的系统，用户通过这些系统访问我们的服务。这些类型的服务具有两组完全不同的风险。Gartner认为，通过瀑布模型可以更好地管理记录系统中的固有风险，而敏捷方法更适合构建和开发参与系统。这是一个简单明了的模型，并且符合我们IT界许多人的经验：对于许多企业核心系统，通常是几十年前的COBOL软件运行在主机上，或者是由供应商构建的封装软件，对其进行更改是痛苦、昂贵和有风险的。
双模式模型存在三个严重问题，这些问题综合起来意味着那些未能超越Gartner观点的领导者将逐渐落后于竞争对手。他们将继续投入越来越多的资金来维护系统，这些系统随着时间的推移会变得越来越复杂和脆弱，同时无法获得采用敏捷方法所期望的投资回报。
第一个问题是该模型过于简化。在Gartner的世界中，我们已经从一个“一刀切”的模型过渡到了“两刀切”的模型。对于那些停留在90年代的组织而言，这是一种非常粗糙的进步，但领先的数字化企业，比如谷歌和亚马逊，正在以更细粒度的风险管理决策来管理其每个产品和服务。并将持续交付作为默认方法。Rob England对双模式模型的这个缺陷进行了很好地讨论。
双模式模型的第二个缺陷是那些快速发展的面向用户的参与系统几乎总是与记录系统耦合在一起。Gartner承认需要在定义的点上同步两种模式之间的内容。然而，现实情况是，除非“敏捷”的参与系统与记录系统的产品负责人在交付生命周期的整个过程中进行合作，否则任何“敏捷”的参与系统的演化速度都将受到与其对接的最慢的记录系统变更速度的限制。实际情况甚至更糟：大多数企业即使针对其敏捷产品和服务，仍然被迫执行不频繁的大规模协调部署，这是由于耦合性的限制。因此，参与系统使用敏捷过程的许多好处都被浪费掉了。
最后，也是最重要的，Gartner的模型建立在一个错误的假设上，这个假设在我们行业仍然普遍存在：我们必须在响应能力和稳定性之间做出权衡。传统观点是，如果我们对产品和服务进行更快、更频繁的更改，就会降低其稳定性，增加成本，并在质量上妥协。
总结一下三个错误的假设：
- 模型太简单
- 慢的记录系统会成为快的参与系统的瓶颈
- 整个观点建立在一个错误的假设上
下面将详细讨论这个假设为什么是错误的
这个假设是错误的。
亚马逊和谷歌等公司之所以能够击败所有竞争对手，不是因为构建了不稳定、不安全的系统。DevOps运动的特殊之处在于它代表了一种游戏规则的改变，一种真正的范式转变。构建DevOps运动的人们不得不解决一个棘手的问题：如何在前所未有的规模上构建可靠、安全的分布式系统，同时实现比行业先前实现的变更速度快上数个数量级。他们的方法的成果可以在2009年John Allspaw和Paul Hammond的演讲中看到，这个演讲开启了DevOps运动：“Dev and Ops Co-operation: 10 deploys a day”。现在，亚马逊的变更速度比这个演讲中提到的要高三个数量级。2015年《Devops报告》的关键结果之一是，随着规模扩大，高绩效团队能够增加每个开发人员每天的部署次数。
这种范式转变并非没有先例。它强烈呼应了丰田在制造业中改变游戏规则的方式。丰田之所以胜出不仅仅是因为比竞争对手更快地将车辆推向市场。它通过更快、更便宜、更高质量地制造汽车，并通过持续改进在所有这些方面提升能力，然后加速超越其他公司。
在过去三年中，我参与了一个研究项目，研究了各种规模和领域（包括金融服务等高度监管行业）的公司的IT绩效。我们发表的同行评审研究结果明确：高绩效团队实现了比低绩效团队更高水平的产能和稳定性。他们通过在其所有产品和服务中实施高绩效、精益文化和采用持续交付实践来实现这一点。
尽管Gartner正确地指出，模式一方法无法用于构建现代、响应式、以用户为中心的服务，但反过来并不成立。敏捷方法和持续交付已经成功应用于各种领域，从大型金融服务公司的大型机系统到消费电子产品的嵌入式系统，敏捷方法和持续交付已被成功应用于各种领域，并在产品生命周期内持续提供更高的质量、更快的交付速度、更强的业务响应能力和更低的成本。
任何希望在数字时代生存的公司都必须超越零和思维。这个秘诀很容易理解，但很难实施：领导者必须设定并明确传达关于上市时间、质量和成本的明确业务目标。然后，他们必须投入必要的资源，让组织中的每个人都能通力合作，从而解决阻碍他们实现这些目标的问题。企业架构、流程、预算、治理、风险和合规性等等都在待解决的问题的范围之内。最重要的是，持久的变革必须来自公司内部。变革不能靠雇佣、购买或咨询。
Gartner 的双模工作为如何启动企业数字化转型提供了宝贵的建议。但是，希望对 IT 绩效产生重大、持久影响的领导者应着眼于在数月而非数年内超越双模模式。正如约翰-科特（John Kotter）在《领导变革》（Leading Change）一书中所写的，全公司各个层级都必须产生一种迫切感，即重大变革是绝对必要的。在这种迫切感、明确的目标以及整个组织中的合作和问题解决文化的支持下，一切皆有可能。
总结一下，双模式只能是一个过度状态，而不是一个终态。他仅仅适合于刚刚开始devops的公司。 最后总结一下，作者通过数据统计的方式来证明了发布快和发布稳是可以兼得的，并给出了一些原因（比如越是害怕的事情就越是要去多做），也给出了一些关键能力（如书的题目，24项关键能力）但是并没有详细阐述我们怎么达成这个最终态。24项关键能力如下，供大家自查和参考。
