任何好流程的关键都是要模块化。许多公司的敏捷流程没有考虑他们应用的结构。由于这个原因，许多敏捷的举措都没有能够充分交付预期的商业利益。只有把底层实体（组织或者软件产品）的结构模块化，才能够实现敏捷。
Richard Nicholson 是 Paremus 的首席执行官和创始人，他在 OSGi （Java 模块化的开放的行业标准）的技术白皮书中描述了结构模块化和敏捷的关系。
一个实体要“敏捷”，它的结构就需要有高度的模块化。因此，关于敏捷的问题应该从“如何构建敏捷的业务系统？”变成“如何构建高度模块化的业务系统？”
随着业务单元和服务提供者的增加，组件构成数量和这些组件间的内部依赖也会随之增加。通常，如果任其发展下去，内部依赖的数量会迅速增加甚至超过组件的数量。结构会变得越来越复杂。
所以，敏捷系统需要显著地具备以下特征：
- 一个分层的结构：每一层都是由下一层组件分层构成的。
- 抽象：对于每一层来说，参与的组件所暴露的行为与那一层陈述的需求和能力有关。
- 孤立：高度独立确保在每一层上每个参与的组件的内部构成对外是不可见的。
- 自描述性：每一层内部参与的组件之间的关系是自描述的；也就是说，按照已发布的需求和能力来描述它们的相关性。
- 变更的影响：通过语义性版本管理可以把依赖关系的变更影响表达出来。
Kirk Knoernschild 是 Gartner 的研究室主任，他在其《Java 应用架构》这本书中表达了对敏捷和结构模块化之间关系的看法，确定了“中层缺失”问题之所在。Knoernschild 总结说在传统 Java 应用的架构中缺失了本质上的结构层。粗粒度的模块化范围是传统的服务层，另一方面细粒度的模块化是 Java 包和类的层次。粗粒度和细粒度之间缺少中间层。
基于 OSGi 联盟创建的开放的行业标准，OSGi 通过提供 Java 模块化框架直接地解决这个问题。
- OSGi bundle 按照 Java 包表述需求和能力。因此，第三方可以直接看出来特定的 OSGi bundle 能否被其他备选方案替代。
- OSGi bundle 使用语义级版本管理。因此，第三方可以直接看出来一个 OSGi bundle 的变更对于那些使用者来讲是不是天翻覆地的变化。
OSGi 还在结构层之上提供了µServices 层。这里有轻量级的服务，这些服务能够在运行期彼此间动态地发现和绑定。OSGi 服务可能同时在同一 JVM 中，或者通过使用 OSGi 远程服务规范的实现，分布在不同 IP 段的多个 JVM 上。
Richard 描述了 OSGi bundle 与 scrum 和看板的映射：
我们很难把 Scrum 应用于大型的单片系统代码库。相反地，Scrum 的概念很好地映射了高度模块化的代码库，这类代码库包含许多自描述的、强隔离的 OSGi bundle。
看板的概念很自然地映射了高度模块化的代码库，这类代码库包含许多自描述的、强隔离的工件；特别要注意的是，看板制品（WIP）流程的思想直接映射了 OSGi bundle 的子集，大家都围绕它们积极地开展工作。因此，看板基于拉动的流程速率是与更细粒度的 OSGi bundle 的变更或发布相匹配的，如果在制品流程中的每个更小的 OSGi bundle 都可以相对地缩短花费的时间，那么自然而然看板基于拉动的流程速率就会相应地有所提升。
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论