Blog article
See all stories »

DevOps: Are we there yet?

I vividly remember my meeting with the newly appointed CEO of a regional Telco in continental Europe late in the summer of 2012. The CEO looked visibly worried when he entered the room. As it turned out, he just met his CMO to discuss new product offerings for Christmas, which he thought were for the same year but were actually for the following season!! 15 months, from concept to launch, for product promotion at a midsize Telco seemed wildly unsustainable. Then to think of competing with new-age technology companies like Google, Facebook, Amazon and others that launch new offerings seemingly every few seconds! Little wonder why Agile & DevOps are the “IT” buzzwords for banks and financial services conglomerates.  FinTechs and challenger banks are setting new standards for business agility and customer centricity.

Over the past few years, bank IT executives have invested a lot of money and intellectual time creating Agile and DevOps teams to build the digital ‘bank for tomorrow’, but the question management is now asking to the CIO is – “Are we there yet?” If the answer is yes, then how does a CIO prove that the investments he or she made have genuinely transformed the IT organisation into a more Agile entity - beyond just the application release level?

I am not questioning the merits of DevOps, but simply challenging the view that success (or even progress) in DevOps cannot be measured by traditional KPIs, or even simple ones like number of releases, mean-time-to-release, etc. Just because your IT team is releasing more frequently does not guarantee they are more productive! Having made the DevOps investment, organisations need to understand whether they are actually more Agile or if they are expending all their energy without actually moving, like running on a treadmill.

Is DevOps providing value?

In an Agile DevOps environment, establishing the right KPIs early is vital to long-term success. Additionally, technical debt and complexity measurement must be considered. Without a technical debt baseline, you can't know for sure if your DevOps team is running an app cheaper, better, faster or if the app is simply accumulating Technical Debt at a faster pace than before.

This baseline can be achieved by running an analysis on the existing applications to produce a set of results which will then guide the process. One of the aims of DevOps is to improve the code base and prevent defective code from creeping into the foundation of mission-critical systems. This will drive support costs through the roof.

One way of addressing this is to implement a framework that provides greater visibility into the performance of DevOps production. Testing in DevOps is, and should be, focused on meeting functional requirements, however the only way to know for sure that any lingering code defects have been stomped it is to conduct a non-functional software analysis.

What does success look like?

Some financial services organisations that have adopted DevOps have seen a significant boost in developer productivity. Early adopter banks have seen processes that used to take six months (some still do for their core back-end applications) come down to six weeks. Fannie Mae, the US Government-sponsored Financial mortgage organisation with over 7,000 employees, has doubled its software output in the last 18 months.

In a world where agile challengers are coming to market quicker than ever, DevOps presents both an opportunity and a risk. A fast, but flawed application release will damage a traditional bank far worse than at a start-up. Implementing the right KPIs to manage and monitor progress helps achieve the vast benefits of DevOps while minimising risks and proving value to the C-Suite. When done correctly, bank IT executives don’t have to sacrifice quality for speed. 



Comments: (0)

Now hiring