We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Enterprise Architecture Matters

Adrian Grigoriu

Enterprise Architecture principles, let's talk about them

Vote 0 Votes

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.


| Leave a comment

I have looked at these "principles" for many years and it seems to me: firstly that they are effectively constraints (almost like goals, measures of success i.e. something to be achieved ideally) and that secondly they are often opposing constraints. So that what is required in design in an understand of the trade-offs. This turns out to be very complex if tackled from 1st principles so in mature disciplines the idea of patterns is used which effectively encapsulate a set of principles (and materials) to suggest how something can be achieved. I am not convinced that principles in their raw form can effectively be consumed and applied

Hi Adrian,

Where do we draw the line between principle and policy?

A lot of the principles listed above read a lot like policy statements or even 'standards' - for example: describe components in catalogues, use web service technology, etc.

My take is that principles should be:
* minimal: captured on a page
* understandable: by anyone in the business
* durable: unchanging with technology and management fashions/trends
* flexible: not something that you assess compliance against, but something that something can be 'in the spirit of'

It follows that I don't believe principles have a strong role to play once we get beyond the 'enterprise' level and down into domain architecture; policies, standards, reference architectures, and so on shape direction at these levels in a manner that doesn't end up having teams in endless debate about pros and cons.. ok so maybe I'm dreaming on that one :-)

The counter to my argument is that principles end up being so high level and airy that they turn into motherhood statements and lose any potency or value.

Leave a comment

Adrian Grigoriu blogs about everything relating to enterprise and business architecture, SOA, frameworks, design, planning, execution, organization and related issues.

Adrian Grigoriu

Adrian is an executive consultant in enterprise architecture, former head of enterprise architecture at Ofcom, the spectrum and broadcasting U.K. regulatory agency and chief architect at TM Forum, an organization providing a reference integrated business architecture framework, best practices and standards for the telecommunications and digital media industries. He also was a high technology, enterprise architecture and strategy senior manager at Accenture and Vodafone, and a principal consultant and lead architect at Qantas, Logica, Lucent Bell Labs and Nokia. He is the author of two books on enterprise architecture development available on Kindle and published articles with BPTrends, the Microsoft Architecture Journal and the EI magazine. Shortlisted by Computer Weekly for the IT Industry blogger of the year 2011.

Recently Commented On

Monthly Archives