Women in Financial Services
How do you build resilience in the system architecture?
Katie.Dix / 14 Apr 2021
How do you build resilience in the system architecture?
Answer.………………Through Failure, Freedom and Chaos!
Think about designing and operationalizing a system which has resilience as a central theme. Will the system work under stress? Will it be able to bear the burden? Will it smoothen itself out after few hic- cups or will it just fall of the cliff of trust?
A great way to build elasticity in systems is to contextualize their functions just like organic human muscles. Anecdotally, if a muscle is not used much it ain’t suitable for stress endurance on a marathon! So if you applied a mind set while building a system that performs excellently but not under stress well it ain’t good because it has not been conditioned for Anti-fragile performance.
What about robustness? Most monolithic data architecture systems were robust but then their reputation tapered as they slowly and quietly starting becoming redundant with the passage of time. Was age the real reason for their demise? No. such systems were simply built to satisfy the ‘to-do-list’ workmanship and their performance was good under stress but only upto a point, beyond which it simply wasn’t robust enough.
Things that are robust actually perform okay under stress, but they do deteriorate over time. And then, things that are built for buffer have the ability to absorb stress to a certain point and then they kind of fall off the cliff. But agile systems, are those things that under stress get better, just like biological systems. Hence the example of a muscle. Think in terms of elastic and not plastic. Moving not stationary, evolving not stagnant. Its time for your organisation to move away from cost efficient systems all the way to systems that can be replicated, fast.
Agile has anti-fragility in its operational capability because of the fact that it learns as it goes. Agile engineering is actually very different than lean and traditional because every one of the features has its own services, not shared (mostly). The idea is that small changes to any one of the features, even when completely built, will have very little cost because you won't have to change the rest of the system and test the rest of the system to make sure that it works. You can release features very quickly. Think of decoupled and independent.
Agile engineering should have tiered architecture that has services at the base, features build on top of those services and apps using those features. What you are essentially doing is adding freedom and responsibility in the tech stack. Giving freedom to your engineers to build not explain, be ready to fix not pass it on to a BAU team. Operationalize and not just test what they build. Its a culture change. A mind set change. Empowerment in your engineering teams is to get the specialist skills own their skin in the game. Speed and scale will follow them! If your org is not doing it already then you need a new way of working to be able to move and break the existing barriers.
Does your tech team use the Chaos Toolkit available on open source? Go check it out. It is an ideal concept to design solutions thinking empathy, idea, user, prototype and testing as the core theme but if you don't fail, test, fail and break what you build, enough, you have not build resilience into the system. Designing is a social process but building resilient systems is a bit like testing the boundaries of freedom by being an extremist sometimes or an anarchist. A resilient system architecture needs a dose of rebel trouble in enough good order so that all your services , features and apps can stand on its feet when things start falling apart.
About Nidhi Nikum
I help Heads of Credit Risk & Capital at Investment Banks, reduce Reg. Capital by up to £180M and cost of Credit regulatory performance by c. £500K per annum by leading Transformation.
Back to blog