Commentary -With IT at the heart of every modern enterprise, most business executives believe IT failures are their greatest day-to-day risk – ahead of terrorism, natural disaster, financial risk or regulatory constraints. Executives see IT applications as blind bets on big, expensive black boxes. Too often, the serious risks to which an application exposes the business are hidden behind innocuous status reports. To accurately measure and monitor this business risk, we need to measure the internal quality of applications—that is, the extent to which their architecture and coding protect the business from damaging consequences.
The recent software glitch in HP's Omega sales compensation system that prevented 2,000 employees from receiving their proper monthly commissions, a worldwide ATM scam that swindled $9 million and possibly compromised sensitive customer information, and a $23 quadrillion Bank of America glitch are just a few examples of highly publicized failures of business critical systems – failures that can wipe out an organization's hard-earned credibility in the blink of an eye.
The cause of such disasters? Toxic applications. Every business suffers with toxic applications – mission-critical applications with undetected time bombs waiting to explode, often when least expected. They are the applications that crash the corporate website, suffer outages during peak business hours, produce corrupt data in financial reports and yield confidential customer data to hackers.
Until recently, the risks of toxic applications were difficult to quantify because their origins were shrouded in the arcane languages of programmers. CIOs and business executives should not have to understand source code, but it is in the source code where business risk lurks. Measuring this risk requires measuring the source code and providing summary insight to executives. Once measured, these risks have to be monitored and managed by both the IT and business executive teams.
If not addressed in time, toxic applications can erupt into one of the following problems.
- Outages – The causes of system outages frequently sneak unexposed even through stress testing, since the load of business transactions required to push the application over the edge may be impossible to simulate in the testing lab. The business loss from outages begins with the lost revenue from missed or failed transactions and is compounded when customers switch to competitors.
- Degraded performance - Although degraded performance may be an indication of an impending outage, the system may just as well continue to trudge along growing slower and slower. Like outages, performance degradation may not be detected during load testing. Yet unlike outages which occur suddenly, performance problems grow slowly wreaking their damage through a thousand small cuts. The cost of a 5 percent loss in productivity spread across 1,000 knowledge workers is shocking when computed. Degraded performance escalates maintenance costs, drains the productivity of business teams, and frustrates customers.
- Erratic behavior – Users often experience bizarre outcomes with applications that otherwise appear stable. These occasional aberrations typically result from inconsistencies, mistakes, or unintended side effects from mistakes developers made in constructing the business logic or user interface. These problems may only become visible when users begin interacting with the application in ways that were never anticipated during development and test cycles. When an application behaves erratically users begin driving up help center costs and may ultimately distrust the application. Worse, a customer’s distrust may ultimately extend to the company as well.
- Data corruption - The first person to detect data corruption is often a business customer spotting inconsistencies in sensitive business documents. Data corruption often occurs because developers do not adhere to rules that control how their components should interact with the database. As a result, database records are updated without the appropriate coordination or control, leading to weeks of corrupted transaction data and countless more weeks spent on re-entering lost transactions.
- Security breaches - Nothing damages a company’s reputation faster than security weaknesses that enable hackers to access critical business information. These weaknesses are rarely in the functional logic of an application. Rather they hide in architectural and coding flaws that frequently pass undetected through testing. The cost of security breaches can be staggering, especially in states that require notification of every customer who was potentially at risk.
Mission-critical applications come with risks that have sizeable business consequences. These risks grow steadily worse as three trends create the perfect IT storm. First, business applications are growing larger and more complex by an order of magnitude every decade. Second, business cycles are compressing, requiring greater agility to compete in fast-moving markets. Third, more of an enterprise’s critical business processes are being committed to IT applications.
These colliding trends force IT executives to accelerate adding functionality to applications that are growing more complex daily. Worse yet, they are required to do it for less money each quarter, feeding the temptation to cut corners on sound development practices. These conditions are the breeding grounds for the types of disasters cited above.
Since we cannot control the pace of markets, we must control the internal quality of critical business applications so that the pace and quality of software development can scale with the size and complexity of systems. Not only can the risks in an IT application be precisely identified and quantified, IT and business executives must take proactive steps to mitigate these risks. Tackling the potential damage hidden in IT applications is the next frontier in IT and business risk management.
biography
Bill Curtis is the Senior Vice President and Chief Scientist of CAST. He is best known for leading development of the Capability Maturity Model which is the global standard for evaluating the capability of software development organizations.
Dr. Curtis holds a Ph.D. from Texas Christian University, an M.A. from the University of Texas, and a B.A. from Eckerd College. He was recently elected a Fellow of the Institute of Electrical and Electronics Engineers for his contributions to software process improvement and measurement.
