Teams should avoid turning a single metric into the main goal. DORA explicitly warns against treating metrics as targets or relying on “one metric to rule them all.”
For example, increasing deployment frequency while simultaneously increasing production failures would not necessarily represent an improvement.
A Practical Reliability Strategy for Banking Applications
A useful approach is to build reliability progressively.
Step 1: Establish a Baseline
Measure the current application’s:
- Availability
- Latency
- Error rates
- Incident frequency
- Recovery performance
Step 2: Identify the Biggest Bottleneck
The problem may be a database, inefficient code, network dependency, deployment process, or infrastructure limitation.
Step 3: Automate Repetitive Controls
Automate testing, deployment checks, monitoring alerts, backups, and other suitable processes.
Step 4: Test Failure Scenarios
Do not only test when everything works. Simulate service failures, database problems, network interruptions, and deployment issues.
Step 5: Review the Results
Reliability should be measured continuously rather than checked only after a major incident.
Final Thoughts
Reliable banking applications are built through a combination of technology and disciplined engineering practices. Strong architecture, scalable infrastructure, reliable databases, automated testing, careful deployment, observability, security, and recovery planning all contribute to the final result.
The available research also shows why reliability should not be reduced to a single percentage. DORA’s framework measures multiple dimensions of software delivery and distinguishes throughput from instability, while its reliability research considers broader operational characteristics.
For banks, the objective is not simply to make applications available. A dependable banking application should remain responsive, protect customer data, process transactions correctly, recover from failures, and evolve without creating unnecessary operational risk.
