Quest for the One True DevOps, Epilogue: There and back around again, DevOps should listen more to customers
Video: Doing DevOps: Tips for getting software development right
"Digital transformation" may be as old as digits themselves. Part of the problem with good ideas in IT is that they tend to wind up melting into the big, broad pot of "digital transformation."
We set about this trip to isolate the true ideal of DevOps -- as envisioned by a couple of guys from Flickr at an O'Reilly conference, and as foreseen as early as 1949 by a visionary researcher posing as a canteen worker in a Liverpool dockyard -- from the many permutations, detours, and manifestations it has assumed on its way to becoming marketable. We've allowed researchers to expand the concept beyond its initial boundaries and, yes, to incorporate much of the idealism of "transformation" at large.
Read also: Agile plus DevOps is slowly but steadily reaching enterprise scale
It takes metaphors to sell an idea. I would be the biggest hypocrite in the long history of ZDNet were I to dispute this fact, as I persist in adorning my blog posts with maps of ancient forts, road atlases from a mish-mash of eras, and mystical realms. The whole point of the map metaphor is to give you, the reader, a place in your mind that has at least a hint of substance, for picturing and plotting the details of a subject as abstract as, say, attaching ephemeral identities to microservices.
But after this long journey, can we say with some certainty that DevOps is a goal unto itself? Or the means to attain a goal that could benefit from better articulation? Here is a review of where we've been, and what we've discovered along the way:
Waypoint 1: The dream of fellowship for software developers and IT operators
There was a reason why the creative and practical parts of information technology were partitioned off from one another, and at least at first, it was not a good one. But Enid Mumford pointed us toward a future of "human systems," where there was essentially one interface between the human and the system, not two. This doesn't mean that every practitioner of the art of computing must adopt some homogenous, socially acceptable philosophy. But having the skill of administering systems should not make you a different class or type (or gender) of person from one who has the skill of programming them.
Waypoint 2: The dawn of automation and the promise of a formula for business success
The ideals of DevOps make clearer sense when the means of attaining them are less metaphorical and more rational. "Digital transformation" may as well be the process that Tony Shalhoub's character feared he couldn't do for real in "Galaxy Quest."
There are ways to apply automation to IT tasks, and to some degree to business processes as well, in such a way that their uniquenesses are ironed out, and they sort themselves into a handful of discrete and categorized patterns. As any strand of DNA will tell you, it's the combination of fundamental elements that produces uniqueness. All programming is about the search for patterns. Automation is real-world programming -- the application of patterns of functionality to the reality of work.
Read also: Executives overestimate DevOps maturity
Waypoint 3: With the fullest measure of courage, DevOps holds true to its objective
The distance between the "two towers" on my metaphorical map of "Middle Ground" represents the gap between what an organization sees -- based on the data it collects about itself -- and what it believes its principal function to be. BPM tricked many organizations into projecting, and then believing, purely hypothetical workflows for themselves based on the types of companies they declared themselves to be in public speeches, TV commercials, and investors' prospectuses.
When executives discovered DevOps and that it utilized pipelines, right away, they began translating their workflows from one metaphorical means of modeling to another. And of course, along came software to help them do it. But the tools of DevOps are actually not about visualizing business processes from the outside in. They compose the routes which deliverables take, from composition to testing and finally to customer presentation, from the inside out. The shapes these pipelines take are manifestations of these routes, but they're frankly not all that important in themselves.
Waypoint 4: Into the eye of the storm, DevOps' bravest warrior finds new hope
I believe that all stories, including technology stories, are made more relevant when they're made more personal. So I told the story of a DevOps analyst I met a few years ago who traded in his job to join the ranks of his own clients.
Read also: DevOps accelerates, requiring new leadership styles
Donnie Berkholz didn't enter his new job with a globally recognized travel firm with the idea of driving cultural change in the executive suite before he could begin practicing DevOps. He didn't have to. They were ready. He didn't sell them on some branded set of tools or methodology. Some departments had already begun experimenting on their own. Perhaps this isn't the case across the board, but evidently, enterprises may be smarter than we expect them to be. When a vendor insists that a customer organization requires cultural change before it can adopt its product or service, or that it must undergo some transformation first, quite possibly it's a scheme to soften up that customer to be more sensitive to its marketing message. And a thinly veiled implication that the customer isn't smart enough to see through it. This is generally wrong.
In the end, the One True DevOps is the single, undivided practice of planning information systems for both development and maintenance, in order that the benefits of those systems may be delivered more efficiently to customers. Researchers such as DORA and practitioners such as Puppet are correct in asserting that the final and total value of anyone's DevOps initiative will be measured by these customers. If we truly believe this assertion, instead of just nodding our heads in its general direction, then we should be forging more direct connections between information workers and the partners and customers whom they serve, rather than fortifying the barriers between them.
IT needs to be given a clear line of sight to the source of customer value: not marketing, not R&D, not the budget office, but the customer herself.
Read also: 5 reasons DevOps will be a big deal in the year ahead
The magnificent map of Middle Ground you've seen throughout this journey was drawn and produced by Katerina Fulton, my daughter in whom I am most pleased.
Quest for the One True DevOps
- Part one: The dream of fellowship for software developers and IT operators
- Part two: The dawn of automation and the promise of a formula for business success
- Part three: With the fullest measure of courage, DevOps holds true to its objective
- Part four: Into the eye of the storm, DevOps' bravest warrior finds new hope