Download pdf - IBM Sponsorship Keynote: Towards a Modularity Maturity Model - Graham Charters

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

26.09.2011


© IBM Corp. 2011

26.09.2011

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


© IBM Corp. 2011

26.09.2011

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


© IBM Corp. 2011

26.09.2011

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


© IBM Corp. 2011

26.09.2011

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


© IBM Corp. 2011

26.09.2011

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




© IBM Corp. 2011

26.09.2011

Level 3: Modularity

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

A v1

B v2

C v1.1


© IBM Corp. 2011

26.09.2011

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

A v1

B v2

C v1.1

D v1


© IBM Corp. 2011

26.09.2011

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


© IBM Corp. 2011

26.09.2011

Level 6: Dynamism

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

A v1

B v2

C v1.1

D v1


© IBM Corp. 2011

26.09.2011

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


© IBM Corp. 2011

26.09.2011

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


© IBM Corp. 2011

26.09.2011

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


© IBM Corp. 2011

26.09.2011

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