we would like to create our CMDB in AssystWeb too. Here we face the problem of representing the product cleanly so that it can be evaluated well later on. I will illustrate our problem with an example:
We have the application Assyst, which uses several technologies: Java 11 and MSSQL 2022. Therefore I created a relationship between the Assyst application and the technologies Java 11 and MSSQL 2022. Java 11 belongs to the product Java from Oracle. MSSQL 2022 belongs to MSSQL from Microsoft. Additionally, the application XY also uses Java 11.
I can represent the technologies and products in two ways:
-
Create the products as products in Assyst and maintain the technologies as objects.
This results in the lowest maintenance effort and the Explorer view is relatively clean.
In this case I would only have to maintain one relationship from the Assyst application to Java 11.
Because Java 11 is derived from the product Java, the product assignment would be resolved automatically.
- Create the technologies and the products as separate objects and link them via relationships.
Here I would have a relationship from Assyst to Java 11 and another relationship from the Java 11 object to the Java product (as Object). This approach increases the maintenance effort because more objects are involved.
My requirement is to be able to display the applications assigned to the products either graphically or in a report. For example, I want a list of all applications that belong to the product Java (not only Java 11, Java in general).
-
With implementation 1 I would have the problem that I need to look at all technologies—Java 11, Java 8, etc.—and also all relationships to applications. Only after gathering all those relationships would I obtain the list of applications that use the Java product.
-
With implementation 2 I could at least use the Impact‑Explorer. I can go to the Java object and display relationships up to two levels deep, as well as filter by relationship type. Unfortunately, the list cannot be exported.
We have decided on implementation 2 because it allows us to work with the Impact‑Explorer. Implementation 1 is out of the question because products are not shown in the Impact‑Explorer.
However, implementation 2 does not make me completely happy:
- There is no way to export the result in any form. Moreover, this is not a direct search but rather a graphical representation.
- The maintenance effort is higher because we have to maintain the products as separate objects.
- What is missing is a clever maintenance method that lets me simply say, “show me all applications for the product Java or MSSQL.” Assigning applications to products directly in the Explorer does not work, because there can be multiple technologies and thus multiple products.
- Representing the application as a system also does not work, because we cannot filter by systems in the Impact‑Explorer, and we need the applications as ObjectB in tickets. An end‑user who reports an incident-ticket in AssystNet only knows the application, so we need the application as an object.
Has anyone else got experience with CMDBs and can give us further tips on this topic? I’m not entirely happy and feel like, depending on the implementation, something is always missing.
Best regards and many thanks!
Jeremias