Architecture Principles

Always, it seems EA’s start by coming up with the Architecture Principles a la TOGAF, so I’ve explored this area and have produced some for Swansea University.

I started out looking at a number of other organisations principles, some had just taken theirs pretty much straight from the TOGAF book, others had their own ideas.  One particular (Birmingham University) caught my eye as they had used ArchiMate’s “Principle” Artefact and could therefore tie principles to other Artefacts – Goals, and Drivers.

I also read some of Gerben Wierda’s advice that principles should describe “Good Architecture” and that if a Principle has a lot of exceptions then it is not a good principle.

In general I tried to select single word names for the Principles in order to help with the use of Archimate.

As I started analysing various principle ideas, it became apparent that…

  1. Some principles appeared to apply to the process of running an Architecture Practice, or even other Business Processes rather than the Architectures itself.  e.g. “Information is Everybody’s Business”.  So these were NOT Architecture Principles.
  2. Principles can be faddish or not universal enough resulting in lots of exceptions – e.g. “Cloud First” or “Service Orientation”, or “Agile.   So Agile may apply to some I.T. Services processes, but not in say HR or Finance.  “Cloud First” implies solutions may not be “Best Fit” for all the requirements.
  3. Principles don’t always fit into the TOGAF four layers that well, e.g. many “Data” principles seem to be security focused, and therefore could equally apply to Business, Application, Technology  layers.
  4. Because Principles generally are described by short phrases or simple names, there was plenty of scope for ambiguity – e.g. “Data should be shared” which comes across to me as public availability of data, rather than the intended “single source of truth”.

So I added a few rules to follow…

  1. Principles describe what good Architecture Looks like.
  2. Principles should apply to the majority of architectures.
  3. Principles should be timeless. “Eternal Verities”.

These types of principles can be used to assess the existing Architecture as well as design new ones.

Swansea University Principles are on the iServer Portal

However, having come up with a fair number (probably too many) principles and looking for more within the GDPR world, I realized that many were connected to University Policies, which were in turn underpinned with Principles.  And these in turn were constrained by Legal Requirements many of which start out with Principles.  Obviously, Policies can have much more detail in them that the more abstract Principles.

So the question arises “Should Polices replace Principles for Architectures?”

This entry was posted in Enterprise Architecture, Uncategorized and tagged . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.