False Certainty: The Monolith Made Me Do It
Simon Taylor
Co-founder 11:FS & CPO 11:FS Foundry
How do I create the 5 year plan for 8 software releases a day?
This is one of my favourite lines from an old school bank executive. It happened live on stage in front of 500 people when I made the point that challenger banks are now operating at 8 releases per day. It might seem nerdy, but why does it matter how often banks release new software?
It helps to understand the context and the problem. When I say "software release", I don't mean the mobile banking apps (although I guess you could count those too). I'm really talking about the spiders web of internal systems a bank has that built up like sedimentary rock over the past 5 decades. As we've mentioned before, most banks weren't born digital, they were digitised.
Many were digitised (or even born) somewhere between the 1970s and 1990s. At the time the best solution for mission critical, countrywide payments and banking systems was the mainframe. These giant, bullet proof systems are frankly incredible bits of history. The entire global economy ran on computers less powerful than your phone. They were big and bulky but they were bullet proof (yes I love alliteration).
Back in the 1970s software engineering wasn't quite the craft it is today. The way we used to write code was long line of complex interlinking loops. Did you ever see that Toyota advert where an impossible sequence of events are strung together to eventually turn on a lightbulb? Imagine that. Or imagine if books had no system of chapters and verses. These monolithic coding structures meant everything was interconnected, hard coded and welded together. It worked but it had problems. If one system went down, it had the potential to take all of the rest with them. It was (and in most cases still is) a precarious situation banks find themselves in.
The way you manage complexity is with a complex and complete plan (alliteration win). In practice this means weekend outages, preceded by months of planning. Oh, and you don't want to be taking systems down *every* weekend, so you plan them, months in advance, maybe even do one per quarter and wrap all the changes into that quarter. It's natural then we look for lots of certainty when this is normal. In a world of so much complexity, bank execs crave certainty, 3 year plans and comfort that if they take the systems down they're not going to find themselves all over the press in the coming days. Tech change in banking manages the scary and the dangerous with people, plans and plodding release cycles (ok I'll stop now with the alliteration)...
There is another way - and it's here to stay. You may have heard the term ‘Devops’, ‘lean’, ‘Agile’. (Let's set aside how abused those terms are and how little I think the concepts have been grasped, or how they terms have been marketed to sell more 3 year plans and false certainty for now...) These terms evolved as programming techniques changed, especially after the advent of cloud service providers (such as Microsoft, AWS and Google). The concept of "microservices" (which we covered in our cloud podcast), turns the idea of the giant monolith on its head. Instead of painting the Mona Lisa and moving it under high security. Microservices is a jigsaw-like approach. Breaking up the functions of technology into small discreet little bits of code that are aware of the services around them, know what to do if they fail and that can have many copies.
Put another way, imagine a bank has a ‘check the price of the US dollar’ software blob. In the monolithic world, changing the way the check price of the US dollar service works would mean: waiting for the outage, planning when you made the change (in line with all of the other changes), and managing all the other bits of the bank that need to talk to that service. You find yourself spending forever figuring out what on earth is going on. It would help if someone, anyone, knew. The reality is most of the people that know how the monolith works have retired, and that’s part of what led to the COBOL cowboys. In the Devops world, the ‘check US dollar service’ would have 10 twins. You could take one of those 10 twins down, change how it works and see if it breaks anything else. If it did break something else, that something else has 10 twins that aren't using the new service. So to the outside world, everything continues as normal. The world has changed. Start-ups are really beginning to challenge the incumbents in many industries and the big tech players too are all using this ability to deploy rapidly, up to 8 times a day to compete in a way that traditional banking and FS competitors couldn't. When the world moves faster it becomes less complicated and becomes more chaotic. A chaotic world requires more experimentation than it does planning. If an organisation is looking for a 3 year plan in a more chaotic market, it will be out of date long before the product is launched. Banks have evolved their entire management structure around budget cycles, and programmes that require 100s if not 1000s of people to manage how precarious changing the monolith is. But we all know it's not real certainty. When the shit hits the fan, people get their hands dirty and code. The real question is, how can a bank or FS company deliver at pace without wrecking the place? But that's a question for another day. If you want some insight into the answer and can’t wait then get in touch at hello@11fs.com and make sure you sign up to our newsletter.
The tech made us
Back in the 1970s software engineering wasn't quite the craft it is today. The way we used to write code was long line of complex interlinking loops. Did you ever see that Toyota advert where an impossible sequence of events are strung together to eventually turn on a lightbulb? Imagine that. Or imagine if books had no system of chapters and verses. These monolithic coding structures meant everything was interconnected, hard coded and welded together. It worked but it had problems. If one system went down, it had the potential to take all of the rest with them. It was (and in most cases still is) a precarious situation banks find themselves in.
Managing the precarious - with lots of planning!
The way you manage complexity is with a complex and complete plan (alliteration win). In practice this means weekend outages, preceded by months of planning. Oh, and you don't want to be taking systems down *every* weekend, so you plan them, months in advance, maybe even do one per quarter and wrap all the changes into that quarter. It's natural then we look for lots of certainty when this is normal. In a world of so much complexity, bank execs crave certainty, 3 year plans and comfort that if they take the systems down they're not going to find themselves all over the press in the coming days. Tech change in banking manages the scary and the dangerous with people, plans and plodding release cycles (ok I'll stop now with the alliteration)...
Banks wanted certainty: What was right is now wrong.
There is another way - and it's here to stay. You may have heard the term ‘Devops’, ‘lean’, ‘Agile’. (Let's set aside how abused those terms are and how little I think the concepts have been grasped, or how they terms have been marketed to sell more 3 year plans and false certainty for now...) These terms evolved as programming techniques changed, especially after the advent of cloud service providers (such as Microsoft, AWS and Google). The concept of "microservices" (which we covered in our cloud podcast), turns the idea of the giant monolith on its head. Instead of painting the Mona Lisa and moving it under high security. Microservices is a jigsaw-like approach. Breaking up the functions of technology into small discreet little bits of code that are aware of the services around them, know what to do if they fail and that can have many copies.
An example: monolith vs devops
Put another way, imagine a bank has a ‘check the price of the US dollar’ software blob. In the monolithic world, changing the way the check price of the US dollar service works would mean: waiting for the outage, planning when you made the change (in line with all of the other changes), and managing all the other bits of the bank that need to talk to that service. You find yourself spending forever figuring out what on earth is going on. It would help if someone, anyone, knew. The reality is most of the people that know how the monolith works have retired, and that’s part of what led to the COBOL cowboys. In the Devops world, the ‘check US dollar service’ would have 10 twins. You could take one of those 10 twins down, change how it works and see if it breaks anything else. If it did break something else, that something else has 10 twins that aren't using the new service. So to the outside world, everything continues as normal. The world has changed. Start-ups are really beginning to challenge the incumbents in many industries and the big tech players too are all using this ability to deploy rapidly, up to 8 times a day to compete in a way that traditional banking and FS competitors couldn't. When the world moves faster it becomes less complicated and becomes more chaotic. A chaotic world requires more experimentation than it does planning. If an organisation is looking for a 3 year plan in a more chaotic market, it will be out of date long before the product is launched. Banks have evolved their entire management structure around budget cycles, and programmes that require 100s if not 1000s of people to manage how precarious changing the monolith is. But we all know it's not real certainty. When the shit hits the fan, people get their hands dirty and code. The real question is, how can a bank or FS company deliver at pace without wrecking the place? But that's a question for another day. If you want some insight into the answer and can’t wait then get in touch at hello@11fs.com and make sure you sign up to our newsletter.