Identifying the data and tools needed to turbo-charge Innovation.
I was asked recently about the biggest challenge I faced during my 20+ years managing sales & trading technology in Capital Markets. My answer was managing the difference between the front office business demand for technological innovation, such as new systems and upgrades and the ability of the front office technology department to supply it, quickly and affordably.
There are many factors that drove this; good, bad, technical and non-technical but certainly the ability of a software system (or systems) to adapt was always a factor.
Below I have listed what I think are the top 6 factors that slowed our ability to innovate:
Getting the right data into the right state to be useful and actionable.
Data and the need for it to be treated as an asset to be managed, curated, and prized was not always recognized. As most “new” features were dependent on data from multiple sources, a lot of additional work was required to get the right data into the right state to be useful and actionable.
Managing thick client applications.
Even to this day, most production systems employ a traditional client server architecture with a thick client (UI) locally installed on the desktop, often managed by a separate team. Keeping the UI performant, dealing with complexity of spreading business logic across client and server and different teams invariably created friction.
Corralling a mixture of in-house and 3rd party technologies
Typically, architectures were functionally decomposed and implemented with a mixture of different technologies, some in-house, some 3rd party. Each catered to a broad range of uses that were generally not needed for the problem at hand and getting them to “play nice” together was always a challenge.
Difficulty adapting systems that were built to solve discrete business problems.
Systems were sponsored and built to solve a discrete business problem. They were not general. Because the future was notoriously hard to predict this usually meant additional effort to bend systems to accommodate a new feature, creating “technical debt” in the process.
A lack of good development tools.
A lack of development tools also meant app dev had a tendency to operate at too low a level, too much time was needed to be spent reinventing solutions to thorny non-functional issues like performance and resilience instead of writing business code.
An inability to test efficiently.
Finally, sales & trading was and is a business-critical function with punitive financial, reputational, and legal penalties in the event of major failures. Systems just needed to work. Fully thinking about testing before building was also a concept that was recognized later.
At velox our mission is to provide an application platform to our clients that maximizes their ability to innovate rapidly. Would be great to hear your opinions on factors that you think are missing.