Modularity is a key element of any good process. Many organizations follow agile processes without considering the structure of their applications. For this reason, many agile initiatives fail to fully deliver the expected business benefits. Agility can only be realized when the underlying entity - the organization or the software product, has structural modularity.
Richard Nicholson, CEO and Founder of Paremus described the relationship between structural modularity and agility in technical whitepaper of OSGi, the open industry standard for Java modularity.
For an entity to be “agile” it must have a high degree of structural modularity. Hence the agility question needs be recast from “How do I build agile business systems?" to “How do I build highly modular business systems?”
The number of constituent components and the inter-dependencies between these components increases when there is increase in business units and service providers. Usually, if left unchecked, the number of inter-dependencies increases much more rapidly than the number of components. The structure becomes increasingly complex.
Therefore, agile systems need to exhibit the following characteristics:
- A hierarchical structure: Each layer in the hierarchy composed from components from the underlying layer.
- Abstraction: For each layer, the behavior of participating components is exposed via stated requirements and capabilities relevant to that layer.
- Isolation: Strong isolation ensures that the internal composition of each participating component is masked at each layer.
- Self-Describing: Within each layer the relationship between the participating components is self-describing; i.e. dependencies are described in terms of published requirements and capabilities.
- Impact of Change: Via semantic versioning the impact of a change on dependencies can be expressed.
Kirk Knoernschild, Research Director at Gartner, explores the relationship between agility and structural modularity in his book “Java Application Architecture” and identifies the problem of the “missing middle.” Knoernschild concludes that essential structural layers are missing in the architecture of traditional Java applications. At the coarse-grained end of the modularity spectrum there are traditional services, whereas at the fine-grained end of the modularity spectrum there are Java packages and classes. However, there is a void in the center.
Based on open industry standards created by the OSGi Alliance, OSGi directly addresses this issue by providing Java with the required modularity framework.
- OSGi bundles express dependencies in terms of Java package requirements and capabilities. Hence it is immediately apparent to a third party, whether a particular OSGi bundle can be substituted with a potential alternative.
- OSGi bundles use semantic versioning. Hence it is immediately apparent to a third party whether a change to an OSGi bundle is potentially a breaking change to those using it
One structural layer up, OSGi also provides µServices. These are lightweight services that are able to dynamically find and bind to each other at runtime. OSGi services may be co-located within the same JVM, or via use of an implementation of OSGi’s remote service specification, distributed across JVMs separated by an IP network.
Richard described the mapping of OSGi bundles with scrum and Kanban as:
Applying Scrum to a large monolithic code base is difficult. Conversely, Scrum concepts map well to a highly modular code base comprised of many self-describing, strongly isolated OSGi bundles.
Kanban concepts map naturally to a highly modular code base comprised of many self-describing, strongly isolated artifacts; specifically, the Kanban WIP process idea maps directly to the subset of OSGi bundles that are being actively worked upon. Hence, Kanban pull-based flow rates can be mapped to OSGi bundles’ change/release become more fine-grain, the Kanban pull -based flow rates naturally increase, with each smaller OSGi bundle spending correspondingly less time in a WIP stat