The Governance Apparition

I first noticed the word governance being sprinkled liberally into IT conversations sometime in the late nineties. It was (and still is) used as foundational prop to suggest that, if you have it, all will be well. The word appeared first, as far as I can remember, in Finance and Investment Banking IT - not surprising as financial governance is all about the appropriate exercise of authority and control. The word itself means a method or system of management and so I guess it’s no surprise that you see it, more often than not, in slide packs delivered by consultants.

I’ve always thought of governance and process as being inextricable - process being merely a repeatable and structured way to achieve something, and governance being those elements of the process that give some confidence what is proposed meets some pre-agreed or desirable standards.

A process without governance isn’t actually much of a process at all. I mean, why bother with a process if what comes out the other end isn’t what you want? Or costs too much? Similarly, governance without process is an unenforceable regulatory framework, blissfully ignored by everyone who can do what they like until the company collapses.

And yet there we were, with our nineties haircuts, discussing governance as a standalone concept. Not just as if it were an important idea (clearly it is) but as if we’d never had it before (we had).

More recently there’s been the rise of Architecture Governance and Service Governance. Has life become so easy that we need to make it more complicated for ourselves? I must say I find it tiresome in the extreme to listen to all this twaddle. What was wrong with just having a process, as lightweight as it’s possible to get away with, yet still able meet various quality, institutionalisation and repeatability goals?

Let’s say I want to create a database for some kind of promotional activity. The process might tell that I must first make a business case, to show that the financial return from the use of that database is higher than the cost of building and maintaining it. I can’t even create a Project Brief to start formal proceedings until I can show I have a money-making concept. This is a good, if frustrating, obstacle because it reduces the risk of starting projects that won’t make any money. Oh but look, that’s also governance, because we’ve subtly steered what’s proposed (the database) towards what’s desirable (money making projects).

Process and governance are the same thing.

Both attempt to direct something proposed towards something desired. You could see it as all governance, with process being itemised steps to enforce measurement, or all process with governance being the checks along the way. The result is the same.

A simple way to view the governance/process objective is that it should give the business four chances to prevent something happening that would be undesirable (because it wouldn’t make money, or wouldn’t be in line with business strategy, which as I have said before is never fixed).

In practice there are lots of opportunities to shut down a project, because it can be done on a whim but, megalomania aside, it would normally be because one of the following no longer hold true.

The four pillars are:

1. Business Approval

   All proposals need quite a bit of work before they look like a project.

   To begin with we need to check it’s even feasible. Is this database going to hold master copies of customer data? Add new data entities to the IT landscape? Require stringent security controls? Need specialist skills? Needs skills already in use? Overlap with another proposal? To answer these, and the host of other questions, requires a lot of work. What should result is a well formed idea and a bunch of ‘commitment dependencies’ that must be met for progress to be made. Flexible and engaging technology input is critical here to make sure those commitment dependencies are realistic.

2. Investment Commitment

   Now we know what we need, someone needs to fund it.

   Companies do this through two mechanisms, either periodically at a regular budget committee meeting, or when planning the following year’s activities. The two are not exclusive of course (many businesses make a big plan for the year ahead, then promptly undermine it with a steady stream of unrelated “top-priority” initiatives). But the point is there’s only so much capital budget available for new ideas.

   If there’s a business plan then proposals that most closely support it are likely to be the ones that get this commitment.

3. Delivery Commitment

   Now we have budget, we have to confirm that someone can do it.

   Our flexible and engaging technology involvement during approval should have been used to inform this step - i.e. there shouldn’t be many surprises in form of investable proposals that aren’t deliverable.

   A flaw in many IT departments is that they focus only on this point forward. If a Product Manager has gone to all the trouble of building a business case, influenced and persuaded the power brokers, and stood sweaty-palmed in front of the CFO to ask for the money, they are unlikely to react positively when IT starts whining about lack of resource/engagement/skills/etc.

   Although formal delivery commitment is often required for planning purposes, any initiative that reaches step 2 without this being a relatively straightforward exercise, is a clear sign of a fundamental IT/Business relationship issue.

4. Implementation

   Now we have to do it.

   From business analysis (detailed requirements only, we have a reasonable grasp of this from our consultancy work to assist with the business case) to architects, to developers, to testers, projects managers, systems and database administrators, etc we have to make this thing work without breaching the tenets of the previous checks of business, investment and delivery - if the business changes, the costs go up, or our ability to deliver is impacted, we have to either re-plan or stop.

   Once complete, our final gate is “go-live” or “no-go” - I’ve seen projects put back months at this stage simply because the amount of change going into operations is too great. If too much change goes live ahead of our promotional database we may even have to re-engineer it to fit the as-is architecture.

And that’s it. It’s not process or governance. It’s both.

At appropriate stages we checked that our proposal was good for the business, then that we could afford it, then that we could do it. Even after these questions were answered we continually re-asked them, to make sure the goalposts hadn’t moved without us knowing.

So what about Architecture and Service Governance?

Well for me they’re buried in the description above. What I mean by that is they shouldn’t be overtly visible to the business. The process by which a proposal is defined, sized, costed and architected, and the process to deliver doable projects might generate services definitions and contracts, and give rise to non-functional requirements, but to the business it should just be part of doing business.

I think sometimes IT gets too ‘IT’ about these things and pretends there needs to be all these layers of bureaucracy to make things seem more sophisticated and safe. But I’ve never met a business sponsor who gives a monkey’s about SOA. They would say that it’s simply IT’s job to deliver solutions that meet those four pillars and to do so with as much longevity built in as their unpredictable business world allows.

And they’re right.