Products and Components

In system architectures, the difference between what is considered an Application (product), and what is a Component is not always clear cut.  This distinction is particularly apparent when it comes to micro-services.  In IriusRisk, it's possible to model individual micro-services as products, or to model them as groups of components within a parent product.  Which option is best depends on how you intend to work with the model, particularly in the UI and through the API.

The points to bear in mind when deciding on which approach is better are:

• The portfolio view displays summary information for Products
• The portfolio view can compare the average risk ratings for Products
• User defined fields can be applied for Products, but not for Components
• Issue trackers can be integrated with a Product, but not a Component
• Test results can be uploaded through the API to both Products and Components

Model Individual Services as Products

Creating a separate product for every service has the following advantages:

• the average risk ratings can be viewed on the Product and Portfolio tabs.
• The tables in the Threats and Countermeasure tabs contain a manageable number of rows which means they're easier to use through the UI
• User defined fields can be attached to each service
• Issue tracker projects can be linked to each service

Disadvantages:

• The average risk of the owning service can't be viewed as a whole.
• Related services can be grouped together using two mechanisms:
  • Use a common 'tag' for each
  • Create a User Defined Field to hold this value.  If the number of owning services don't change often then consider using a pre-defined list instead of a free form text field.

Model Individual Services as Components within a Product

To use this method, related components should be placed in Groups.  Groups are defined by editing the Component (double click on the component in the Threats tab, or choose the "Edit Component" option on the architecture tab), the "Group Name" text field will be editable in the questionnaire window:

Advantages:

• The average risk ratings of the entire product can be viewed, rather than the average risk ratings of individual services
• Lower licensing costs
• All threats for the entire product can be edited in a single table

Disadvantages:

• All services would have to use the same Issue tracker project, because this is associated with the Product, not the Components
• The number of threats in the threats table can become unwieldy and difficult to manage in the UI
• The average risk ratings of individual services can't be viewed since they're all aggregated together as one product