Architectural Care and Feeding

In addition to architectural maturation and evolution, which are driven by features and the capabilities that support them, the development team must also care for and feed their architecture. An architecture is like a carefully designed garden. Unless you tend it, 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 make massiveand very costlychanges to correct the neglect. Architectural care and feeding isn't about adding new features or capabilities; it is about keeping the features and capabilities that you've got in good shape.

Consider the following care and feeding forces that shape the architecture. Many of them are discussed in greater detail in subsequent chapters.

Technological Currency

Every complex application interacts with a wide variety of fundamental technologies. Staying current with technological advances as your product evolves ensures that you won't have to engage in expensive redesign. 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.

Technological Debt

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 on technical issues in order to hit the ship date. More bluntly, successful software teams know when they need a potentially ugly hack to get the system to a shippable state. The problem with hacks is not in the current release (which needed them to ship) but in subsequent releases, when the so-called compromise makes itself known, often exacting a heavy toll to fix it.

These compromises are another kind of technical debt, similar to that incurred when you implement a feature without the underlying capability. Part of architectural care and feeding is paying down this debt.

Known Bugs

Every complex application ships with bugs, which you can think of as pestiferous weeds. Leaving them in your garden, especially when they are big enough to be seen, can take an unnecessary toll on your development staff. Give them some time to fix the bugs they know about and you'll end up with happier developersand a better architecture. You also foster a cycle of positive improvement, in which every change leaves the system in a better state.

License Compliance

Complex applications license critical components from a variety of vendors. As described above, as they upgrade their technology you 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. Watch out though: Wait too long and you risk falling out of compliance with your component vendors . Remember to review each vendor's upgrade. Know when you must upgrade your architecture to maintain compliance. License compliance is discussed in greater detail in Chapter 5.

I invite you to add your own categories for architectural care and feeding. 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 a departmental application designed for 100 users to an enterprise application that can handle 1,000 users or converting an application whose business model is based on an annual license to one based on transaction fees is not the kind of architectural change I'm talking about! Such changes require fundamentally new capabilities and substantial modification of the architecture.