Architecture principles and enterprise architecture sometimes seem inextricably intertwined. Where there is an enterprise architecture department, there always seem to be architecture principles. Partly, this is due to the much-used ‘architect as city planner’ analogy, partly, I can’t help suspecting that it’s something that can be done without too much engagement with the wider organization (which is a different thing entirely from saying that it *should* be done without too much engagement from the wider organization).
Now, some, notably Gerben Wierda of Mastering ArchiMate fame have stated that architecture principles are more often actively harmful than actively helpful. I’m inclined to agree with him that if, as he states, architecture principles become just another club to beat people over the head with, then that’s right. They can also end up failing at the other end of the spectrum, by being toothless. A principle such as ‘architecture should aim to maximize value to the business’ is hard to disagree with, but it’s what an American manager would call ‘motherhood and apple pie’ – completely un-actionable precisely because it’s impossible to disagree with.
But’s let’s assume that that the architecture principles are actionable, and that they are being used sensibly. Another desirable quality for principles is traceability – traceability from business drivers and traceability to actual decisions.
Let’s start with the first one. It’s always worth asking why we are performing a particular activity, and if an architecture principle is being applied, then it’s worth being able to justify why the principle exists. This is especially so when the activity in question is requiring people to change their behavior in some way – it’s a natural human reaction to question why they should be required to do so.
So it can be quite useful to be able to justify each principle, and the best way to do that is to trace the origin of each individual principle to the business driver or external regulation that brought the principle about. A good way to do this is a motivation model, both from the standpoint of ‘eating your own dogfood’ (no point in creating models if you can’t model yourself), and because a picture paints a thousand words.
Now let’s talk about traceability to decisions. It’s all very well to have a principle, but it’s a good idea to understand if they are having any effect. In other words, does a principle ever get applied to projects? I it helpful or do projects always get an exemption to a given principle? If it’s the latter, then what is the point in having the principle in question, unless it’s to simply pad out the principles catalog?
I could be persuaded either way on the value of architecture principles – as is so often the case, the devil is very much in the details. Principles need to be effective and they need not to be a pointless cudgel. Being able to trace them upwards (to business drivers and external regulations) and downwards (to project that they affect) is one way to help achieve such a goal.