Architecture and risk. Its about the cost of change.

When developing an IT solution, there is always the risk that a new requirement will break the architecture. That a new requirement will need a significant change to the way the system is designed. The system re-design will take significant time and introduce significant delay. The business investor will be kept waiting for their new BVI which includes the significant change.

There are a number of architectural principles that can be followed to reduce this risk of significant system change.

However, as an architectural principle, when choosing an architecture for the solution, consider the cost of changing from one to another.

Imagine you have a choice between two architectures. They are similar and are both candidates. One can easily and cheaply replaced be by the other. The other cannot be changed easily and the cost of replacement is high. All ealse being equal, chose the architecture that is easier to change.

It may be necessary to create some additional functionality to lower the cost of change.

Consider you are building a web-site for a new business. You have the choice of implementing persistance using a flat file or an Oracle database. The flat file is cheaper and would be ideal if the volumes stay low whereas the Oracle database would be needed if the volumes grew significantly. The ideal solution would be to start with the flat file and then migrate to the database if and when it is needed. In order to do this, the team will need to build a persistance layer to isolate the business logic of the system from the persistance mechanism. Interaction with the persistance mechanism would then be through an explicitly defined interface. Changes to the persistance mechanism would then be isolated from the business logic. The additional cost of the persistance layer should be thought of as an option to enable the cheap and easy change of persistance mechnism.

The application of this approach leads to high cohesion and loose coupling.

The general rule of architecture should be to avoid commitments in the design.