Do Architecture Principles Matter?

Jeff Scott from Forrester doesn’t think so. In his post entitled Principles Don’t Matter, he discussed the challenges with principles. Some of his assertions are:

  • 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.



0 thoughts on “Do Architecture Principles Matter?”

  1. Principles are statements of good intentions yes. But that doesn’t make them not principles. Webster’s provides 13 definitions of the word principle(s).
    Of course you can choose ones that do not fit, but I would choose the one that does which is “guiding sense of the requirements and obligations of right conduct:”
    Principles come from 2 sources. 1 if best practice or accepted wisdom, e.g. buy before build.
    Principles are not hard and fast, if there is good business reason not to comply with a principle in a particular instance then that should not be a problem. It does not mean that that principle is worthless. E.g. Buy before build is generate, but if enormous business advantage can be gained by building over buying then why not.
    Principles are easy to govern, monitor and manage. Part of the management is the enterprise debt non-compliance creates.
    It’s all documented in the “Process” document in the governance section here and a set of these standard principles can be found at the same location in the “Principles” document.
    It’s not complicated.
    The 2nd set of principles are organisation specific and come from modelling and understanding the target state of the enterprise.


  2. Of course EA Principles can end up as shelf-ware or nice decorative posters on the wall. I’ve seen this as well.
    To be effective, the use of the EA principles needs to be built into the EA processes for governance, compliance, design assurance of the subsequent programmes, business changes, new solution developments etc. Decisions and business cases are strengthened by compliance with the principles. Where there are conflicts of interest between two solution development projects, then the EA principles become a way of deciding the way forward. If proposed changes do not comply with the principles then they can be denied.
    I’ve generally regarded the set of EA (and other IT) principles to be a sub-deliverable that is a component of the IT Strategy. This positioning gives them extra relevance and visibility within an organisation.


  3. I do want to say that I don’t want to lead my readers to say I don’t think principles are valuable. They are, but need to be built in a way that is actionable to the architects that are to use it. Principles are a great way to show alignment with the business to qualify our architecture decisions. However, it doesn’t take away the challenges that are mentioned in this post. Mitigation strategies will need to be in place to ensure these common pitfalls do not happen in your enterprise.
    Perfectly stated! I think that we are more or less saying the same thing in regards to the opportunity for principles. The point you make about them being tied to strategy is a key one. It links principles to something actionable. That in my opinion, has been one of the major flaws in principle development. If a set of principles are created alone and not directly tied to strategy they are doomed to fail. I also agree that they need to be built into decision support. I talk about this a bit in previous posts on architecture trade-offs and qualification of architectures using structured methods. These all hinge on having the right principles.
    I agree in theory but this is too high level. There are very clear challenges with the implementation of principles. I have seen it over and over again with major EA organizations. The ones that do succeed are the principles tied to something tangible.
    If you have a moment, I would like to hear how you have mitigated the challenges addressed in this post. Again, I am not personally questioning the value of principles necessarily, but rather how they are built and implemented.
    Thanks to the both of you for taking the time to provide feedback!


  4. A different take on principles….
    In any enterprise stuff changes – the people change, the technology changes, business processes change, funding changes, projects and programmes change rapidly, strategies change – even the organisations involved in the enterprise can change.
    What defining characteristics of an enterprise do survive in a world of constant change – change facilitated and promoted by Enterprise Architecture?
    In the end principles and purpose are all the enterprise really is – the rest is flux. Principles are transcendent – they are above the flux. But they are subjective – and so need to be written down and communicated. If your principles turn into ‘shelfware’ – they are not really your principles – your enterprise is not living by them – it may even be unprincipled.


  5. Critical part is where you illuminate the distinction between a principle and a strategy. Most of our ‘principles’ aren’t principles at all. They are statements of intent, desired strategic objectives or an elaboration of the vision statement. Great stuff.


  6. Enterprise architecture principles are there, being followed or broken explicitly or implicitly by all organizations all the time. Writing them out is a good practice, but not the end of the story. Implementing them is a challenge in all organizations, since the EA program is a city planning without a zoning office in most organizations. So EA has little authority to implement the principles, regardless how well written the principles have been. Architects have been very creative to use many different ways to insert themselves into the organization processes to apply the principles, but it is an uphill battle. This difficulty doesn’t make principles useless.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s