Jiri’s Notepad

This is a final part of the series on project architecture governance. Previous parts introduced the concept, and covered individual governance aspects including accountability, organisation structures, and responsibility.

Accountability, responsibility and organisation structure help to steer the project in line with the architecture and strategy, but on their own they are content-free and probably look like architecture astronautics. I want to bring the subject back to the ground combining previously mentioned elements.

Underneath all the complexity, IT projects are quite simple - you get a customer, agree what you are going to deliver and then deliver what was promised.  Yet the projects repeatedly go astray. “How can this happen,” you may ask, “when we have been doing the same thing for last 20-30 years and now have plenty of goof management techniques?” The answer is simple - It is way too easy to lose focus. Combine a few rounds of re-scoping to get around the technical challenges with some personnel changes and you end up in a situation when no-one remembers what was supposed to be delivered.

Assurance, which I put into the governance bucket, is then a way of controlling that what is delivered. You could express this using the control theory : At the beginning, customer specifies requirements and once the solution to these requirement is delivered, organisation runs an assurance function comparing the results against the original specification:

This sounds rather simplistic, but you would be surprised that some companies do take this approach. Commercial folks love this because it is nice and clean from a process point of view, especially when programme management and delivery are carried out by different companies. Sadly, the price you pay for this simplicity is a higher risk of the project going astray. That’s why it is in my view better to carry out assurance throughout the whole lifecycle, especially before and during the design:

You may be surprised, because most of the assurance activities are not what architects normally do. The key distinction here is that the lead architect (assuming he or she is the real deal is accountable for the existence and effectiveness of the controls, but not be responsible for the execution of assurance activities, which are delegated to various parts of the organisation.

Architecture governance is an important factor ensuring alignment of the solutions with the requirements and strategies and achieving conceptual integrity of the delivered solutions. Even though it is not a silver bullet, it does its jobs providing checks and balances over delivery, allowing people do their job better.