email article
	printer friendly
	more resources

ARM Yourself for Enterprise App Dev
An architectural reference model (ARM) can help you increase application stability in the face of changing requirements.
by Mark Collins-Cope

July 15, 2005

If you've been involved in large-scale software development for any length of time, you'll recognize these symptoms of application architecture and design decay: You must cut and paste repetitive code (along, of course, with any associated bugs), as proper reuse isn't a viable option. Poor code factoring makes reuse impossible, so any simple functional change must be made everywhere that code is duplicated.

Also, the chaotic package structure of the application means your staff faces a prohibitively expensive learning curve. There's no clarity of responsibility in what package does what. Everyone keeps treading on everyone else's toes when making changes to the system, and the lack of consistent packaging rules makes intelligent work scheduling difficult. Automated testing is difficult as well. It's impossible to test any package in isolation due to poor dependency management; fixing bugs is difficult; and spaghetti-like class dependencies make it difficult to track the source of an error.

All in all, the whole application seems to be unstable, simple functional changes require reworking large amounts of code, and everything breaks all the time.

In this article, I'll discuss an architectural reference model (ARM) for large-scale applications that I've successfully employed on three large enterprise application developments. The ARM is made up of five architectural strata: interface, application, domain, infrastructure, and platform (see Figure 1). The overriding purpose of the ARM is to provide a clear set of rules for large-scale application decomposition that encourages separation of concerns, maximizes reuse of code (primarily) within the application and (secondarily) across applications, leads to good code factoring without duplication, and increases application stability in the face of changing requirements.

To achieve this, the ARM has an easy-to-apply set of rules that bring structure to your application, improved code factoring, increased consistency in packaging rules, and more manageable dependencies between packages.

Each stratum acts as a placeholder for the packages that together will make up the source code to your application. It's important to note that the stratum are not themselves packages, but—as per the rules below—help to determine what should and shouldn't be in any individual package.

The ARM has general rules, which apply across the whole model, and stratum-specific rules, which apply to each stratum. These are the general rules:

• Strata are divided according to functionality and dependencies. Each stratum has an associated set of responsibility guidelines that determine what the packages and classes within it are allowed to do. Each stratum depends on the strata below it; the functionality of the classes within it will be built using the facilities provided by lower stratum classes and packages.
• Depend downward. Packages in a given stratum are allowed to depend only on packages in the same or lower stratum. Avoid dependencies to packages in the same stratum.
• Packages can live only in one stratum. A package that contains some classes belonging to one stratum and some belonging to another is designated to live in the higher stratum. Well-factored applications tend to have a greater number of classes within the lower strata—one objective of the ARM is to put a focus on this type of factoring—so if a package crosses strata boundaries, you should consider restructuring it. Applications with all or most of the packages in the higher strata tend to be poorly factored and often exhibit the problems I discussed at the beginning of this article.