利用可组合性的力量进行软件开发架构变革

现在，企业比以往任何时候都更需要应对不确定性并迅速适应不断变化的经济状况——考虑一下近期疫情、供应链中断和人工智能的广泛使用等事件的影响。随着变化步伐的加快，组织必须创新并快速调整其 软件 系统以适应不断变化的业务需求。  

随着变革步伐的加快，许多架构师可能希望能够像搭乐高积木一样轻松地组装、重组和扩展 软件 系统，从而跟上变革的步伐。 可组合业务架构 通过应用模块化、可组合性和可重用性等几个架构原则来实现这一愿景。遵循这些原则可使组织做出战略架构选择，优先考虑急需的灵活性、敏捷性和适应性。 

虽然这些好处在概念上可以通过可组合业务架构实现，但正如任何从业者都知道的那样，好的概念不足以使其在现实环境中发挥作用。在实践中，建立可组合架构可能面临许多挑战：多云环境、混合云和本地环境、业务IT团队与中央IT团队，以及缺乏治理。  

在这种情况下，您需要获得所有可能的支撑，包括平台、基础设施和技术，以使可组合架构成为现实。 

让我们深入研究这些原则，探索实施它们的出众实践，并讨论如何使用 API、集成技术和市场将它们集成到组织的框架中。

变化是新常态

过去几年，经济不确定性不断上升，因为企业面临着许多外部不可预见的事件，例如疫情、供应链短缺、去全球化、战争、能源危机、技能短缺、通货膨胀和气候变化。虽然你不知道接下来会发生什么，但不确定性正在上升。 

首个步骤步是对出现的变化做出反应。企业努力适应这些外部变化，这将需要改变所有领域，包括其 软件 系统。过去，改变 软件 系统很困难，因为 软件 系统僵化，实际上很难改变，从而阻碍了企业更快地适应。 

为变化做准备，需要把修改与扩展成本纳入架构设计。模块边界、接口和依赖若过于僵化，后续调整会更加困难。

由于变化已变得如此普遍，试图建立僵化的 软件 系统并假装它们在未来几十年内保持不变是一种幻想。有远见的企业不仅要做出反应，还要为变化做好准备。 

但为变革做准备并不像听起来那么容易。复杂之处在于，你不能只为一种情况做准备；相反，你需要系统地为可能发生的一切和许多可能的情况做准备，这样你就有选择权，可以对变化做出反应。为变革做好准备意味着避免任何形式的僵化，专注于灵活性，这样你就可以毫不费力地适应系统。

您的系统架构是否抵制改变？

当变革风暴来临时，什么是重要的？  

在自然界中，树木会在暴风雨中折断，但竹子却能长存。两者有何不同？树木坚硬，而竹子柔韧，有助于抵御强风和多变的风。 

在我们的架构中，我们应该避免僵化，而应专注于创造灵活性。挑战在于灵活性的水平，因为我们不希望它变成混乱。 

灵活性是有效应对变化的关键。那么如何构建像竹子一样灵活的 软件 系统呢？构建易于更改的系统需要从一开始就成为构建的所有系统的一项要求。具有内在灵活性的可组合架构使应对变化变得更加容易。 

灵活性和应对变化的原则

有几个原则可以实现更灵活的架构：模块化和可组合性、云的可扩展性以及数字解决方案的民主化。

目标应该是创建灵活的系统，以便更容易适应不断变化的业务需求。 

你应该如何分解这个系统？  

我们从 DL Parnas 的工作中了解到，乐高原则模块化、可组合性和可重用性是创建更灵活系统的关键。您专注于创建具有高内部高内聚力的模块，并以轻量级方式（即弱耦合）组合它们。如今，您可以使用相同的分解原则以 API、事件和数据的形式表示模块。您将系统变成乐高积木的集合。  

你应该如何组织工作？  

使工作民主化，并允许业务IT团队创建数字解决方案。人工智能在民主化中发挥着重要作用。同时，需要实施治理以提供护栏并限制复杂性。理想情况下，您的开发平台将提供适合非技术用户和专家的 UI，以优化协作和效率。 

系统应在哪些平台上运行？  

基于云的平台和架构是灵活性的理想选择。可扩展性是灵活性的一个重要方面，而云是实现灵活性的出众方式。同时，某些组件可能推荐部署在本地区域或本地数据源附近，以满足特殊的非功能性要求。总体而言，这会导致许多人采用混合架构。 

您应该使用哪些工具？  

可组合架构可结合API管理、集成服务和开发工具实现。选型应逐项核对连接器、运行时、治理、部署与许可条件；采用何种平台不是架构成立的唯一前提。

让我们看看如何将这些原则付诸实践并构建更加灵活的架构。 

乐高原则：模块化、可组合性和可重用性

现代企业 软件 环境已有机发展成为异构环境。它们通常包括云端和本地的各种应用程序、SaaS、供应商提供的应用程序、定制开发的应用程序和在大型机上运行的旧版应用程序。  

可通过API或事件暴露适合复用的数据与功能。旧系统接入需核对接口、适配器、认证方式与数据语义，不能预设平台能直接连接所有技术栈。

API数量增加后，应明确目录、版本、访问控制、可观察性与生命周期责任。平台能否覆盖各部署环境，须依实际运行时和接入范围验证。

可组合架构将系统环境转变为一个平台，您的 软件 团队可以在该平台上构建、定制、个性化自动化工作流程。这个平台上至少有 3 个角色在其中运行： 

API 开发人员： 创建 API 并将其作为平台上的构建块提供。该角色期望平台提供自助服务。  API 消费者：专注于通过 软件 解决特定业务需求。找到正确的 API 并尽快编写它们。可能以图形方式，甚至借助 AI。您需要能够以简单直接的方式编写构建块。  平台运营商：运营具有自助服务功能的平台基础设施和市场，专注于治理，使中央IT与业务IT团队之间的互动更加顺畅，通常担任平台运营商和 API 开发人员的角色，而业务IT团队则担任 API 消费者的角色。这与民主化原则相辅相成。 

数据和能力获取的民主化

传统企业应用和集成方案往往由中央IT团队统一规划与交付。然而，它们与各种业务职能及其需求相距甚远，并且常常成为整个企业业务职能发出的请求的瓶颈。  

越来越多的业务部门内IT团队得以成立，并能够承担业务的数字化项目。业务部门内IT职能被称为“影子IT”的日子已经一去不复返了。新的思维方式是“全员参与”，需要它来管理变革。业务IT的优势在于与业务更紧密的结合、更短的反馈周期以及 IT团队更具体的领域知识。因此，业务IT团队可以更好地提供数字创新、快速周转时间和更多自主权。 

但系统仍然需要安全、可靠和高效——这一职责通常由中央IT团队承担，需要业务IT与中央IT团队协作。典型的责任划分如下： 

中央IT团队通常通过护栏、约束和治理为业务IT创新提供一个安全的平台，并且  业务IT团队使用该平台进行创新并满足其业务功能的特定需求。  

虽然业务IT团队通常在平台上工作，但中央IT团队负责运行平台。一些企业甚至运营融合团队，其中中央IT与业务IT团队在 DevOps 模式下协作。 

业务IT与中央IT可通过共同治理的平台协作。是否提供可视化编排、连接器或AI辅助，应依据产品版本与许可核实，并保留安全评审、权限控制和运维责任。

拥抱云

大多数组织将其系统环境的一部分迁移到云中，以利用云的可扩展性和弹性。但云并不是一个统一的地方；使用多个供应商和类型的产品，通常是作为一种战略选择，以实现对特定云提供商的一定程度的独立性。

 这会导致混合环境——一些系统在本地，一些在云中，并且使用多个云提供商和云产品。在这种情况下，灵活性是一个优势。系统可能会转移到不同的云提供商，从本地转移到云，或者非常有选择性地从云转移到边缘。 

除此之外，全球组织还需要遵守数据治理要求，即数据只能在某些司法管辖区及其适当的云区域中存储和处理。全球组织通常需要将功能部署到各个司法管辖区的云中心。 

现代云环境中出现了两类挑战： 

您需要针对多个云、区域和本地的各种部署场景分别进行开发。  从运营角度来看，您需要对已部署的API 和集成保持概览 — 无论它们部署在何处。每个云提供商可能都会提供一个控制平面，但这仅涵盖相应云中的元素，而忽略了其他云提供商和本地部署。 

混合与多云部署可从管理可见性和组件可移植性两个方面评估：

统一管理能力应核对所支持的API网关、集成运行时和环境接入范围；组件复用与跨环境部署仍取决于接口、权限、连接器与目标环境，通常需要适配和验证。

治理边界、运维责任与跨环境适配明确后，集成平台可作为实施工具；可组合性仍需通过具体模块、接口及变更场景验证。

意外复杂性：使用错误的工具构建可组合架构

如果使用错误的方法来应对变化，您往往会在基本复杂性之外引入意外复杂性。基本复杂性是问题和业务领域及其流程所固有的。当您使用错误的工具解决问题时，就会产生意外复杂性。使用锤子砍树会带来意外复杂性，使用错误的 API、  API 管理和 集成平台 来创建 软件 解决方案也会带来意外复杂性。 

北京软件开发外包公司可按项目范围协助实施；可组合业务架构的基础仍是明确的模块边界、接口与治理机制。虽然变化和颠覆可能带来威胁，但只有在遇到僵化或僵硬的系统结构时才会成为问题。通过遵循可组合业务架构的原则，您可以灵活地有效应对快速变化。您可以将变化变成您的盟友，变成更多创新的机会和未来增长的动力。