Towards a modularity maturity model - osgi users forum uk 16-nov2011
14
© 2011 IBM Corporation
-
Upload
mfrancis -
Category
Technology
-
view
1.464 -
download
1
description
Presentation by Graham Charters at OSGi Users' Forum UK meeting on Nov 16, 2011 in London.Abstract: 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.
Transcript of Towards a modularity maturity model - osgi users forum uk 16-nov2011
© 2011 IBM Corporation
© 2011 IBM Corporation
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
© 2011 IBM Corporation
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
© 2011 IBM Corporation
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
© 2011 IBM Corporation
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
© 2011 IBM Corporation
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
© 2011 IBM Corporation
Level 3: Modularity
Characteristics
• Declared module contracts (capabilities and requirements)
• Private parts are implementation detail
• Dependency resolution first, module identity second
Benefits
• System structure awareness • Client/Provider independence • Requirement-based dependency
checking
A v1
B v2
C v1.1
© 2011 IBM Corporation
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
• Fine-grained impact awareness • Bug fix • Implementer breaking change • Client breaking change
A v1
B v2
C v1.1
D v1
© 2011 IBM Corporation
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
© 2011 IBM Corporation
Level 6: Dynamism
Characteristics
• Dynamic module life-cycle • Modules fully life-cycle aware • Operational support for module
addition, removal, replacement, without loss of state
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
© 2011 IBM Corporation
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
© 2011 IBM Corporation
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
© 2011 IBM Corporation
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
© 2011 IBM Corporation
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
