In the old world of deployed software – which for many asset managers remains the status quo – releases may be perceived as problematic. They only come every 6, 12 or even 18 months, particularly major ones.
As a user of this software, the entire responsibility for all testing, potential data issues, and deploying to production falls to you.
It is not surprising that managers are looking for ways to generate efficiencies and remove this time and resource-intensive burden.
The solution is generally considered to be Software-as-a-Service (SaaS).
As of writing, there is not yet an established SaaS for asset managers, but a few up and comers. A SaaS solution will release more frequently than a legacy system, let’s say weekly, on schedule. The vendor, not the end-user, manages testing, data, and deployment over the weekend which is part of the definition (it is a service, not just software).
To achieve this, SaaS vendors put all clients in the same system, literally. That means one upgrade for all, which in theory reduces the cost for the vendor to manage testing and deployment. However, it does come at great costs which we’ll explore in this series.
The first such downside is that users must upgrade at the same time. i.e. there is zero flexibility for a user to choose when to receive a new release.
This can be problematic if, for example, there is an internal governance process dictating that no changes to critical software can be done during certain periods, such as the first weeks of the year or in times of high market volatility.
It also makes it impossible for clients to have their own test process of the release in addition to the one offered by the vendor.
You may wonder what this means.
In our view, it is the creation of a solution from the ground up in the cloud, but in the architecture of such a system the vendor addresses the shortcomings of the subscription SaaS model.
Such architecture has only been possible for a few years, with technologies such as Kubernetes and containers becoming viable for mission-critical production environments.
This enables the vendor to manage the upgrade, data, and deployment on behalf of the user while still allowing for multiple versions to be in production at the same time for different users. This is illustrated in the diagram above.
There is still just one version of the code base, bringing all the stability and cost benefits that goes with that, but it can be deployed and tested on a user-by-user basis.
As you can see, there are many differences between SaaS architecture that may be suited for asset managers of different sizes. It is not a one size fits all solution, and this is the way it needs to be. After all, the fund management industry is too complex for a cookie-cutter system.