中心化还是去中心化？

关键要点

• 大型IT组织必须在中心化与去中心化之间做出决策，取决于具体的任务和目标。
• 中心化可以在提升创新速度的同时，增加一定的管理和监管效率。
• 采用自动化手段可以减少由于中心化带来的行政负担，从而不影响团队的创造力和灵活性。

许多大型IT组织在某个时期必须决定哪些功能需要中心化，哪些需要去中心化。一些组织选择建立共享服务小组；其他组织则专注于在安全性和架构方面中心化管理，或是中心化采购和财务管理。如果管理不当，中心化的功能可能变成令人沮丧的瓶颈，与去中心化团队的共享服务之间的互动也可能导致行政浪费。企业应如何决定中心化的内容，并如何组织中心化服务与去中心化单位的互动以减少浪费？

作为美国国土安全部（DHS）某个分支机构的首席信息官，我曾深感繁琐的中心化所带来的困扰。每当我们想要新的服务器或更改数据中心时，必须向负责管理数据中心的DHS合同组织提出申请。我们的网络基础设施与其他DHS分支共用并进行中心化管理，因此即使是小型网络更改也需要繁琐的文书工作、审查和长期等待。对于IT项目，我们必须遵循DHS监管框架MD-102的繁琐要求，这个框架是为了监管海岸警卫队的预算而设计的，也适用于软件系统的交付，因此其核心关注点是巨大的资本投资和物理对象。中心化似乎妨碍了我们想要实现的一切。

如今的数字工作方式呼唤去中心化、赋权和自主的团队。这与中心化的职能和治理之间的矛盾难以协调！但是，某些职能又是无法去中心化的，或者去中心化会导致低效。在我们的案例中，DHS总部负责整个企业的安全，通过中心化协商供应商合同，我们能够利用采购量来获得更好的折扣。

中心化与去中心化之间的紧张关系是当今数字IT环境的核心。不出所料，这种话题在我与企业领导的许多对话中以某种形式出现。

为了有效处理这种权衡，我倾向于从“速度和创新”这一原则入手，这在当今环境中至关重要。通过去中心化权力、以自主的、赋权的跨职能团队进行工作，最好能促进创新。这些团队可以靠近客户，轻松感知市场变化，可以通过跨职能参与孵化创意，无需在职能孤岛之间进行交接，从而快速完成工作。当一个自主团队依赖于中心化职能时，会拖慢速度，增加行政开销，施加限制创新的官僚主义。

这是我的出发点，但这个问题需要更加细致的探讨。在什么情况下应该中心化职能？我的第一个答案是：只有在确实能加速那些去中心化团队并支持其创新的情况下。若中心化组织能够提供服务，这些服务本来需要团队自己花时间去完成，而这一过程没有额外的行政开销来拖慢团队，那么这就是好的。

当然，随着云计算的兴起，我们无需再为数据中心担忧。现在想象一个中心化的云平台团队向软件交付团队提供准备好的基础设施。团队可以自助配置他们所需的一切基础设施，无需等待平台团队的操作。相反，平台团队将平台设定为，当团队自助配置基础设施时，自动使用经过安全团队审核和配置的云资源，并且财务团队已经批准了这些资源的成本效益。现在，中心化的 платформ组织实际上让交付团队的工作变得越来越快，因为他们无需评估这些资源的安全性，或进行额外的安全工程，以及不必证明所使用资源的成本效益。而且没有额外的行政开销，因为他们仍然可以自行配置基础设施。

在这种情况下，中心化职能实际上加快了去中心化团队的工作，这无疑是一个重大成功！请注意与我之前DHS示例的对比，那里中心化职能导致了延误和挫折，因为它们涉及到例行干预和实际的交接给另一个团队。

因此，当中心化能提高速度时，确实应该中心化职能。但这仍然不是全部故事。组织中心化的另一个原因是为整个企业提供治理和监督。在DHS，总部需要监督安全和支出，因此建立了中心化的机构以处理这些事务。我们如何在不降低效率的情况下满足这些需求？

首先，我们应该问，是否真的有必要进行中心化治理。在我的书中，我建议对IT领域的自动化标准化冲动保持谨慎——我们常常假定需要标准，而仔细分析会表明，这种标准化可能并不值得为了其遵循而付出额外的成本或减慢速度。我喜欢指出治理和管理之间的权衡。治理制定规则并引入实施机制，因此会产生相应的成本。但往往通过良好的管理也可以实现相同或更好的效果。例如，治理可能迫使团队使用标准化的软件交付平台。而管理则可能会询问未使用标准平台的团队，为什么他们如此决策。他们是否在做出决策时考虑了公司的最大利益？并不一定需要规则与实施来促使良好行为；往往有效的管理就可以解决这个问题。

但假设确实需要中心化治理。好消息是，如今这往往可以通过自动化实现，通过建立不降低去中心化团队效率或增加负担的“护栏”。我有时会谈到“自动化你的官僚制度”。现如今，我们可以做到“合规即代码”、“政策即代码”或“审计即代码”。你的官僚制度不会干扰速度和创造力，相反，它仅在护栏内将二者对齐。

我已经给出了一个自动化官僚制度的例子：平台团队仅提供经过审核的资源供团队自助配置。安全团队的治理已经嵌入到可用组件的选择中，他们无需进一步干预。另一个例子是：我们让安全团队创建自动化测试，检查其他IT团队是否遵循他们的政策。通过确保他们的代码通过安全测试，交付团队可以独立地以最快的速度移动——然而，通过这些测试，安全团队提供了治理。同样地，你也可以自动化财务控制，或许限制未被使用的资源，或者阻止团队使用不合成本效益的资源，或许在团队计划进行潜在高支出时通知财务。所有这些自动化机制都执行了中心化的治理控制，而不会拖慢团队速度、干扰他们的创造力，或增加行政开销。

因此，以下是我在管理中心化/去中心化权衡时的经验法则：

• 默认去中心化
• 当中心化能提高去中心化单位的速度时进行中心化
• 当需要治理时中心化，但以不形成依赖的自动化方式进行。

—

马克·施瓦茨是亚马逊网络服务的企业战略家，《商业价值的艺术》和《在灵活时代的IT领导力：入座的机会》一书的作者。在加入AWS之前，他曾担任美国公民及移民服务局（属于国土安全部）的首席信息官，此外还曾担任Intrax的首席信息官和Auctiva的首席执行官。他毕业于沃顿商学院，获得MBA学位，此外在耶鲁大学获得计算机科学学士学位和哲学硕士学位。

加载评论…