Two of the recurring themes that come up in banking technology strategy discussions relate to the drive away from Waterfall and towards Agile project delivery whilst, in parallel, driving away from recovery towards greater technical resilience. I believe that it is important to look at these two strategies together to ensure that there is congruence between these strategic goals. In this article, we look at waterfall vs agile project delivery.
Banks have significant estates of legacy applications and services, which are not yet fully re-architected to support continuous integration and the resilience movement. Any attempt to demonstrate agility through frequent code releases, outside of more traditional release management processes, could actually lead to even greater instability that is unlikely to be mitigated by greater technical resilience.
Agile delivery is critical for "speed to market” and for keeping up with an ever-changing world of client expectations, emerging competitors and regulators. Banking technology history cannot be rewritten overnight. The cost of believing that agility and resilience can be achieved through driving aggressive programs, designed to instill a new culture and ethos, could be flawed and inadvertently lead to greater change instability in the short to medium term.
Legacy platforms, until sufficiently re-architected, will continue to need the due diligence associated to planned releases and clear plans for recoverability. The Conduct Risk agenda requires us to ensure that major technology changes are made with integrity that safeguards both our clients and employees. Reputations are hard won and easily lost through poor change execution.
What are your thoughts? Let us know in the comments section below.