What makes software business-critical?
Whether a system is considered business-critical determines the level of test coverage, redundancy, and support it receives, as well as whether a standard solution is an option.
According to a study by Cisco and Splunk in collaboration with Oxford Economics, unplanned outages cost large German companies an average of $295 million per year, $89 million of it in lost revenue. How much protection a single system gets against downtime depends on how business-critical it is considered to be. We use this term ourselves on our website because we develop software for business-critical processes. But when exactly does an application become business-critical – and can you measure it?
What defines business-critical software
An application is business-critical if its failure stops the core business, operationally, legally, or financially.
Examples:
Operational: If the system fails, there is no real workaround. At best, work moves to another system or onto paper for a few hours.
Legal: If the system fails, an outage puts customer data and documents subject to retention rules at risk.
Financial: During a system outage, no new orders come in and they are not made up for afterwards.
What matters is the process the software carries: a small tool that controls order approval can be more critical than a complex data warehouse.
What does mission-critical, business-critical, and success-critical mean?
In everyday use, these terms are often used interchangeably, even though they describe different levels of damage.
Mission-critical systems must not fail, because the failure itself would be a disaster. Here, redundancy belongs at every level, and failover to a backup system has to happen as fast as possible, without losing data.
Business-critical applications cause significant damage in the event of a failure, but the company can weather it. For example, a sales team can work for a day without its CRM. Revenue is lost and a few hours of overtime pile up, but core operations keep running. Enterprise-critical is usually used interchangeably with “business-critical,” occasionally with the added implication that the impact extends beyond a single department.
Success-critical sits one level below. If it fails, business operations slow down, but continuity is not at stake.
Levels of criticality
| Level | Recovery time | Typical Systems | Impact |
| Mission-Critical | Seconds | Air traffic control, payment processing, energy grid control systems | Catastrophic. Redundancy at every level; failover must occur within seconds. |
| Business-critical Often synonymous with: Enterprise-critical | Hours | Order processing, ERP, CRM, billing, inventory management | Serious. A failure would cause significant damage, but the company would survive it. |
| Success-critical | Days | Reporting, dashboards, marketing tools, internal wiki | Slows things down. Business operations slow down, but continuity is not at risk. |
There are no standard definitions for any of these terms, but they can be categorized using two metrics: the recovery time objective (RTO) and the recovery point objective (RPO). Without those two numbers, there is nothing concrete to back up a request for more budget or broader test coverage.
In addition, how critical a system is also depends on the industry. A time-tracking system is more business-critical for an agency that bills by the hour than for a retailer that uses it for admin.
How to identify business-critical software
Five questions give you a first read if an application is business-critical.
- What does one hour of downtime cost? This includes the wages of the teams that can no longer work, lost revenue, and the cost of the subsequent rework.
- Which systems depend on it? Some applications are critical simply because of what depends on them. A master data service doesn’t generate revenue on its own, but if it fails, it blocks eight other connected systems.
- Is there a fallback mode, and how long can it realistically run? Alternative systems can bridge a half-hour gap, but after three days a backlog builds up that can take more effort to clear than the outage itself caused.
- How quickly must the system be back online? The answer to this question helps you determine the RTO and RPO.
- Does the application provide a competitive advantage? Software that supports a custom process is harder to replace than software that performs standard tasks.
Once you have answers to these questions, you have a much clearer picture of how critical a system really is.
The cost of downtime
Direct costs result from lost revenue and tied-up labor hours. The Cisco/Splunk study estimates the global cost of unplanned downtime at approximately $15,000 per minute.
Knock-on costs arise after the issue is resolved: data reconciliation, rework, and rescheduled deadlines. How large they get depends on how cleanly the recovery goes, and only 38% of the technology leaders surveyed say they can always pinpoint the cause of an outage. Hybrid IT environments and dependencies on SaaS providers complicate the analysis.
Reputational costs are hard to quantify, but they do show up in the numbers: According to the same study, companies lose an average of 3.4% of their market value following a major outage.
Compliance costs put a clock on all of this. Under NIS2, in-scope companies across the EU have 24 hours to file an early warning about a significant incident, 72 hours for a fuller notification, and a month for the final report. Even suppliers outside the directive's scope feel it, because those obligations get passed down by contract. Hitting those windows takes usable logs, monitoring that flags incidents early, and people who know the system well enough to find a cause fast.
The CrowdStrike IT Outage
The CrowdStrike IT outage on July 19, 2024, shows that this risk is anything but theoretical. According to Microsoft’s estimates, a faulty configuration file in the CrowdStrike Falcon security software crippled approximately 8.5 million Windows systems worldwide, including those at airports, banks, and hospitals. Two German hospitals had to call off surgeries. Delta Air Lines grounded 7,000 flights and put its losses at more than $500 million in a lawsuit against the vendor. The incident was not an attack, but rather an error in a routine update.
Two details of this incident are particularly interesting from a development perspective:
- First, for many of those affected, the outage dragged on for days, because every machine had to be repaired by hand in safe mode. This illustrates once again that the duration of an outage is determined by the recovery process, not by the error itself.
- Second, Delta alleged in the lawsuit that the update had been rolled out without testing. Normally, changes of this kind are tested internally and then deployed in phases to prevent a global disruption from occurring in the first place.
The Consortium for Information & Software Quality (CISQ) estimates the cost of poor software quality in the U.S. for 2022 at least 2.41 trillion U.S. dollars, with accumulated technical debt totaling around $1.52 trillion. The report identifies finding and fixing bugs as the single largest cost driver over a system's lifetime.
Off-the-shelf or custom-built?
Whether a standard solution or a custom development is the right choice depends on how unique the process is, not on how critical it is. Accounting is business-critical in many companies because payment cycles, month-end closings, and VAT filings are subject to deadlines, but most organizations do their accounting in the same way. Processes like these are well served by mature products, hardened by thousands of users and updated as the rules change. A custom-built solution would have to rebuild the same regulatory logic and then keep it current on its own. Off-the-shelf software is usually the better fit here.
The limitations of off-the-shelf software become apparent in three areas:
- If the process is part of your competitive edge, bending it to fit a standard product means giving some of that edge away.
- If multiple systems need to work together, the integration effort can exceed the cost of developing a custom application.
- If data such as trade secrets must not leave the company, the field of viable products narrows sharply.
If any of these points apply, custom software is probably a better fit. To help make the decision, it’s useful to compare the costs of a software subscription vs. custom-built solutions.
Building and running business-critical software
Business-critical software is developed continuously over many years, and any change to a live system can pose a risk. That is why automated testing is what keeps changes affordable. It turns a modification that previously required days of manual verification into a process that takes only minutes. At makandra, test-driven development has been part of our approach since the company’s founding, and we’ve now applied it to more than 200 projects.
However, even tests can only catch what someone thought of in advance. The rest surfaces in the production. That’s why changes run against copies of the production environment before they go live. In addition, a phased rollout ensures that errors reach a small group at most and that outages on the scale of CrowdStrike don’t occur in the first place.
A third factor belongs in the plan from day one: longevity. For a system intended to last ten years or longer, a significant amount of work remains even after it goes live. The foundation ages: frameworks and libraries receive security updates for a few years, then official support ends. From that point on, newly discovered vulnerabilities remain unpatched, and eventually an upgrade to a new version is required, usually under time pressure and with the system still live. Modularity and automated testing keep such upgrades affordable.
That leaves operations itself. A team that built an application and also runs it finds the cause of a problem faster than a provider who only knows one half of the setup. Set against that 38% figure from the Cisco/Splunk study, this is a strong argument for keeping development and operations in one place. We have supported the Studyflix learning platform since 2018 through a hundredfold increase in traffic – from ongoing development to scalable operations.
Conclusion: Assess the situation first, then decide
Business-critical is not a property of the technology, but rather a statement about the process that the software supports. Anyone who applies the label should be able to back it up with two numbers: how long an outage can last and what it will cost during that time. These two numbers drive everything else, from test coverage and architecture to the question of who runs the system.
