Coined in 2009 by Patrick Debois, DevOps is the continually growing, agile approach to software delivery. A portmanteau of development and operations, the idea of DevOps comes from the kind of agile development that allows holistic software delivery.

The truth is that in the decade since the term DevOps was coined, it has become more and varied than it was ever conceived could happen. In fact, depending on who you talk to, you may not even be able to find consensus as to what DevOps actually are.

So we’re calling it. DevOps is dead and in this article, we’re going to bury it.

Kinda.

A Brief History of DevOps

In 2009, Patrick Debois encountered a talk by a young tech guy called Andrew Clay Shafer, and for the most part, the rest is history. Shafer and Debois found themselves sharing an ethos for agile team administration.

Debois would go on to try to mitigate the sometimes fraught and often combative relationships between the development team and the operations team. He realized that the disconnect between the two stations, and the limitations of a waterfall workflow, were hindering rather than helping employees. Instead, he suggested DevOps as the place where development and operations meet to incorporate agile working methodologies and best practice.

Deboise was certain that DevOps had the potential for increasing efficiency while lowering delivery risks. By automating the process between software development and IT teams, DevOps is a set of practices and an ethos around building, testing, collaborating, and releasing software both more securely, and more efficiently. Rather than allowing IT and business teams to continue to exist in silos, DevOps was designed to increase conversation, collaboration, trust and openness between the teams, to the benefit of both.

And it was great. For a while.

So what’s the problem?

At its start, DevOps had a purpose, and a clear aim: It sought to break down silos in organizations in order to create better quality code and more effective systems. Unfortunately, as things tend to go, DevOps downfall has been in its success.

Rather than incorporating the DevOps mindset of collaboration, trust, and effectiveness as a something you are, DevOps has instead become something you do. More and more companies hire specifically for a DevOps role, rather than that being a skillset or even attitude that somebody can bring to the table.

On a surface level, this may not seem like a problem. This attitude towards DevOps turns it into a process revolving around tooling. Ignored on a cultural level, this kind of agile creativity is instead turning into a burden or a series of hurdles, rather than something to help the overall software build.

Through its legitimizing, DevOps has actually turned into something that it was never meant to be. Far from the safe, secure, time-crunching attitude that could improve delivery, it is now a vague phrase that people feel like they should know something about.

Yet perversely, that doesn’t mean that DevOps doesn’t have a place in the 21st century. Instead, it simply means that it is mutating, shifting slightly into something a little different. It’s fair to say that DevOps has had a rebrand.

Not Gone, Not Forgotten

Let’s just say it outright. If people think including DevOps means just pulling in an automation system, then they’ve missed the point. Rohit Antao, partner and enterprise DevOps solution leader at PwC says that "A lot of organizations have gone down this path, approaching it as a pure technology play—let's get a DevOps tool, and life will be so much better.”

Mark Warren at Perforce puts the problem even more bluntly. As far as he is concerned, DevOps is "a thing everybody wants but nobody wants to do.”

Rather than bringing about a superficial change of job titles - throwing in someone in charge of DevOps and calling it a day - it’s important to understand that DevOps is as much about the relationship between teams as it is about one particular job or role. Far from actually being dead and gone, DevOps is more like an energy conversion as it feeds into the kinds of existing roles that you’ll find in agile teams - from product and engineering to QA and operations.

The future of DevOps, just like its original existence, lies in its ability to be agile, versatile, and collaborative. Through incorporating the attitude and methodology behind DevOps, and integrating it with existing job roles, it’s possible to reap the benefits of automation and programming, while also increasing agility and efficiency.

The future of DevOps

The future of DevOps is going to continue to evolve. Tech Beacon has highlighted the seven positions that will be necessary for the success of teams in general - and the way in which DevOps can improve and support the team going forward.

1. The Evangelist

In order to truly live up to its potential, it’s vital that DevOps is presented by somebody who understands the full capabilities of the systems, while also being able to identify and quantify the benefits for the business. The DevOps Evangelist leads the way by promoting the benefits and being able to ensure that both the development and operations teams are on board.

The role of The Evangelist is also to make sure that the teams are trained and empowered, and that those teams have what they need to really fulfill their purpose. Fundamentally, The Evangelist is the leader who can excite people across both teams, as well as C-suite, into understanding that DevOps is as much about a method of working as it is about particular tasks or structure.

2. Release Manager

This is a role that could come under a variety of names:

  • Release manager
  • Release engineer
  • Product Stability manager

What’s important is that the purpose of this role is to look at how the product is managed and coordinated from development to production. This is a role which oversees production and workflow on a far more granular level than a project manager, looking at the technical details and hurdles - not just on making the product but on supporting and upholding the entire chain.

3. Automation Architect

If you’re going to have a system which relies hugely on automation, it’s a bit of a no brainer that you need to ensure that the automation is built successfully. Also known as integration specialists, as the name suggests, their role is to analyze, design, and then to implement the necessary strategies for making sure there are continual deployments.

This is a role which becomes even more important if there’s a remote team or wide geography within a team. The automation architect builds the automation superhighways and then keeps them clear so that the developers and testers and work quickly and freely, uninhibited by roadblocks.

4. Software Developer/Tester

At the center of the DevOps structure is the software developer or tester. However, far from in other teams, the role of the developer/ tester involves a much broader scope of roles and responsibilities. Instead of being simply about writing code, it’s important that the developer/tester engages with testing, deployment, and monitoring.

This is where the architect’s automation is vital. When you have developers/testers who are working on testing and monitoring their own code, while also building new work, it’s impossible to also engage with manual testing and staying agile.

However, a successful architect can ensure that developers/testers can continue to work at their best pace, without the quality of their work suffering. This is a really poignant example of how the DevOps environment builds a system of reliance, teamwork, and trust across teams and silos.

5. XA Professional

So if the developer/tester can engage with quality assurance, DevOps effectively reduces the need for QA testers. Instead, what is needed are XA experts. Confidence in the functionality of the team and the product is instilled from jump - but an XA expert will ensure that nobody loses focus on the importance of the end user. It’s also vital within a team that is focussing inwards on the creation of the product, that you have a member of the team looking outwards at the end user, and ensuring that they are being delivered something that does what is promised.

6. Security engineer

Because of the way the DevOps model works, system security should be baked in every single step of the way. Far from going in at the end in order to tack on something that might be necessary, the security engineer’s job is to work alongside developers and embedding security in as part of the system.

This kind of agile thinking, and team development means that you are less likely to create a product with gaping security holes that can go unmissed when the job is seen as a formality at the end.

7. Utility Technology Player

No matter whether their background is in IT development or operations, a successful DevOps team needs versatile and talented team players who can operate across different tools, platforms, networks, and teams. Sometimes known as DevOps engineers, they are an integral part of sprint planning and ensuring that quality, resources, and security are prioritized as a matter of concern for the business.

Their job is to make sure that they can speak up and represent for their team, and include the DevOps ethos across the organization. In many ways, they prove the point of The Evangelical - creating a hybrid, cross-thinking way of working that inspires all teams to work more collaboratively and with more understanding.

New DevOps, who dis?

In the end, it’s no longer effective for teams to be solely focussed on one task, before passing it onto another department. This factory line processing is something which DevOps is challenging.

The most effective transition to DevOps working has everything to do with the people involved and their working methodology than it is about the need for automation. Instead, as DevOps develop and progress, we’re much less likely to see DevOps as a specific job, but return it what it was always intended to be: A way for teams to work closely, and for team leaders to empower and celebrate the diversity of their team’s abilities.

DevOps is dead, Long live DevOps!