DevOps in the Ascendency

  • Aruna Ravichandran
  • Kieran Taylor
  • Peter Waterhouse
Open Access


In 2016, Formula 1 (FI) racecars, the ultimate in four-wheeled technology, are awash in wireless sensors and transmitters.


Application Economy Lean Manufacturing Mobile Banking Disruptive Innovation Agile Practice 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

“Be ahead of the times through endless creativity, inquisitiveness, and pursuit of improvement.”

—The Toyota Precepts1

Accelerating Agile Practices in Today’s Software Factory

In 2016, Formula 1 (FI) racecars, the ultimate in four-wheeled technology, are awash in wireless sensors and transmitters.

Running your eyes across the graceful, sculpted bodywork of these 200+ mph engineering wonders, the only discernible interruption of their low-slung carbon fiber noses are small clusters of wireless antennas jutting up directly into the drivers’ sightlines.

As subtle as these transmitters may be, why would designers, who spend endless time and resources attempting to improve the aerodynamics and drivability of the machines, accept such a stark concession? The answer is simple—to arm their teams with priceless real-time data used to continuously improve performance.

Along the pit row wall, in the trackside garages, and back in the very design centers where F1 engineers continue to refine their handiwork, telemetric information provided by those tiny antennae is immediately translated into change.

While team principals and technical directors sitting directly adjacent to the track communicate directly with the drivers, advising them how to adjust settings on the fly, their colleagues in the garages prepare to adjust everything from tires to aerodynamics when the machines pull into the pits.

Meanwhile, back at the factory, live data is consumed by all manner of engineering teams who continually produce and modify new components to be utilized in subsequent competitions—beginning the process of further advancement even before the current race is complete. The push for innovation in F1 is a perpetual activity; in this sense, perhaps more so than in any other sport, the only constant is technological change.

That Toyota Motor Corp., the global automotive giant best known for advancing such data-driven, process-centric “just in time” manufacturing practices—concepts that revolutionized mass production of passenger cars—had such a short-lived and disappointing record in F1 can only be classified as ironic. However, the Kanban and Kata methodologies leveraged by Toyota since its inception, paralleled on a smaller, more specialized scale by today’s F1 teams, stand as the most widely emulated management frameworks in history.

With an emphasis on the adoption and evolution of processes designed to optimize resources while increasing production speed and quality—and most importantly promoting constant innovation—the “Toyota Way”2 represents arguably the leading model for continuous improvement.

In the words of W. Edwards Deming—the legendary American engineer and management consultant who helped spearhead the reinvention of Japanese industry after WW2—Toyota’s approach embodies the notion that, “It is not enough to do your best; you must know what to do, and then do your best.”3

Grounded in constant observation and measurement of efficiency—from supply chain management through final production, with the goal of constantly improving output, including and in particular worker productivity—this methodology flies in the face of traditional “waterfall” workflows. American automaker Henry Ford may be credited with revolutionizing the assembly line, but Toyota is widely recognized for decoupling and perfecting it.

Rather than creating linear dependencies, where each successive activity is wholly dependent on completion of the task preceding it, this revolutionary approach emphasizes techniques wherein production is dynamically adapted on the fly to result in optimal efficiency and maximum quality.

Further illustrating the staunch devotion to continuous improvement represented both in the Toyota Way and in his personal doctrine, Deming famously said, “It is not necessary to change. Survival is not mandatory.”4

This observation is neither subtle, nor, given industrial history, seemingly misplaced.

Embracing DevOps in the Application Economy

In today’s rapidly evolving Application Economy, it is widely recognized that, driven by the evolution of digital channels—across both the business-to-business and consumer segments—many organizations are reinventing or recasting themselves as providers of software and digital services.

For example, the global population of mobile banking users is forecast to double to 1.8 billion by 2020, representing over 25 percent of the world’s population, according to KPMG.5 As a result, banks are increasingly focused on advancement of web-based and mobile applications, versus expansion of brick-and-mortar operations.

Furthermore, as business delivery mechanisms shift to the digital landscape, end users’ tolerance of latency of such applications has grown increasingly narrow. According to a study published by Wired in June 2014, roughly 50 percent of consumers expect a web page to load in two seconds or less—or they move to abandon it.6

Given this transformation, as traditional business services are replaced by largely web-based and mobile-friendly applications, organizations are being forced to completely reexamine their software development and IT management practices. Technology is no longer viewed as a supporting dependency, but rather as a primary element of conducting business.

Within that context, most of today’s organizations are moving aggressively to adopt more agile, efficient software delivery and IT management practices to meet customers’ evolving expectations. Among the fastest growing and most widely adopted strategies, aimed at bringing Toyota-like efficiency to the world of the applications lifecycle, is the methodology known as DevOps.

Whether or not Patrick Debois understood that he was creating, or at the very least putting a name to, the movement that would completely redefine the manner in which organizations build and support software is unclear. What is known is that since Debois, a systems administrator, and a handful of like-minded software development and IT operations experts first coined the DevOps moniker in 2009, the concept has become a global phenomenon.

The underlying concepts encompassed by DevOps are, at first glance, straightforward, but represent seismic reformulation within the context of software production and support. Rather than maintaining discreet applications engineering (“Dev”) and IT management (“Ops”) competencies and organizations, DevOps dictates use of smaller teams with cross-functional expertise to improve software functionality and the processes used to deliver it.

As highlighted in the seminal DevOps novel, The Phoenix Project, this mindset eliminates the fragmented approach to applications delivery that has traditionally crippled many organizations in addressing the digital market opportunity. Rather than asking developers to build an application and then charging IT management with ongoing support, creating highly disparate and inefficient dynamics, DevOps brings those specialists together so that engineering is completed with a constant eye toward ongoing management.

Just as critical in boosting organizational efficiency and software quality, DevOps methodology—like the Toyota Way—also promises to increase the ability to change the existing code base and deliver new capabilities to end users, while cultivating internal experimentation. Leveraging automation to do so is another hallmark of the Japanese carmaker’s model and is also core to the DevOps approach.

In a May 2014 editorial published in the Wall Street Journal, noted technology evangelist and The Phoenix Project co-author Gene Kim echoed the words of Deming in framing his view of ongoing DevOps adoption. Titled “Enterprise DevOps Adoption Isn’t Mandatory — but Neither Is Survival,” Kim, also an established entrepreneur, posits that “the business value created by DevOps will be even larger than was created by the manufacturing revolution.”7

Responding to some experts’ observations that DevOps is only relevant for lean-minded, applications-driven startups such as consumer transportation darling Uber, Kim asserts that even the oldest, most entrenched businesses must wrap their arms around the movement to compete and survive. The author contends in the WSJ piece that this is, “because IT is the factory floor of this century, and not just for manufacturing companies. IT is increasingly how all businesses acquire customers and deliver value to them.”

Like the so-called “lean manufacturing” wave that swept the business world in the 1980s—directly related to the success of Toyota in growing to the point of global sales domination—Kim asserts that today’s organizations must seek to drive every element of inefficiency out of their software development lifecycle (SDLC).

Just as companies that failed to adopt leaner manufacturing processes in the latter half of the 20th Century lost out to rivals that did, the expert, among many others, maintains that organizations who overlook the need to adopt DevOps in today’s Applications Economy will likely disappear.

Evidence that Kim and other proponents are correct in predicting that organizations’ willingness to embrace DevOps will directly impact their ability to compete is already mounting. Numerous research reports have reinforced that leading DevOps practitioners already appreciate significant competitive benefits.

In a 2015 study published by Freeform Dynamics, in partnership with CA Technologies, researchers found that the 20 percent of organizations that had broadly adopted DevOps methodologies were 2.5 times more likely to have charted improvements in customer retention.

The report, “Assembling the DevOps Jigsaw,”8 also found that these early adopters were 2 times more likely to have realized improvements in customer acquisition, and 3.4 times more likely to appreciate growth in market share. Perhaps most notably, those organizations already well into their DevOps transformations were 2 times more likely to have recorded a positive impact on revenue, and 2.4 times more likely to have experienced higher profit growth.

Regardless of the given era and environment, those financial results would seem to speak for themselves. Yet, according to the Freeform Dynamics survey, 80 percent of all organizations have yet to embrace DevOps completely.

DevOps as a Critical Requirement

The reality is, whether organizations are ready or not, the requirement to aggressively adopt DevOps methodology has quickly become the new normal in the Applications Economy. At the very least, the notion that such change is inevitable in cultivating continued business growth must be recognized as an inconvenient, yet irrefutable truth.

In an increasingly fast-paced, complex, and ambiguous business world, competing on a landscape dominated by the continued evolution of digital channels and mobile devices, the only tractable strategy is to adapt to survive. Driven by the exponential speed of change, organizations must wrap their arms around DevOps if they hope to defend and expand their market opportunities.

Within this current atmosphere—defined by volatility, uncertainty, complexity, and ambiguity (VUCA)—DevOps offers an unprecedented opportunity for organizations to transform their SDLC to increase efficiency and meet end users’ changing expectations. By fundamentally recasting the manner in which they approach every element of software development and management, DevOps represents the broader future of business in general.

Despite the tendency to celebrate industry “unicorns” such as Uber—startups whose technology and business models immediately lent themselves to DevOps adoption—research such as the Freeform Dynamics “Jigsaw” report illustrates that organizations of all sizes and industries must change, or risk potential obsolescence. This conclusion is already being proven out by widespread assimilation of the involved methodologies by everyone from lean startups and centuries-old manufacturers, to nonprofits and government agencies.

Banking on DevOps Practices

Adoption among stalwart names in the banking industry—recognized as one of the most entrenched and “old school” segments in the entire business world—offers further proof of this pervasive need for DevOps transformation.

While notoriously staid in some senses, banks have also long-embraced significant levels of software and IT to diversify their services and increase profitability. Examples include inventions such as automated teller machines (ATMs) and the vast electronic transaction processing systems that allow these companies and their clients to move capital around the world in real time.

With roots dating back over 150+ years into the Dutch banking trade, global corporation ING is one such old world company that has successfully embraced DevOps transformation. Driven by existing inefficiencies in its 15,000-strong IT workforce and the need to address changing customer demands to increase its (EU) 15 billion annual revenues, the Amsterdam-based company embarked on an aggressive DevOps strategy beginning in 2011.9

Aimed specifically at enabling so-called “continuous delivery” of its applications to suit emerging customer preferences around online and mobile banking, company officials sought to remodel SDLC methodologies by invoking a manifesto of legendary Apple co-founder Steve Jobs. Citing a 1989 interview with Inc. Magazine in which Jobs famously said, “You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new,”10 ING set about on its DevOps initiative.

With the expressed goal of retrenching its SDLC to eliminate onerous, time-consuming waterfall practices and accelerate the pace of applications innovation, ING first moved to create more agile “scrum” teams that brought together development and operations expertise. From a process standpoint, one of ING’s tactical goals was to begin testing new applications code in a far more “production-like” environment, such that emerging issues could be identified and resolved faster, accelerating code delivery to end users, while improving quality.

In support of those initiatives, the banking giant also leveraged significant automation to address SDLC requirements, including configuration management and software deployment. By bridging the gap between dev and ops, and employing new levels of automation, the company was able to increase the pace of its applications releases from an average of once every 13 weeks to weekly updates.

In support of this larger continuous delivery effort, ING was also able to increase its pace of underlying mobile applications code deployments from several hundred per month to over 80,000 per month, in less than two years. By leveraging DevOps workflows and supporting automation, the Dutch bank transitioned from release cycles dictated by technical roadmaps, to those focused on strategic business objectives.

Ultimately, customers expressed their approval both in adoption and via public forums, as ING’s mobile application reviews on the Apple iTunes App Store climbed from one star in 2011, to four stars in 2014.

DevOps: A Key Component of Business Agility

The ING story stands out not only as detailed proof of the manner in which DevOps represents a tremendous opportunity SDLC reinvention, but also as a specific example of how large, entrenched organizations can also emulate the much admired startup mentality. At the end of the day, the company’s continuous delivery exercise allowed it to appease the changing preferences of mobile applications users, the ultimate goal of countless new startup ventures.

For years, everyone from management consultants to Wall Street investors have beleaguered the need for such pre-Internet companies to better leverage the “lean and mean” traits of their upstart peers. With the dawn of the DevOps era, driven by the Applications Economy, organizations, regardless of scale and history, have in fact been presented with this specific opportunity.

By completely transforming the manner, and more importantly the speed with which new ideas can be translated into marketable products and services—in the specific form of applications—organizations that have traditionally been slowed by their inherent size and complexity can rapidly accelerate innovation.

Conventional wisdom dictates that large enterprises with sundry customers and products face greater risk in attempting to launch new services and supporting business models. Meanwhile startups, unburdened with existing processes and systems, can rapidly pivot from one guiding approach to another, reinventing themselves whenever the need arises. Enterprises, typically guided by the need to requite shareholder interests, have been prone to err more toward stability, limiting their rapid growth potential.

For example, it is widely recognized that this entrenched, risk-averse mentality has allowed startup companies such as eBay and Airbnb to displace longstanding giants of the global retail and hospitality industries, respectively. If you could turn back the clock 5-10 years and give Sears and Hilton another chance to adopt the same strategies used by their startup rivals, obviously they would jump at the opportunity.

Part of this, in addition to a lack of shareholder reckoning, revolves around the fact that startups have also been able to quickly embrace emerging business technology trends, including cloud computing, mobile apps, open source, crowdfunding, and other means of collaborative economics.

Yet, if the core of this mentality, empowered by technological agility, is that innovation is merely a “good idea made possible,” then adoption of DevOps represents just such an opportunity for organizations, regardless of size, to accelerate business via more efficient applications delivery.

As framed by Jez Humble, leading technology consultant, recognized as a founding father of the DevOps movement: “The long-term value of an enterprise is not captured by the value of its products and intellectual property, but rather by its ability to continuously increase the value it provides to customers—and to create new customers—through innovation.”11

At its core, the premium placed on the startup mentality, as previously referenced, relates primarily to the notion of market disruption. This is perhaps best exemplified, thus far, by those Applications Economy darlings that have successfully introduced new business models supported by web and mobile technologies.

However, leveraging DevOps and its halo effect of increased innovation through more efficient and rapid delivery of differentiated applications, one could easily assert that in the matter of enterprise versus startup, the playing field is being leveled quickly. Specifically, as organizations leverage DevOps to become more agile in addressing the Applications Economy, they are able to better keep pace with their smaller, more innately nimble rivals.

Circling back to the origins of the Toyota Way, the involved tenets of disruption via technological innovation have always been recognized as catalyst in transforming industry; in fact, even the genesis of this specific example has roots predating the auto industry.

In 1896, Sakichi Toyoda invented Japan’s first self-powered loom, incorporating numerous revolutionary features, most notably the ability to automatically halt production when threads moving through the devices were broken.12 Leveraging his invention, Toyoda built his startup into a leader in the Japanese textiles industry.

Those concepts, which became the legendary Toyota Way, were merely carried over when his son Kiichiro launched the automaker Toyota Motors in 1937. As it would turn out, this technology-driven approach to innovation and disruption would also dovetail perfectly with the lean management concepts promoted by Deming as he helped resurrect Japanese manufacturing in the 1940s.

At the time, automakers in other areas of the globe, notably the United States, likely would have never accepted that such a company, far smaller than their own booming operations and literally rising from the ashes of war, would have the opportunity to dominate the worldwide market.

In 2012, after decades of displacing customers from other brands, Toyota was recognized at the world’s largest automobile manufacturer, having produced its 200-millionth vehicle and grown into the first automobile manufacturer to ever produce more than 10 million vehicles per year. In 2016, amid larger worldwide economic concerns and a headline-grabbing airbag recall issue, the company remains among the global sales leaders in its industry.

Companies such as Toyota and ING, along with endless agile startups, offer tacit proof that for organizations seeking to increase market relevance and disruption, DevOps offers an attractive template. Yet, citing Freeform Dynamics’ findings that only 20 percent of all organizations have achieved any semblance of DevOps maturity, the movement is clearly still in its nascence.

To wit, the researchers found that even though 80 percent of respondents to its survey view DevOps as a “key component of business agility,” only 55 percent of organizations laid claim to having created a well-defined DevOps strategy. Furthermore, while 86 percent of those organizations surveyed labeled DevOps-oriented education of business stakeholders and greater alignment of IT and business priorities as important, only 33 percent and 37 percent, had enacted those programs, respectively.

Loosely stated, the concept of disruption, in general, suggests that market incumbents typically become less profitable and open to displacement from more agile peers based on the entrenchment of inflexible business models. It is widely acknowledged that there are two primary models for market disruption in the current era—“new market” disruption and “low end” disruption—at least as defined within the context of so-called “disruptive innovation” theory.13

In the case of new market disruption, the landscape is forever altered when a new products arrives that somehow better addresses a segment that incumbents have not yet envisioned or delivered. Whereas with low end disruption, incumbents see business chipped away by products that aim to encompass a smaller subset of perceived value drivers offered at a lower price point.

Looking closer at the promise and outfalls of DevOps—and the ability of adopters to better align themselves with the exploding demand for software and applications—one could easily argue that this ongoing technological revolution directly supports both archetypes of the disruptive opportunity. It would seem obvious that those organizations that have yet to jump in sit greatly imperiled by its continued advancement.

Some may view the Darwinian views of Deming, or Gene Kim, as overstated, particularly as related to DevOps and the Applications Economy. One could imagine that organizations that do not yet supply applications to consumers or business partners would remove themselves from the larger conversation.

However, in the following chapters of this book, there is a great deal of evidence—backed by specific technical practices—that make it clear just how sensible, if not necessary, it is for every organization to view the DevOps opportunity as their best chance for success and survival.

DevOps: A Practice for Champions

At the conclusion of the 2015 F1 season, the world champion driver Lewis Hamilton and teammate Nico Rosberg of the Mercedes AMG Petronas Formula 1 Team, also winners of the highly coveted F1 constructor’s title, returned to the outfit’s UK headquarters to thank the factory workers who made their victories possible.

While most of those people, numbering in the hundreds, never joined the team at the track on a single race day during the globe-spanning nine month season, the champions heaped praise on their colleagues, recognizing the year-round effort that supports the entire operation.

Mercedes made easy work of the rest of the F1 field in 2105, having won a stunning 16 of the 19 total races. At the same time, this was not without constant updates to its racecars, with new components constantly meeting the team around the world as they progressed throughout the grueling race calendar.

“In racing there are always things you can learn, every single day. There is always space for improvement, and I think that applies to everything in life,” Hamilton has been quoted as saying.14

“With the team, whether it be my guys that are at each Grand Prix, the team back at the factory who work day and night to develop the car, build the parts, and send the parts, the IT team, and the crew cleaning the factory. Everyone. We do it together. We all feel the joy when we are winning and the same pain when we are losing,” the champion driver continued.

Without the constant delivery of new innovations, without the continued experimentation and refinement of the involved technologies, and of course all the underlying processes, Hamilton affirms, the likelihood of his success would be scant, if not impossible.

DevOps offers the chance for any organization to run more like a championship team, ever improving performance, going faster, and winning.


Only a few years into the Application Economy it’s clear that huge benefits are being appreciated by those organizations capable of embracing emerging processes and technologies that enable agile methodologies. DevOps is widely recognized as one of the most influential and important movements that empower that transformation.

At the same time, such a sea change in the manner that organizations approach software development and operation, or any process for that manner, cannot be realized without some growing pains. In the next chapter, we’ll take a look at the historic state of disconnect that has existed between developers and IT operations staff, and the approach that organizations embracing DevOps have employed to reinvent the manner that such experts collaborate.


  1. 1.
  2. 2.

    Toyota Motor Corporation Annual Report, 2003, page 19.

  3. 3.

    “Made in Japan,”, Rena Delbridge, copyright 1995:

  4. 4.

    Edward Deming, Out of the Crisis, (Cambridge, MA, MIT Press, 1982), p. 227.

  5. 5.
  6. 6.

    “Great Expectations: 47% of Consumers Want a Web Page to Load in Two Seconds or Less,” by Nilesh Patel, Wired, copyright 2014:

  7. 7.

    “Enterprise DevOps Adoption Isn’t Mandatory — but Neither Is Survival,” by Gene Kim, copyright WSJ, 2014:

  8. 8.

    “Assembling the DevOps Jigsaw,” Freeform Dynamics, copyright 2015:

  9. 9.

    “ING Bank Case Study,” CA World’14 Presentation copyright CA Technologies.

  10. 10.

    “The Entrepreneur of the Decade,” by George Gendron and Bo Burlingham, copyright Inc. Magazine 1989:

  11. 11.

    Jez Humble, Lean Enterprise: How High Performance Organizations Innovate at Scale, (Sebastopol, California, O'Reilly, 2015) p. 39.

  12. 12.

    “Automation with a Human Touch,” Toyota Motor Corporation World site, copyright 2016:

  13. 13.

    “What is Disruptive Innovation?,” copyright Harvard Business Review, Dec. 2015.

  14. 14.

    “Mercedes AMG Petronas Team End Season on Top,” By Donny Halliwell, Inside Blackberry, copyright 2015.

Copyright information

© CA 2016

This chapter is distributed under the terms of the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License (, which permits any noncommercial use, duplication, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if you modified the licensed material. You do not have permission under this license to share adapted material derived from this book or parts of it.

The images or other third party material in this book are included in the work's Creative Commons license, unless indicated otherwise in the credit line; if such material is not included in the work's Creative Commons license and the respective action is not permitted by statutory regulation, users will need to obtain permission from the license holder to duplicate, adapt or reproduce the material.

Authors and Affiliations

  • Aruna Ravichandran
    • 1
  • Kieran Taylor
    • 2
  • Peter Waterhouse
    • 3
  1. 1.CA TechnologiesCupertinoUSA
  2. 2.WinchesterUSA
  3. 3.BlackburnAustralia

Personalised recommendations