Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Towards a modularity maturity model - osgi users forum uk 16-nov2011


Published on

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.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Towards a modularity maturity model - osgi users forum uk 16-nov2011

  1. 1. © 2011 IBM Corporation
  2. 2. A Maturity Model Source: Wikipedia 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 © 2011 IBM Corporation
  3. 3. 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
  4. 4. 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 © 2011 IBM Corporation
  5. 5. 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 © 2011 IBM Corporation
  6. 6. Segue Module Identity != Modularity Modularity “(Desirable) property of a system, such that individual components can be examined, modified and maintained independently of the remainder of the system. Objective PCIe x16 is that changes in one part of a system should not lead to unexpected behavior in other parts.” VGA DVI 015/glossary.html © 2011 IBM Corporation
  7. 7. Level 3: Modularity Characteristics Benefits • Declared module contracts • System structure awareness (capabilities and requirements) • Client/Provider independence • Private parts are implementation • Requirement-based dependency detail checking • Dependency resolution first, module identity second B v2 A v1 C v1.1 © 2011 IBM Corporation
  8. 8. Level 4: Loose-Coupling Characteristics Benefits • Separation of interface from • Implementation client/provider implementation with independence implementation used indirectly • Fine-grained impact awareness • No factories • Bug fix • No ‘new’ • Implementer breaking change • Services-based module • Client breaking change collaboration • Dependencies semantically versioned B v2 A v1 C v1.1 D v1 © 2011 IBM Corporation
  9. 9. 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 © 2011 IBM Corporation
  10. 10. 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 without loss of state • Apply fixes B v2 A v1 C v1.1 D v1 © 2011 IBM Corporation
  11. 11. 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
  12. 12. 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
  13. 13. 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 © 2011 IBM Corporation
  14. 14. TrademarksIBM and WebSphere are trademarks or registered trademarks ofInternational Business Machines Corp., registered in manyjurisdictions worldwide.Java and all Java-based trademarks and logos are trademarks orregistered trademarks of Oracle and/or its affiliates.Other product and service names might be trademarks of IBM or othercompanies. A current list of IBM trademarks is available on the Web at“Copyright and trademark information” © 2011 IBM Corporation