Bankloch

Introduction With customers becoming more and more demanding, they expect their financial services to be 24/7 available. Unfortunately the current monolithic architectures in the financial services industry are not very   fault resilient . Banks and insurers have invested heavily in redundant infrastructure to increase the availability of their application landscape, but these investments only provide a solution for a limited set of failures (mostly the hardware failures). Any uncovered failures (like e.g. network issues, application failures due to software bugs…​) and maintenance activities (like software releases, operating system upgrades, database maintenance activities…​) still lead to service unavailability. With customers nowadays being used to 24/7 available, online services, like Facebook and Google, don’t understand anymore why banks and insurers are not able to provide the same levels of availability. This provides an extra argument (next to the need for increase

The dream of any product manager in the Financial Services sector has always been to   come up with an idea   for a new (or improvement on an existing) financial product or service in the morning and   have it implemented in the afternoon . Unfortunately the harsh reality is that   adapting the IT solutions typically takes months, if not years . Despite years of evolution in software engineering and the best intentions of all involved parties, the speed of software delivery has not much improved (if not to say worsened) in the financial sector. Introduction of new programming paradigms (Object-Oriented Programming, Event-driven Programming, Functional Programming…​), new implementation methodologies and organizational styles (Agile, DevOps, Extreme Programming, Development Anarchy…​), new programming languages (Go, Scala, Kotlin, Python…​) and new programming frameworks (Spring, Angular 2, React, Ruby on Rails…​) are the order of the day, but do not live up to their promises.