Although I feel as if it’s been dispelled to a significant degree, there lingers the misperception that DevOps [1] is mostly for companies that sport ping-pong tables and have free sushi for lunch. Firms that manufacture construction equipment and have large swaths of legacy computer code? Not so much.
It’s not particularly surprising that this misperception exists. A traditional IT organization glances at a company like Netflix and they may see a unicorn wholly unlike themselves. They’re not even entirely wrong. More extreme implementations of approaches such as microservices or near-continuous production releases likely won’t become the norm—especially in the “classic IT” (aka Mode 1) parts of their infrastructure. However, that doesn’t mean DevOps principles can’t also benefit the conservative IT of conservative firms.
It’s about the software
The first reason that DevOps practices apply outside of greenfield, cloud-native (aka Mode 2) IT is that the rules are changing. The “software is eating the world” meme has become something of a cliche but it’s no less true for that. As my colleague James Labocki wrote in a recent post, "Bank of America is not just a bank, they are a transaction processing company. Exxon Mobil, is not only an oil and gas company, they are a GIS company. With each passing day Walgreens business is more reliant on electronic health records.” Furthermore, as James also noted in that post, these shifts in technology and how business is transacted are creating new competitors that come at you from non-obvious directions and places.
Therefore, while the priorities for classic IT may be different from those of cloud-native, it still needs to change. I’ll go so far as to say that calling this “legacy” is a potentially dangerous turn of phrase as it implies static and in need of wholesale replacement. In fact, to quote James one last time:
In mode-1 they [IT] are looking to increase relevance and reduce complexity. In order to increase relevance they need to deliver environments for developers in minutes instead of days or weeks. In order to reduce complexity they need to implement policy driven automation to reduce the need for manual tasks.
Getting there requires DevOps tools and approaches (together with policy-based hybrid cloud management).
DevOps thinking is proven to work in traditional industries
I thought DevOps was pretty new, you cry! In some ways, DevOps as we usually talk about it today is indeed the child of pervasive open source, continuous integration technologies, platform-as-a-service (PaaS), software-defined infrastructures, and a host of other relatively modern technologies. However, as Gartner points out in “DevOps is the Bimodal Bridge” (paywall):
Mode 1 organizations can use systems thinking for incremental improvements, such as reductions in waste and improved risk mitigation. While DevOps has embraced these methodologies, the concepts have, in fact, decades of real-world application in manufacturing and other industries.
(Here's one version of a presentation I give from time to time about the lessons from manufacturing for DevOps on Slideshare.)
Gartner also maintains that: "there are many elements in DevOps that may, in fact, apply across the modal spectrum. It is our firm belief that by 2020, at least 80% of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups for the overall benefit of the organization."
The need to work across IT
One number from a recent IDC InfoBrief sponsored by Red Hat “DevOps, Open Source and Business Agility: Lessons Learned from Early Adopters” (June 2015) popped out for me even in the context of multi-modal IT.
A majority of organizations (51 percent) don’t plan to have a dedicated DevOps organization. (36 percent do and 13 percent were unsure.) From my perspective, this is mostly a positive result. While dedicated organizations may suggest commitment and focus, they can equally mean stovepiped projects that don’t address the needs of or solve problems for the mainstream IT organization. As a result, their scope may be limited and fail to integrate with core IT systems.
As Cameron Haight notes in another Gartner research note: "Initial DevOps toolchains are often focused on tactical integration scenarios, thereby restricting the ability to develop more flexible, general-purpose architectures."
Even when it makes sense to initiate DevOps as a pilot project, it’s important to keep attention (of both management and the DevOps folks doing the hands-on work) focused on the end business benefits, which should be the ultimate drivers. In the aforementioned IDC InfoBrief, employee productivity and business revenues were seen as important DevOps business impacts. But the #1 impact? Increase customer satisfaction and engagement. You’re not going to achieve that with a project touching a small portion of your IT.
[1] Here’s how we define DevOps at Red Hat.
DevOps is an approach to culture, automation, and platform design for delivering increased business value and responsiveness through rapid, iterative, and high-quality IT service delivery. It applies open source principles and practices with:
- Culture of collaboration valuing openness and transparency
- Automation that accelerates and improves the consistency of application delivery
- Dynamic software-defined and programmable platform
No comments:
Post a Comment