On Modernization

I’m currently working with a large retail banking client to help them modernize their payments infrastructure. The word “modernize” is used in just about every client interaction. It appears in all the slide decks. It’s part of the business case justification.

But modernization is a relative term.

The big question is: What does the client mean by modernization?

The existing system is a vendor product running in an on-prem application server. It’s an opaque monolith that is challenging to operate, and to cap it off the vendor has announced that they’re ending support in a few years so my client needs to get off this platform in order to stay competitive in the payments space.

They plan to re-implement the system as a set of services deployed as JAR files to virtual machines running on on-prem infrastructure using VMC2, and leveraging IBM MQ for messaging.

No docker or kubernetes. No Kafka. No cloud.

I have advised them that they are leaving a lot of potential improvements on the table with this choice of infrastructure.

We could improve reliability if we used a managed container service. We could achieve infrastructure utilization with containers. We could get higher throughput and fault-tolerance with Kafka. We could reduce our cycle time, MTTR, and environment parity with infrastructure-as-code. We could modernize.

Unfortunately the client has told us that they don’t have other options. Their ITS department hasn’t certified the use of docker, the quote from infrastructure to build a dedicated Kafka clusture was too expensive, and their cloud onboarding process is so onerous that running on-prem is more expedient and cost-effective.

So we’re running virtual machines on-prem.