Blog

Demystifying DevOps, an architects's perspective

We all want to develop better software, faster—not just for the sake of having cool software, but because we use software to solve business opportunities and to create competitive advantages for companies. DevOps is a much-used buzzword that gets thrown around when talking about ways to deliver software more quickly—but there are misconceptions about what it is and what it is not.

First of all, let’s talk about how enterprise software development used to work. Using what’s called the waterfall method, a company would identify a business need that could be addressed by software, build out a list of requirements for the software, procure funding and then throw the entire project over the internal wall to the development group.

The developers would then work on the project, and when their software was ready, they would hand it off to an operations group, who would install the software, make sure the storage and compute resources were sufficient and then delivered a production-ready piece of software that could be tested by the business group.

This process took three or more years, and according to a report from the Standish Group, “The results for all projects show that agile projects have almost four times the success rate as waterfall projects, and waterfall projects have three times the failure rate as agile projects.” Only one out of 10 enterprise software projects developed using a waterfall method solved the business problem or addressed the opportunity that they were meant to solve.

Looking for a Better Way

Given this abysmal success rate, it’s no surprise that companies started looking for ways to both speed up software delivery and also improve the success rate. Many implemented an “Agile” approach, based on breaking things up into smaller chunks, trying to provide incremental value, breaking down business silos and “failing fast.” This last piece is remarkable because determining early on in the process that a piece of software doesn’t solve the business problem is a step towards a higher success rate. Indeed, this improved the business success rates by 355% compared to projects run using the waterfall methodology.

However, even as business people and developers were working together to solve business problems with software, the operations team often wasn’t involved. Once the software was ready to go, Operations ported the code to production, monitoring it and fixing problems when the application didn’t meet customer needs.

The next step in the evolution of the software development process has been to bring everyone together, integrating not only the business side into development work but also bringing in operations and security experts. This paradigm shift is called DevOps. When done right, it can dramatically decrease release times and increase business success.

Addressing Misconceptions

There are thousands of DevOps tools out there to help companies delivery software smarter, better, faster and cheaper. If companies don’t get the fundamentals right, however, tools matter very little.

DevOps is not a tool. It’s not a pipeline management tool, and it’s not a new platform or a type of container orchestration. At its core, DevOps requires a cultural change. Without this change in company culture and organizational structure, all the DevOps tooling won’t get the results that businesses today expect.


  The mistruth that is harmful is that the benefits of Agile software development or DevOps software delivery will be fully realized by the business and end users without further changes to the entire organization.” (source Plutora.com)

Implementing DevOps means redesigning how your teams are structured. It means creating groups who, together, have all the expertise necessary to bring a piece of software from idea to reality, including at the implementation and monitoring stage—and to do so in a safe, secure and compliant way.

It also requires changing the way large companies control projects and funds. If a DevOps team that has to wait months to get sign-off on a project or get the OK to spend X amount on resources, the speed advantages of the DevOps system (and any tools you have implemented) evaporates.

In surveys, it turns out that only around a third of companies that have implemented DevOps achieve the value they expected, while 37% don’t see any value at all in DevOps. That’s probably not because DevOps doesn’t work, but because they aren’t making the fundamental corporate changes needed to make DevOps successful. TechRepublic survey shows that 22% of companies using DevOps end to end. The biggest issue is that the barriers between developers and all of the operations groups still exist.

Breaking Down Barriers

The key to success in DevOps is to focus on breaking down barriers between parts of your organization. Purchasing a new tool is easy. Fundamentally changing the way not just that your IT division works together but how the entire company functions to get things done is hard.

One of the most significant barriers is the “you don’t have the knowledge” excuse used to block cross-functional groups. standishreportTreating infrastructure changes like changes to software code is a way to get developers and infrastructure and operational staff on the same page. The challenge is that there are so many tools that all have to be changed to support each application that maintaining the software as code becomes a problem. Software services like Agile Stacks embed both methodology and tools to maximize a DevOps-first approach to infrastructure-as-code. The Agile Stacks platform subscribes to the Git philosophy of complete version control and code governance. This new type of automation powering continuous software delivery is the missing piece to keep IT staff focused on DevOps to solve business problems and not on maintaining a stable DevOps toolchain.

Getting the most out of DevOps requires more than operations and development working together—there has to be input on the business logic driving any particular feature or application development that comes from outside IT. Developers need to be tuned in to how their code fits into the overall business goals.

Neither developers nor operations specialists can ultimately decide if an application is a success, business-wise. They can evaluate the technical merits of the application, see how frequently there are errors, see if it causes any outages. However, to ‘fail fast’ in a business sense, you need input from sales, marketing, support and other stakeholders who are better positioned to see how end users are reacting to the new functionality.

Establishing this kind of tight feedback loop, that involves developers, operations, security, business, and customer input, isn’t how large dev teams traditionally collaborated; if at all. In order to get the full benefit out of DevOps tools—including Agile Stacks—re-examining how the company collaborates is essential.

The good news is Agile/DevOps are worth it to the business. Those companies who indeed implement a DevOps approach, both in practices, applications and in culture, can deliver value to their customers much faster, take advantage of opportunities and build a competitive advantage on providing appropriate technology solutions for customer pain points, faster than anyone else. Publicly accessible data like the Standishgroup reference proves that Agile can achieve greater success than Waterfall if added tools like Agile Stacks automate parts of DevOps. Your projects could achieve >50% success over unskilled DevOps staff and 27% over competent DevOps staff. 

Topics: Cloud, CTO, DevOps First, DevOps Automation

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all