Blog article
See all stories »

Core banking: no more lipstick please

Traditionally, core banking systems have been developed as large monolithic systems. There are a few issues with this approach.

- To scale such systems, the only way is to scale vertically, i.e. use larger and larger hardware, whether it be mainframes or UNIX systems. The cost of such vertical scaling is exponential.

- The more and more changes that are applied to such systems, the more and more difficult, costly and risky it becomes to change these systems. At some stage it becomes impossible to change and a replacement is required.

- Such systems are also typically built by quite hierarchical organisations. According to Conway's Law, the systems that are built by an organisation mimic that organisation's communication structure. An organisation where communication is difficult will build a system that is typically monolithic.

About 10-15 years ago there was a push towards SOA. Very good ideas but generally poor implementations and very much driven by vendors who were pushing their enterprise service bus (ESB) and middleware solutions. Rather than using the middleware as a way to allow systems to communicate with each other, people implemented business logic in this middle layer because the underlying systems were too difficult to change. This just tied the systems together and the result was still a big monolith, difficult to change. As the saying goes, you can put lipstick on a pig, but it's still a pig.

Over the last 3 to 5 years there have been a few important changes in the way software systems are built.

- The practice of Continuous Deployment is becoming more and more popular. In CD, one considers that any change, however small, should be a possible release candidate. So rather than waiting and accumulating many changes for months and then doing for example quarterly releases, every change can be a release. To enable this, we need to automate the whole pipeline from code change, via automated testing, to release.

- Micro-services, an evolution of SOA, has seen the light and pioneered at institutions such as Twitter and Linkedin. The idea is to break down a monolithic system in small parts according to business functionality provided. A micro-service is a service like in SOA but the important thing is the 'micro' part, it does something small but it does it completely and it does only that. Another important aspect is the communication between micro-services. It uses lightweight protocols such as REST and publish subscribe messaging systems such as Apache Kafka. No more big ESB's. A micro-services approach aims to build a system that is loosely coupled and highly cohesive which is what software architecture is all about. Changing such a system is much easier since changes will typically only need to be made to certain micro-services without upsetting the whole system.

- Thanks to the openness of micro services and API based services, building a system is now more about assembling services rather than building things from scratch.

- Today, organisations have increasingly flatter structures which improves communication, something which we then see reflected in the systems that are built. Combined with the micro-services and continuous deployment approach, you see smaller teams taking end to end responsibility for small parts of the system. In some organisations, such as Amazon, teams are responsible not only for developing something but also for running it in production. Contrast this with organisations where you have a team of developers and a support team.

- New technologies such as Docker make it very easy to implement and deploy micro services as stand-alone entities. Micro-services can be easily distributed over different systems using technologies such as Docker containers.

- Cloud providers have evolved a lot, see for example how easy it is start up a system on Amazon Web Services.

All of this evolution has resulted in the fact that - with the right tools - we can now easily build distributed open systems and run them on cheap hardware and scale them horizontally (add more cheap boxes). So we no longer need the mainframe and large UNIX systems from before.

Of course there are some drawbacks to this as well, but let's leave that for another time.


Comments: (7)

Rodney Farmer
Rodney Farmer - Realtime Transactions - Little Rock 08 March, 2017, 10:44Be the first to give this comment the thumbs up 0 likes

To the extent everyone cludged their middleware/ ESB does help the case, but enterprise scale, security, and resilience of a well-architected infrastructure remain the best answer for universal bankers. As micro-services are packaged together in great numbers and volumes, we are likely to find those drawbacks you mentioned in the last sentence.  

A Finextra member
A Finextra member 08 March, 2017, 11:05Be the first to give this comment the thumbs up 0 likes

Thanks for the comment Rodney. It is interesting to see how some of the ESB vendors of yore are rebranding their solutions as service delivery platforms, claiming they've been doing micro-services for years.

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 08 March, 2017, 15:37Be the first to give this comment the thumbs up 0 likes

Nice post. Ever since I entered the software industry over two decades ago, I've been hearing some version or the other of your statement "building a system is now more about assembling services rather than building things from scratch." Then and now, this statement is valid if you replace system with a car or a PCB. But, it's still aspirational for software systems, notwithstanding a slew of enabling technologies like CBSA, SOA, MicroServices, etc., that have come and gone in the meanwhile. There could be several reasons for this state of affairs but I've always noticed one thing: Nobody recognizes the real elephant in the room, namely, the maker's emotional attachment for their work product, whether you call it component or API or microservice or whatever.

I believe we'll see real progress on your statement turning into reality for software systems only when the emotional factor is taken out of the picture and replaced by a catalog of software building blocks and a marketplace where they can be purchased with a credit card, the way it happens in automobile, electronics and other industries where your statement is valid.

Keen on knowing if you know of any such catalog and marketplace for software building blocks?

A Finextra member
A Finextra member 09 March, 2017, 07:58Be the first to give this comment the thumbs up 0 likes

Good point K.S. Although I wonder if it's a protectionism rather than an emotional factor.

Regarding a marketplace, you do find this in the small business sectors. Look for example at Xero, an accounting solution, offering a marketplace with integrations with hundreds of other software components.

Unfortunately, the entreprise software world is lacking much of the transparency and openess that is required to build such a marketplace right now.

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 09 March, 2017, 10:341 like 1 like


A capacitor in a PCB is a commodity. Unlike software, which is positioned by IT vendors, and accepted by customers, as providing competitive advantage to their owner. Even if s/he wants to, a PCB designer can't design a capacitor from ground up. Unlike software system designers who can theoretically - if not also practically - build most components from scratch and, more importantly, refuse to accept code written by others on faith. I used "emotional attachment" as a catch-all phrase to describe these characteristics of software systems. Protectionism is an equally valid expression.

Because suppliers position enterprise software as providing competitive advantage, most owners of enterprise systems think of them as trade secret. As a result, it's impractical to expect any transparency and openness in this realm. Therefore, I'm not sure when and if such a catalog / marketplace will become a reality in enterprise software building blocks. Ergo, it might forever be an aspiration to build a software system by assembling components from a reusable library.

A Finextra member
A Finextra member 10 March, 2017, 09:50Be the first to give this comment the thumbs up 0 likes

Good points KS and EB. If you look at the manufacturing and electronics sectors the individual components ( read "an M6 allan screw", a "6 ohm resister" , " A 12 microFarad capacitor" etc ) are so well "specked" out. The industry is ready for "API'sation" and the chance of failure is negligible.... I can close my eyes and buy a "timer circuit" and plug it into my PCB architecture. The same is not yet true of the software sector... Initiatives like BIAN, IFX etc have not taken off as much as we would have liked to... and thats the reason that the "lego blocks of banking" are still not commonplace...  dnaappstore .com may come close to it .... but it got acquired by a bigger player .....

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 10 March, 2017, 14:25Be the first to give this comment the thumbs up 0 likes


You've hit the the nail on the head. The excellent spec'cing of electronic components is what I meant by catalog.

That said, I'd be remiss if I failed to mention the drive towards software cataloging by GITHUB et al. Despite such initiatives, Open Source movement presents another source of difference between software and other industries. I pay $X for 12μF capacitor, plug it into my PCB circuit, and forget about it. OTOH, even if I totally trust a software component on GITHUB and use it in my system, OSF terms may preclude public acknowledgment of such assembly process of developing a software system. While the open source component itself is free of license, OSF imposes conditions of redistribution of modified code back in the open source community. Redistribution of modified code is not always easy. There could be IP issues involved. After reading Flash Boys, I've learned that there could even be outright stealing involved. In this book about algo trading Michael Lewis references a top tier investment bank that brazenly uses open source code in its proprietary software and doesn't contribute anything back to the open source community. While it's a major violation of OSF rules, life goes on. If a company is unwilling / unable to conform to OSF rules, it could very well be assembling software systems from open source components without announcing it publicly.

As a result, it's quite likely that, whatever little reuse of components is happening in software systems, we may never know all about it.

Now hiring