Problems with Long Software release cycles

There are three categories of Investment Management Systems (IBORs, OMSs, PMSs) when it comes to software release cycles:

• Long cycles in traditional legacy software, where software releases are typically delivered every 6-24 months and you manage the upgrade process. In this model, you are in control of the date for the upgrade.
• Short cycles in one-size-fits-all Software-as-a-Service (SaaS), also called first generation SaaS. Upgrades are usually delivered multiple times per quarter/month. In this model, the vendor dictates the date of the upgrade.
• Short cycles in Enterprise SaaS, also called second generation SaaS. Upgrades are usually delivered multiple times per quarter/month. However, you have some control over the date of the upgrade.

Limina was started in part due to the problems with long software release cycles. As fellow investment managers, we were clients to vendors who hadn’t experienced what it’s like to operate in the front line of the markets. Stakes are almost always high and any interruption to systems at the wrong time could have a significant impact. Receiving upgrades every 6, 12, 18 or even 24 months was equally frustrating, as we had to wait for functionality that we needed to develop our business, for example to launch new funds and investment strategies.

With an on premise system, upgrades take a considerable amount of time and effort, and generally we upgrade annually – meaning we have to wait a long time for software improvements.

- Head of Technology, $9bn Asset Manager, about the state before adopting Limina and why they moved

With that background, you can probably figure out that the product Limina offers (the Limina investment management system) is an Enterprise SaaS Investment Management Platform. With that said, we know from the same experience how difficult it is to find honest and transparent information out there. Hence, we will keep this post as objective as we possibly can. In the name of complete honesty, Limina’s solutions aren't perfect either, which you can read about in our article on the topic. Alternatively, if you would like to find out when we are likely a great fit, you can find that out in our video interview.

Why shorter software release cycles are often (but not always) preferred by the buy-side

Shorter software release cycles can offer many benefits to the buy-side, including lowered operational risk and increased flexibility. Below is a summary of the benefits and drawbacks of long vs short release cycles: 

Frequent upgrades are valuable mostly because they free you from the shackles of long release cycles. I.e. it's more about removing downsides, than about creating upside.
 
If you want to invest in business development now or in the future, for example launching new funds or strategies, there is a good chance long release cycles are holding you back.

We were running one of the established hosted solutions, and certainly had some challenges. The software was very complex since it had grown over a long time, which made it difficult to onboard new team members and some portfolio managers even retreated back to spreadsheets in the end.

Change management was another challenge, we had to rely on external consultants to perform upgrade projects and implement new functionality. This resulted high total cost of ownership and slow delivery of enhancements, which in the end impaired our ability to provide the best return for our investors.

 - CEO, $6bn Asset Manager, about the state before adopting Limina and why they moved

Why the investment management industry still has long software release cycles

Generally, older investment technology offer long software release cycles and newer Software-as-a-Service (SaaS) offer shorter. As of writing, there is not yet a globally established SaaS for asset managers (Limina is an emerging vendor), but a few exist that service predominantly hedge funds.

A SaaS solution will (most likely) be released more frequently than a legacy system, let’s say weekly. To achieve this, one-size-fits-all SaaS vendors put all clients in the same system, literally. That means one upgrade - for all users at once.

The first obvious downside with this approach is that users must upgrade at the same time. I.e. there is zero flexibility for a client 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 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.

This is one of the reasons that such SaaS solutions are not broadly adopted on the buy-side. There is an emerging alternative however, which we’ll explore next.

Enterprise SaaS: A set menu of options - simplifying change management

With the next generation of technologies in the cloud, it’s possible to create a solution with the best from two worlds – an “enterprise SaaS” solution. This is the creation of a solution from the ground up in the cloud, designed to fit governance processes and adhere to oversight requirements of institutional and established asset managers. Such solutions for the buy-side have only been possible to build since approximately 2015, which is when the underlying technologies become viable for mission critical production environments.

Enterprise SaaS enables the vendor to manage the upgrade, data, and deployment on behalf of you, while still allowing for different versions to be in production at the same time for different clients. This is illustrated in the diagram below. There is still just one version of the code base, which means all benefits around stability and cost are kept, while offering deployment and testing on a client-by-client basis.

A note on Limina’s investment management system: we offer the two release cycles illustrated above, every 3 weeks and every 3 months. About 80% of our clients opt for the shorter cycle but knowing they can switch to the longer cycle at any point should they need to, to support their change management or business development. If you would like to learn more, please don’t hesitate to contact us.

The elephant in the room: Testing responsibility and forced upgrades

In both one-size-fits-all SaaS and Enterprise SaaS, the system runs in an environment controlled by the vendor. Even for Enterprise SaaS, where there is a choice between upgrade cycles, if you don’t want to follow either option, the vendor can still enforce an upgrade. Of course, this is much more likely in one-size-fits-all SaaS, but it’s important to point out that it could also happen in Enterprise SaaS however unlikely. This is a trade-off that most investment managers are willing to make, since the alternative of on-premises (“on-prem”), hosted and cloud-enabled (not cloud-native) software comes with so many other problems and issues.

The second challenge with SaaS and cloud-native is testing. With a SaaS solution you give the responsibility of testing and deploying to the vendor. Essentially, you're buying a service, not just software. However, you might want to run custom tests in your environment before every release. This is generally not possible in one-size-fits-all SaaS but an Enterprise SaaS solution might allow for it. We recommend you to check as part of any procurement what happens if not all your tests pass – what does the vendor warrant, if anything?

Read more about all downsides with enterprise SaaS in our article.

Choosing the software release cycle model that is right for you

Hopefully, by now you have a better understanding of the different release models:

• custom (on-premises, hosted and cloud-enabled software);
• vendor-dictated (first-generation SaaS & one-size-fits-all cloud-native); and
• a set menu of options (second-generation SaaS / enterprise cloud-native).

You are (if we did our job explaining well) in a better position to decide which is right for you and how important this question is in a procurement.