Home
Architectural Care and Feeding
February, 1999
This article was published in the Cutter IT E-Mail Advisor, February 17, 1999.
An application architecture is more like a carefully designed garden than a series of city streets. Unless you tend to its care and feeding, it will soon become unruly, overgrown with the wasteful vestiges of dead code. Ignore it long enough and you'll find that your only recourse is to engage in massive -- and very costly -- changes to correct the neglect.
Successful software architectures not only describe the fundamental structural characteristics of a software system, they also adapt with relative ease to the stresses put on them by changing requirements and multiple releases. Want to add a new feature? No problem -- as long as the feature is reasonably within the design constraints and goals of the original architecture. Well-defined interfaces between subsystems contribute to parallelism among development teams. Effective subsystem design also isolates external dependencies, allowing developers to make needed changes to a given subsystem without unduly impacting other aspects of the application. Finally, bug counts for successful architectures stabilize over time, and generally remain under control for many releases.
Creating such an architecture does not simply "happen". Successful architectures are thoughtfully planned and prudently implemented through a variety of well-known principles, including low coupling, high cohesion, and information hiding. That said, even the most elegant architecture will ultimately fail unless you take specific steps to maintain it.
I find the following dimensions helpful when considering changes that are designed to address or prevent current or potential problems in the architecture:
Technological Currency. Every complex application interacts with a wide variety of fundamental technologies. Staying current with advances in these technologies as your product evolves ensures that you won't have to engage in expensive redesign efforts. Technological advances are often the key to providing additional benefits to your users. The result? A double-win. (It doesn't hurt your marketing department either, as the phrase "new and improved" will actually mean something.)
Addressing Technological Compromises. Developers are constantly struggling to release the system on time while creating appropriate long-term solutions. Successful software teams know when and how to compromise to hit the ship date. Unfortunately, "compromise" usually means "hack." The problem with such hacks is not found in the current release (which needed them to ship) but in subsequent releases, when the "compromise" makes itself known, often exacting a heavy toll to fix it. Successful architectural management means identifying such hacks and evaluating their potential damage. If the potential for damage is great enough, you must take out your pruning shears.
Addressing Known Bugs. Every complex application ships with one or more bugs. Think of them as pestiferous weeds. Leaving them in your garden, especially when they are big enough to be seen, can cause an unnecessary toll on the sensibilities of your development staff. Give them some time to fix the bugs that they know about, and you'll end up with happier developers -- and a more stable architecture.
License Compliance. Complex applications license critical components from a variety of vendors. In general, as described above, as they upgrade their technology, you'll respond in kind to keep pace. Of course, sometimes you may not need their new technology and are better off directing your development efforts elsewhere. But watch out: Wait too long and you risk falling out of compliance with your component vendors. Remember to review each upgrade from your component vendors. Know when you must upgrade your architecture to maintain compliance.
This list is just a starting point, and I invite you to add your own categories for architectural care and feeding. Finally, be careful not to confuse radical changes in feature sets that require similarly radical changes in architectural design with the kinds of changes described above. Scaling an online application designed for 100 users to one designed for 10,000 users is not the kind of architectural change I'm talking about! Such a change would likely require a fundamental new architecture.