大多数IT复杂性并非源于糟糕的规划，而是多年来明智决策不断翻倍累积的结果，关键在于明确哪些该保留，哪些该剪裁。
我曾接触过最复杂的IT环境，它们并非被有意设计成那样，而是由一群理智的人在切实压力下做出一连串合理决策后的产物，比如：因为现有供应商无法满足延迟要求而引入新的云服务提供商，因为业务部门急需某项功能而采购了单点解决方案，因为人员编制冻结而叠加了托管服务。在当时，每一项决策都顺理成章。问题出在多年之后，当长达二十年的合理决策交织在一起，演变成一个没人能全面审视和理解的环境。
承载最高复杂性的往往不是那些做出最差决策的企业，而是增长最快、对IT团队需求最高，或是采购权分散在各个业务部门的企业。某种程度上，这种复杂性正是成功的副产品，但这并不意味着维持它的成本会有所降低。
复杂性如何构建
当我在领导全国最大的云与托管服务业务之一时，我开始非正式地记录企业客户在最初几次会议中如何描述他们自己的环境。大多数时候，几乎所有对话中都会出现相同的词汇：传统遗留、历史沿袭、技术债务，以及几乎必不可少的“我们需要它来满足合规”或“那个团队不肯放手”，这种复杂性早已超越技术本身，它与人、流程、合规要求以及企业的实际运转机制紧密交织在一起。
随着时间推移，我观察到一种大致分为三个阶段的发展模式，尽管置身其中的人在经历时并不会察觉到明显的阶段划分。
第一阶段是累积阶段，这是IT运维的常态：随着业务需求增长而扩展能力。业务部门急需，就上线一个SaaS应用，监管要求数据主权，就部署一个新的云区域，平台三年没更新，就用单点解决方案填补空白，企业通过并购不断扩张，在这个过程中继承了大量新合同和供应商，这些都不是错误的决策，但每一个决策都会增加一个集成界面、一份合同、一层支持关系以及预算中的一笔开支。
第二阶段是偏离阶段，在这个阶段，团队成员开始绕过官方渠道(IT、财务、法务或采购)，因为官方流程太慢或太繁琐，无法满足他们实际或预期的需求。影子IT虽然名声不佳，但在我合作的大多数企业中，这更多是理性人在用手头现有的工具解决实际问题，而非叛逆行为，只是官方提供的工具往往并不称手。
第三阶段是我所认为的锁定阶段，此时，环境中的相互依赖关系如此之多(有些有文档记录，许多则没有)，以至于做出任何重大变更都让人感觉风险极大。技术债务高企，令人感知到的现代化改造成本十分昂贵。要推动变革，需要比单纯对比现有方案与现代化方案进行更多的干涉利益相关者沟通和分析。每一次潜在的简化尝试都伴随着一连串没人敢打包票的下游影响，因此环境继续保持复杂，运维负担也不断加重。
Flexera 2024 State of the Cloud Report指出，企业平均浪费了28%的云支出，这一数字在多年来的同项研究中保持着惊人的一致。根据我的经验，这种浪费很大一部分并非源于不负责任的采购，而是为了维持在不同时间点、出于当时合理但如今难以理清的原因所获取的重叠能力而付出的代价。
为什么简化工作总是停滞不前
我见过许多简化倡议雷声大雨点小，最终被束之高阁。原因通常是现实层面的，而非政治层面的，尽管政治因素会让现实问题变得更加棘手。
团队面临的最大问题之一是没有人能够掌握环境的全貌，我见过一些整合倡议耗时远超预期，因为每当团队以为自己摸清了依赖关系时，总会发现最初调研中漏掉的另一个应用或工作流，这种情况下没人做错事，只是环境演进的速度超过了文档更新的速度——当你多年来一直在压力下不断扩展能力时，这种情况必然会发生。
这种现象比企业愿意承认的更为普遍，Gartner调查发现，影子IT占大型企业IT支出的30%到40%，其中包括业务部门自行采购的工具、为特定项目搭建却从未下线的工具，或者通过并购继承但从未完全集成的工具。当你试图去简化一个你无法完全看清的东西时，容错空间极其狭窄。
第二个问题是，简化会影响到企业内部真实的人。在企业的某个角落，一定有人依赖着你想要淘汰的应用或流程，这可能是一个连接着本该在两年前就关停的数据库的报表或工作流，也可能是一个对平台进行了深度定制、导致未来无法顺利迁移的团队。真正的简化需要小心翼翼地梳理这些依赖关系，这需要耗费大量的时间和协调精力，而大多数IT团队在维持日常运转的同时，根本没有足够的精力来做这件事。
第三个问题是，很难提前证明商业合理性，成本是客观存在的，但它并不总是体现在单一清晰的账目上，而是表现为更慢的故障响应时间、更高的供应商管理开销、新IT员工更长的上手时间，以及错失采用新技术能力的时机，所有这些因素都凸显了如果不解决这些问题，风险就会不断累积，这些成本很难汇总成一个足以支撑跨季度整合项目立项的具体数字，因此项目往往要等到某些环节彻底崩溃、不得不解决时，才能拿到预算。
在现实世界中行之有效的做法
在此我想保持谨慎，因为有些建议听起来简单，做起来却不然。“只需合理化你的供应商组合”说起来容易，但要做到不引发新问题，需要极强的纪律性。
在我亲历的环境中，始终有效的第一做法是从合同层入手，而非技术层，大多数企业对自己花钱买了什么，比对自己正在运行什么有更清晰的认识，一次彻底的合同与支出审计会比技术架构审查更快地暴露冗余，因为资金轨迹通常比配置轨迹更清晰，这不能给你呈现全貌，但能为你提供一个立足于现实的起点。
第二做法是在触动任何东西之前先绘制蓝图，在简化方面执行出色的企业，会投入大量时间(往往长达数月)对现状进行梳理盘点，然后再决定要整合什么，这是一项枯燥且不会作为重大成就出现在董事会汇报中的工作，但恰恰是它区分了成功的整合与停滞或失败的整合。
第三做法是围绕业务周期而非IT时间线来分阶段推进工作，我见过一些技术上无懈可击的简化项目走向失败，仅仅是因为它们的排期没有考量业务部门承受风险的能力。在季度结账期间进行迁移，或者在零售旺季更改架构——无论技术层面有多合理，这类决策都会削弱人们对IT团队专业判断力的信心。
我们的目标不是为了简化而简化一个环境，一个成熟的企业级IT环境必然会带有一定的复杂性，因为它所支撑的业务本身就是复杂的。你真正需要的是一个每一个工具、供应商、平台和合同都有明确存在意义的环境。你清楚谁是责任人、成本是多少以及它会带来什么风险。我合作的大多数企业距离这种状态并不遥远，他们只需要在开始做减法之前，先停止做加法。
