Quest for the One True DevOps, Part III: With the fullest measure of courage, DevOps holds true to its objective
Video: DevOps is the hot topic in 2018: Five reasons why
"There is widespread acceptance that business and IT strategies should be linked or interdependent. Indeed, the operative word, linkage is used by many researchers to characterize an approach to IT planning that responds to, as well as shapes, business strategies. While this has achieved the status of conventional wisdom among practitioners, and is often an unquestioned axiom among researchers, the nature of linkage has not been adequately clarified in the literature. That is, the concept of linkage has been historically invoked as a metaphor to argue for the integration of business and IT strategies without adequate articulation or clarification of its characteristics."- John C. Henderson and N. Venkatraman MIT Sloan School of Management Strategic Alignment: A Framework for Strategic Information Technology Management [1989]
In many of Europe's major countries, public broadcasters are financed through state funds. The business model of sustaining broadcasting through taxation, amid surging competition from streaming services such as Netflix and Hulu -- and, in times of desperation, enforcing those media taxes with fines and jail sentences -- is no longer viable. As a 2015 report from business consultant Accenture [PDF] concluded, "In the new, consumer-driven world, access to content, rather than distribution, will become the critical differentiator."
It has been a new, consumer-driven world ever since the first consumer was born, although audience metrics may be imprecise as to when that was.
We're at the third phase of our metaphorical Quest for the One True DevOps. On our map of the Middle Ground of IT, we find ourselves at one of the tallest peaks in the DevOps Mountains. From here, completely coincidentally, we can see two towers. The one we're standing next to is the Monitoring Tower. It's all-seeing, absorbing light from all points in the realm, but at no time is it ever totally cognizant of what it sees.
The other tower lies in the distance, in a valley to the south. At its apex is the oldest oracle of logic, the Eye of Antiquity. It can look anyplace for something specific, but is never certain of what direction it should look to find it.
It just so happens that this first tower is being used by a broadcaster. The whole world seems to be shifting beneath its foundations, and it's struggling for a way to adjust.
Read also: Agile plus DevOps is slowly but steadily reaching enterprise scale
World service
For most of its existence, the British Broadcasting Corporation has established its services on a business model of collecting public fees. In 2013, the job of forging a completely new service model -- first for major events such as sports, and later for the entire program portfolio -- fell to Zoe Bolton.
"I was responsible for developing the service operations," Bolton told a Splunk company conference in London in 2016 ( according to a transcript by Diginomica). "The people, the processes and deciding what toolsets we were going to use -- it was the complete unknown. . . We were like a start-up model really, even though we were working for a huge organization. We couldn't really rob from the existing operations team, because we hadn't really done anything like this worldwide around e-commerce before, and it's a lot more complicated."
The broader concept of DevOps implies a collaboration between, if not the outright merger of, two often disparate business units. But for Bolton and the BBC, there was no Dev team to begin with, and the Ops team was busy with its own operations. It was the convergence of no one with nothing.
"Whenever they have a new program, they normally would add a page to their Web site, or a mini-site, or a tile, and they want to know whether that's doing well, and what they need to do to tweak it to make it go better," explained Andi Mann, Chief Technology Advocate with Splunk. "By using a DevOps-inspired mode of constant feedback, they use Splunk to monitor the activity on that new tile, as well as things like application activity, who's watching those shows, response times, and infrastructure activity. And they feed that all back to the marketing team, and they work cooperatively with marketing to make sure the tile placement is right, that errors aren't holding people back from clicking through. They could be trying new ways of engaging with viewers."
Prior to Bolton's arrival, the BBC's services were being maintained by six completely separate systems. Every month, a combined report was prepared on all six systems' collective performance, using Microsoft Excel as the reporting mechanism, in a process that consumed one week of effort each time.
Read also: Executives overestimate DevOps maturity
Bolton's efforts, coupled with the adoption of the Splunk platform, managed to accomplish what has often been stated to be principal goals of DevOps: the automation of critical business functions, and the bridging of gaps between divisions. But as a department head for program operations, not IT operations, she did it without either Dev or Ops. And the departments she managed to bridge together were program services and marketing. (Unfortunately, the name "ServiceMark" has already been claimed.)
"I think it was [ Peter] Drucker who said, you can't manage what you can't measure," noted Mann. "More importantly, you don't know if you're doing the right things unless you have that measurement set up in the first place. What are you even trying to improve?"
It seems reasonable enough to declare that any software, in and of itself, cannot present the entire solution for an organization reforming its business model. The story of the BBC's "digital transformation," however, appears to demonstrate how software, or a cloud-based service that presents software, completely facilitates new business efforts -- at least those efforts grounded on audience or customer measurement -- without the intervention of the departments typically charged with overseeing such a task.
Put another way, the BBC appears to have provided us with a working demonstration of a successful implementation of DevOps that did not require the kind of "top-down" "buy-in" that many of its advocates would mandate.
Truth or consequences
There actually has been a class of software that has applied itself to the modeling and, where feasible, automation of fundamental business processes. Business process management (BPM, although some vendors use the "P" to stand for "performance") is nothing new to this century.
In DevOps, the operative model is the pipeline; in BPM, it's the workflow. Since the 1990s, business analysts have used a flowchart-based approach to visualize the steps that take place in the performance of a business transaction. Keep in mind, this is not a computer function being modeled, but rather the sequence of tasks that people perform (often through the use of tools, computers among them) to achieve discrete, desired results. It was usually the results with which these processes were tagged.
Read also: DevOps accelerates, requiring new leadership styles
These processes, and the functions that accompany them, lie at the very center of organizations; for many, especially in the financial sector, they are the very definition of the business.
Originally, DevOps pipelines were not the same as BPM workflows. That changed when the tooling for delivery pipelines became an industry in itself.
"DevOps starts and finishes with the customer," wrote Bob Tarne, a coach in Agile processes for manufacturing companies, for IBM DeveloperWorks. "Customer demand starts the development cycle. Planning is the initial step to determine how customer demand will be met. Business needs to be able to react quickly to customer feedback. Lean and agile techniques facilitate the ability to react quickly."
Almost identical language has been used to describe supply chain management software. Taken out of context, this quote from Tarne looks as though someone had done a global search-and-replace of "supply chain" for "DevOps."
It's here where we realize our journey toward the terminal of the pipeline has led us on a detour into the public market. There, we discover that to distribute our new ideal throughout the realm, marketing has to wrap it in a message that sells.
"We found that there are collections of practices that are strongly correlated with high-performing IT departments," said Puppet chief technical strategist Nigel Kersten, discussing the latest research for the 2017 State of DevOps Report, produced in cooperation with DORA. "If you want to actually work out how high-performing you are as an IT department, it turns out that deployment pain -- very subjectively, for the people doing deployments, how painful are they? -- is a really good proxy for all sorts of much more sophisticated, and much more difficult-to-measure, items.
Read also: 5 reasons DevOps will be a big deal in the year ahead
"So if you're just starting out, ask your development teams, or whoever actually deploys your software, how painful are they? And then record that trendline. If it's going up, you're improving. If it's going down, you're getting worse. If it's not moving at all, all the things you're doing are not actually making any difference. Other than that, the two big measurements you want to focus on, are speed and quality, because they're meant to be the promise of this new world of working."
With all this discussion of pain and pleasure as signals of bad and good behavior, respectively (presumably), one might get the impression that we've stopped discussing technology and joined a psychology lecture.
Quoting from the 2017 State of DevOps Report: "Transformational leadership enables the necessary practices that correlate with high performance, and it also supports effective communication and collaboration between team members in pursuit of organizational goals. Such leadership provides the foundation for a culture in which continuous experimentation and learning is part of everybody's daily work. The behavior of transformational leaders thus enhances and enables the values, processes and practices that our research has identified."
All of a sudden, we're in the behavioral modeling business. DevOps, which began as an earnest plea by a couple of guys from Flickr to have the Mr. Spocks and the Mr. Scotts of the world come together more often to discuss things, has transcended the scrum room and hurled itself directly into the realm of B. F. Skinner and operant conditioning. The behavior of workers in an organization can be changed to better align with the goals of the business, if we manage to find that magic element of inspiration -- that "transformational leadership" quality that cannot come from software.
If you think I've jumped into a culture chasm myself, take a look at the late University of Georgia political science professor Dr. Robert T. Golembiewski's milestone work, Handbook of Organizational Behavior. "Transformational leadership is appropriate for managing conflict," Dr. Golembiewski wrote. "This type of leader, sometimes referred to as a charismatic leader, uses his or her personal power to inspire employees to new ways of thinking and problem solving."
Then, just three paragraphs later, "Conflict management requires experimentation and risk taking. B. F. Skinner's operant conditioning, which refers to voluntary learning of behavior through positive reinforcement, is particularly appropriate here." Without a great deal of effort, and perhaps without much awareness, at least some of us appear to have substituted the classic "Skinner Box" with a CI/CD platform.
Read also: What is DevOps? An executive guide to agile development and IT operations
The ring goes way south
Is this interpretation of DevOps going too far? Are we commandeering a metaphor that has shown results in improving the mindset and performance of IT workers, to resuscitate the old, and perhaps tired, notion of performance management?
"The thing that we learned," revealed Chef CTO Adam Jacob, "was that top-down business process automation doesn't deliver the results you thought it would, particularly because of ossification."
Rules of behavior do tend to reinforce themselves, especially by way of feedback loops -- and yes, that's something B. F. Skinner did discover. It's that feedback that makes the workflows and business logic at the center of organizations rigid and resistant to change, Jacob is arguing here. The feedback needs to be redirected, he suggests, so that the loop extends outside of individual departments, so that the signals being received are reflective of the changing state of affairs, and not some artificial state of satisfaction. Thus each feedback loop in the chain of the organization, he suggests, must be tightly coupled.
"Historically, we've always wanted to decouple it, to break it down and say this piece doesn't rely on the shape of the other," Jacob continued. "But that's not true. In complex systems, everything works because the shape of x fits in the shape of y."
Splunk's Andi Mann also spoke in terms of behavioral programming.
"DevOps defines an end state," Mann told us, "where you're delivering software better and faster because your teams are working together collaboratively and communicating better. And this is an output.
"A lot of people describe DevOps in terms of culture change," Mann continued. "Not about tooling or even about process, but about culture. But again, culture is an output as well, not an input. We need to start looking at the artifacts that create culture, the artifacts that change your ability to collaborate, that define those boundaries and silos and how you break them."
Mann's interpretation of the chain of automation would place data, measurements, and signals at the start of the sequence, and culture changes at the end -- in the category Skinner would call "consequences." But it is one single, unbroken chain. There is a competing set of theories -- for example, Gartner's vision of bimodal IT -- which would suggest that different classes of business processes have their own exclusive cycles, which run at their own speeds. Some have reinterpreted the bimodal notion to refer to "old stuff" and "new stuff," but as its creators have pointed out, it's really an acknowledgment that not all business processes share the same chain.
If that's the case, then maybe DevOps does belong in a category by itself after all.
"I believe that good computing practices and good DevOps practices are applicable to all change, all deployment, and all technology," remarked former Forrester analyst Robert Stroud, now chief product officer for continuous delivery software provider Xebia Labs. "But the reality of it is that the business doesn't always require every application to run at the same speed."
Stroud suggests the presence of what he calls "multi-speed IT" -- not a bimodal or two-faced scheme, but a series of somewhat self-contained processes. "The reality of it is," he told us, "some systems will ideate faster or slower than others. But you still want to put that change through the same rigor, the same testing, the same check-in processes, the same ideation processes, the same validation of the code that it's effective, that it works, that it serves a purpose and is fit for use. Then you want to deploy it in an automated manner. So as far as DevOps is concerned, we want to make the DevOps processes, and the DevOps way of working, consistent across the whole environment. Let the business choose how often it ideates -- it's their choice. Ultimately, IT exists to run the business. We're not here to tell the business what to do."
Read also: Harnessing AI to make DevOps more effective
Stroud's vision places IT in the role of automating business processes using the same methodology, but not producing components of the same chain. The pipeline, as he projects it, fashions a set of repeatable actions and functions for each class of business activity. But their connection with one another may be more asynchronous, in the manner of Web services -- waiting to be called, and then sending signals when they're done.
It's that vision which begins to look more like where we started: the simpler, more logical, less psychologically obsessed realm of software development. It doesn't demand cultural change as a means for delivering an ideal, and all the goodies and downloads that come with it. Nor does it profess the ideal of analyzing every signal in search of the meaning behind the data that will deliver, in the end, cultural change. For that matter, there isn't much cultural change to it at all.
Read also: Is DevOps sustainable after the consultants leave?
Regrouping
The end of our journey is in sight, and already we start to feel the need for warm blankets and perhaps elven bread. We're about to embark on a guided tour of the most unchanging element in all the realm: the corporation. There, we'll see what a former prominent DevOps analyst learned when he put the principles he used to teach to the ultimate test, as he joins the enterprise itself. Will what he have gained have been worth the sacrifice? And what can we gain from the lessons he's learned?
We'll see if we can escape the volcano without losing a finger. Until then, hold strong.
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
Journey Further -- From the CBS Interactive Network
- "Executives overestimate DevOps maturity" by Robert Stroud, Forrester Research
- "The failed promise of Business Process Management (BPM)" by Patrick Gray, Tech Decision Maker
- "DevOps success factors: Culture, APIs, and security" by Tas Bindi, Riding the DevOps Revolution
Elsewhere
- "Rethinking Bimodal IT Part 2: Coping with Change" by Scott M. Fulton, III, CMSWire
- "What is Chef? A primer for DevOps newbies" by Steven J. Vaughan-Nichols, HPE enterprise.nxt
- "Change Control: Overcoming the Compulsion to Repeat the Past" by Scott M. Fulton, III, SmartBear
Related stories
- Searching for the perimeter in cloud security: From microservices to chaos
- Micro-fortresses everywhere: The cloud security model and the software-defined perimeter
- Microservices and the invasion of the identity entities
- Machine learning and the spectre of the wrong solution
The map of Middle Ground for this series of Scale was drawn by Katerina Fulton.