A lot of software applications are developed every day, but a lot more of them are reused over decades. We serve many very large and mature organisations in the financial services sector, and their strategy, unlike, say, tech-first startups, is quite often to nurture and repair rather than move with the flow of technology. A lot core and tertiary applications, specially in that world, are what we call “very 20th century”.What’s wrong with this approach?

• These applications cannot use the asset-light, cost optimised, fast-adapting strategies which modern technologies and cloud infrastructure offer. So their management teams are slow to upgrade, and are always looking for justifications to justify an upgrade of “perfectly good” investments instead of figuring out how to be the most delightful to use. That’s what happens when you’re asset-heavy.

• They often look really dated. In a world where even B2B systems are judged by B2C yardsticks, this is a serious competitive downer. The UX, not just the UI, is functional but non-intuitive. Users resist them.

• They don’t scale well. It’s that simple. They’ve not been designed for true horizontal scale-out.

• They simply lack some features which are far easier to add with a modern tech stack.

• They have slow release cycles, lower reliability, because they have not embraced modern processes like automated build and deploy, automated testing, etc.

• In severe cases, mobile apps simply get discarded by app stores because they are too outdated to comply with their norms. The absolute maximum life of a mobile app on the Android Play Store without upgrades is three years.

These may sound like commonsense points, but you’d be surprised how often we see this 20th century mindset in our large financial services sector clients. At the same time, we are the first to say that technology for technology’s sake gets you into deep, and hot, water.

So, what then is a modern application?

• We use open source stacks and SaaS services from the Big Three cloud providers to give you the asset-light and nimble engineering stategy you need.

• We understand the tech we bring to the table. (We remember the payment systems startup which projected a load figure of 25,000 transactions a month -- not an hour, not a day, but a month -- but wanted a true micro-services architecture, with separate server instances for each web service call. Our thinking has feet firmly on the ground.) The keyword for tools, technology, and processes is “appropriate”.

• We understand horizontal scaleout. (We so often see client teams who seem to believe that just running multiple application servers means scaleout; the DB remains a bottleneck.)

• We embed observability into our applications. We embed debug code into our source, switchable via global flags. We embed Prometheus exporters, pumping out data to a central “observatory”. You know before anyone else does, which SQL query has begun to deteriorate.

• We mix and match databases, mixing SQL, non-SQL, and even query services which run out of S3 data objects, to provide the best scale at the most optimum cost.

• We think serverless-first. Containers are now at the heart of our architecture, and we use serverless PaaS like Lambda wherever it fits.

• Nimble at a business level implies rolling out new features rapidly at the engg level. We do this for you with automated testing, code analyser tools, automated build and deploy, and automated configuration management.

• We use more modern programming environments like Flutter, Go, React, and hybrid mobile apps. (We won’t tell you how many Java Struts applications or Tomcat v4 we see in large enterprise organisations.)