The New Modularity

Software Development

On vacation last week, I read a wonderful book about the value of modularity: Carliss Baldwin and Kim Clark's Design Rules, Vol. 1: The Power of Modularity (MIT Press, 2000)—and it changed my thinking about how companies should approach aspect-oriented programming.

In earlier columns, I've written that businesses should limit their initial work with AOP to focused incremental pilot projects, and I've discussed different ways to approach them. I still believe companies should undertake such focused projects, but reading Design Rules clarified for me some of the potential strategic and market implications of AOP.

A Technical Means to New Modularity

Last month, I said that AOP's biggest impact is that it has changed how we think about software. It's given us a new kind of modular element—aspects—and a new kind of structural relation—crosscutting. With these ideas in the air, we're coming to see software design differently. We see different kinds of modules than existed before, and we see different ways of organizing systems.

Even without AOP, we find that technology to enable re-modularization is widely available—for example, in tools such as the Byte Code Engineering Library (BCEL) and JavaAssist, among others. Because Java and .NET are byte-code-based, these tools are fairly easy to write and use, and are widely applicable.

The idea that systems can be decomposed differently, along crosscutting aspects, along with the availability of tools that support it, provides the technical means for re-modularization of systems based on these platforms, and the platforms themselves.

Some will argue that bytecode manipulation may not be permissible; I'm not going to get into that here. I'll just note that the popularity of open source tools like BCEL makes it clear that there's a lot of bytecode manipulation going on.

Others will argue that direct byte-code manipulation is too raw and high-powered for widespread use, and I agree. In fact, AOP was developed based on experience with that kind of meta-programming and reflection. Because it's declarative, and weaker than pure behavioral reflection, it's easier to write principled code with AOP. It's also harder—but certainly not impossible—to write bad code with AOP.

Value and Modularity

To this technical argument for re-modularization, Baldwin and Clark add a deep analysis of the relation between platform modularity and business value. Their book is too complex for me to do it justice here, but part of their discussion touches on the fact that when a platform is modular, it permits additional experiments with parts of its implementation (the modules). Those experiments can be done by organizations other than the primary platform provider. This means that greater investments can be brought to the platform than is the case with monolithic platforms. This in turn increases the platform's value to its users. At the same time, it raises challenges and opportunities for platform control.

In some ways, the authors' analysis should not be new to us, as we see the big players constantly vying for control over the platforms that we all use. But by tying their analysis so clearly to modularity, Baldwin and Clark provide an important and interesting connection between a core technical issue and economic value.

Java- and .NET-based platforms are already very modular. The core technology and frameworks such as Enterprise JavaBeans (EJB) support this. But the advent of aspects—a new idea about how modules can be cut up—together with technology to support that modularization means we can carve up these platforms differently. For example, whereas EJB containers are monolithic, AOP enables the individual aspects that comprise the container to be split out.

For such platforms as enterprise application servers, there's a lot of value in "hard-core computer science issues like how to handle transactions, caching and synchronization. This lets application developers ease their work without necessarily mastering all the details of those issues. However, if such things as transaction handling, caching and so on can be modularized as aspects, then their value changes and control over value shifts. Other players can provide competing implementations, so there's more investment. Developers can choose different implementations for different purposes, so there's more specialization. At the same time, control can move away from platform architects, since they're not guaranteed to be the providers of the best implementation.

This same process can also play out within an enterprise. One large company, after using AOP to modularize a core aspect of its architecture that had previously been spread over thousands of files, reported privately that the first thing one of its architects said was, "Great, now I can experiment with different versions of that aspect. I was never sure that we had it perfect before. I just knew that I couldn't change it, so I didn't bother trying.

Rethinking Outside the Box

Existing software platforms will be re-modularized with aspects—it's an idea whose time has come.

Why am I so sure? Now that the aspect idea is in the air, and the core platforms of our time make at least ad hoc crosscutting easy, aspect-like re-modularization of our platforms (both core and higher-level) is technically within reach. Doing that re-modularization with low-level bytecode manipulation presents problems that AOP was designed to address. Furthermore, key economic forces will also drive the aspect-based re-modularization of platforms.

We're already seeing this happen in the Enterprise JavaBeans (EJB) space. EJB has provided a small set of fixed aspect-like services, and developers are using AOP to provide a more open and flexible version of this functionality. It's time for companies to start thinking strategically about the implications of this new generation of modularity technology on the platforms on which their business relies. Baldwin and Clark's book makes it clear that strategic thinking can create significant value for end users. It can bring additional investment in aspects to platforms that previously were locked in. And it can make platforms more vibrant.

Given this, if you provide a significant Java or .NET-based system, you should begin thinking strategically about aspects. At the very least, read Baldwin and Clark's book, and then get a chief architect, an AOP expert and a strategist together to map out the sweet spots for re-modularization. Mapping out the economic forces that swirl around those sweet spots will enable you to lead the way rather than getting caught behind.