On March 15, I gave four keynote speeches on DevOps in Toulouse, France. As the main speaker of Econocom Club MEP 2018, an annual think tank summit organized by the European business-to-business digital services provider, I shared the day with 15 firms in industries as prestigious as financial services, energy, aerospace, aviation, and telecommunications and heard all about their implementation projects.
The lessons learned from this year’s summit are troubling, they tell a story the vast majority of DevOps vendors aren’t prepared to hear: They miss their client expectations. There’s a severe disconnect between what’s expected and what’s delivered.
Participant visions and approaches didn’t surprise me; they simply confirmed my point that DevOps is misunderstood. By stressing the implementation of Continuous Delivery (CD) toolchains—selling technology is more lucrative than transforming a business—IT service providers aren’t helping.
What do these lessons tell, exactly? if you’re an open-minded leader who understands that a new IT service delivery paradigm more focused on business concerns is needed, this is for you.
The Untold Frustration
In his opening speech, facilitator Fabrice Berne was inspired to ask participants while they introduced themselves to share the purpose and challenges of their DevOps implementation project.
What I heard didn’t surprise me; it was a mix of fascination and frustration—participants were at the same time excited to work on a DevOps project and frustrated because they weren’t getting the promised business benefits.
“The reason is, you all tackled your DevOps project the wrong way,” I said. “You started by implementing the CD toolchain, thinking tools on their own will deliver the expected business benefits. That illusion is widespread in the IT community!”
So, What is DevOps?
As my claim turned the atmosphere icy, I added, “DevOps can’t be narrowed to these tools—not even to agile practices and automation. It’s more than that. DevOps seeks to make the business competitive, wealthy and healthy by continuously delivering high-quality software.” And concluding my introduction, I made it clear: “The fundamental question is, How is business value created? Many experts, particularly techies, struggle to answer it.
“Let me say this straight: Most DevOps projects fail because certain experts erroneously spread the idea that the most important piece of DevOps is the CD infrastructure,” I said, adding, “The fact of the matter is these experts and the IT solution vendors they represent are creating confusion; through massive marketing hypes they force CIOs to address DevOps through the distorted lenses of the so-called DevOps tools.”
The Inconsistent Disparate Visions
The following chart results from a survey we conducted at ITaaSNow last year. It involved 2,681 businesses that were unhappy with their cloud and DevOps migration projects; we wanted to show how poor DevOps approaches lead businesses to failure:
“As you can see, there’s no homogeneous perspective right now,” I told the audience. “It varies according to the business culture, objective and strategy or the DevOps architect’s understanding, experience and expertise. In most cases, these customized visions are incomplete and generate no business value at all.”
I picked two failure causes in the chart to demonstrate my point.
Starting with the notion that, “automation is the core of DevOps,” I argued, “DevOps primarily seeks to help generate business value. Generating business value is about identifying market and customer expectations, translating expectations into profitable service ideas, developing, deploying, promoting, selling them and continuously improving customer experience.
“Where did techies get the idea that to make a business profitable the only thing to do is to implement Git, Jenkins, Cucumber and Chef into a CD toolchain?” I asked, somewhat ironically.
Picking a second cause, “DevOps strategy should only stress software development activity,” I continued. “Thinking that isolatedly software development activities will generate business benefits without involving marketing, sales, testing and operations is a pure illusion. Once again, generating business value is a complex process that covers identifying market and customer expectations, translating expectations into profitable service ideas, developing, deploying, promoting, selling them, and continuously improving customer experience.
“Where did solution vendors get the belief that, software development alone is enough to generate business value?,” I asked. “That’s another myth they nurture!”
I then warned: “Make no mistake about it: All the visions represented on the chart are either incomplete or wrong. They do not reflect what DevOps is. You must acknowledge once and for all thatit is a business transformation effort, not only an IT capability implementation. Period.”
The Contrast with the Founding Fathers’ Vision
“Who better than its founders can provide the right vision and definition of DevOps?” I asked.
Relying on Jesse Robins, John Allspaw and Paul Hammond’s vision as reported by Chef co-founder Adam Jacob in a memorable article, “The Secret of DevOps: It’s Always Been About People, Not Technology,” I unveiled what I consider the primary features of DevOps.
In his article, Adam reminded us, “Becoming better at building and delivering software is the stake. It’s not an optional piece of their strategy: It’s the future of how their customers want to work with them. Software is table stakes for survival.”
He added, “But the real answer lies in looking at what John, Paul, and Jesse were doing in 2009—not in the specific technical choices they made, but the style in which they worked, the essence of what they believed made them high functioning and successful. … Then the challenge begins: how to apply this new style to businesses trying to become better at building and delivering software.
“DevOps is about bringing together all the people you need to build and run your business effectively, and empowering them to move as quickly as possible toward their goals. Tools matter. Make no mistake: Trying to change the way you work without changing the mechanisms by which you do that work is a futile exercise in excruciating failure.”
He concluded, “Fundamentally, it is about taking the behaviors and beliefs that draw us together as people, combining them with a deep understanding of our customers’ needs, and using that knowledge to ship better products to our customers.”
With Respect to Techies, DevOps is Primarily a Business Operational Model
“If you paid attention to what Adam Jacob reported about Jesse, John and Paul’s vision, you probably noticed that it emphasizes two fundamental elements of high-performing businesses: the well-known IT infrastructure and the unknown operational model,” I told the audience.
Moving to the next slide, I provided evidences to my point, “As the picture shows, DevOps, according to its founding fathers, isn’t the CD platform, automation toolchain or the platform-as-a-service (PaaS) infrastructure solution vendors and certain consultants would like you to believe.”
The slide seemed to clear up a doubt about what the audience had been hearing. I confirmed, “With all due respect to my fellow techies, as I’ve been implementing it, DevOps transcends software development issues; it’s a business operational model supporting your company’s competitiveness.”
I told the audience I chose to represent it as a two-component system “because I wanted to make sure IT professionals and business leaders understand that implementing DevOps is primarily a business transformation effort for optimizing the organization’s operational model and IT infrastructure.” I added, “The operational model is the subset of interactions, staff and skills, processes and practices, values and beliefs, and tools that’s repeatedly mobilized across your organization to generate the expected business benefits. It’s where all its value propositions and competitive advantages—organizational agility, flexibility and velocity, innovation culture, more like it—are created. As (fellow speaker) Stephanie Carton puts it, the operational model is where DevOps culture is implemented.”
Anticipating the audience’s reaction to that point, I said, “It doesn’t mean CD toolchains are useless or doesn’t bring value, without them we’re dead. The point here is, business benefits result from an optimized operational model enabled by a well-engineered CD toolchain.”
I’m not the first one to go against the techie perspective of DevOps, I warned. “Ernest Mueller in his fantastic, “DevOps: It’s Not Chef and Puppet,” raised the red flag.” His message is clear: “If someone has a systems problem, and you say that the answer to that problem is Chef or Puppet, you understand neither the problem nor the tools.”
The Near Future of DevOps
In the first part of this article, I wanted to share with you the clarifications I made and more importantly, re-establish the truth on messages as erroneous as “DevOps means CD toolchain and Agile practices,” and “CD infrastructure or software development on its own creates business value.” They’re misleading CIOs and are taking hundreds of projects straight into the wall!
In part 2 of this article, next month, I’ll tell you what we debated about the near future:
- Why Agile and Lean practices will boost business competitiveness?
- What is ITaaSNow DevOps Capability Maturity Model (CMM)? How does it enable continuous business performance improvement?
- What is Artificial Intelligence for Operations (AIOps)? Why will it make DevOps the cornerstone of businesses’ digital strategy?
Stay tuned!
The Key Takeaways
This what I wanted to tell you about DevOps as we discussed it. The key takeaways are:
- DevOps isn’t narrowed to agile practices and CD toolchains. Don’t fall into the trap of certain solution vendors who tell you that Git, Jenkins, Cucumber, Chef, Containers and microservices will boost your business performance. It’s false; things aren’t that simplistic.
- DevOps combines an optimized operational model and a CD platform to bring together marketing, sales, post sales, software development, testing and operations into an application delivery capability that boosts your organization’s competitiveness.
- Starting the CD toolchain implementation without optimizing the operational model is the surest way to take your DevOps implementation project into the wall.
- DevOps implementation is primarily a business transformation effort, not just an IT capability deployment effort.
What matters isn’t applications and digital services delivery at the speed of light, but the timely delivery of added-value applications and digital services to the right market segments and business users.
According to Econocom’s feedback, most participants are reviewing their DevOps implementation strategy; they will make their operational model optimization the priority. Mission accomplished!
