Faster Financial Software Development Using Low Code: Focusing on the 4 Key Metrics

Introduction

Indulge me in imagining this scenario: an upstart financial services professional is working with limited resources on a lean consultancy team, expected to continually wow clients with personalized service and keep within a shoestring budget. (Sounds familiar?) Their team continues to grow and they find themselves with bigger clients, more demanding contracts, and yet, the same level of attention expected—necessitating tools that are as personalized to clients’ needs as the level of service is.

Only problem? All too often, the terms “agile” and “lean” actually mean “operating without enough developer resources,” and “using other tools or subscriptions would be outside our budget.”

Organizations in such a situation would undoubtedly benefit from the opportunity to combine their skills and experience in client service and expertise in financial services with those of a (currently) non-existent software engineer that speaks their business language. Constraints on budget and resources to scout, hire, onboard, and integrate talent are many, even in well-financed and structurally sound organizations, and they too would benefit from a solution that enabled the re-skilling of existing talent to make them even more “dangerous.”

 

The Low-Code/No-Code Revolution Across the Enterprise

Software development is moving “in-house” to drive digital transformation—quickly replacing End-User Computing (EUC)—and the stakes have never been higher for businesses to innovate quickly and capitalize on these ascendant tools. Financial services companies, in particular, seek to benefit from centralizing and streamlining their existing software development capabilities for clients, including building this capability from the ground up when it has previously been outsourced.

This is for a few reasons, namely security and the reduction of friction; Financial services companies deal in vast amounts of sensitive data, and security is a major concern of institutions and customers alike. Keeping software development in-house creates one less vulnerable touchpoint for cybercriminals to exploit; one less party to trust with sensitive data, and to transmit that data to and from; one less item on the client’s balance sheet to worry about when the same services can be performed faster and cheaper by their existing team!

To that end, low-code/no-code platforms are rapidly accelerating the capabilities of the enterprise to develop robust, bespoke applications with speed and security as part of their remit to clients. Examples of these range from the extremely targeted Genesis, a low-code/no-code platform built specifically for financial markets to the “one-size-fits-all” Appian, a general purpose low-code/no-code platform used to build many enterprise applications. With low code and no code, “citizen” developers are empowered to build applications and help unclog always-under-pressure IT departments.

Achieving speed, stability, and availability in software development is possible; in fact, these are all complementary outcomes. In this article, I’ll share actionable tips to achieve an effective pace of software development, as defined by the 4 key performance metrics described in Accelerate, a book by Dr. Nicole Forsgren et al., and with current industry data from the 2021 State of CD report from the Continuous Delivery Foundation.

1. Deployment Frequency

Defined as: How often changes are sent to users, ranging from less than once every six months to on demand many times a day.

The use of low-code/no-code platforms allows for improved deployment frequency by reducing friction and increasing delivery speed between the updates development and their shipping. By removing the reliance on IT teams to deploy and by simplifying the coding process into logical steps, any necessary updates can be made in short order, and problem areas in the logical sequence in need of revision can be quickly identified and patched. If low-code platforms help you build additional features quickly and simply, you will be able to deploy them to your end users just as fast.

Some additional tactics to optimize deployment frequency include the following: staffing teams properly and fully; auditing your organizational structure to be sure it is devoid of any redundancy that could slow workflow; automating deployment; prioritizing QA early and often in the development process; accurately assessing and building in ample testing time to your overall project timeline.

What’s more, being responsive to users’ feedback and quickly iterating on your bug identification and updates are key ways to show your users that you’re on top of things. An “elite” deployment frequency is “on-demand (multiple times per day)” according to Accelerate, indicating a team that is ready to deploy updates, whether critical or not, to their users at any given time. Only 1 in 10 developers are elite performers in terms of deployment frequency according to the State of CD report.

Your application is meant to solve a problem, and that is never one-size-fits-all. As client challenges evolve, so should your solution.

2. Lead Time for Changes

Defined as: How quickly changes can be sent to users, ranging from more than six months to less than an hour.

Similar to deployment frequency, an efficient lead time for changes (i.e., how long does it take to go from code committed to code successfully running in production) displays responsiveness and tenacity on behalf of your organization and/or team. However, this metric focuses on how quickly changes are implemented, instead of how often. For nearly two-thirds of developers, it takes at least one week to go from code committed to code successfully running in production, according to the 2021 State of CD report.

Optimizing performance for this metric shows your user base that your updates and implementations are sound, and that you care about keeping their UX up to date as quickly as possible.

Low-code/no-code platforms and tools have significant potential to improve lead time for changes. Low-code platforms offer the flexibility of using a traditional programming environment, or a point-and-click environment, or a combination of the two. Moving boxes around in the logical sequence of a low-code platform provides a level of abstraction that lower-level programmers or even the “citizen developers” on your team can grasp and utilize easily (relative to traditional coding), which opens up the potential for the entire team to contribute to shipping changes to users, saving time and opening the floor for new perspectives. With low-code/no-code platforms, more team members may work on ideas iteratively with customers to quickly build a series of experiments that test the usefulness of those ideas at a minimum-viable scale. With a short lead time for change or feedback cycle, the ideas showing strong evidence of good product-market fit can then be invested in heavily.

Some additional tactics to optimize lead time for changes include the following: utilizing multiple development environments to test software holistically and detect any bugs early; working closely with QA post-development environment in a feedback loop to ensure bugs are removed; clear expectation-setting and project management from managers to smooth workflows.

3. Time to Restore Service

Defined as: How long it takes to restore service, ranging from more than six months to less than an hour.

Unplanned outages, service incidents, and/or defects in any capacity, across all industries and categories, pose a serious threat to your product’s reputation, your brand, and your relationship with users. People can accept that these things happen, and while you may not be able to control when an outage might strike, what you can control is your level of preparedness to quickly respond in the event of an outage. Half of developers report that they restore service from an unplanned outage in less than a day according to the 2021 State of CD report.

Low-code/no-code platforms, particularly those that can show key quality metrics and status of work may vastly simplify the process of identifying service incidents and working to fix them. The ability to look at a deployment visually, at a higher level of abstraction than traditional code, is key for this rapid targeting and rectification of broken code that might have caused the outage. The high-level visual view provided by low-code/no-code platforms can be made available to both engineers and leaders, bringing better alignment around recovery strategies.

Some additional tactics to optimize time to restore service include the following: avoiding a high number of outages in the first place through thorough development; maintaining a culture with a sense of urgency in your organization; developing and maintaining a robust dashboard for incident capture and reporting, to ensure incidents don’t slip through the cracks.

4. Change Failure Rate

Defined as: How many times something goes wrong, ranging from 76% to 100% of deployments to only 0-15% of deployments.

By simplifying and abstracting the software development process through a low-code/no-code platform, development teams can reduce their change failure rate. When low-code/no-code platforms get the level of abstraction right, they can offer more “golden-path” ways to build the system which can result in an inherently lower margin of error. The change-failure rate often goes down with the experience of the team and low-code/no-code platforms can help in this way by providing a shorter on-ramp for team members to effectively leverage the platform and steer towards best practices.

Accelerate breaks this metric into different groups (ranges) of percentage of changes to production or released to users resulting in degraded service (e.g., lead to service impairment or service outage) and subsequently requiring remediation (e.g., require a hotfix, rollback, fix forward, patch). In other words, how often is your product failing? The book defines an acceptable frequency (for 3 of 4 categories) as 0-15%—i.e., your product fails and results in a disruption to service roughly 10% of the time. The outlier is the “low” range of Software Delivery Performance, with an abysmally high failure rate of 46-60% of the time (see chart below).

A low change failure rate shows your user base that the product is sound. It has been built with a strong foundation of code to prevent frequent degradations, and potential issues have been anticipated and “baked in” to the product “right out of the box.”

Similar to Time to Restore Service, some additional tactics to optimize (and lessen) your change failure rate include the following: avoiding a high number of outages in the first place through thorough development; maintaining a culture with a sense of urgency in your organization; developing and maintaining a robust dashboard for incident capture and reporting, to ensure incidents don’t slip through the cracks. As well, be sure to maintain a robust issue management system that is properly routed to capture incidents as soon as they happen.

What Does This Look Like in a Low-Code System?

Organizations undergoing a digital transformation must adopt principles and practices that guide them toward continuous delivery—e.g., continuous integration, test automation, continuous deployments, automated security, and others. The 4 key metrics from Accelerate low-code systems offer organizations not only a measurement of success for software delivery but also a bellwether for organizational performance.

Low-code/no-code systems are a viable means of arming your organization with the tools necessary to achieve these key metrics. Not only for “speed,” measured by Deployment Frequency and Lead Time for Changes, but also “stability,” measured by Change Failure Rate and Time to Restore Services:

Teams should utilize these platforms to reduce friction and increase delivery speed between the development of updates and the shipping of them; by simplifying the coding process into logical steps, they allow for potential issues to be quickly identified and patched. If low-code platforms help your teams to build additional features quickly and simply, you will be able to deploy them to your end users just as fast. They have inherent efficiencies in comparison with traditional code writing. Debugging is simplified, and any planned patches, new features, or changes to existing code can be implemented straightaway. The level of abstraction means lower-level programmers or even the “citizen developers” on your team can grasp and utilize the tool easily, opening up the potential for the entire team to contribute to shipping changes to users, which saves time and opens the floor for new perspectives.

Further, one of the biggest strengths of low-code/no-code platforms is giving teams the ability to look at a deployment visually, at a higher level of abstraction than traditional code, which is key for rapid targeting and rectification of broken code that might have caused an outage, or is in need of updating or otherwise changing. With less code to go around, there is an inherently lower margin of error, allowing your team to focus their efforts on continuous improvement and delivery, pursuant to the overall performance of your business and user satisfaction.

Why This Matters for the Enterprise

Organizations that prioritize DevOps and accelerate the speed of software development and adoption will have a competitive advantage over counterparts who don’t make similar investments. Financial services firms should continue to invest in software development acceleration, specifically low-code and no-code platforms, for several reasons.

These companies must bolster the stability of their software products and improve their speed, as financial services firms ranked highest among all industries for “stability” of software delivery performance, but toward the 50th percentile for “speed” of delivery, according to the State of CD report. This makes sense, as financial services products simply can’t afford to fail, in terms of Change Fail Rate and Time to Restore Services—both of which have the potential to cause major disruptions for individuals, and even greater consequences for enterprise or commercial clients with untold sums of money on the line.

Speed of delivery—measured by Deployment Frequency and Lead Time for Changes—is less of an issue, as financial services firms are (rightly) more focused on their products being functional rather than being delivered to users and updated rapidly. However, as banks and other financial institutions face mounting pressures to innovate from new business models from technology companies and FinTech startups, keeping customers may well become a matter of “How fast can you innovate?” setting the stage for low-code/no-code adoption to improve this already mediocre speed of software development and delivery when compared with other industries.

Low-code/no-code systems help to simplify the software development process such that stability can be even further strengthened to protect against such failures, compared with traditional coding; as well, these tools can help financial institutions speed up their software delivery significantly, offering clients new and more useful products that keep them excited about who they are doing business with.

Educating Firms on the Importance of Low Code/No Code

While some analysts agree that the industry has “crossed the chasm” on DevOps acceleration (to paraphrase Geoffrey Moore) the biggest barriers to broad low-code/no-code adoption and digital transformation still lie in a lack of education among employees, C-Suite executives, and users (customers) in the finance community.

Finding ways to connect with finance professionals and “speak their language” when evangelizing low-code/no-code solutions is key. While software development acceleration platforms certainly provide immense value across the enterprise, explaining use cases that make sense for financial services professionals, tying in potential solutions to the business challenges they face, and explaining the ROI in the short and long-term are crucial to obtain buy-in from this sector.

Professionals everywhere are talented in myriad ways, so it behooves firms to invest and dig deeper into their existing talent, re-skilling and empowering them with these tools, to gain competitive advantage—rather than looking externally to developer vendors that won’t understand the business nearly as well as the employees themselves.

Conclusion

Low-code and no-code platforms have enormous potential across financial markets—from simple business process management (BPM) to more complex uses. They are an empowering new development for business professionals to create applications for clients, enabling them to innovate and solve problems in a way that was previously foreign and inaccessible, behind the walls of traditional software development education and talent (i.e., your engineering or IT department).

Clients will always be interested in the best possible solutions for the least possible cost, the fastest time to market, and the bottom line. As the industry grows and low-code/no-code platforms become more sophisticated, it will be all the more important for financial services professionals to seek adoption of such tools in their organizations, lest they be left by the wayside as more future-focused competitors take their business.