Towards a Modularity Maturity Model

370 views

Published on

OSGi Community Event Keynote proposing a Modularity Maturity Model, given in 2011.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
370
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Describe background:
    Started writing article describing progression of modularity adoption.
    Realized commonality with Maturity Models.
  • Towards a Modularity Maturity Model

    1. 1. 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
    2. 2. Page 2 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved, © IBM Corp. 2011 24.03.14
    3. 3. 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
    4. 4. 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
    5. 5. 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
    6. 6. 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
    7. 7. 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
    8. 8. 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
    9. 9. 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
    10. 10. 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
    11. 11. 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
    12. 12. 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
    13. 13. 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
    14. 14. 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
    15. 15. 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

    ×