My Stuff

2010 Conferences

OSGi DevCon @ JAX London

February 23 - Keynote titled OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox


March 22 - 25 - Tutorial on Modular Architecture

Über Conf

June 14 - 17 - Sessions titled Turtles and Architecture and Patterns of Modular Architecture


July 26 - 30 - Two sessions on rich mobile applications and one on agile development. Half day tutorial on software process improvement.

Tweets @ Twitter

re: #apple event "We sold more iPads than any PC manufacturer sold of their entire PC line." 2012-09-12

re: #Apple Event ""Our notebooks now rank #1 in the US in Market share in the last three months." 2012-09-12

Right on. I just won a Best Buy drawing worth $1000. Either that or I won a shiny new virus by clicking the link. Hmm...what to do. 2012-08-29

The #osgi alliance response ( to the @mreinhold #jigsaw announcement ( 2012-08-29

Good Q&A with @mreinhold on project #jigsaw. Modularity will change the way we design and run apps! 2012-08-28

LinkedIn Profile

The opinions expressed on this site are my own, and not necessarily those of my employer.

Modularity & Architecture

Filed Under Agile, Architecture & Design, Development, Java, OSGi |  

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.


8 Responses to “Modularity & Architecture”

  1. ewe on September 17th, 2009 3:36 pm

    I still don’t get your point. Common definitions of architecture deal with components, interface and connectors. What you suggest is modularity, which is exactly the same to me.
    It’s the endless loop: to reduce big upfront architecture, we need flexibility, which means we need modularity, which means we need…architecture.
    We can argue about the granularity of modules vs. component. We can also argue about the abstraction level of design vs. high-level design vs. architecture.
    But you can not eliminate architecture neither design. What you can change is the intent of the architecture or design. Old way was “do it right” and new way says “do it flexible”. And ultimately “right=flexible”!

  2. Agile Architecture, Lean Principles : Software & Technology on September 22nd, 2009 7:45 pm

    [...] joints so it’s more difficult to understand where we need the flexibility. My posts titled Modularity & Architecture and Modularity by Example show visual examples comparing designs that are isolated and insulated to [...]

  3. The Use/Reuse Paradox : Software & Technology on October 7th, 2009 5:05 pm

    [...] Understanding principles, patterns and practices (like SOLID and modularity patterns) that increase architectural agility help resolve the tension between use and reuse, and are certainly a step in the right direction. But so too is understanding that certain decisions must be deferred until we have the requisite knowledge to make the most informed decision possible. Because of this, we should strive to minimize the architectural significance (impact and cost) of change by making our designs as reversible as possible. Reversibility doesn’t always mean great flexibility, though. Sometimes it means we make something as simple as possible so that it’s easy to change later. Either way, it’s imperative to accommodate the natural shifts that occur throughout development, and modularity plays a central role in making this happen. [...]

  4. 3 Pillars of Architecture : Software & Technology on January 27th, 2010 4:44 pm

    [...] - In Modularity and Architecture, I offered up a few industry definitions of architecture. Common keywords that span definitions [...]

  5. Architecture Lives Here : Software & Technology on March 4th, 2010 4:48 pm

    [...] the past, I’ve talked about the importance of designing the joints of a system. OSGi services represent these joints, since services are essentially a module’s published [...]

  6. OSGi: Complexity is NOT the Problem : Software & Technology on April 15th, 2010 6:40 pm

    [...] Modularity & Architecture - A response to the entry on eliminating architecture. [...]

  7. louis vuitton epi soufflot on January 15th, 2014 11:58 pm

    louis vuitton epi soufflot…

    M?me si vous avez certainement l’un des suppl?mentaires ? prix tr?s v?hicules de s’assurer, vous obtiendrez couverture d’assurance remises sp?ciales pour sp?cifiques Options . En v?rit? , comme Floride , Ny , et du New Jersey fonda…

  8. nike blazer noir et rose on January 24th, 2014 6:32 am

    nike blazer noir et rose…

    Phase 2) Footwear: Absent is the working day of 1 pair of shoes, and 1 pair of sneakers. Variety is essential right here. Gown Shoes for perform, Informal Footwear for Seasonal adjustments, Athletic footwear for the exercise you require as well as a mo…

Leave a Reply