Image source - State of DevOps Report
Most organisations are stuck in the middle of the DevOps maturity model, and security and platform thinking emerge as valuable trends
The annual State of DevOps Report - and the related book 'Accelerate: The Science of Lean Software and DevOps' - are influential publications in Foundry4-land so we are always interested when the latest edition lands.
While it is always useful to read about the new trends they have identified via their research (and this year's are particularly interesting) the real jewel in the crown is the way the report provides a benchmark on the uptake of DevOps approaches and where our thinking (and clients) sit within this.
Of course, no maturity model is perfect, but this DevOps Evolution Model maps tidily to the majority of our experiences working with clients to develop their DevOps and Agile practices.
A feature of this year's report, which has been consistent since 2018, is that the majority of respondents still find themselves 'stuck in the middle', hovering around Stage 3 of the model, with a good level of autonomy in their DevOps teams but more work to do around automation.
Our own experiences are much more context-dependent. In the last year we have experienced everything from set-ups that would not even be considered Stage 1 through to operations that are exemplars of Stage 4 working.
Given a 'greenfield' opportunity and a fairly clean slate to work with, our instincts naturally lead us to a modern, lean software approach that leans heavily on automation and product thinking - and maps nicely to Stage 4. The reality though is that our teams often face 'brownfield' environments with fragile legacy infrastructure, processes and risk aversion. Even moving these kinds of services onto the DevOps scale at all is challenging, as it involves a lot of ground work, changing attitudes, and introducing new practices. But it's especially rewarding when successful.
This year's trends - as we see them
Two trends identified in this year's report - the internal platform approach and changes as code - are interesting but remain primarily aspirational for most organisations.
First - the internal platform approach, where according to the report
'..the platform team provides the infrastructure, environments, deployment pipelines and other internal services that enable internal customers — usually application development teams — to build, deploy and run their applications.'
This ‘self-serve’ approach empowers teams, removes friction from delivery and speeds up outcomes. There are elements of it we already adopt, and this practice will grow. However, it requires a level of scale and investment that is beyond most pre internet-era companies to be effective right now.
Second, a change management approach which sees changes written as code. This requires a significant shift in thinking and process that is likely to be a slow burn in many organisations. It involves a transition from procedure-driven, people powered change management (that shares risk at the cost of velocity), to a situation where trust in automated testing and code quality is such that teams are empowered to decide when and where to iterate. This is a major culture change - one worth fighting for but unlikely to be won overnight. For now we continue to prepare for this future by building environments that are ready and waiting for this culture change.
What's relevant now
More immediately interesting is the call for genuinely embedded Security capability in multi-disciplinary delivery teams. This is something that has been just below the surface for some time and is rightly now getting more attention - its time has come. Why? Because integrating security fully into the software delivery process improves your ability to quickly remediate critical vulnerabilities.
It feels like everyday there is another data breach or high profile website getting targeted by people with ill intent. This is not a problem that can be swept under the rug and bringing security thinking in from day one limits attack surface areas and increases capability to respond if the worst does happen. This provides a better service but also increases trust in the delivery approach, giving organisations reassurance and justification for moving to these modern, cloud based environments.
While we might not be totally embracing the 'platform' approach as outlined in the report, we are fully committed to another element the writers have identified. We very much see ourselves as a software organisation with a deeply embedded product mindset.
Where the report talks about:
- The platform team gathers requirements from internal stakeholders
- Someone on the platform team acts as a product manager for the platform(s)
- There is a roadmap for the platform
- The platform team provides onboarding help
- The platform team tests new capabilities with the teams that will use them
...we recognise this in all our work. Even where our people are not acting in a product role this kind of thinking is at the forefront of their approach, whether they are engineers, designers, in quality assurance (QA) or delivery management.
In particular, we believe that internal systems need to be treated with that product mindset as much as externally facing products or services. It's therefore great to see this acknowledged as something key to a successful DevOps organisation.