EA professionals often specify architecture principles but rarely use them, if at all. In fact, are you using architecture principles in practice? And how, as an after thought tick list or actively during the decision process?
We all have principles that guide our ways in life. They are essentially rules guiding our decision making. Useful indeed. Principles make the hard decision taking process less agonising than it is. They direct you to select an option or follow the order of choice. That saves you time and provides consistency across time and the Enterprise.
Principles may be be expressed as commands/imperative statements, something like the Ten Commandments or Seven Commands ("You shall not steal"). Sometimes they exclude options. Principles are valid though only in a certain context that must be specified. That is, if the conditions are different the principles would not apply.
For principles to work, a governance framework must be defined: the definition of a principle should specify the decision that has to be made, the choices (eventually), the body (role)that makes the decision and the typical use case (when to use it).
To justify usage, the definition of the principle must state the expected benefits returned by the application of the principle (the why, rationale).
Enterprise Architecture (EA) principles though are more than Architecture principles. But this distinction is seldom made.
EA principles could be roughly categorised around EA development phases - architecture, design, implementation, deployment... - or non-technology EA domains such as Information Management or Security.
Architecture principles, a subset of EA, aim to provide simplification, rationalisation, re-use and standardisation of the current "organically grown" architectures (any system has one). That is architecture principles are about designing a "clean" architecture. They are employed by architects and should be applied at a solution design phase. The benefits are coming from the simplicity of the design: managed complexity, reduced duplication, increased reliability, easy to build on and change...
Here are a few Architecture principles (and sub-principles):
• Group functionality in components/modules -
• Employ high cohesion and loose coupling
• Hide implementation behind interfaces
• Use SOA paradigm
• Define services around business functions
• Describe services in catalogue
• Group components in layers
• Do not traverse layers
• A layer shall provide services only to the layer above
or for the EA Design & Implementation phase
• Use web services technology
• Investigate first solution in the Cloud, Buy it or, at last resort, Build it. (Rent/Buy/Build)
"Data is an Asset", is this a principle judged through the above norms? The context is not specified. Data is sometimes an asset but at other times it is a liability. For instance, personal data not destroyed after usage, unnecessarily duplicated or existing in obsolete versions.
In any case, more than a handful of principles would be hard to employ in the real time thinking process unless you use them as a post-thinking tick list, which is not what we normally do.
To ease usage, reduce principles number, make them snappy and group them in categories of application. Care should be taken to avoid overlaps and conflicts of resolution - principles should be orthogonal.