We recently spoke with Dietmar Nowatschek, Head of Product and Co-Founder of Hudson Fintech, about Entity Component System (ECS) Architecture. Dietmar shares his views below on Capital Markets technology and the need for a more flexible approach.

From Pixels to Prices – The New New Thing for Capital Markets Technology

Over the past decade there has been a great deal of talk about ‘FinTech Disruptors’ offering transformative technologies. However, scratch beneath the surface of many of these firms and, at least in the Capital Markets space, you find a technology that is interesting yet not exactly pioneering.

One of the reasons is that the underlying architecture of software in Capital Markets has not changed significantly in the last 30 years. There is a reliance on large and inflexible production systems, onto which multiple layers of software have been bolted-on over time.

Changing or upgrading these systems is laborious. Even a simple change, quick to develop and unit test, could still require weeks of regression testing as code dependencies are not fully understood. Due to time pressures, however, only the bare minimum of regression testing is normally done, which often results in issues after go-live.

It’s time for change……

Learning From The Video Games Industry

Entity Component System (ECS) architecture is a design philosophy that is extensively adopted in video games but, so far, has been overlooked for Capital Markets software.

In the world of video gaming, ECS is not the only approach, but it is by far the most common because it presents a set of design guidelines that allow for rapid development of high-quality products. Apart from being a software design pattern, ECS also promotes the decoupling of roles, so that each element of a game can be worked on by respective experts, and an extensive re-use of code in the form of physics, graphics, AI and other engines, which are used across a wide range of game categories.

At its core is a data-driven methodology, which eliminates the complex hierarchies of object-oriented design that are present in traditional systems. Instead, ECS views everything as just an ‘entity’ (a simple numeric identifier), with ‘components’ (the raw data) attached. Code is stored in ‘systems’ which require certain data to be present for its code to operate. Hence a system will only process entities that hold, at least, the required set of components.

Previously developers had to think about the data model ahead of time and build a class hierarchy around it. If something changed, such as a new requirement or a new regulation (SFTR, for example), that data model needed changing too. Using ECS, new components can be defined, added to entities, and new systems written to process these entities. Importantly, existing systems will still process entities as before whether they hold any new components or not, which dramatically reduces regression testing efforts.

Using ECS Architecture in Capital Markets

The challenges faced by any type of software in Capital Markets are rather different from the ones posed by video games: instead of frame-based, single user, single location applications with low resilience and availability requirements, we face an event-driven, global, multiuser scenario demanding high resilience and constant availability.

Over the last two years, my colleagues and I at Hudson Fintech have developed a platform that is built on ECS design principles, but these have been adapted and enhanced to meet the demands of Capital Markets. For example, we added the concept of workflows that allows linking systems together to create new functionality.

By using ECS design principles our platform offers the following benefits:

• Data-driven design – flexible data model allows to adapt to changing market conditions and regulations easily
• Ever expanding trading engine – new components and systems are added over time, meaning reduced time to market for new business functionality
• Decoupling of roles – domain experts focus on their area of expertise, like quants developing new pricing logic or compliance defining new reporting criteria. Software engineers then code these as new systems. Business Analysts use the various engines to build new trading and reporting functionality themselves
• No interdependencies – while systems can be linked to each other via workflows, each system stands on its own. There is no code dependency between systems.
• Automated testing – systems are small, stand-alone units with well-defined inputs, outputs and functionality; as such they are comprehensively tested using an automated testing framework
• Minimal regression testing – since there are no dependencies between systems, and adding systems and components doesn’t impact existing functionality regression testing effort is minimal
• Applicable to any size project – ECS offers a low-cost way to provide new functionality of any scale. It is therefore even suitable for smaller projects where the cost of a vendor system would be prohibitive.

Plugging the Gap

We have launched the Hudson platform based on ECS principles, initially supporting Repo trading. The architecture that our platform is built on presents opportunities to create new standard, or bespoke, functionality quickly.

There are many technology issues that ECS can resolve creatively with solutions that can complement the various other technologies already in use. With that in mind Hudson is developing its own end-to-end solution, but is also integrating with the current ecosystem and adding value to edge cases where traditional software has not been able to deliver.