Rapture: Taking advantage of the present while looking forward to the future
- March 22, 2014
- Alan Moore
Incapture’s Rapture platform was born out of a desire to not repeat the past, to take advantage of the present and to look forward to the future.
While working for a number of capital market banks and asset managers I had the opportunity to design, build and deploy a large number of different applications. Although the end functionality could often be vastly different some of the core components of the application stack were the same — in fact it was often deja vu in that I ended up rewriting (or recreating) the same functionality again and again. The enlightened among you would argue that this is a classic case of a need for a common platform or framework – something on which these applications could be built but in these organizations at this time the pressure was to deliver at any cost (time was of the essence) not to deliver a perfect and forward looking solution. This behavior, repeated over and over again, is often the source of the large legacy software infrastructure at these type of organizations and the challenge they now face to look forward.
The last two to three years have seen a fundamental shift in architectures for software applications — the advent of cloud computing, distributed systems, big data environments and the like have been instrumental in this change. These technologies were available before this time, it’s just that the market has matured to the point where such things are now commodity instead of esoteric.
In designing a platform to solve (or help transition) the problems of the past and to take advantage of the present we needed to ensure that the platform we design today does not become obsolete as new technologies and approaches emerge. We ensured that the platform has a pluggable model by default – it should be easy to replace one implementation with another. We also ensured that the API to our platform could be called by any language (the transport is open) with little effort. We cannot predict the new languages that will be created but we certainly should ensure that our platform can leverage those new languages with ease.
Where we are
In release Version 1 of Rapture we successfully captured these desires in a platform that can be used with new architectures around distributed processing and common access to data while still providing a legacy migration path for existing applications. The pluggable architecture and options around customizing and enhancing the core platform makes it easy for 3rd party developers to integrate their services and technology with our common platform. Finally and most importantly we have taken the core platform and extended it with key functionality in the Financial Services space – recreating nearly all of that common functionality that so frustrated me in my early career. If I had Rapture then I could have spent all of my time building key application functionality (Risk Analysis, Pricing, Trade Capture) instead of most of my time on managing data, processing, scheduling, entitlements, audit trails. I could have also delivered my applications via many different means – spreadsheet front ends, web front ends, thick clients – all calling the same common layer that delivers the business logic.