Page tree
Skip to end of metadata
Go to start of metadata
On this page

 

Behind the concepts

CAST AIP data is composed of a hierarchy of Systems, Applications, and Modules.

  • Applications are intended to be tightly coupled sets of executable software components (one or more), deployed together, that deliver some or all of a series of steps needed to create, update, manage, calculate or display information for a specific business purpose.
  • Systems are intended to represent groups of Applications that regularly interact or interrelate together.
  • Modules are intended to model executable software components or tightly coupled sets of executable software components (one or more), developed and deployed together, that deliver some of the steps needed by an Application to operate.

Many features and default behaviors are taking these definitions into account.

E.g.:

  1. The CAST Application Analytics Dashboard consolidates Applications from Dashboard Services and supports user-defined grouping
  2. Snapshot perimeter is the whole Application
    1. each Module has to be processed together to deliver the correct assessment.
    2. Applications in the same System can be processed at different time, with different frequencies

Important considerations

The Systems, Applications, and Modules organization drives the quality and quantity information feedback to CAST Dashboard end-users.

Important considerations about the Systems, Applications, and Modules organization are:

  • The Systems is a grouping of Applications
    • The grouping is important as it will expose grouped Applications together, thus supporting direct benchmarking within a System, and also allowing some System-level aggregations (cf. following bullet points).
    • As grouped Applications can be of very different nature, there is no aggregation of quality indicators' results, except for high level ones, that is: Health Factors (the underlying levels helps make results comparable), as the average of all included Applications.
    • Then, sizing indicators are aggregated at the System level, as the sum of the quantity information of all the included Applications.
  • The Application is a grouping of Modules
    • Application is built from grouped Modules: what is not part of a Module will not be part of the Application
    • Application is the entity that gets "snapshoted": the assessment frequency is Application-wide, requiring that you do get a Snapshot of all included Modules, but allowing to have different assessment frequencies for different Applications of a single System.
    • Application aggregates quality indicators' results, as the average of all the grades of all the included Modules.
      Quality aggregation does not – need to – take into account the presence of objects in multiple included components, as each Module is assessed autonomously, taking into account its own contained objects.
    • Application aggregates sizing indicators' results, as the sum of the sizing results of all the included Modules.
      Sizing aggregation takes into account the presence of objects in multiple included Modules, and does not count them multiple times
  • Application, System and Module node names will be used for result restitution throughout the CAST Engineering Dashboard. Picking meaningful names is therefore highly valuable.

 

  • No labels