Where are you on your DevOps journey? First let me say that if your large-scale corporation or public body already has this DevOps thing nailed, feel free to stop reading now, and indeed I'd love to hear from you about what you did.
For the enterprise organizations I speak to, DevOps is something that happens in pockets. Smaller, newer businesses have the benefit of a lack of scale, which means things can happen fast out of the gate. Keeping things small, against all odds, is a route to success: on one software project I was involved in, with hundreds of developers, I wished I could take ten of the people involved and hide them away. That way, I thought, they could build the product everyone else was working on (and which, ultimately, was never delivered). But even had I succeeded, there would have been a point where the team had to engage with the wider world.
The fact is that DevOps is not "the easy path in a world where everything else is hard," and it is never going to be. Sooner or later, even small teams have to grow; external collaborators have to be involved; and larger strategic needs have to be encompassed. In a previous blog I talked about the importance of visibility, the ability to measure, and thus set direction. This is one tool in the toolchest for development organizations looking to grow, but it won't create a magical oasis of success in the middle of an organization that doesn't want to change.
And meanwhile, a bunch of other things need to be taken into account. Risk management, security and compliance cannot be ignored until the end of the software lifecycle. Complex requirements need to be managed and maintained. Modern architectures need to work with existing applications and legacy data. Infrastructure choices are a swirl of cloud providers and in-house services. Teams are neither in-house nor outsourced, but somewhere in between as businesses look to recruit engineers. A wide variety of stakeholders need to be involved, their views and priorities not only heard but responded to. The list goes on.
Time is not on anybody's side, due to another factor, writ large by the current pressures of Covid-19: that businesses are growing increasingly impatient with their IT organizations, or more specifically, with their rate of delivery. Those new features that might bring new business at some point in the future? Yes, they've moved up the priority list overnight, and have become perhaps the only thing that might keep the organization afloat. I may be overstating things but you get the picture.
As a result we see software teams reflecting dual, and indeed conflicting personality types. There's no route back to waterfall models with two-year cycles; meanwhile, the aspirational goals of DevOps-type models are great in principle, but imply too great a mountain to climb. So, we see sprints and scrums, CI and CD terminology being used, even as managers revert to linear practices and coping strategies. As a general trend, bluntly, we are not on a path to DevOps success, any more than we are on a path to SEI CMM Level 5 optimal delivery. And just saying "Do more DevOps" is not going to cut it.
Don't get me wrong: I'm more optimistic than disheartened. I have it on good authority from organizations I speak to that the principles of DevOps are sound: for evidence, here's an interview with Harbinder Kang, Global Head of Developer Operations at Finastra, who has seen a great deal of success from engaging with development teams, applying the right metrics and building on success. For this kind of story to be scaled pan-enterprise however, we need to take into account the needs of large-scale organizations by design, rather than treating these needs as annoyances that get in the way of progress.
DevOps doesn't need to change its core principles, but the way we approach delivering on its goals needs a rethink. DevOps cannot be imposed on the enterprise, any more than the methodologies and best practices it has superseded. As someone who has been involved in many of them, delivered the training, offered the mentoring and most importantly, seen the green shoots of success, I have a vested interest in this.
While it can't simply be dropped into an organization as-is, DevOps can nonetheless mature and evolve in how it embraces the realities of larger organizations: not least in all their glorious complexity, their collaborative nature, and need to deliver compliance at every stage. These are not "shift-left" add-ons, but core elements of how DevOps success needs to be measured, and built upon. For more on this, you can draw some comfort from looking at how safety-critical environments (such as healthcare equipment) can nonetheless act in an agile, innovative manner.
So, alongside where you are on your DevOps journey, I would add another question: where is DevOps in its own evolution?
I see areas such as Value Stream Management as both success factors and illustrators of a best practice approach that is maturing in its own right. Above all, I would not be disheartened if you are finding that DevOps is not working for you, for two reasons:
First, innovation will always be hard, and rapid change in a complex environment is inherently stressful.
Second, the practices, tools, and platforms upon which you stand also have their work cut out if they are going to meet your needs, against a background of fast-evolving infrastructure and an increasingly demanding business and customer audience.
So, hang in there, keep the faith and work on getting the basics right, even as higher-order best practices gain a better understanding of enterprise needs and change accordingly. We all have our work to do.
