The longer your infrastructural software is kept operational, the greater the risks. Problems embed themselves deep in the code, making them hard to find and define. Constant incremental changes over time heighten the risk of ultimate failure.
Yet in a time of exponential technological change, standing still is not an option.
At some point you must face the challenge of replacing your infrastructural software, or risk being left behind by the competition.
There is no manual telling you what the ideal lifespan for a system might be, but change is always necessary and inevitable.
Managing the Pain of Migration
In the world of electronic trading infrastructure, where data migration is never straightforward, this anxiety is keenly felt.
Real-time handling of data needs to be interpreted and processed.
Orders and information coming in from clients and being subject to automatic decision making can be complex to migrate.
The implications of getting this wrong are costly, in both financial terms and by falling foul of MiFID II regulations, which cover the failure to take proper control in the development and testing of trading systems.
Furthermore, migration becomes more complex when the data in and out is not 100% controlled by your organisation.
Migrating a firm’s clients and external links is risky and likely to be an Amber Flag warning moment for the organisation.
The burden of testing of links to external commercial organisations can be eased by exchanges and vendors. As they tend to offer a commercial service that allows outward links to be fully tested in a semi-live environment.
However, links to clients are not so easy
Once an external client is onboarded, they are onboarded. They no longer see the need to do any further testing (unless they are the instigators of change).
Apart from the odd friendly client you can’t expect them to step up and be an integral part of your migration process.
Some may be prepared to take part in some final tests prior to the switch over, but even at this stage the expectation is that it will work, and that this will just be the final rubber stamp.
So, the conundrum is how do you seek to mitigate the migration risks with the onboarding of data and external clients?
4 key factors of data & client migration
The starting point is to ensure that any new system has the necessary support to reduce the risks as much as possible.
Any design and development process must be equipped to address the factors that form the basis of any data & client migration.
These are:
- Capturing the configuration from the legacy system
- Configuring the new system for each client
- Testing, testing and more testing
- Phased migration
Capturing the configuration from the legacy system
The legacy system needs to produce its existing configuration in some form as logical and accurate data output.
The data can then be analysed an output created to automatically generate much of the configuration for the new system.
The success of this process depends on a collaboration between the teams of the original system and those developing the replacement.
Configuring the new system for each client
Once the data has been analysed it can be used to recreate the existing use cases, eliminating any unnecessary complexity from the originating system.
Any additional requirements can be added to the new configuration at this point.
Using the power of a platform like RA Hub, it is possible to consume multiple types and sources of data and easily examine, manipulate and convert the data to reflect the original configuration.
This is a tried and tested process which is part of our powerful migration suite.
Make sure that the client behaviour has not changed and that the migration has not broken the logic
Under MIFID II whilst a lot of the detail of testing and conformance testing could be described as common sense there are some very specific requirements.
For example, an audit trail of who, when and what makes any changes.
Whilst the FCA report on Algorithmic Trading Compliance in Wholesale Markets focuses on algorithmic trading, the principles apply to all aspects of good practice in electronic trading.
This is one of the most challenging parts of any development amendment – complexity builds over several years and it is almost impossible to manually identify where conflicts could exist. In some cases, it’s even impossible.
So, the more the generation of the test pack can be automated the easier it becomes to identify and trap these conditions.
Whilst Institutional memory serves to provide continuity in development and the understanding of what has been done and why, teams change, individuals move on and up, and the loss of this knowledge can have substantial and wide-ranging impacts on the ability to capture edge cases.
How does RA HUB fix this?
As part of the migration suite RA Hub not only provides a fully automated testing facility, but as part of any migration project it automatically creates the use cases to be included in the automated testing suite from existing transaction logs.
This captures all the scenarios that have ever been experienced and each of these tests will show that the system has been able to process the data correctly.
These testing scenarios can continually be augmented by any additional tests identified as part of the development process.
Testing, testing and more testing
Logical, thorough and extensive testing is part of any development cycle.
RA Hub provides a scriptable testing tool and allows the logging of all tests and their successes.
It also logs the depth to which tests have been completed, and details such as who and when.
It will also identify the percentage of the system configuration that is covered by the tests – helping to ensure the entire system is tested, not just the most common elements.
However, having a good automated test system and good test coverage is only worth it if you have good tools to allow the analysis of any problems.
Again, we have developed the RA Monitor linked to RA Hub to provide forensic analysis of the results and the ability to follow the full transaction path to identify where errors occur.
Phased Migration
Having the ability to switch client by client, function by function, or exchange by exchange, allows complete flexibility in the phasing of the migration.
This will give you complete control as to how fast or slow you choose to complete the project.
At Rapid Addition we fully understand the sheer extent of the challenge of migrating from one system to another.
RA Hub has been designed to ease the burden and risks of migration and on-boarding.
Case Study: A client using RA Hub to bring together multiple disparate systems across the globe, used the automated testing system – which constantly takes the last 30 days behaviour – to add it to the test suite such that the behaviour of the system is constantly capturing new tests.
Challenge us to prove it
Challenge our team to discuss your concerns and how a move to RA Hub and Monitor suite can help solve your problems and experience a smooth transition.
RA Hub Overview
A single package RA Hub provides:
- All the tools for a smooth onboarding process
- Realtime deployment once satisfied with testing
- Configuration not coding
- Doesn’t need a development team to configure
- Visual representation of client configurations
- Automated testing – clear traffic lights to see if there is an error in configuration OR has broken an existing client
- Easy access to searchable and readable logs
- A powerful monitoring tool to forensically analyse test results
Contact us today and take the next steps towards realising the enormous business benefits of RA Hub!