I really hesitate to introduce a term like 'meta-governance' but that's what we need - governance of governance itself. Governance can be a barrier to business agility and business effectiveness - if done wrong or with a heavy hand. Governance itself needs to be governed to ensure that we deploy 'just enough' governance to manage real risks and promote real trust in automated systems - even if remembering that 'just enough' probably includes adhering to the letter of all applicable regulations.
Governance frameworks such as COBIT are important, not because they give us a bible that can be imposed on employees (with the implication that employees can't be trusted) but because they provide a reference against which business automation practice can be assessed: are there governance issues that we don't cover and, if so, should we; are there issues that weren't important but now are (so we should now instantiate more of the framework); are there things that we do that go beyond the framework and, if so, is this necessary or just 'gold plating'?
This is becoming an issue today particularly because of the rise of DevOps, which started as a movement when Agile developers found Operations delivery was becoming a bottleneck; and Operations realised that their future was limited if they became seen as The People Who Say NO!
However, if greater business effectiveness is the objective instead of simply more efficient software delivery (and, let's face it, delivering more and more software is only a good career move if that software is actually used by the business to make money or grow the business) then we do need to include 'just enough' governance in the DevOps process.
Despite the views of many developers, 'new' is not necessarily 'good- and software delivery can damage business service levels as well as improve them. Even assuming the software actually works (that is that it "meets spec and doesn't fall over often") - perhaps the spec is wrong (even if developed with agile techniques and with real users on the team, perhaps you got the wrong users) or out-of-date (perhaps the environment has changed and your company hasn't noticed yet); perhaps the new system is too clumsy, or too slow, to be used effectively; perhaps it falls foul of some knee-jerk regulation just introduced.
Sometimes saying "NO" before a turkey hits production is the best for all concerned. Of course, perhaps the adoption of real Agile principles makes producing a turkey 'impossible' - well, rather less likely - but is Agile as you practice it 'real Agile' with all the discipline that implies; and 'less likely' really isn't the same as 'impossible' anyway.
So, in an environment with increasing regulation and where web-based commerce means that the scope of impact of a real turkey could include destroying the business before anyone could react, governance is an important part of DevOps, something which IBM's DevOps story (just one example) appears to recognise.
So what sort of governance do we need? Well, I have a "Sim City" vision for governance, where you explore the behaviour of a developing system in a (controlled) computer-gaming-style simulation environment - this is just one possible option. As you build a new system using a model-based systems engineering approach, you execute the developing system models as a production-oriented simulation of the real business process. There are systems today that help you simulate the behaviour of any external systems or processes you'll need to integrate with, so all of the stakeholders in the new system can play with it and bring up any issues they have well before any code hits production. Participation in a simulation of a developing - evolving - business outcome could even help to facilitate the achieving of an effective feedback loop involving customers and deployed applications and developers.
With a suitably controlled development environment, you could even start collecting evidence for regulatory and safety compliance - even if this was just a framework that needed confirmation after implementation in production, this confirmation should then be quick and efficient, with no surprises.
'Sim city governance' would be lightweight 'just enough' governance and it might even be fun. But it might deliver some comparatively strong governance, in practice; strong in comparison to what IT often achieves at the moment, anyway. For instance:
- If IT governance overall is about delivering automation that is cost-effective and supportive of business strategy and process, without waste, it will rapidly become obvious (as long as all stakeholders are encouraged to play the simulation) if what is being simulated is being gold-plated and/or isn't anything the business really wants. It is much easier to get the business practitioners that can tell you this interested in a computer-game simulation than in a requirements spec - or even a business process model.
- Regulatory requirements are sometimes obvious to business practitioners and not mentioned; and they often make little sense to developers - and then have to be expensively bolted on at the last minute, sometimes impacting any or all of performance, usability and security. This disconnect might be overcome if the appropriate stakeholders could see a realistic simulation during development.
- There's often a similar disconnect between security practitioners and developers, which could again be identified while 'playing' with a simulation.
- Performance testing - end user experience validation - is really only feasible in production, with conventional development. However, with a controlled simulation, the likelihood of performance surprises in production (and, in particular, meeting the sort of performance problems that are inherent in bad design) could be much reduced. You might consider predicting real production performance, with confidence limits, from a good simulation.
- Risk management and risk mitigation should be built into the design of a well-governed system - but, once again, is often a bolted-on afterthought. And, once again, a lack of appropriate risk management is more easily identified in a life-like simulation than in a system spec or formal model.
So, does anyone else think that the availability of life-like simulations, with underlying links to formal systems engineering models used to build automation, would help promote just-enough governance? Governance that could help to ensure that DevOps rapidly delivers into production safe (or adequately well-governed) and effective automation?
