Category: Risk & Security

The software architecture is one of the most important artifacts created in the lifecycle of an application. Architectural decisions directly impact the achievement of business goals, as well as functional and quality requirements. Yet once the architecture has been designed, most architectural descriptions are seldom verified or maintained over time. Architecture compliance checking is a sound application risk management strategy that can detect deviations between the intended architecture and the implemented architecture.

Application Risk Management: Good Software Architecture is Good Business

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.

Software Risk: 3 Things Every IT Manager Must Know About A Risk-Based Testing Model

As technology increasingly becomes the backbone of business, it is also becoming the single most expensive asset within any organization—bringing the topic straight to the boardroom. What most of us may not appreciate is that the custom software being built for enterprises has surpassed a threshold of complexity that would allow for any one person to understand an entire mission-critical system. And, unlike any other part of our critical infrastructure, there is no single manager who is responsible and accountable for the integrity of a company’s software backbone.

Software Risk Goes to Washington

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.

Does code quality really help the business?

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.

Reduce Software Risk through Improved Quality Measures with CAST, TCS and OMG

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?

The Holy Grail: Objective risk level estimation

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.

Why Performance Engineering Isn't Enough

Risk detection is about identifying any threat that can negatively and severely impact the behavior of applications in operations, as well as the application maintenance and development activity. Then, risk assessment is about conveying the result of the detection through easy-to-grasp pieces of information. Part of this activity is about highlighting what it is you’re seeing while summarizing a plethora of information. But as soon as we utter the word "summarizing," we risk losing some important context.

Is Every Part of the Application equal when Assessing the Risk Level?

Risk detection is the most valid justification to the Software Analysis and Measurement activity: identify any threat that can negatively and severely impact the behavior of applications in operations as well as the application maintenance and development activity.

Risk Detection and Benchmarking -- Feuding Brothers?

My six-year-old can tie her own shoes. I honestly did not realize how big of a deal that was until her teacher told me a few months ago that she had, for a short time, become the designated shoe tier in her classroom. Apparently, thanks to the advent of Velcro closures for kids’ shoes, nobody else in her kindergarten class knew how to tie their shoes.

Mozzilla Thinks Crashes are a GOOD Thing...Really?

Any advocate for better software quality knows that one of the biggest challenges is helping the CIO reach the CFO. When your team needs a budget for an important project, those conversations often break down. Thanks to the unavoidable technical complexity of IT, oftentimes the CIO might as well be speaking Esperanto to the CFO.

The Tech Babel Fish for CFOs

We all know testing is an essential step in the application development process. But sometimes testing can feel like your team is just throwing bricks against a wall and seeing when the wall breaks. Wouldn’t it make more sense to be measuring the integrity of the wall itself before chucking things at it?

Don’t Wait For Load Testing to Find Performance Issues

  • Why good architecture is a synonym of cost reduction

  • Reduce Software Risk through Improved Quality Measures with CAST, TCS and OMG

    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.

  • Estimating the Hidden Costs of Cost Estimation

  • The Holy Grail: Objective risk level estimation

    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?

  • Don't Underestimate the Impact of Data Handling

  • Why Performance Engineering Isn't Enough

    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.

  • Is Every Part of the Application equal when Assessing the Risk Level?

    Risk detection is about identifying any threat that can negatively and severely impact the behavior of applications in operations, as well as the application maintenance and development activity. Then, risk assessment is about conveying the result of the detection through easy-to-grasp pieces of information. Part of this activity is about highlighting what it is you’re seeing while summarizing a plethora of information. But as soon as we utter the word "summarizing," we risk losing some important context.

  • Surviving the IT Perfect Storm

  • How to Build the Best Action Plan for your Application

  • Risk Detection and Benchmarking -- Feuding Brothers?

    Risk detection is the most valid justification to the Software Analysis and Measurement activity: identify any threat that can negatively and severely impact the behavior of applications in operations as well as the application maintenance and development activity.

  • Don’t Blame the Outsourcer

  • Mozzilla Thinks Crashes are a GOOD Thing...Really?

    My six-year-old can tie her own shoes. I honestly did not realize how big of a deal that was until her teacher told me a few months ago that she had, for a short time, become the designated shoe tier in her classroom. Apparently, thanks to the advent of Velcro closures for kids’ shoes, nobody else in her kindergarten class knew how to tie their shoes.

  • The Tech Babel Fish for CFOs

    Any advocate for better software quality knows that one of the biggest challenges is helping the CIO reach the CFO. When your team needs a budget for an important project, those conversations often break down. Thanks to the unavoidable technical complexity of IT, oftentimes the CIO might as well be speaking Esperanto to the CFO.

  • Don’t Wait For Load Testing to Find Performance Issues

    We all know testing is an essential step in the application development process. But sometimes testing can feel like your team is just throwing bricks against a wall and seeing when the wall breaks. Wouldn’t it make more sense to be measuring the integrity of the wall itself before chucking things at it?

  • Android Application Failures Still Try Our Souls

  • -->