- Principles are not really principles… Instead they are mostly good intentions.
- Principles are passive. A principle sits there until something comes along to test it.
I have to say I agree with Jeff on his assessment. Coming from large organizations that have implemented Enterprise Architecture I have seen this quite a bit. For example, I have seen very large EA organizations create the master set of principles that took them a better part of 3 months worth of very senior talents time to then proceed to frame them on a wall and never to be followed again. This is obviously an extreme but I have seen this behavior at more than a handful of organizations.
My opinion on issues with principles are:
- They are subject to interpretation by the architect. Meaning that since principles are very high level there is a lot of room to make an interpretation.
- Effectiveness hinges on the competencies of the architect.
- Is an all or nothing implementation. Meaning, if only a select few architect follow them and the rest don’t this breaks down.
- What is a principle any ways? Jeff Scott eludes to this when he makes reference to: “buy before build” principle? Isn’t it really a strategy?".
- The problem is that the term principle is too generic and means different things to different people.
- There are issues of abstraction and scope.
While there are issues, there are positives about principles as well. I would caution folks looking at building a robust set of principles from scratch in today’s economic climate and pressure on IT. I definitely wouldn’t recommend a multi-month organizational soul searching exercise on what are my company’s principles. What I would recommend is similar to Jeff’s assessment. Build out a set of pragmatic principles that are actionable and relatable to your IT strategies. Make the higher order bit the strategies rather the principles themselves.
Tags: Enterprise Architecture