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

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

3. Source: Wikipedia
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
Page 3 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved, 26.09.2011
© IBM Corp. 2011

4. 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
Page 4 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved, 26.09.2011
© IBM Corp. 2011

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

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

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

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

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

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

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

12. 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
Page 12 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved, 26.09.2011
© IBM Corp. 2011

13. 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
Page 13 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved, 26.09.2011
© IBM Corp. 2011

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

15. Trademarks
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.
Page 15 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved, 26.09.2011
© IBM Corp. 2011