Is DevOps the Master Key to Everything?

We were once asked by a student during a training session of his problem. He manages the Quantitative Trading Desk for the company and recently a long-waited automated IQS (Interdealer Quotation System) is deployed, which should have increased their work efficiency and accuracy significantly. Soon after the team started using the new app, they realized the rounding methodology is not set to be consistent with the counterparties. They can rectify it with Excel but that creates one extra layer of works.

The manager came to IT team for help. The reply is that it’s a feature requirement not a break fix, and the original project team is now dissolved and reformed for other projects so the feature needs to wait.

One word might have crossed your mind at this point as a potential solution, DevOps.

What Is DevOps?

The story began way early on 2007, Patrick Debois, a Belgian software developer, was caught up in the conflicts between developers and system admins when consulting on a data centre migration project for the government. He shared his frustration with Andrew Shafer at 2008’s Toronto Agile Conference, together they formed the Agile Systems Administration Group.

One year later, group members John Allspaw and Paul Hammond give their famous talk on Flickr’s collaboration of Developers and Operations at the O’Reilly Velocity 09 conference. The talk inspired Debois to come up with the term “DevOps” which is first brought up in October 2009. Since then, the concept has evolved and gained popularity among organizations looking to improve their software development processes and streamline communication between departments.

It Works, Until It Doesn’t

The application of DevOps effectively bridges the information gap between the development and operation ends, improves collaboration between teams. DevOps seems to be the universal solution for application development, our Quant Desk manger should have maintained a hybrid team to nurture their new initiative.

The concept sounds bullet proof. In reality, companies try to implement DevOps by grouping developers and operations under the same management. What we often observe is that operation folks are constantly putting out fire, which is started unintentionally by the development specialist. The gap of communication is even wider than when they were in separate teams.

DevOps Is More a Culture Than a Methodology

Don’t get me wrong, I am not against DevOps. On the contrary, I am a true believer, as the spirit of DevOps comes from Agile manifesto. Let’s recap what those 17 software developers had pledged some 20 years ago. The first line of the famous manifesto reads: Individuals and interactions over processes and tools.

DevOps emphasizes on communication and collaboration for people having different skill sets, different roles and responsibilities. The better they understand each other’s work, process, priorities etc., the more synchronized and fast responding they can be in facing the complex and ever-changing business environment. DevOps requires a cultural change led by examples from executive levels. It’s a journey of continuous learning, and continuous improvement according to the needs of the business and organization.