This article invites organisations to do to their Risk and Governance functions what DevOps has done to traditional IT Operations: Transform those areas from being necessary operational expenditures and stage-gates to being competitive advantages.
Two failure modes
In organisations we work with, we often see two different failure modes. The first is hierarchical command and control through dedicated groups — architecture, security or service management being the most common — that have a massive impact on speed of delivery. These groups often maintain strict lists of approved tools and rigorous control gates for reviews at various stages. The second is at the opposite end of the spectrum: delivery teams doing whatever they want with close to zero governance imposed on them, often resulting in chaos, and a sprawl of tools and processes used across the organisation.
We find these two failure modes often reflect organisational culture and growth patterns.
Start-up and scale-up organisations tend more towards zero governance; sometimes because it hasn’t made it to their priority list yet, and sometimes in a deliberate effort to differentiate themselves from big corporate environments that tend more towards tight control and rigorous implementation of governance frameworks.
As those smaller organisations mature and grow, they often find themselves moving from zero governance to implementing “too much” governance with little regard for trying to find a middle ground. We also see the opposite trend of traditional organisations throwing out all governance as they attempt to modernise and accelerate, focusing purely on speed rather than on how to bring speed and quality into virtuous alignment.
We advocate moving away from those extremes and finding a new middle ground. Ideally we're looking for the combination of techniques that ensures organisational risks and opportunities are handled while still giving teams as much autonomy as possible within those constraints.
The need for responsive governance
Modern software delivery paradigms
The way we're designing, crafting and delivering software is constantly evolving. As of today, we know some things to be working better than others:
- Building technology platforms that support incremental, constant change over time
- Delivering through cross-functional teams that are aligned to business outcomes
- Giving those teams end-to-end ownership and accountability for code from delivery to operations in production
- Favouring architectures that are appropriately coupled through modular design
- Optimising for both high delivery velocity along with quality.
Many of these preferences are based on a subtle but powerful observation: we’ve recognised that increasing the speed of delivery and improving quality aren’t conflicting goals, but rather mutually supportive. While this is not something that’s particularly intuitive for many people, the team behind DORA has collected a lot of supporting evidence over the years that this is the case.
Traditional governance
Organisations need to satisfy many different stakeholders. They employ governance as a means of achieving their strategic goals and staying within an appropriate risk appetite. IT governance as a subset specifically aims to provide a structured approach to align business strategy with IT strategy, identifies and addresses risks and ensures an organisations’ compliance to laws and regulations.
All of those goals are fundamentally aspects of quality, the axis that traditional models of IT governance tend to optimise for. Organisations often employ technology governance via frameworks and certifying standards like ISO27k1, COBIT, TOGAF or ITIL/IEC20000 in some or all of the following areas:
- Audit and compliance (Including regulatory compliance and legal risks);
- Risk and information security;
- Software architecture: alignment with strategy, coordinated action (cloud-migration, monolith-splitting) longer term roadmaps, scaling, performance, resilience etc;
- Cost (funding models, budgets);
- Business continuity and disaster recovery;
- Quality, change and release management;
- Project and programme management.
There are a lot of positives about those frameworks — after all they’re the collective memory of all things that have ever gone wrong in a large number of organisations. The way they’re implemented, however, tends to be inappropriate for modern, responsive organisations:
- They’re very infrequently updated (ITIL got its first update in eight years in February 2019)
- They tend to be fundamentally designed for traditional delivery and operating models, reinforcing silos
- Rollouts tend to happen big-bang for entire organisations
- They’re non-responsive to change (static or changeable only by committee).
Getting it right: governance as a competitive advantage
While most standard IT governance frameworks acknowledge that their implementation should apply the least amount of friction possible, they don’t identify the great potential of responsive governance.
Moving at the highest possible speed of delivery while maintaining the highest amount of stability allows us to “steer the ship — but avoid the rocks”, making the application of such a governance framework a major market differentiator. It would give organisations the confidence to move at the right speed while not exposing themselves to undue risk.
The following sections describe effective strategies for creating this dynamic approach to technology governance, summarised in six principles:
- Move from mandate to vision and principles (and guardrails)
- Automate and delegate compliance
- Enlist gatekeepers as collaborators
- Provide paved roads
- Radiate information/rethink your communication patterns
- Get comfortable with evolution.
Governance Principles
P1: From mandate to vision and principles (and guardrails)
Governance is largely concerned with setting the direction an organisation intends to move in, and then verifying that it’s actually doing so. Most modern technology organisations have realised that they get the fastest delivery throughput by organising themselves into reasonably autonomous units, both in terms of teams and architecture. The challenge is how to specify the desired direction in a way that doesn’t nullify the speed gains of allowing teams high levels of autonomy.
Our favoured approach is moving from mandating specific tools, protocols and solutions to framing a higher level vision with a set of principles and constraints, which still leaves a good degree of autonomy and creativity on how to fulfil them.
There are some good examples of architectural or engineering vision statements: