The initial Vision of the architecture degenerates toward chaos
The degradation of code through the cumulative effects of a series of small changes is well known. Architecture suffers similar problems.
The importance of getting the Architecture of a system right first time has long been acknowledged. Most methodologies now recognize Architecture as a major risk area. Typically, Architectural issues will be addressed early. An architectural proof of concept may go through two major phases; first a selection of one or more likely candidates and a demonstration that the architecture works for ‘happy day’ cases, then a rigorous test to ensure the architecture can handle the worst of the known requirements.
Modern Agile methods recognize the impossibility of eliminating change to requirements, and the potential impact this may have on the Architecture. Architectural Degeneration is usually caused by the need to adapt to changing requirements. Here, the risk of not getting it right first time is addressed.
The underlying problem with the traditional approaches is that there is a fear of change. This probably originates from the RippleEffect, and as a result the development teams are constrained to alter the code as little as possible to provide the required change in functionality. Ideally, after a change in functionality, the code should appear as if that functionality were always intended. This may require a certain amount of re-arrangement of code in addition to the changed functionality. Where this re-arrangement does not occur, the code and architecture will degenerate.
Two traditional approaches to this problem are CodeOwnership and OwnerPerDeliverable, both patterns from the Bell Labs site. These concentrate on ownership of concept, in order that the concept may be kept pure by single ownership. We may classify these as amelioration. A partially effective preventative measure is the Architectural Spike (the early addressing of architectural issues) that is in existence in some form in most methodologies.
Modern methods include SystemMetaphor and ConstantRefactoring. These are used in the context of XP where DevelopingInPairs aids in dissemination of a common understanding. The system metaphor is a simple, unifying idea, possibly from a totally unrelated domain, that acts as a focus for all development and provides the skeleton of a solution on which the details can be placed. ConstantRefactoring, when performed correctly and with a common understanding of a big picture for the system under development, can ensure that the architecture evolves to keep pace with its requirements, and is a truly curative approach. SystemMetaphor is a preventative approach to replace CodeOwnership where CollectiveOwnership is deemed desirable.