Category: Risk & Security

When the entire Facebook platform -- including mobile, web, and third party apps -- went down last week, users took to Twitter hashtag #FacebookDown in a blind panic to lament the social media outage. Though these outages might seem harmless and commonplace, Facebook’s reputation rides on their users’ ability to log onto Facebook from anywhere, at any time. And the more Facebook users have to turn to Twitter or other social networks to have their online voices heard, the harder it will be for them to log back in.

The current state of outsourced application development is a sorry state of affairs because of myriad software quality issues causing unprecedented glitches and crashes. It’s not that all outsourcers are making terrible software, rather, it’s that governments and organizations have no way of accurately measuring the performance, robustness, security, risk, and structural quality of the applications once they’ve been handed the keys.

Because the world of software development is so incredibly complex and modular, quality assurance and testing for software risk has become costly, time-consuming, and at times, inefficient. That’s why many organizations are turning towards a risk-based testing model that can identify problem areas in the code before it’s moved from development to testing. But be careful, because hidden risks can still exist if you don’t implement the model properly throughout your organization.

Most organizations have started to realize that code quality is an important root cause to many of their issues, whether it’s incident levels or time to value. The growing complexity of development environments in IT -- the outsourcing, the required velocity, the introduction of Agile -- have all raised the issue about code quality, sometimes to an executive level.

Business applications have always been complex. You can go back to the 70s, even the 60s, and hear about systems that have millions of lines of code. But here’s the rub: In those days it was millions of lines of COBOL or some other language. But it was all one language. All one system. All one single application in a nice, neat, tidy package.

I had the pleasure of moderating a panel discussion with Bill Martorelli, Principal Analyst at Forrester Research Inc; Dr. Richard Mark Soley, Chairman and CEO of Object Management Group (OMG); Siva Ganesan, VP & Global Head of Assurance Services at Tata Consultancy Services (TCS); and Lev Lesokhin, EVP, Strategy & Market Development at CAST.

In my last post we discussed the complimentary nature of remediation cost and risk level assessment. As a follow up, I wanted to dwell on the objective risk level assessment. Is it even possible? If not, how close to it can we get? How valuable is an estimation of the risk level? Could it be the Holy Grail of software analysis and measurement? Or is it even worth the effort?

I’ve been asked time and again how CAST is different from performance engineering. And here’s my answer: The CAST discipline of software analysis and measurement versus performance engineering couldn’t be more different. And I’ll explain why and how in a moment. But along with that, it should be noted that they also are like peanut butter and chocolate -- they can go very well together.