A lot of software systems do not meet some of their requirements and business objectives. Other systems have turned to design pearls only a few architects can understand. In either case you are in trouble. If a system does not meet its requirements or business goals customers will be dissatisfied. In addition, the system cannot be evolved to future versions before the problems are addressed, often causing large and expensive refactoring activities. If a system is a design pearl, it contains a lot of unnecessary architecture artifacts, making the system less expressible and simple. After short or medium time, these systems tend to become big balls of mud.
To prevent such problems there are different means. One of the most important one being requirements traceability. Each architecture change must address a requirement and/or a business goal. You should also clearly trace back the architecture decision to the requirement or business goal in your documentation. Architecture review methods such as ATAM use this information to figure out tradeoff points, sensitivity points, risks and chances of your architecture.
In the optimal case there will be patterns available to support your architecture design. For orthogonality you should apply the same patterns for the same problem contexts. Likewise, relevant cross-cutting concerns such as error management should be explicitly addressed by architects and enforced through guidelines.
Note, however, that architects may come up with the best architecture or the most consistent and complete guidelines, but will fail if the implemented architecture differs from the envisioned architecture. Thus, architects should walk around and communicate to enforce the architecture vision.
Just staying in office, throwing the architecture over the fence, and hoping everything will be in place after a while, is the best receipt for project failure.
As change is the rule and not the exception, architects must always ensure that any change in the set of business goals or requirements will lead to an appropriate architecture refactoring. With other words: if the focus may change and you need to stay in focus, then you'll have to change if the focus actually changes.
