For those in the thick of OSGi, it is easy to forget what it was like to get started, and what benefits are achieved at each stage. Drawing inspiration from the various SOA maturity models, I thought it would be an interesting exercise to try to put together a modularity equivalent, and so the Modularity Maturity Model (M3) was born. The title says "Towards" because this is an initial proposal and so input from the audience (rocks, rotten vegetables, and maybe even faint praise) would be welcome.

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