The Agile Manifesto’s mantra of “We are unlocking better ways to develop software” caused a thought revolution almost precisely fifteen years ago. Today, it is regarded in many places as a standard part of every progressive development houses’ style. The same can be applied to all the hype surrounding DevOps. Today, a modern IT operation is deeply dedicated to its topics of Agility, conveyed in DevOps.

It’s more than just joining forces

In practice, DevOps is more than just the joining of the forces between “Dev” (i.e. the project driven development) and “Ops” (i.e. the service oriented operation). It’s all about taking up the mantle of joint responsibility for a result – and rightly so. Beyond that, there are also changes, due to the associated automation. Now, better and more innovative tools and new roles come into existence, which can be taken on by developers and system engineers.

Due to the five core volumes with its currently 26 core processes of the IT Infrastructure Library (short: ITIL), the IT service management does already know of at least one fundamental process description that is latently similar to DevOps. Yet, there’s a difference to what was spread by the technical discussions of the past months. To choose between ITIL and DevOps is neither a question of faith nor is it a question of principal. Both approaches can even run in parallel; they aren’t so far apart from each other. Due to the upcoming ITIL update, they come even closer to each other. This update will introduce aspects of Agile into this new ITIL version, but also aspects of DevOps and Lean.

IT operations had also described change-processes by means of the ITIL framework and disseminated them in the ITSMCommunity. This happened for an especially long time through the itSMF (IT Service Management Forum). This way the stability of the operation – where software does develop the actual benefit for the end customer or user – doesn’t contradict the agility of the software development. Besides this, the matter of cooperation in IT didn’t only come to be with DevOps, it always has been relevant in successful organizations.  Teamwork itself is more of a cultural topic, but its process is being strongly accelerated by the digital transformation.

The stumbling block

Currently, inevitable changes of the companies’ culture are usually announced through discussions about tools. However, in the wake of these discussions there is also the need for an agreement on how to cooperate – and this applies in particular to DevOps. If operations and development can’t understand each other, then the entire company falters and loses its connection to the market.

Purely digital companies like the long-distance bus company FlixBus or the hotel reservation service HRS show that no new business is possible without any digital capabilities like mobile apps, platforms or high speed market access.

DevOps also leads to structural changes. It transforms a large IT unit into smaller teams. This creates a growing scope for creativity, which goes hand in hand with the increasing autonomy of these smaller competence-teams. But in order for this autonomy to succeed, the companies must also change former hierarchical ways of thinking. This must also happen among its employees and managers. For example, if DevOps requires cooperation but development and operations don’t work together for the sake of the overall success, then the project’s “sponsors” must escalate.

In these cases, all involved parties should meet in person to agree on common ideas for the cooperation. At the end of the day, that’s nothing new either. The introduction of DevOps is a change-project. Neutral consultants and a DevOps maturity model that is adaptable to the company or organization can support this.

From hype to living reality

Meanwhile the DevOps hype has become self-evident. Ops does take agile basic-tools of the development as facilitation for its own work; Kanban Board, Kaizan, Jira and Backlog are no longer foreign worlds. In Sprints, the cross-divisional tasks are processed together with the requesters, specialist departments, and the development. A translation into the respective other world has been omitted and any misunderstandings caused by underlying Stand-ups or Daily’s are quickly solved.

Furthermore, a positively integrated DevOps does create further scale effects, besides the significantly improved cooperation:

• The company is reducing costs, because losses through friction are going down.
• The software development units are gaining at least 20% more time to develop new features.
• Ops is no longer the last instance, in regards to new developments. Instead, Ops is involved right from the start, in order to address operational issues in good time, such as the need for stabilization patches, a timely firewall activation or ensuring the software application compatibility with the operating system versions of the production systems.

Reflecting on quality

An essential technological component of successful, high-quality DevOps is a tidy implemented and increasingly standardized CI/CD solution (Continuous Integration and Continuous Delivery Pipeline). It guarantees a fast and quality assured delivery of code via software to an operable application on the servers of the production environment. Speed is standard. Stability is crucial for the business. The CI/CD pipeline is also software, which is developed, maintained, and operated according to software methods. Freestyle pipelines are a thing of the past.

It’s also a thing of the past, that operations so far had no competences to master the development process. In return, the development doesn’t have to provide  a 24/7 operation and build-up of the service system structure. But where does that leave the present? Dev assumes more responsibility, in a sense of “You built it, you run it”, for the availability of the programmed application in the production operation. And Ops does further develop its ability to establish build- and deployment-processes as agile services.

Ideally, a DevOps team is a mix out of operations and test employees, as well as software developers and architects. In a best case scenario, the requesting product owner is also a part of this team. This creates the necessary, internal customer proximity, and also the innovations for the further development of the application software and the CI/CD pipeline that must also be developed in parallel. Working so close to the customer also requires pronounced communication skills. It’s no longer possible to hide behind the Ops’ console or the Dev’s programming code, because roles and competences have long since changed .

But what competencies are required to create such a high-quality CI/CD pipeline or to adapt it to business needs? Jenkins is often used as the carrier of a CI/CD pipeline, especially in the open source area. This is supported by the high number of plug-ins, as well as the extraordinarily high community support and the use in many commercial companies. Jenkins is also used to control other tools which also need to be mastered. The code management includes SVN and Git, the build creation includes Maven, and the software delivery on the server includes the tools Puppet, Chef and Ansible. Altogether, there are about 60 – 80 tools, which are bustling in this area.

DevOps finally becomes a highly professional DevOps, i.e. DevQOps, if the appropriate tests are integrated into the CI/CD pipeline: Functional test, load and performance test, code quality and security test. Other organizations or companies also speak of BizDevOps or SecOps. Here it’s the “Q” – for quality – that is the perfect crux of the matter, because the stability safeguards the basic values the DevOps philosophy to the outside world. The resulting internal effects are also quite important. By working on the same eye level, problems are addressed and solved immediately.

The time of ticket ping-pong is over. The result: fewer incidents and problems and a higher employee motivation. In concrete terms, this means that the system engineer reacts less to tickets and monitoring system and works proactively with Jenkins. This puts them right in the middle of the action and at eye level with everyone who is involved.

Trust remains an important value

Conclusion: In a digital world where technology is constantly evolving, the next level of the DevOps automation is supported by machine learning and the internet universe is endlessly expanding through the Internet of Things, it is human trust which remains as a necessary value for collaboration and, thus, for business success.

Trust results from transparency. Companies and organizations will have to leave old paths of silo thinking, isolation and demarcation and bring the employees of their departments and suppliers or partners together. This places a high demands on data protection, purchasing and corporate cultures. DevQOps in the described way can be an important building block to exemplify the necessary model.