Share this:

How to Identify Architecturally Complex Violations

Bill Dickenson, Independent Consultant, Strategy On The Web


Dr. Richard Soley, the Chariman and CEO of OMG, published a paper for CISQ titled, How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems in Line with CISQ Recommendations, that outlines the software quality standard for IT business applications. The last post explored the relationship between unit and system level issues.


The logical and obvious conclusion is to dramatically increase the effort focused on detecting the few really dangerous architectural software defects. Unfortunately, identifying such ‘architecturally complex violations’ is anything but easy. It requires holistic analysis at both the Technology and System Levels, as well as a comprehensive, detailed understanding of the overall structure and layering of an application. For those needing further confirmation and explanation of such problems, the most common examples for each of the four CISQ characteristics, are described below.   


#1 Reliability & Resiliency: Lack of reliability and resilience is often rooted in the “error handling.” Local, Unit Level analysis can help find missing error handling when it’s related to local issues, but when it comes to checking the consistency of the error management across multiple technology stacks, which is tactically always the case in sophisticated business applications, a contextual understanding at the Technology and System Levels is needed. A full analysis of the application is mandatory because developers may simply bypass data manipulation frameworks, approved access methods, or layers. As a result, multiple programs may touch the data in an uncontrolled, chaotic way. Bad coding practices at the Technology Level lead to two‐thirds of the serious problems in production.   


#2 Performance Efficiency: Performance or efficiency problems are well known to damage end‐user productivity, customer loyalty, and to consume more IT resources than they should. The ‘remote calls inside loops’ (i.e. remote programs executed on a remote device from another program itself located in a loop) are a well‐known example that creates performance problems. A top down, System Level analysis is required to search down the entire system calling graph to identify the source of the problem. Performance issues in the vast majority of cases reside in System Level.


#3 Security & Vulnerability: Detecting backdoor or unsecure dynamic SQL queries through multiple layers requires a deep understanding of all the data manipulation layers as well as the data structure itself. Overall, security experts Greg Hoglund and Gary McGraw believe cross‐layer security issues account for 50% of all security issues. The Common Weakness Enumeration database maintained by MITRE is essential for removing common defects.

One thought on “How to Identify Architecturally Complex Violations

  1. We are exploring CISQ for our application. we need some clarification on the below measure.Kindly clarify on this,
    “7.17 Pattern definition of ASCRM-RLB-5: Runtime Resource
    Management Control Element in a Component Built to Run on
    Application Servers”
    Measure Element:
    “Number of instances where the application uses deployed components from application servers, yet uses control elements from the list of low-level resource management API.”

    I need to know what are the list of Low-Level RM API’s referred in this violation.It would be great on your response. Thanks and kind regards.

Leave a Reply

Your email address will not be published. Required fields are marked *



Comment validation by @