Trading systems workflow evolution, 3 things to consider including what we can learn from Fighter jets

Two things have spurred me to write this article.

1. I have been reading more than is strictly healthy around the F35 fighter plane on Quora, and the Next Generation Air-Domainance platform being developed by the US government
2. I recently watched the FinJS panel event from the latest FinJS event which has now been published on Youtube

Trading systems workflow has evolved over the last decade with many companies rolling out modern web trading systems, and slowly replacing their legacy systems.? But this takes time, is very expensive and many of these legacy systems are complex and take years to replace.? It isn’t uncommon to see a Trader with 8 or more screens and many applications.? For most lines of business, taking a business case to the Traders and asking for a huge amount of money to replace all their applications in one go with a web application is a tough sell, especially when the ask is for a large pot of money, a long period of time to essentially come back with a more modern version of the same application.

As mentioned after watching a recent FinJS panel event (which can be seen here) - Mariya Brown , Michael Banham and Colin Eberhardt were asked many questions around the Evolution of Workflow technology (in Financial Services).? It’s a great watch, with many interesting thoughts that came out of the discussion, but I wanted to bring up three points that were raised that got me thinking.

Colin Eberhardt mentioned that ultimately you don’t want to switch between 36 applications, but you want to surface the information the Trader needs when they need it and enable them to take action.??

Mariya pointed out that she would like to convince more Product Owners to do proper User Journeys, therefore minimising the number of applications and certainly reducing the number of super configurable grids with applications more optimised to the User Journey.?

Michael highlighted that current Trader desktops tend not to be what we would considered modern “if you are thinking of a modern workspace, you wouldn’t be thinking of a traders desktop, it’s far from being modern ……we are a long way away from a modern workspace, the challenge is how do we get there, how do you take 8 large ticking grids into that (modern) workspace….. the way in which you can do it … there are various ways you can do it, … one way is to build out some … web content but also integrate it back with your legacy applications”. ? Essentially Michael is recommending doing it in an agile way as opposed to a big bang approach.

It got me thinking about what things I consider to be key to the more successful workflow projects.

The conclusion I came to is that three things tend to stand out for the more successful?projects

1. They tend to be more agile.? Often replacing one specific piece of functionality at a time over a big bang approach.

True agile projects, which focus on a few or one specific piece of functionality at a time I think tend to be a lot more successful.? This aligns with Michael’s view.? Each time a new piece of functionality is rolled out and tried, it can be considered a success or failure fairly quickly and thus can be input into the next business case.? This is hard especially with multiple complex, large historical legacy systems all with their own backends, middleware, OSs etc etc.? But software like Here? (formerly OpenFin) can help take on some of that heavy lifting for you to make the task at least at the technical integration point easier.

Whilst everyone can acknowledge that some things are harder to do using an agile approach, I was amazed to read that the NGAD fighter programme in the US is trying hard to adopt an agile approach to development instead of the multi year development approach typically taken for fighter jets.? Instead of taking years to develop and fly the early prototype, the US shocked the defence world by already developing and flying a replacement for the F22 years ahead of schedule by adopting more agile methods.

Given the US government can adopt more agile methods of development that include significant hardware integration, which can make going agile all the more challenging, and still have significant success, I believe it challenges us to believe other other projects with significant integration challenges can also succeed if approached in the right way.

2. There is strong Product Ownership and a lot of push back against providing super configurable screens and pushing for more up front design.

During the FinJS event Mariya was essentially arguing it takes time to really understand what users want, and that can take longer than just asking the developers to build ultra configurable screens, but the pay off are systems that are much more optimised to the job, and in the long term you can reduce the number of screens the traders have and optimise their work flow significantly.

Back to fighter jets for a moment, this is clearly true of the F35 display and sensor fusion in the F35.? While previous jets often had two seats due to the sheer overload of information provided to the pilot, in the new F35 there is only one seat for a pilot as there is no need for a second pilot.? The reports coming out of trials couldn’t be clearer, new pilots with only a few hours of training are roundly beating experienced pilots in other jets due to the combination of stealth and well summarised sensor information laid out clearly for the pilot to see what is going on.? The big jump up everyone talks about with the F35 is the information jump, essentially the fusion of all the sensor information into one big display optimised specifically for the task, which significantly beats older fighters with displays which haven’t had as much effort thought into what they are showing.

3. The Business Case for the project is successfully lined up with the development of the project.

I believe this a huge barrier to the success of many projects, and it is completely understandable why.? Companies completely reasonably try and plan their years up front, including financial planning of projects which of course includes the business case for them, and the features they will have to enable some financial payback.? The challenge often is the financing of the project puts huge pressure on the IT departments to run the project in a waterfall way to accurately report back to the board on the success and progression of the project.? This pressure comes out in the way IT projects are procured, and often leaks out to pressure on vendors for providing a fixed price, fixed set of features in a way that often sets up the vendors to have conflicting objectives from the client.

Back again to the NGAD programme in the US, due to the sheer cost of the F35 project, and although the fighter is considered a success, there are many articles talking about the sheer cost overrun of the project.? Due to this, the NGAD programme is being run in a much more agile way including the request for funding.??

So while defence procurement and spending often lags behind development of private software development, I hope my admitted quora level knowledge of the defence industry has opened a debate on can we learn successes from Fighter plane design and apply it to Trading systems work flow development and approaches.? I’ll leave you with one thought, next generation jet fighter design is considering AI heavily for the optimisation of the information presented to the pilot, time for Financial Services to do the same for their workflows?