Towards a Modularity Maturity Model
-
Upload
graham-charters -
Category
Technology
-
view
162 -
download
2
Transcript of Towards a Modularity Maturity Model
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
24.03.14
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
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
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
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
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
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
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
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
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
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
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
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
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