Author: Ethel Anderson
You might think comparing your bank’s monolithic architecture to Frankenstein’s monster is a little harsh, but they have a surprising number of things in common.
- They were both stitched together over time to create a giant
- The resulting monster/monolith is huge, ugly, and, let’s face it, not something you want to spend time with
- They both started out friendly but by the end, they’re not exactly easy to deal with…
- They’ll both bite back if you make the wrong move
- You get the picture
Frankenstein—he was actually the crazy scientist, not the monster—set out to create a perfect being created out of the very best materials, and when banks start to build their architecture their goal is similar, and for a short period of time, their creation could be the perfect solution for their needs.
Building the monster: when monoliths turn ugly
It’s no surprise that monoliths exist, especially in the financial services sector where businesses have unique needs and security is a priority. A monolithic architecture allows the financial services business to keep their architecture in-house in a highly secure environment. Access opportunities can be controlled and integration to external sources restricted to vital services. It places the bank or other financial institution in control of their system without the need for external solutions or exposing the business to unnecessary risk.
Seems like the perfect solution, right?
Perhaps, for as long as the business doesn’t need to make changes…
When a bank first builds its internal architecture it doesn’t create a monster, it creates exactly what it needs at the time with all functions built into one main system. However, business needs are continually evolving, which means that adaptions and add-ons need to be built into the monolith. The first time this happens it’s a simple process, as the architecture is clearly laid out. In fact, it might not even be a problem the first few times changes are made, but every time a change happens the system becomes a little less recognizable and more difficult to control. A leg gets bolted on here, an arm there, perhaps even an extra head. Each surgery gets more complicated and each stitch a little riskier.
Then, eventually, there’ll come a time when someone makes a change that doesn’t just break a piece of the monolith monster, it stops the monster’s heart. What was once convenient and secure, is now a giant burden that will take hours, weeks, or even months to put back together.
Building the replacement
Replacing a broken monolith is a challenge for many, if not all financial institutions. Why? Because the legacy system is ingrained into all parts of a business, including the people in the organization. The first step in the process is admitting that there’s a problem, which can be a huge challenge. The conversation can often feel a lot like this scene from Frankenstein:
Waldman: You have created a monster, and it will destroy you!
Doctor Frankenstein: Patience, patience. I believe in this monster, as you call it. And if you don’t, well you must leave me alone.
Convincing key business stakeholders that the existing structure is unmanageable and not capable of keeping up with evolving business needs can be incredibly difficult, but it’s the first hurdle that must be crossed to move forward. The second step is to decide on a replacement architecture.
Why a microservices architecture can drive business change
If there’s one thing you can count on when it comes to technology, it’s that it’s always evolving. Each advance leads to an increase in consumer expectations. While monoliths have many benefits, long-term maintenance and making updates can be immensely time-consuming. In many organizations, this effort would be better spent on developing a microservices architecture to replace the monster monolith.
Instead of building all of the functionality needed into a monolithic structure, microservices break down the monolith into a set of defined services that handle specific tasks. Each microservice is self-contained, and independent, which allows a business to only call on the microservices needed to complete each task, which makes the system fast, agile, and easily scalable. Microservices are also technology agnostic, making integration of services from multiple providers a simple process.
One of the biggest advantages of a microservices architecture is that it allows a business to test innovative changes and react to market needs very quickly. How? By allowing their team to update individual microservices without the risk of breaking the whole system. Let’s look at this in a risk decisioning environment:
A business creates a risk model that needs seven data points to return a score. In a monolithic architecture, the integrations to the data sources and the decisioning process are all part of the same system. So, when an application comes in it must pass through the entire process to return a risk score. This makes the decisioning process slow and difficult to change. If a business wants to test new scoring methods or new data sources it must make a change to the entire system.
In a microservices environment, each part of the decisioning process is self-contained, which means the system only needs to call on the required microservices to return a score. So, when they want to make changes, test new ideas, or even implement a whole new risk model the team only needs to make changes to the individual microservices that handle those tasks. It’s quick, easy, and offers extraordinary levels of flexibility. The agility offered by a microservices architecture means that businesses are not only free to take innovative risks, they’re also ready to quickly adapt to any changes in the risk landscape,
Microservices also help businesses provide high levels of customer service, especially in the lending industry, as applications can be approved in under a second. While technology may be increasing consumer demands, it also provides the opportunity to exceed expectations.
Avoiding a FrankenStack
Yes, microservices offer unparalleled flexibility when it comes to risk decisioning, but they have to be used in the right way. The term Frankenstack was coined to describe the monstrous architecture created when sales and marketing teams ‘integrate’ tools from many vendors into their sales funnel. The collection of bolted together services fit awkwardly together, don’t function as expected, and cause problems that are difficult to fix. If businesses aren’t careful they can develop a microservices ‘Frankenstack’, where they fail to adequately plan the design of the microservices architecture. Some potential fail points include resistance to fully embracing microservices, overcomplexity of individual microservices, poor security, lack of knowledgeable IT resources, and slow performance. One solution to this problem in a risk analysis setting is to use a low-code risk decisioning platform such as Provenir. The Provenir Platform handles the risk decisioning process from start to finish, including the creation and security of microservices both within the platform and for integrations to external data sources. The platform can also use microservices, created in the low-code user interface, to support and automate an existing loan origination system. This microservices system empowers the risk decisioning process to be completed extremely quickly and securely, with a risk score able to be calculated within a second of the application being received.
From monster to high-performance machine
Although a microservices architecture still involves connecting components together to provide full functionality, there is a key difference: instead of being bolted together in an ugly, difficult to undo way, microservices are more like a plug and play system, where processes can plug into specific services when they’re needed. This is a highly efficient, agile, and digital-forward method that empowers your team to innovate all stages of the risk decisioning process, which in turn will improve accuracy, expand options, and help your business grow.
Making the move to microservices?
This overview of microservices in the financial services industry will light your way.