How to Build a Paper Tiger Governance Board, in 4 Easy Steps

When talking about architecture the ‘G’ word comes up a lot. Personally I hate it. I’ve seen too many well-meaning Enterprise Architecture (EA) teams trying to govern, and all they end up doing is creating a perception that Architecture adds no value. Worse, they are seen as slowing things down. Kicking off an Architecture Initiative with governance is leading with your chin – do you really want people’s first taste of Architecture to be someone telling them what they need to do in order not to stop their project? It flies in the face of the ‘posters on the wall‘ with the ‘content tailored to the audience‘ type of architecture I’m promoting. I appreciate the value of having effective architecture governance – but the road to overblown and ineffective governance is also paved with good intentions.

Organisations that need EA look at the mess of overlapping applications and design approaches all around them and think – “if only we could stop people from just ‘doing what they wanted‘ and all start pulling in the same direction”. And then they think – “some simple governance to check before they go too far, promote a bit of re-use, where’s the harm in that?” Surely these wayward projects would appreciate the guidance? After all it should be quicker to re-use than to start again? And before you can say Technical Design Authority you’ve convinced yourself you need some design principles and a board with a three letter acronym.

The umbrage I take with the above approach is that we need to be talking about spans of control, empowerment, allocation of decision rights, and building architecture communities long before we start enforcing a governance board on anyone. In my humble opinion Governance should be a paper tiger.

Here’s a sensible four step model for Enterprise Architecture led adoption of governance, from scratch, over a period of about 18 months:PT2

  1. First – start with the architecture community. Get people talking to each other, and feeling like a community. Use any means appropriate for the culture of the organisation. Bring them together and tell them what’s going on from a ‘big picture’ point of view – be a messenger from the CIO etc – and talk honestly about the direction of travel for the big components of the architecture.Then – encourage them to start presenting their work – their architecture decisions, not as a stage-gate, but as a sounding board. Value add, but optional.
  1. Then formalise your sounding board to have an agenda, and get three types of regular content along:
    • Big picture materials – for walkthrough and review. (EA supplies these, things like technology roadmaps, business capability models, logical models, etc)
    • Project level changes. (From project solution architects)
    • Principles / standards / maxims discussion. (From anyone, initially)
  1. As things take off – and the volume of materials increases, reduce the scope to just the ‘architecturally significant things’ at the regular meeting, rather than everything. The repeated ‘set menu’ projects that follow the standard patterns that emerge over time, don’t get as much value from the peer review. It’s the ‘a la carte’ items – doing something new, something potentially ‘architecturally significant’, which have the impact.
  1. Finally – show the group your big picture logical models of the Enterprise and ask them to mark up the bits they are changing in specific projects. You could colour code adds, moves, and deletes. Use this paint by numbers approach to minimise the effort for solution architects. This visual mark-up is the basis of a high level design. Then you can adopt the three letter acronym, and call it governance.

I’ve used the above model: a slowly-slowly, community-driven approach to governance. It gives time for Enterprise Architecture to get known for doing useful things first, before restricting the ways people work and the things they do via governance. You need to ‘earn the right’, and by then, the community is already on your side.

Look out for future blogs on writing effective principles, setting up spans of control, and running an effective waiver process.


Related Reading