Ungoverning the Business

If there’s one aspect of enterprise IT guaranteed to get the dander up it’s Standards and Governance. Some time ago I wrote a short piece on governance called The Governance Apparition making the point that governance should never really be seen as separate and distinct from ‘doing things’. If a company has a process for ‘doing things’ and an internal body (usually architecture) tries to ‘govern’ the outputs of that process the governance will fail.

It will fail because it’s almost impossible to avoid making governance look like a hindrance to delivery. Delivery is hard enough; nobody appreciates bolt-on processes that make it harder. That’s not for a moment to suggest governance is a bad thing. ‘Doing things’ is not enough to make IT successful. ‘Doing the right things in the best way’ is what it’s all about and governance provides the checks and balances to make sure, as far as is reasonable, some sense of right and best exist so interested parties can see what they are getting into.

I called it the Governance Apparition because, when it’s done by a team that’s not engaged with delivery, all the documentation and process and meetings and sage words serve only to create the illusion that it’s having an impact on output quality. Delivery teams deliver the same things regardless of governance. Sure, they might show up to meetings and debate the rights and wrongs of what’s in train, but whilst that’s happening delivery carries on. Very, very, occasionally a business might trash a software stack ready for production because it doesn’t meet the standards laid down by a governance group. I say ‘might’ because I have never seen it happen. What actually happens is the business weighs up the lost investment and the lost revenue from not going live as soon as possible against the sleepless nights they are going to have over not complying with a bunch of standards they never really understood in the first place.

Let’s see ..

Option A - Comply with Governance

Get shouted at by your boss for wasting the company’s money on building throwaway software and delaying the realisation of business benefit. Then spend more money and delay the project to comply with IT standards.

Option B - Ignore Governance

Or rather play the governance game until it’s either too late to make changes or you are begrudgingly handed a dispensation to go ahead anyway.

Even assuming that the software is in some way crufty, for a business sponsor (a) obviously equals the career-limiting option and (b) equals making it someone else’s problem at a later date. The answer is invariably (b) and the response of governance groups, after a few days of despondency, is invariably to create yet more elaborate documentation and process and meetings and sage words to make sure governance works next time. Ironically the result is that it becomes further disconnected from delivery and is less likely to work next time. More governance, less control.

My answer has always been to forget governance and focus only on defining a lightweight delivery process that contains a minimum set of checkpoints. Nobody minds checkpoints in delivery because they exist anyway: do we know what our scope is? Have we got the right budget? Does this demo look like what’s actually needed? Weaving a few subtle extra questions into this isn’t hard, and doing so acknowledges an important fact - everyone wants to do the right things in the best way. Right and best are not the preserve of architecture and it’s offensive to everyone to position governance as existing to [police naughty developers](/article/law-and-order/ hell-bent on doing the wrong things in the worst way.

But how can governance be lightweight? Lightweight governance might sound to some like an oxymoron. If you work in corporate IT and you have governance structures I am willing to bet nobody ever calls them lightweight. I think the answer lies in some radical thinking.

Let’s all stand up, shake our arms out, relax and think radically for second.

Governance exists because of standards. Corporate IT needs standard tools, models and ways of doing things so that everything doesn’t become a big gnarly mess with twenty different places to store similar data and seventeen different ways of integrating a new system to get at that data.

Oh wait .. if you work in corporate IT could you just go and grab a picture of your architectural landscape? No need to show it, you are among friends, we can respect commercial sensitivities.

OK.

Let’s go back to the idea that without standards you’d end up with a big gnarly mess.

Now take a look at your picture.

Sorry? Didn’t catch that through your tears. It’s a big what?

Relax. Let it go. You have no standards. You just thought you did.

Shall I tell you why? It’s because standards don’t work. I know. I said this might get a bit radical. Standards are fool’s gold. Say it with me. The truth will set you free.

Just as the idea for governance is a good one, so it is for standards. Standards make sense until the very moment you try and create some. There are lots of reasons for this but principally it’s because you are trying to encapsulate some sort of canonical, authoritative, guidance for future development based only on what you know (hindsight) and what you think will happen (guesswork). It will take you too long and it will be wrong. When you come to govern the use of standards they will be unhelpful to delivery projects (because of the gaps) and they will be irrelevant (because most likely the standard won’t fit). And what you really, really, need to avoid is a conversation where the delivery team talks about meeting the business requirement and the governance team talks about meeting the standard.

So should we just give up? If governance and standards don’t work you could just leave the hindsight plus guesswork activity to development teams. Many places do and it can certainly work for smaller environments. Not for bigger corporates though. Things like changes in personnel mean that over time each project will adopt its own way of dealing with things and at an enterprise level this has a cost to the company. The subtext that each project should leave something behind to make the next project a bit easier is a good one. And therein I think lies the answer.

At the recent Future of Web Apps (FOWA) conference in London, Francisco Tomalsky gave a short but thought-provoking presentation entitled “Web Apps State of the Union” (I can’t find a link but will insert one here if I can source one). He was talking about web applications and the threat to all the good work that been done over the last ten years by the advent of the modern mobile web. Particularly from native apps on devices like the iPhone which are not web apps per se but proprietary data-service consumers. He made a great point that an argument not to get into is whether it’s better to be Open (web apps) or Good (native apps). Open has all the right intentions but relies on standards, or at least it thinks it does. The problem is standards done badly (as they are) hinders the kind of progress we’d like to see, which means Good will win. But it will be the wrong kind of Good. The kind of Good that works for now but pretty much disables interoperability later.

Seeing any parallels? IT governance is all about standards-based openness (and failing) and governance/checkpoint-free delivery gives you Good, but at a price later.

And yet there is a world where good and openness work together. One that doesn’t have the kind of progress-killing bureaucratic standards we associate with enterprise IT governance. It’s called the Open Source community. I’ve always thought corporate IT and open source could work together. In Embracing the Third Way I made a case for it (the first way being ‘buy’, the second being ‘build’ and the third being ‘engage with an open source community’). Corporate IT has money and requirements and open source teams have the smarts and the freedom to innovate. An interchange of code is possible without either having to dilute the culture of the other.

And, as Francisco Tomalsky said in his presentation,

in a world where you have true open source, you don’t need standards

Of course there are standards in open source, they just masquerade as accepted practices and archetypes. The difference is community and forkability. The creators of projects engage in a community process, partly through the code and partly through user groups. Patterns of accepted practice evolve, but these are constantly questioned in the groups, especially by noobies who often elicit the best kind of debates. Where a pattern doesn’t fit a localised requirement the code base can be forked and adapted. If the changes have wider appeal these changes are integrated back into the core so everyone benefits.

Now look at your enterprise landscape again. What would you settle for? A continued struggle to force the adoption of standards that will rarely succeed (and make you enemies in the process) or a more enlightened existence where standards are rejected in favour of practices which are constantly debated as part of their acceptance and more importantly forked and merged to give them life.

Notes

• The artwork, used with permission, is called “Still in business” by Graham McKean. Unfortunately you can’t buy that one but you can find other works for sale at The Leith Gallery, Meridian Art and the Arran Art Gallery. Many of Graham’s works have quite distinct themes to them, this one is taken from a series that you’ll find portraying besuited people in some quandary or other.

• The subtitle is from the classic 1948 film The Treasure of the Sierra Madre and is an often misquoted line