I came across a blog by Richard Veryard on architectural principles. He argues against the importance of SOA/EA principles by stating that “they may have some limited use, but they are not strong enough to bear the weight that is commonly put on them”. This is only true if the architect misunderstand what the architectural principles are or the architect is unable to link the principles with the reality and measure them. How can you measure the applicability or usefulness of architectural principles? I will share with you my 2 cents thought on this.
Enterprise Architecture, SOA or any other architecture, for that matter, needs to be guided by certain architectural principles. Where do these principles come from? Well, in the first place, the architectural principles must support the Enterprise architecture objectives/goals (which in turn must be driven by business objectives or strategies). That means the principles you put together or use to guide your architecture is not just from no where. They have linkages to the business objectives. For example, the business objective may be to be the best in customer service/satisfaction – customer centric. So, the Enterprise Architecture objectives must support that business objective. The principles must be developed to guide to achieving that business objective (customer first). Your architecture will then be guided by those specific principles.
There is a challnge though. Let’s say you have an architecture that is in compliance with the priniples. But, how do you know the architecture get implemented without losing the core priniples? How do you measure the effectiviness of your priniples? Unless you make sure that they are implemented and you are able to measure the effectiveness, those priniples may be disconnected from the reality (i.e. deployed business solution); in which case Richard’s argument may hold. Here is how you may measure:

1. Develop specific guidelines based on those principles. These guidelines are NOT abstract – rather they are concrete guidelines that the solution architects, developers, etc use. The developers may not understand the “abstract” principles. You need to translate the principles into concrete guidelines that they understand. To make sure that a single principle is properly followed, you may have to develop many clear and concrete guidelines that the developers use. By doing so, you are saying that “if those guidelines are followed and implemented accordingly, the principles are followed”.
2. Put together the metrics based on the compliance with those guidelines. Here is where you make sure that your principles are followed through compliance with those concrete guidelines. Here you need a governance process to assess such compliance. How do you measure the effectiveness of the principles? Well, your metrics need to include business related metrics in addition to low level metrics. If the business is happy – you know -:). Your principles are not effective if there are many “exceptions or problems” in complying with your guidelines. In which case you may have to review your principles (or the guidelines that represent them).

If the right principles are developed based on EA objectives (which support business objectives) and the implementation of those principles are followed down to the solution deployment through concrete guidelines (which are meausrable), then priniples are very important for any architecture initiative.

Awel Dico