Governance is a way to manage risk.  The risk of bad investments in IT, the risk that current solutions go sour due to inappropriate direction.  Others.  These can be mitigated by setting up some rules (Strategy, Policy, Standards) and having the Program Management people make sure the implementation teams follow the rules … perform ‘vitality checks’ to make sure the aforementioned ‘rules’ are still relevant in the face of changes in business intentions, competitive environment, new technology … any other factors.

So, “Governance” can be generalized as “Architecture Review Boards”, but must have the foundation of managed statements of Strategy, Policy and Standards.   Any mature process has the pattern … Say what you’re going to do, Do what you said to do, and make sure you continue to do what you said … and check to see what you said is still relevant to needs to evolve.  (See the article on Communication, Compliance and Vitality)

But there’s more to be done in documenting architecture decisions so they can inform downstream decisions 12 months later.  There’s more to be done with ensuring that Enterprise Architecture strategy, principles, standards and roadmaps guide Solution Architecture reviews. 

This is where you get away from the architecture review board being a casual and unprepared meeting where a Solution Architect or Development Lead shows up with some slides and gets to find out what some guys in a room think.   That’s how architecture governance is done in many places.   The problem with that model?  Couple of things … First, the most powerful voice in the room leads and alternatives are not even suggested  And second …  the guys in the room might be different six or twelve or 18 months later.    Nothing is documented, there is no lasting record of ‘architecture decisions’ and even if so, those decisions are not thoroughly documented with alternatives, rationale for choosing or not choosing them, trade-off analysis, any other than very cursory cost analysis.

How much staff work would be needed to do these architecture review boards, supporting analysis, supporting documentation?   A bunch more than a casual meeting.  So, an organization has to decide how much to spend on architecture governance.   How much staff support.  How much time of architecture leaders, development team leads, project assistants, business analysts, etc..   Evidence from recent history of an enterprise’s experience with solution decisions, and how they fit into the enterprise architecture management process.  Whether gaps in Solution Architecture practices have caused any failures, wasted time or money.  It would be wrong to blindly apply some industry best practices at great cost in staff effort and even extra FTEs.  But it many cases, it would be wrong to do nothing. 

Finding the right level of effort can benefit from experienced outside consulting.