Kirk is a software developer who has filled most roles on the software developer team. He is the author of Java Design: Objects, UML, and Process (Addison-Wesley, 2002) and he contributed to No Fluff Just Stuff 2006 Anthology (Pragmatic Bookshelf, 2006). His most recent book, Java Application Architecture: Modularity Patterns with Examples Using OSGi was published in 2012. Kirk is a DZone Zone Leader and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

Modularity & Architecture

  • submit to reddit

I recently wrote about eliminating architecture, and there were a few comments, especially by folks on JavaLobby, who thought I had my head in the clouds. Too much theory. Too many abstract concepts. Not achievable in a real world development scenario. That I’m making a play on words. Let’s take another angle.

Defining Architecture

There are numerous definitions of architecture. But within each lies a common theme, and some key phrases. Here are a few of the definitions. From Booch, Rumbaugh, and Jacobson in UML User Guide (Addison-Wesley, 1999):

An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural elements and behavioral elements into progressively larger subsystems, and the architecture style that guides this organization — these elements and their interfaces, their collaborations, and their composition.

From the ANSI/IEEE Std 1471-2000:

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

In TOGAF, architecture has two meanings depending on context:

1.)   A formal description of a system, or a detailed plan of the system at component level to guide its implementation
2.)   The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

And in a QCon presentation by James Coplien and Kevlin Henney, architecture is defined as:

1.)   Architecture embodies the critical design decisions that typify a system. Relates to cost of change, organizational structure, structure of code, capabilities of a system, etc.

2.)   The significance of decisions needs to be understood and assessed. A heavy-weight approach is likely to reduce understanding and our ability to assess

Certainly, we see a pattern here as some key phrases and terms recur. These include “significant/critical decisions”, “components”, “structure”, and “cost of change”. And the definition from the Fowler article (which is actually part of a statement made by Ralph Johnson) introduced in the Eliminate Architecture post uses similar terminology and phrases.

It is these definitions that led us to the goal of architecture - eliminate the cost and impact of change. If we are able to eliminate the cost and impact of change, then change is no longer architecturally significant. If something isn’t architecturally significant, then we don’t consider it architecture. Essentially, we’ve eliminated architecture because the cost of change is no longer significant. That must be what we strive to achieve. And the way to achieve this is by increasing flexibility while taming complexity. Let’s take an analogy.

An OO Analogy

The goal of object-oriented design can be summed pretty effectively using the open-closed principle, which states:

a system should be open for extension but closed to modification.”

This is done through abstraction and inheritance. If we have abstractions in the right place, we can extend the system by introducing new classes without modifying existing system classes. The key is that we have to recognize which areas of the system require this added flexibility.

Certainly not all areas of the system can possess this flexibility. It’s unrealistic and entirely too complex. But it should still be our goal. It’s the same with architecture. Obviously we cannot eliminate the architectural significance of all change, but it must still be our goal. Otherwise, what goal are we striving to achieve?

Modularity - The Missing Ingredient

Two of the key elements of the architectural definitions are component and composition. Yet there is no standard and agreed upon definition of component (reminding me of architecture, actually), and most use the term pretty loosely to mean just “a chunk of code”. But that doesn’t work, and in the context of OSGi, it’s clear that a module is a software component. That’s excellent fodder for my claim that agile architecture requires modularity because agile architecture demands that we design a flexible system that allows us to make temporal decisions based on shifts that occur throughout development. Modularity has been a missing piece that allows us to more easily accommodate these shifts.

I illustrate this using the simple diagram at right, and it’s what I was referring to in the Eliminate Architecture post when I stated that modularity, in conjunction with design patterns and SOLID principles, represent our best hope to minimize the impact and cost of change. It’s easier to change a design embedded within a module than it is a design that spans modules. I provided a similar example in Modularity by Example.

In other words, it’s easier to isolate change by insulating a design within a module. Designs that span modules are the joints of our system, and changes in these areas are more complex and costly. This is where we need the flexibility. It’s where we need stability. But if we don’t have modularity, we don’t have joints. Or maybe everything becomes a joint? Either way, without modularity we can’t identify the joints so it’s more difficult to identify where we need the flexibility. If we are able to avoid changes that span joints, that change is isolated…insulated…encapsulated within a module, and the impact of change is minimized..

Can we do this in all cases? Of course not! Just like we cannot always design software that’s open for extension but closed to modification. But it must be what we strive to achieve. Again, modularity has been the missing ingredient. And now is a perfect time to start understanding how to design more modular software.


Published at DZone with permission of its author, Kirk Knoernschild.


Mike P(Okidoky) replied on Thu, 2009/09/17 - 12:37pm

Are people that use OSGi to create a modular environment to be able to "re-deploy" and make changes without having to restart the entire system, aware that it's possible to dynamically develop Java using JRebel? With JRebel you don't have to worry about not being able to change base classes, interfaces, etc. It turns Java into an almost completely dynamic live pliable scripting language.

Alessandro Santini replied on Fri, 2009/09/18 - 5:04am in response to: Mike P(Okidoky)

I would stand very clear from applying changes that affect a class structure on a live system.

Having said that, how does JRebel affect modularity and software architecture in general?

Csaba Szucs replied on Fri, 2009/09/18 - 8:09am


I believe, too that "eliminating architecture" is an unlucky phrase (kind of playing with words) and actually a bit hides your real message: modularity, patterns, flexibility, complexity, isolating (possible) changes & blocking them to escalate/ripple through the sw code.

I think, too modularity is very important and one of the basic points in object-oriented design. I am afraid to state that every developer knows modulary very weel and applies it consciously in his or her every-day design and programming. By the way I remember this excellent book: Object-Oriented Software Construction by Bertrand Meyer,

 I also recommend this more philosophical book on OO: Object Thinking by David West,

 I also feel problematic that there is no standard module/component definition in Java until now. More precisely each programming model/environment has developed its own definition. Module/component can be a class, a number of related classes, a plug-in, an EJB etc.

 I think, the time when the definitions for architecture were written, these software component/module artifacts did not even exist at all.


Alessandro Santini replied on Fri, 2009/09/18 - 10:30am


I hope you won't get it personal if I keep on dismissing your posts on this subject.

First of all, I would like to invite you to review the ISO9126-1 standard (Quality Characteristics for Software
Architecture). Here modularity is explicitly stated as a subfeature of the "maintainability" feature.

In addition, you can map all the S.O.L.I.D. principles with their corresponding ISO9126-1 features/subfeatures.

Most medium-large scale JEE projects have always been modularized using multiple JAR files, multiple EARs or multiple WARs. OSGi brings new features, but there's nothing so spanking new to hail to a new era in software architecture.

SOLID is nothing more than a con(solid)ation of design priciples that have gained the mainstream  over the last years.

So, what is this article (and the previous one) trying to say? That we should modularise more? Well, I  hope most software architects know this already.

As to "Eliminate Architecture" - catchy title, but you will never get rid of it. Simply because OSGI is per se an architecture. So you have not eliminated an architecture, you have simply made assumptions on the underlying layer (pretty much like JEE). 

I would also like you to take a read to these definitions of "architecture" (from Merriam-Webster):

a : formation or construction resulting from or as if from a conscious act

b : a unifying or coherent form or structure

This simply implies that any software has an architecture.

An interesting read about ISO9126-1

Gerd Ziegler replied on Mon, 2009/09/21 - 9:47am

Lets think about this pragmatic definition of architecture:

A software-system has a defined architecture if a programmer does not have to think about where to put his code, the architecture tells him where.

Alessandro Santini replied on Mon, 2009/09/21 - 3:32pm in response to: Gerd Ziegler

Cannot agree more. Although I tend to define this "design".

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.