In solution architecture, architecture principles are the primary design rules of a system. They limit the design freedom for detail designers, builders, and users. For instance, an architecture principle for IT infrastructures could be to use Windows as the primary operating system for all servers. This principle makes the resulting architecture better manageable, as knowledge of only one operating system needs to be learned. At the same time, it limits the freedom of choice of components built upon the infrastructure: software only available for Linux cannot be used.
Architecture principles must be defined before starting a new infrastructure project. Usually the principles are generic and exist already. Principles should always be written down, including their motivation (why did we choose for this principle?) and implications (what freedom does this principle limit?).
Apart from architecture principles, design principles can be defined to limit the design freedom even further. As an example, design principles can describe how the naming of servers is organized. This is not architecturally relevant (since it is realatively easy to change later on and it can be decided at a later time), but still very important when creating a new IT infrastructure landscape.
After the implementation of the IT system, it is maintained by system managers, usually for many years. The architecture principles used when the system was designed must be used and guarded during the complete life cycle of the system to avoid instability of the system. Systems managers must therefore be familiar with the architecture principles of a system when they start managing it.
This entry was posted on Friday 12 April 2013