Who is responsible for lowering software risk? Cutter Consortium Senior Consultant Pete Kaminski has been looking at the business risks posed by software and how to mitigate them. He gives context to the issue this way:
“Driving business risk down is just smart business. Software-related business risk is an increasing portion of business risk, so knowing how to assiduously reduce software risk has become part and parcel of today’s business reality. Fortunately, there is an array of tools and methods that you can apply across your portfolio of software assets and development projects to manage software risk, which we’ll explore in this Executive Update. Industrializing software risk management is critical for organizations in the digital age. It unleashes the 'smarts' in developers so that they can work on the difficult parts of building and delivering applications for the future, while ensuring current, past, and future risk is baked out of applications, putting both human intelligence and software intelligence to their best use.
“Risk can be measured and mitigated at two complementary levels: the component level and the overall system level. There are powerful static code analysis tools available for both levels. Choice of analysis type depends on where the system is within its development and operation lifecycle of the software portfolio.
“Systemizing software risk management offloads automatable work of software architects and engineers so that they can focus instead on knowledge work and innovation for business benefit. Doing so allows the organization to improve development velocity, reduce the chance of outages or security breaches, and compete for current and future business more effectively.”
As Kaminski details in his recent Executive Update, Mitigating Business Risk: A Systems Perspective, many IT organizations are structured in a way that defies effectively managing business risk. Who should be responsible? Overall security is the mandate of CISOs, but they aren’t involved in day-to-day engineering/application development; architects set up the standards that determine how developers reduce risk, but are often disconnected from development when the apps are being built; and QA, while in charge of product quality don’t ordinarily have insight into how software is engineered. By default, mitigating software risk falls to developers. However, with today’s applications growing in both size and complexity, and a dizzying pace of delivery, developers’ view into software systems is diminishing. Ultimately, it should be the product owners/product managers who are responsible for managing the risk. Kaminski recommends they do this by leveraging contextual software analysis.
In his report, Kaminski reviews some tools, including Coverity Architecture Analysis and CAST Application Intelligence Platform (CAST AIP) to help measure and reduce software risk.
According to Kaminski, in addition to reducing business risk such as loss of revenue, negative PR, and negative customer/employee experience, mitigating software risk helps:
Cutter clients can read Pete Kaminski’s full Executive Update, Mitigating Business Risk: A Systems Perspective, as well as his follow on Update, Mitigating Business Risk: Unlock Software Potential.