CAST Architecture Checker

Oct 01, 2012

Measuring the technical quality of business software applications is evolving from an art to a science with the availability of software tools that automate the process of code analysis. However, it is critical to understand that there are two categories of software quality with very different implications for operational performance. The first category is Code Quality which measures individual or small collections of coded components written in a single language and occupying a single tier (e.g., user interface, logic, or data) in an application. The second category, Application Quality, analyzes the software across all of the application’s languages, tiers, and technologies to measure how well all an application’s components come together to create its operational performance and overall maintainability. 

Although the code quality of individual components is important, by itself it will not ensure the overall quality of the application. Quality is not an intrinsic property of code: the exact same piece of code can be excellent in quality or highly dangerous depending on the context in which it operates. Ignoring the larger context in which the code operates – the multitude of connections with other code, databases, middleware, and APIs – will often generate a large number of false positives. 

Today’s business applications are complex, built in multiple languages on multiple technologies (see illustration below). Even more challenging, these applications usually interact with other applications built on different technologies. 

Business Critial Application

Analyzing the quality of modern applications is monstrously complex and can only be accomplished with automated software that analyzes the inner structure of all components and evaluates their interactions in the context of the entire business application.

Due to this new type of architecture, architects in IT organizations need to define a way to enforce best practices and architecture, in order to ensure efficiency and stability of business critical applications. One of the main abilities an architect needs is to review the layer dependencies and to ensure that the implemented architecture is in compliance with the defined architecture. Components in one tier of a multi-tier application are typically designed to access components in another tier only through an intermediate “traffic management” component. Bypassing this traffic management component will usually result in a cascade of problems. 


Since CAST AIP's knowledge base will contain all of the components of the application and framework as well as the dependencies of those elements, the architect will be able to define a group of components and control the dependency between those modules. The selection of the module can be done via naming convention - path, type of objects, and dependency with a third type of object.

The result of this check will then be available via the architecture checker or will be integrated as part of the assessment model and the end user will be able to review the list of components in violation for this architecture rule.