Tech Time: Has Your Core Software Been Sunset?

One of our senior directors got a call a few weeks ago from the CEO of a core provider. Mr. CEO complained that one of our consultants mentioned to a client that his core system was no longer being supported. The CEO passionately argued that our consultant used the term “sunset” with the client as it related to his core system.

Now, I can see why a software provider would be upset if a consultant was telling clients that its core product was no longer viable, but software can stay in the market a long time in “maintenance mode.” So perhaps we should spend a few minutes discussing how software decisions are made by core banking system providers.

Let me explain.

Over the course of my career, I spent several years managing software development teams through the project management office, including quite a bit of time at a large core provider. One important thing I learned is that not all software gets the same amount of attention from the development team and senior management.  

Think of it this way: Each year, software companies have only so many resources to allocate to software development. Software development is an expense for a core banking systems provider, so—based on the sales from the previous year, how much profit the management team wants to take and how much they want to spend on developers—they budget how many resources end up in that specific software development bucket. If you are a CEO or CFO managing the budget at your financial institution, you fully understand resource allocation issue at hand. You have choices to make.

Delivering on the Software Road Map

Let’s break down an example of how budget allocation works at a software provider. Let’s say that a software provider has two main products in their software budget, and each of those products has three projects where they can allocate their software developers.

Example:

Product A

• Maintenance on Product A
• Product A – new functionality (road map item) 1
• Product A – new functionality (road map item) 2

Product B

• Maintenance on Product B
• Product B – new functionality (road map item) 1
• Product B – new functionality (road map item) 2

First, it is important to understand that maintenance is required. You have no option but to make sure that things like bug fixes, software outages, regulatory updates and third-party interface updates are covered. The software needs to work, as the financial institutions are paying monthly fees. So, after you make sure you have enough developers to cover maintenance, the remainder of the budget can be allocated to new functionality.

The above example is extremely simplified, because I have never seen a software product team with fewer than 10 to 12 items on their development road map. But for simplicity’s sake, let’s say that 70% of the development budget of this theoretical provider goes to maintenance. That leaves the product managers of Product 1 and Product 2 to fight over the remaining 30% of development time across the 4 new functionality road map items. Now, change the four road map items to 24 functions that clients are clamoring for, and you see the dilemma that all software providers face. Which of those 24 projects will be funded this year, and which will have to wait another year?

So, why do you, as a customer, care about this? Why do you need to know about development road maps and software developer allocation when deciding whether to keep or change your current provider?  

Here is why:

Old software, once developed, is something of a cash cow. These days, customers pay for it either on a monthly or annual basis. If the software provider can convince their current customers to remain on the product and cover very basic maintenance, everything else is profit—all the revenue, with very low expense. It is only after enough customers have left that software platform and the revenues do not cover maintenance that the software provider needs to either sunset the product or migrate customers to a newer version.  

Oddly, it is in the software provider’s best interest to keep some products in “maintenance-only” mode. Older products are often their most profitable. You, as the customer of a product that has gone into maintenance mode, have probably seen some of the signs of one of these cash cows:

• Road map items never get finished.
• You are paying for the provider to develop new functionality, which the provider can then offer other customers.
• Quotes for customization or professional services seem exorbitant. (The provider may not have the development team available to customize.)
• The only items in the provider’s development release notes appear to be maintenance or bug fixes.

Maintenance-Only or Unofficial Sunset?

At Remedy Consulting, our business includes helping customers through requests for proposals and demonstrations of new software products. Generally, a financial institution will start an RFP when it suspects that its software solution is just not keeping up with the times—but often, a credit union does not recognize the above signs of an under-maintained product until we have the discussion about changing out the software.

Think about it: The software provider would be insane to tell its customers that the product they currently pay for is no longer at the top of the development priority list. Providers hope customers renew their contracts and that new functionality is less important to the current customers than maintaining the base model they’ve had for many years. Maybe what the customer pays for maintaining the software currently is cheaper than replacing it with another product.

So, let’s go back to the CEO at the top of this article. If you were the CEO of a small core provider where profit margins are already tight, and then you lost some customers, you may have hit the tipping point where you need to start laying off developers—or, at a minimum, struggle to maintain the software without having the resources (or the interest?) to update new functionality.

If this was a larger core, Mr. CEO could migrate his customers to a new product and officially sunset the older product. But smaller cores typically cannot do that, as they don’t have the resources to build a newer product. The CEO is now in a bad place, and although he didn’t declare a sunset of his product, he also has not built new functionality into the product. From our perspective, it would be hard to recommend that provider’s core to one of our clients who is in RFP mode.

If you are responsible for making vendor decisions at your credit union, keep an eye on the indicators above. If you realize that some of your software providers are not delivering on their road map items, decide if that is important to you. If the product is not member-facing, the price is low and your team does not require cutting edge functionality, that might be OK. Consider finding a consultant that knows market pricing during your next renewal and see if you can get a better deal.

However, if a laggard product is member-facing or drives revenue, it may be time to look at other vendors to see what else is out there. If you are already in the process of an RFP and find a product you like but haven’t spent a lot of time on the product road map, consider talking to the vendor’s client references before buying. Ask about that product’s history in developing new functionality. How many items have been delivered from the road map in the past 18 months or so?

If you are looking for help to determine if you need to complete a system selection, please reach out.

Charlie Kelly is a partner at Remedy Consulting and host of BankTalk Podcast. Remedy Consulting helps financial institutions thrive through specialized consulting services in System selections, core contract negotiations, outsourcing/in-house advisory, mergers & acquisitions and FI strategic planning. As a trusted advisor to banks and credit unions, Remedy Consulting has executed over 700 system selection and vendor negotiations since 2016. Clients receive cost reduction on their vendor contracts and increased efficiency with Remedy’s Price Repository. To learn more about Remedy Consulting, visit www.remedyconsult.net.