Use reference architectures and architectural patterns to assist in making decisions. Good architects know to use
the work of others when making decisions and "a good architecture is full of patterns".
Some decisions relate to compliance with standards and policies. These need to be taken into account when
understanding the context of the problem as well as justifying the decision. Examples of standards and policies which
will affect architectural decisions are:
-
Security and privacy policies. For example authentication, authorization, auditing and non-repudiation
policies.
-
Operations and recovery policy. For example error handling and reporting, recovery and rollback policies.
-
Data management policies. For example persistence, security and privacy policies.
-
Interoperability standards. For example repository interfaces using SQL, JDBC or adapters that interface to legacy
systems.
Making an architectural decision usually depends on experience as well as a thorough understanding of what qualities
constitute a good architecture. Here are some properties to be aware of when making an architectural decision:
-
Consistency - All parts of the architecture are in harmony, and there are common approaches to partitioning and
allocation.
-
Completeness - Everything has been provided.
-
Correctness - Structure and behavior are consistent with governing principles and concepts; there are no ambiguous
properties.
-
Well-formedness - The architecture is well defined, and all aspects can be logically related. All
descriptions should be precise, accurate, and traceable to formal constructs. All architectural components should
be highly cohesive.
-
Orthogonality - Architectural components are independent and loosely coupled.
-
Generality – Architectural components work in other contexts.
-
Extensibility - The architecture can be extended.
-
Transparency - You can use the system without knowing its implementation.
-
Openness – Architectural components can be modified and integrated in alternate ways.
-
Parsimony - There should be "economy of function" and everything should be needed i.e. there is no unnecessary
function or redundancy.
-
Simplicity – A good architecture should be "as simple as possible but no simpler."
|