Are MP’s demands the solution to UK’s banking IT problems? (Part Two)

For some time now the European banking sector has been in the firing line.

CAST, whose software quality solutions are designed to prevent such unscheduled IT glitches, predicted last year that the systems which run exchanges as well as those internal to banks, were not robust enough to ensure IT issues did not cause costly business interruptions. Sadly, this has already proved true weeks into the New Year. Therefore, there is an urgent need to measure the software risks banks face on their critical IT applications to help take objective decisions about how IT transformation should take place.


Further factors that banks can take to improve the reliability and security of their code and minimise the risk of becoming a victim of a major software outage include:

  • Conducting careful structural testing of the software before deployment
  • Transparency between the banks and its vendors, to ensure the appropriate level of software updates and protection is taking place.
  • Diligent patching and software updates can often be behind the major IT glitches at banks, so these need to be carefully conducted
  • Measure the quality of their software against global standards from CISQ (Consortium for IT software Quality) which measures the four aspects of software including, reliability, security, performance efficiency and maintainability.


CAST believes the financial services industry needs standards based on low cost, automated measures for evaluating software size and structural quality that can be used in controlling the quality, cost and risk of the software that is produced either internally or by outsourcing partners.


This is where CISQ code quality standards can be used to carry out an audit of its applications. Without a benchmark to measure against they are less likely to have an understanding of where the problems are within their system.


CISQ code quality standards can be used to detect critical violations of good coding and architectural practice in software. Initially, there would need to be the measurement against software quality standards at every release, e.g. measure code compliance to secure architecture, and put CISQ software quality measures into contracts with outside developers or software vendors to track established outcomes.


Using such architectural and structural analysis tools in accordance with the CISQ standards allows for non-IT executives and application owners to use this insight to identify which of the applications present the greatest risk to their business or involve the highest cost of ownership. These measures can also be used externally to benchmark service level agreements in their outsourcer agreements with greater accuracy.


Why do we need software quality standards?


Software quality measurement is often in the eye of the beholder, and it can fall victim to the perspective and values of whoever happens to be judging the code. But it should not ,now that there are agreed industry standards. These are designed to develop a common understanding between developers and enterprises of how software systems are analysed, as well as how to detect architectural and coding flaws.


The fact of the matter is that the top management at companies like HSBC don’t seem to understand the complexity of the technology they’re managing and they leave the responsibility for reliability to their development teams. Their developers try to do a good job, but they are also pushed by the business to deliver the digital transformation, the next marketing program, and the next customer service functionality as soon as possible.


At the heart of the issue, neither the developer nor their management have all the information in one place to make informative trade-offs. IT executives think structural issues are technical and not their concern, but it’s the technical issues that account for more than half of software disasters and top management needs to step up to manage these and implement an audit of its applications.