The document proposes a 6-level Modularity Maturity Model that describes an organization's ability to produce modular systems. Level 1 represents ad hoc development with no modularity. Level 2 introduces formal module identities. Level 3 adds declared module contracts. Level 4 achieves loose coupling through services. Level 5 involves modularity-aware code repositories. Level 6 allows dynamic updating of running systems. The model is intended to help organizations understand current practices and prioritize improvements to increase modular design and development.

1. COPYRIGHT © 2008-2011 OSGi Alliance. All Rights Reserved, © IBM Corp. 2011
Towards a Modularity Maturity Model
Graham Charters
IBM
21st
September 2011
OSGi Alliance Marketing © 2008-2010 .
All Rights Reserved
Page 1

2. Page 2 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
24.03.14

3. Page 3 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
24.03.14
A Maturity Model
• A set of structured levels describing how well an
organization can reliably and sustainably produce
required outcomes
• May provide
• a place to start
• benefit of prior experiences
• common language and shared vision
• framework for prioritizing actions
• define what improvement means
• Can be used as a benchmark for
comparison and an aid to understanding
Source: Wikipedia

4. Page 4 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
24.03.14
Modularity Maturity Model
• A Maturity Model for Modularity 
• Focus on organisational capability
• Modularity technology agnostic
• Drawn from observations from a number of
projects and customers
• An 80:20 guide, not a 100% law

5. Page 5 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
24.03.14
Level 1: Ad Hoc
Characteristics
•No formal modularity focus
•Bunch of classes with no structure
•Flat class path
•Library Jars
•Monolithic application
•Archives of archives
Characteristics
•No formal modularity focus
•Bunch of classes with no structure
•Flat class path
•Library Jars
•Monolithic application
•Archives of archives
Benefits
•Cheap to get started
Benefits
•Cheap to get started
.../Bv2.jar
.../A_v1.jar
.../C.jar

6. Page 6 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
24.03.14
Level 2: Modules
Characteristics
•Formal module identities
• In artifact or catalogue
•Identities can be versioned
•Dependencies based on identities
• Build
• Development
• Operations
•Examples: Maven, Ivy, RPM, OSGi,
etc…
Characteristics
•Formal module identities
• In artifact or catalogue
•Identities can be versioned
•Dependencies based on identities
• Build
• Development
• Operations
•Examples: Maven, Ivy, RPM, OSGi,
etc…
Benefits
•Decouple module from artefact
•Clearer view of module assembly
•Enables version awareness
• Build
• Development
• Operations
•Enables module catalogues
Benefits
•Decouple module from artefact
•Clearer view of module assembly
•Enables version awareness
• Build
• Development
• Operations
•Enables module catalogues
A v1
B v2
C v1.1
Identity Artifact
A v1 .../B_v1.jar
B v2 …/Bv2.jar
C v1.1 …/C.jar

7. Page 7 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
24.03.14
Segue
“(Desirable) property of a system,
such that individual components can
be examined, modified and
maintained independently of the
remainder of the system. Objective
is that changes in one part of a
system should not lead to
unexpected behavior in other parts.”
www.maths.bath.ac.uk/~jap/MATH0015/glossary.html
PCIe x16
VGA
DVI
Modularity
Module Identity != Modularity

8. Page 8 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
24.03.14
Level 3: Modularity
Characteristics
•Declared module contracts
(capabilities and requirements)
•Private parts are implementation
detail
•Dependency resolution first, module
identity second
Characteristics
•Declared module contracts
(capabilities and requirements)
•Private parts are implementation
detail
•Dependency resolution first, module
identity second
Benefits
•Fine-grained impact awareness
• Bug fix
• Implementor breaking change
• Client breaking change
•System structure awareness
•Client/Provider independence
•Requirement-based dependency
checking
Benefits
•Fine-grained impact awareness
• Bug fix
• Implementor breaking change
• Client breaking change
•System structure awareness
•Client/Provider independence
•Requirement-based dependency
checking
A v1
B v2
C v1.1

9. Page 9 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
24.03.14
Level 4: Loose-Coupling
Characteristics
•Separation of interface from
implementation with implementation
used indirectly
•No factories
•No ‘new’
•Services-based module collaboration
•Dependencies semantically versioned
Characteristics
•Separation of interface from
implementation with implementation
used indirectly
•No factories
•No ‘new’
•Services-based module collaboration
•Dependencies semantically versioned
Benefits
•Implementation client/provider
independence
Benefits
•Implementation client/provider
independence
A v1
B v2
C v1.1
D v1

10. Page 10 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
24.03.14
Level 5: Devolution
Characteristics
•Artifact ownerships devolved to
modularity-aware repositories
•Repositories may support
• Collaboration (commenting,
ratings, forums)
• Governance (approvals, life-
cycle)
Characteristics
•Artifact ownerships devolved to
modularity-aware repositories
•Repositories may support
• Collaboration (commenting,
ratings, forums)
• Governance (approvals, life-
cycle)
Benefits
•Greater awareness of existing modules
•Reduced duplication, increases quality
•Collaboration/empowerment around
modules
•Quality/operational control
Benefits
•Greater awareness of existing modules
•Reduced duplication, increases quality
•Collaboration/empowerment around
modules
•Quality/operational control
B v2
C v1.1
D v1
A v1

11. Page 11 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
24.03.14
Level 6: Dynamism
Characteristics
•Dynamic module life-cycle
•Modules fully life-cycle aware
•Operational support for module
addition, removal, replacement
Characteristics
•Dynamic module life-cycle
•Modules fully life-cycle aware
•Operational support for module
addition, removal, replacement
Benefits
•No brittle ordering dependencies
•Ability to dynamically update a
running system
• Extend capabilities
• Apply fixes
Benefits
•No brittle ordering dependencies
•Ability to dynamically update a
running system
• Extend capabilities
• Apply fixes
A v1
B v2
C v1.1
D v1

12. Page 12 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
24.03.14
Simple Summary
Level Name Summary
1 Ad Hoc Nothing
2 Modules Formal identity, decoupled from artifact
3 Modularity Formal module contracts, decoupled from identity
4 Loose-Coupling Services, semantic versioning, decoupled from
implementation
5 Devolution Modularity-aware repositories, collaboration,
governance, decoupled from ownership
6 Dynamism Life-cycle awareness and independence, decoupled
from time

13. Page 13 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
24.03.14
Time to apply...
• How do your projects and
organization fair?
• How do some well-known
projects fair?
• How are we doing as an
industry?
• In answering these questions
we can better understand the
tasks and benefits ahead

14. Page 14 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
24.03.14
Level 7
Characteristics
•Sees the modularity in anything and
everything
•A higher state of modularity
enlightenment
•10+ years eating and breathing
modularity
Characteristics
•Sees the modularity in anything and
everything
•A higher state of modularity
enlightenment
•10+ years eating and breathing
modularity
Benefits
•Can address all modularity problems
Benefits
•Can address all modularity problems
: Peter Kriens

15. Page 15 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
24.03.14
IBM and WebSphere are trademarks or registered trademarks of
International Business Machines Corp., registered in many
jurisdictions worldwide.
Java and all Java-based trademarks and logos are trademarks or
registered trademarks of Oracle and/or its affiliates.
Other product and service names might be trademarks of IBM or other
companies. A current list of IBM trademarks is available on the Web at
“Copyright and trademark information” at
www.ibm.com/legal/copytrade.shtml.
Trademarks