3 tenets to automating better and faster
Banks have made substantial investments to make their businesses more resilient, which helped many withstand the worst impacts of the pandemic.
But the transition to digital strategies and processes still rates as a big risk, ranking fourth in a recent EY survey of bank chief risk officers. Only credit, cybersecurity and climate-change risk ranked higher, EY found.
No matter what the industry, building modern systems can be a difficult challenge due to a variety of competing goals around speed, stability, security, longevity, and cost. To work with and upgrade legacy technologies and systems, companies need to manage these conflicting and sometimes contradictory attributes. When it comes specifically to the banking industry, the challenge can be even greater because of the narrow tolerances for failure and the high expectation of stability.
In building out Modern Treasury, which automates payments between companies and their banks, we have narrowed in on three core tenets that guide how we build software – ones that can help all organizations automating legacy systems.
1. Stability over speed
In software automation, there is always a push/pull relationship between stability and speed. Going faster may hurt quality, while spending more time on reliability often leads to growing timelines. The best companies understand this dichotomy and pick the balance that works best for their needs. If you’re a social media company, for example, it’s probably more important to be fast and remain on the cutting edge of the latest industry trends. In banking, there’s only one choice and that’s to be as stable as possible. Consumers and businesses have little tolerance for mistakes when it comes to their money or finances. Twitter’s “Fail Whale” became a cute symbol for the social media giant’s constant downtime, but if a large financial institution were in the same position, it would become unflattering national news. That’s not to say banking organizations shouldn’t strive to be faster (they should) but not to the detriment of the stability of what’s being built.
2. Know when to build and when to buy
Many organizations have a tendency to build everything in-house due to a perception that doing so is “cheaper.” What these cost analyses so often miss is the continued maintenance and support costs associated with the project. Every piece of software, every line of code, is a liability. For projects that aren’t core to the organization or don’t help deliver a differentiating customer experience, the best course of action is often to just buy the software and move on. For instance, if you don’t have the software engineers who are experts in writing CI/CD software or in building APM software, it may make more practical sense to just use Buildkite and Datadog and concentrate on more core parts of your business.
3. Do it right the first time
Many organizations build incentive structures around having engineers just build what’s needed at the time without consideration for what would need to be built next.
But thinking long-term often pays off much more. If you do it right the first time, and consider how that software will be added to or rearchitected in the future to support more features, you can save precious cycles. Have engineers consider what might need to be built in the medium term and architect the current solution to account for that. Put another way, “If you had to support this later, how would that change your development approach today?”
This often means that the solutions take longer to build. But they’ll be more stable in the future when new demands are placed on them because they were designed with those demands in mind. Doing software development this way may cost speed in the beginning but, over the long term, it more than makes up for itself.
Sam Aarons is the co-founder and CTO of Modern Treasury, a platform that automates business-initiated payments. He was previously responsible for building the payment operations system at LendingHome, which has funded over $3 billion in mortgage loans.
