We’re long past the days in which a single, monolithic “IT Department” can address the entirety of an organizational and employee technology needs. More than ever, enterprises need to quickly and continuously deliver new functionality while concurrently paying attention to security, stability, interoperability, and reliability.
If that seems like a tall order today, you’re spot-on.
As a result, you may have heard the term DevOps—a portmanteau of development and operations. If you haven’t, then there’s a good chance that you will in the near future. But what is it? What are its benefits? And what about its limitations?
In this series of three-part series, I’ll cover its background, some of the challenges that its practitioners face, and a cautious look at its future.
DevOps: Brief History and Origins
The roots of the term DevOps stem from a 2009 conference in Ghent, Belguim. Fast forward eight years and it’s no overstatement to call its rise meteoric. A quick look at Google Trends demonstrates as much:
As for why DevOps has exploded, the answer isn’t “rocket surgery.” The history of traditional phase-gate IT projects isn’t a particularly successful one. In fact, it’s riddled with failures, lawsuits, and general disappointment—a topic that I address in Why New Systems Fail.
DevOps fuses several different practices, cultural philosophies, and tools.
At a high level, it’s a reaction to previous IT delivery methods. As such, DevOps attempts to fuse several different practices, philosophies, and tools. It’s no coincidence that cloud computing and Agile software-development methods such as Scrum preceded DevOps. Organizations wanted to augment their ability to deliver applications, features, and technology services. DevOps represents nothing short of a fundamental rethinking of the way in which IT operates. (For a great read on the subject, check out The Phoenix Project by Gene Kim.)
In no particular order, organizations that embrace DevOps can expect to realize the following benefits:
- Delivering quicker and more frequently. By definition the payoff for Waterfall-based projects takes place at the end, if all. Organizations can realize benefits far earlier than with waterfall methods.
- Detecting issues and errors earlier. Let’s say that you’re thinking of purchasing a home. Isn’t it better to find a crack in the foundation as early as possible? What happens if you only discover it after you sign the mortgage? The same principle applies with software development.
- Developing a more holistic view of the enterprise. As Esther Shein writes, organizations “mov[e] away from managing IT via functional disciplines like data center, security and app development.”
- Achieving greater visibility and transparency. Incredibly, many organizations cannot document the state and progress of their IT efforts. With roots in manufacturing, quality assurance, and supply-chain management, DevOps seeks to minimizes waste.
Don’t expect DevOps to disappear anytime soon. The speed of business and tech isn’t slowing down. No, it’s not a panacea for bad management and awful ideas. Done right, though, DevOps makes for faster, better, and more transparent IT.
What say you?
In part two of this series, I’ll discuss some of the challenges associated with DevOps.
IBM sponsored this post. For more content like this, visit IT Biz Advisor.