Embed Size (px)
DESCRIPTION
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.
Citation preview
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
Page 2 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
26.09.2011
Page 3 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
26.09.2011
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
Page 4 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
26.09.2011
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 5 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
26.09.2011
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
Benefits
• Cheap to get started
.../Bv2.jar
.../A_v1.jar
.../C.jar
Page 6 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
26.09.2011
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…
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
Page 7 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
26.09.2011
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
Page 8 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
26.09.2011
Level 3: Modularity
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
A v1
B v2
C v1.1
Page 9 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
26.09.2011
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
Benefits
• Implementation client/provider independence
A v1
B v2
C v1.1
D v1
Page 10 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
26.09.2011
Level 5: Devolution
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
B v2
C v1.1
D v1
A v1
Page 11 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
26.09.2011
Level 6: Dynamism
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
A v1
B v2
C v1.1
D v1
Page 12 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
26.09.2011
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 13 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
26.09.2011
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 14 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
26.09.2011
Level 7
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
: Peter Kriens
Page 15 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,
© IBM Corp. 2011
26.09.2011
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
