Modularity Maturity Model

The Modularity Model was introduced by Dr Graham Charters at the OSGi Community Event 2011 (slides). It is an extension of the Capability Maturity Model, which was created as a result of research funded by the US Department of Defense and published in 1993. The Capability Maturity Model allows organizations or projects to measure their improvements on a software development process.

Note that the below is a work-in-progress, and the numbers/descriptions may evolve over time. With that caveat in place, the modularity maturity model currently looks like this:

• Level 1:Ad Hoc. Nothing is modular. Everything is a bunch of JARs, or worse, a bunch of classes. Typically results in a monolithic application.
• Level 2:Modules. Modules have a formal versioned identity, and dependencies are done against the module identity rather than the units themselves. Maven, Ivy, RPM and OSGi fall into this category.
• Level 3:Modularity. Modules are declared via module contracts, not via explicit module identifier/versions. The requirements might be abstract (e.g. Declarative Services is available) or might be specific packages (e.g. org.osgi.framework).
• Level 4:Loose coupling. Implementations are not found via factories or constructors; instead, they are queried dynamically from a registry or injected on demand.
• Level 5:Devolution. Artefact ownerships are devolved to modularity-aware repositories. They may support collaboration or governance for accessing the assets by relation to the capabilities required.
• Level 6:Dynamism. Modules participate in a dynamic life cycle which includes the ability to add, update and remove modules at runtime, whilst preserving the state in the system.