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

OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,© IBM Corp. 2011

24.03.14


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


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


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


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


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

http://www.maths.bath.ac.uk/~jap/MATH0015/glossary.html


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


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


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


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


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


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


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


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

Towards a Modularity Maturity Model

Technology

Transcript of Towards a Modularity Maturity Model