Governance is not an end in itself

What’s the point of governance? What is its role in enterprise-architecture, or anything else, for that matter? Is it anything more than the dreaded ‘architecture police’ – governance for governance’s sake?

These questions came up for me in a passing request by Andrew Gallagher, aka ‘TheWombatWho‘:

• TheWombatWho: @tetradian Wondering if you’ve written blog on ‘architecture governance’? Interested in your views.  Folk seem to see it as ‘end in itself’

As it happens, I’ve written quite a lot on governance – do a search on this blog for ‘governance‘ for some examples. But it’s a theme that’s worth exploring explicitly here – and, in particular, that point about “Folk seem to see it as an end in itself”.

For once, I am going to sing the praises of TOGAF, because this is one area that they definitely do get right – or right enough, anyway. (Yes, a lot of people do get it wrong whilst nominally following TOGAF – but that’s their fault, not the fault of TOGAF itself.) For this, the key sections in the TOGAF specification are chapter 15, Phase G ‘Implementation Governance’ in the ADM (Architecture Development Method) cycle; chapter 23, on ‘Architecture Principles’; and chapter 50, on ‘Architecture Governance’.

(We’ll forgive the reflex lapse into IT-centrism in the latter two chapters, describing architecture-governance as a subset of IT-governance – it’s a howler of an error, of course, but understandable under the circumstances.)

In a way, we really need to read those chapters in the reverse order:

• we first need to understand architecture-governance in general;
• then the crucial role of architecture-principles as decision-guides within that architecture-governance;
• and then apply it within the real-world practice in the respective stage of the ADM cycle.

But either way, read those chapters now, before coming back here.

Given all of that, the first point that should be self-evident is that governance should never be ‘an end in itself’. Instead, governance exists solely to support a business need – or, more specifically, to keep things on track towards that business-need.

This, however, is where it gets kinda complicated. It’s hinted at in TOGAF, where it talks about “a hierarchy of governance structures” and “it is common to have subsidiary principles within a business or organizational unit: examples include IT, HR, domestic operations, or overseas operations”. The catch is that it’s not as simple as a hierarchy – more like intersecting sets, some of which might seem from some viewpoints to seem to be in hierarchical relationships, but from other viewpoints are not hierarchical at all. For example, regulatory and compliance constraints are routine drivers for governance that might apply directly only within one business-domain, but may well impact on ‘higher’ business-needs. An overly-simplistic approach to governance, partitioned solely according to some preconceived hierarchy, may seem to work well within the local context, but can cause serious whole-of-system problems elsewhere. In short, it ain’t as simple as it looks from just reading the book: You Have Been Warned?

Next, what governance is really about, at the most general level, is the same is what I’ve suggested elsewhere is the real ‘Why?’ behind enterprise-architecture: that things work better when they work together, on purpose. It’s crucial to be aware here that the ‘things’ in question, for governance, are not solely those to which the immediate governance might seem to apply – for example, the implementation-processes and outcomes that are the focus of interest in the TOGAF ADM Phase G – but how those ‘things’ intersect with and impact on everything else within the overall enterprise: how those ‘things’ support purpose as a whole.

So where does the ‘business need’ come from? Let’s use the TOGAF ADM to illustrate the point here:

To find the business-needs in scope, we look backwards along the ADM cycle:

• in Phase G, we apply implementation-governance
• in Phases E and F, we identify the change-plan that we’re going to apply that governance to
• in Phases B, C and D, we identify the context and roadmap for that plan, or suite of change-plans
• in Phase A, we should identify the overall business-need and context for this item of architecture-work

Working backwards even further, in Phase H, we would do the review that should help identify the business-needs to be addressed in the next iteration of the architecture-cycle.

But notice two key points here. The first is that we actually need governance for all of these concerns – not solely the implementation-governance that applies in Phase G. (To be pedantic, we also need governance of governance itself – which can get seriously recursive if we’re not careful!) The second is that is that these needs are not so much in a hierarchy as something more like a meshwork – which is why we not only need a form of governance to match, but which is where architecture comes into the picture, as the capability within the enterprise tasked with the theme of ‘things work better when they work together, on purpose’. It’s a mesh: our job is to prevent it collapsing into a mess…

The danger, if we look at it solely in terms of the ADM sequence, is that it’s easy to think of this as entirely top-down: big-picture strategic-intent, to change-roadmap, to detailed-plan, and then to implementation of each individual plan, with full traceability and control all the way back up to the original big-picture intent. That’s the Taylorist dream, in fact: implementation of the grand top-down master-plan. The catch, of course, is that Reality Department has very different ideas about how the world works – especially in the kind of context of wildly-dynamic change such as we so often have to work with in real-world enterprise-architecture. Which is where governance comes into the picture – but not as top-down ‘control’. Not if we want it to succeed, anyway.

The fundamental perspective we need to hold is that governance is not the Department of ‘No’ – it’s the Department of ‘Yes-And…’. It’s not about ‘control’ – it’s about negotiation with the practicalities and demands of reality. Things change, contexts change, needs change, options change, constraints change, implementations change – and all of it is happening dynamically, all at the same time, across an entire architecture. If we think we have any real control over all of that, or can stop all of that change happening, we’d be deluding ourselves, and others, big-time. Instead, we have to work with all of that change, whilst still holding to the initial intent. That’s the real trick; that’s what governance is really about, and really for.

And that’s why we need all those descriptive tools and techniques such as architecture-principles, and enterprise-vision and values: they provide anchors or ultimate reference-points to guide decision-making – especially for the more difficult and challenging decisions, where nothing else seems certain. (That’s a core theme in the ISO-9000 quality-system standard, by the way.) That’s why we need reference-frameworks, and that’s why we need sensemaking tools such as SCAN: they help to guide decision-making when things get uncertain.

A practical example, from our work at Australia Post: three projects all wanting to use RFID technologies, each incompatible with each other, all needing to operate in the same physical space, and one of which would require all of its data actually being owned by an external corporation. The point for governance is simply to point out that each of these is a governance-issue:

• given the core theme of ‘things work together when they work together’, we really can’t allow such a situation to develop with things that definitely can’t work together
• we have an architectural principle, derived in turn from a legal constraint that’s binding on the corporation as a whole, that core enterprise-data must remain under the control and ownership of the corporation at all times

Remember, though, that governance is the Department of ‘Yes, and…’. so “Yes, this is what you each want to do, and yes, you each have valid reasons for wanting to do it this way; and this way isn’t going to work across the whole; so let’s sit down and work out another way that will work better, together”.

As enterprise-architects, what we don’t try to do here is tell solution-architects and system-designers how to do their job: if nothing, else they’re likely to have a much better understanding of current technologies and their capabilities than we do, and we do need to show some respect and humility in the face of that fact. Instead, our role in this kind of governance is to quietly hold our ground in relation to the original plan, the roadmap, the business-need, the principles and the overall vision, emphasising that each of these have their validity too, and should not be overridden casually just to make life a little bit easier in the short-term for individual designers and developers; and to guide conversations about how to do things better, about how to hold to that core theme of ‘things work better when they work together, on purpose‘.

That dynamic meshwork of purpose is what we most need to work with here. Everyone has their own purpose, their own intent, their own drivers, their own reasons for doing things – or wanting to do things – the way that they do. Our job is to acknowledge all of that, respect all of that, and hold people gently to the shared-purpose that underpins both the organisation and the larger shared-enterprise within which it operates – using project-plans, roadmaps, principles, values, vision and the like as guidelines for each of those governance-conversations.

Sure, playing the Department Of No, with top-down diktat and rigid enforcement, always looks like the easier way to do governance, and certainly is much more appealing to architects’ egos. The catch, though, is that it just doesn’t work well at all: all it does is breed annoyance, resistance, and under-the-cover short-term hacks that can be really disastrous in the larger scheme of things – and besides, the people on whom that kind of top-down ‘governance’ is so often inflicted may instead be the only ones who are right. By contrast, respectful conversations via the Department Of Yes-And is what does work: and the outcomes of those explorations often open up great opportunities for the wider whole.

Ultimately that’s what governance is all about: conversations, about purpose, and finding ever-better ways to keep to that purpose, in ways that work better for everyone and everything working together.

Just conversations, that’s all.

Pretty simple, really.

But not easy. Not necessarily. Certainly not always. ‘Simple’ ain’t the same as ‘easy’… 😐

That’s how I view governance, anyway: over to you for your view or comments, perhaps?