A long, long time ago, in my career days just before being an analyst, I was a software development consultant. I loved doing it — these were the Three Amigo days, full of unified models, cross-functional teams, dynamism and service orientation. Had it not been for the crushing amount of time I was spending travelling (and therefore not seeing my young family), I might still be doing it now.
The job was not without its challenges. Technical complexity, and tight timescales combined with getting people on board and showing them how, yes, drawing things out before hacking code really could speed things up without jeopardising quality. All in all, however, things went in the right direction, but for one difficulty that was near-fatal for a project I was supporting.
I can remember the meeting like it was yesterday. The shape of the room, the large windows down one side, the whiteboard on the wall. Opposite me and to the right was the operations manager for the firm. On my left were representatives of the development team.
Nobody gets out of bed in the morning thinking, “I know, today, I’m going to go out of my way to upset people.” Yet, here was the operations manager, in an impossible situation. “You want it deployed… when?” he asked, shaking his head. “As we said, by the end of the month,” said one of the developers. “But that’s… impossible. It can’t be done,” he said.
He didn’t mean to be angry, but he was clearly frustrated for a number of reasons. That the expectation was on him to make things easy, even if they were not. That he was therefore being put in a position of being the difficult one. And yes, that he would have to work out how to manage the new application alongside everything else he had to deal with.
Of course, he was frustrated because he didn’t understand why he hadn’t been told about the deployment weeks, if not months before, so he would have had time to prepare. But more than this: ultimately, because the situation seemed so unnecessary. How had the organisation arrived in a place where this conflict was even a thing?
It would be great to say that this is the challenge DevOps was set out to resolve, but that isn’t the case. In large part, DevOps is rooted in a world in which bright young things at well-funded startups are building exciting new capabilities on top of highly commoditised, cloud-based platforms: people who haven’t had to suffer the indignities of not one, but thousands of legacy systems vying for attention.
Of course, it was only a matter of time before the notion of frictionless deployment was confirmed as a jolly good idea for brown-field organisations. Which have, as my anecdote illustrates, been tussling with notions of dynamic software development practice for many years, through the waves of eXtreme Programming, Agile development, continuous integration and indeed, the realm of DevOps.
As per a recent conversation, DevOps proclaims to break down the wall of confusion between two technical tribes, each with their own ways of speaking and acting. And who wouldn’t want to do precisely that? Continuous deployment is a laudable goal, as is everything else building up around the pipeline right now — testing, security, data management, performance management, you name it. All help the notion of a single, seamless flow.
But still, when we look at the enterprise (a.k.a. any large organization that has an accumulated technology investment), we find that deploying DevOps itself is extremely hard, if possible at all. As a good friend, a colleague from my consultancy days and now senior developer at a big bank, commented: “I’m fascinated by any large company more than 10 years old that thinks anything like DevOps will make the slightest difference to their ability to deliver business impact through software-intensive systems,” he said.
It may well be that one day, we can all default to massively scalable, managed infrastructure that adjusts itself to the workload at hand, at which point all organisations could be in the same position as startups — though as a senior decision maker said to me, this could be ten years out or further; having said this, we are also looking at a re-distribution wave, following cloud’s impetus to catalyse centralisation, as illustrated by what’s currently termed the Internet of Things.
This, complex and dynamic situation is the starting point for the report I am writing on DevOps in the enterprise. Like the operations manager of old, large organisations are frustrated, as their desire to innovate and push into new areas using software is stymied through repeated disappointment caused by process friction and organisational inertia. Technology vendors may claim to have the answers, but they are all-too-frequently preaching to the converted, as the real challenge — of delivering real, practical, sustainable improvement — remains out of reach.
Over coming weeks, I will be scoping out the development and operational challenges faced by organisations today, and looking at how these can be addressed. The answers may come from a direction we currently label with the term ‘DevOps’, but rest assured, even this is no more capable of being a magic bullet than the technology solutions that purport to deliver on the dream.
So, yes, watch this space. Also, if you have any insights you want to share, let me know. Perhaps, with some thought about what actually works across the variety of scenarios that exist, we can distil out ways for even the largest, most hampered organisations to improve on what they are doing right now, or to move beyond successful experiments into enterprise scale, yet efficient software delivery.