In many financial firms, there is a clear distinction made between “Change the Bank” (CTB) and “Run the Bank” (RTB) investment. CTB is generally taken to mean the costs associated with building new systems and subsequently making significant changes to them, whereas RTB usually means the operating costs associated with existing systems.
This distinction has often given rise to separate “Change” and “Run” organisations with their own sub-cultures and ways of working, which makes it harder to tackle the challenges of legacy systems. How did we get here?
Some of the factors that have driven separation are:
Segregation of duties. Financial firms have segregation of duties between front-office and back-office functions, which is designed to improve accountability and control as well as reduce the risk of fraud. Similar concepts are often applied to prevent developers from directly making changes to production systems.
Perceived differences in skillset and cost profile. The skills that are required to run systems are often perceived as being more commoditised and therefore cheaper than the skills required to build and change systems. This tends to lead to Change and Run being viewed as different animals.
Offshoring. It is often perceived to be easier to outsource support and maintenance to lower-cost and geographically remote third parties and therefore realise cost savings. This can literally create separate organisations for Change and Run.
The “Built Once” fallacy. There is a persistent misconception that systems are “built once” and then go into “support and maintenance” for the rest of their operational lives. Again, this reinforces the idea that Change and Run are two different things.
Budgeting. Organisations often build separate budgets for CTB and RTB. There is a popular view that change is discretionary and, conversely, that RTB is mandatory. This tends to incentivise the over-estimation of RTB costs and under-estimation of CTB costs, as well as reinforcing the separation of Change and Run.
So, what can be done to break down these walls? Fortunately, there are some key trends that can help:
Agile adoption. Many organisations have adopted agile ways of working, particularly in delivering technology-dependent projects. While there are different methods, a fundamental theme is to build multi-skilled, cross-functional teams and empower them to solve problems end to end, from idea to production. Such teams often cut across organisational boundaries and can help break down silos.
The rise of DevOps. Cultural change born out of the recognition that delivery of software from idea to production requires integrated pipelines and processes with minimal friction. Organisational barriers increase friction significantly, so segregated organisations are counter-cultural to DevOps.
Evergreen thinking. The increasing recognition that systems are not “built once” but continually evolving to meet changing business requirements. This has given rise to concepts such as “evergreen architecture” – it needs to be refreshed and kept current throughout its life.
Tooling and automation. Vast improvements in tooling mean that Continuous Delivery has become an everyday reality, particularly in large-scale commercial cloud environments, where quality and repeatability can be easily built into pipelines without relying on expensive and ineffective manual checks and processes. This enables the “safety” of segregation of duties without the cost and friction.
Focus on total cost of ownership (TCO). Makes it easier to see costs across Change and Run and better understand their drivers, e.g. high defect rates that result in increased operational costs due to manual workarounds. To get a true view of your TCO, you need to look across the whole lifecycle.
What can you do in your own organisation? Here are some practical steps that you can take to help break down walls between Change and Run.
1. Understand your path to production. Identify the different parts of your organisation that are required to get from idea to production and get them involved.
2. Empower your teams. Establish multi-skilled teams and empower them to solve problems across organisational boundaries. Don’t try and re-organise everyone overnight – start somewhere meaningful, prove it can be done and build up from there.
3. Remove constraints. Where is the organisational friction in getting from idea to production? Are governance forums effective, e.g. in reviewing hundreds of changes? Can testing be automated?
4. Understand the cost drivers. Work out your TCO and understand its drivers to help you optimise costs overall, rather than simply cost-cutting on a localised basis.
5. Learn from others. Endava has over 20 years’ experience of delivering mission-critical software systems for our clients. We provide thought leadership and multi-skilled agile teams that can deliver technology solutions to business problems in a cost-effective way with all the capabilities required. We have extensive experience with evergreen architectures, automation and DevOps, making Continuous Delivery a reality.
In conclusion, there are many factors that have given rise to the separation of Change and Run in many organisations. While this separation is not easy to overcome, the evolution of architectural and DevOps thinking as well as the adoption of agile and modern software engineering tools and practices are making it more straightforward to adopt true idea-to-production approaches to building and operating systems. This creates an environment in which it is easier to break down walls between Change and Run and address legacy systems issues.
