Historically when firms built their risk systems, they would build them as large monolithic three-tiered applications that covered the full gamut of the organization’s needs.
These systems would work well for a few years. But over time the requirements would change due to:
- New regulations
- Changing business needs
- Evolving software engineering best practices
- The introduction of new operating systems and hardware
Eventually these systems would get the dreaded moniker of “legacy systems” and would need to be ripped out and replaced with something more modern. The unfortunate fact is that the task of replacing legacy systems comes at great cost and project risk for the organization.
Recently, many organizations have been embracing the concept of “microservices” in their risk systems. Instead of one large monolithic application, they have many small applications covering small subsets of the overall system requirements.
One advantage of structuring programs in this way is the flexibility it provides. These services can be written in different programming languages, selecting the language most suitable for each task. For example, one might use Python for ETL services, JavaScript for Presentation services and C++ for Calculation services. Using this approach, you can take advantage of the best features of each language.
Another benefit of using microservices is scalability. By building applications in small parts, the constraints of machine boundaries become less relevant. The risk system can be spread over many machines either on premise, in the cloud, or in combination.
Computing power can also be dynamically scaled. One common application of this is that computational resources might be more readily available at night. Therefore, a job which is highly computationally intensive, for example historical back-testing, could be scheduled and performed over night when other systems are dormant and computational power is available.
A further advantage is reliability. One problem you often find with large systems is that when they fail, they do so in a major way. The entire system may need to be brought down, causing a massive disruption to the business. As someone who has spent time working in IT roles on trading floors, believe me when I say that when the risk system is down, nobody is happy. If the system is built using microservices, it can be built in such a way that in the event of an error in one service, that particular service can fail, and send out an alert. While that service may need to be restarted, the majority of the system stays up and running. The disruption is minimized, leading to fewer angry traders, and happier IT staff.
Those with backgrounds in software development may find the idea of building small modular service somewhat familiar. In a way it is similar to the Single Responsibility Principle in software development. When software developers adhere to the Single Responsibility Principle, they build their functions into the logical units, which do one and only one thing. This tidy-minded approach produces clean-looking, easy to read code. When the concept is elevated from the level of code to the system architecture level, it produces elegant easy to understand solutions.
Philosophers talk about the idea of the “Ship of Theseus.” Over time, parts of the Ship of Theseus would get damaged and were replaced. Eventually, every piece of the ship had been replaced, so that none of the original parts remained. Which begs the question: Was it still the same ship?
The final advantage of using microsystems that I’ll talk about is that it makes your risk system like the Ship of Theseus, in that it can be kept consistently modern. Every part of the risk system is a small application unto itself. Thus, when the time comes for that bit of functionality to be updated to take advantage of a new technology, it can be done without a major overhaul of the entire system. Eventually the system itself might be many years older than even the oldest individual service. In this way, the system evolves over time and remains modern.
It’s worth noting that FINCAD F3 has been built on a microservices-oriented architecture. This flexible design enables firms to change up their trading strategy at will, easily enter new asset classes without coding work, and keep up as the market and business changes. To learn more about FINCAD F3 architecture, check out our related eBook: How to Drive Competitive Advantage with trading and Risk Enterprise Architecture