What is the recommended approach to model system with multiple touchpoint, such as ESB, Middleware, & Authentication services, in the CMDB without overcrowding/impacting the default dependancy view?

[Sakr]

I have a requirement to document the dependencies of systems with multiple touch points, (such as middleware, authentication services, and ESB,…etc.) in the CMDB and represent their relationships and impact on other systems in a visual way without overcrowding the dependency view for the other CIs.

Ideally, I would like to keep the default CI dependency view unchanged and to have a separate view(s) to show the different integrations for each of the special systems. As an example, a view to show the ESB Middleware and all Systems talking to it. Another example would be the Active Directory and all systems that depends on it for authentication.

The way my team came up with to get this done is:

• Choose/create a unique relationship type to represent each of the relationships between every one of the systems and their dependencies. As an example: (Application X Integrated Via::Integrates ESB Middleware)
• Configure the default CMDB Dependency Views to NOT show the relationship chosen above, to not overcrowd the existing view.
• Allow a different view to only see the new relationship through predefined filters.
• Repeat the above steps for each of the special systems, so that each special relationship can be viewed by the relevant stakeholders only without impacting the traditional dependency view used for impact analysis.

I’d love to hear your thoughts and recommendations regarding the best way to achieve this in service now.

Cheers,

Ahmed

[CasperJT]

Hi Ahmed,

We have a subclass of Application Service called 'Integration Service'. We use this to store information on Integration Scenarios.

An integration Scenario is the specific configuration of an ESB to transmit data between two or more Application Services.

The means we can indicate that the Integration Service Integrates with App Service A to transfer data to App Service B/C/D. We are currently using 'sends data to::receives data from', but we might adjust that at some point.

Additionally we also show, which Application Service the Integration Scenario uses in order function. That way we can also show the impact on our recipient App Services, if the entire ESB is down due to maintenance or scheduled service.

Br.

Casper

[Sakr]

Hi Casper,

Thank you for the helpful reply.

How would you restrict the dependancy view from showing the integration relationships between the EDB and the recipient App services and the dependancy of the App services on their infrastructure at the same time?

In my use case, I need to have the ability to show only one of them at a time or to treat them as different layers to the same view to keep the dependancy view simple.

Regards,

Ahmed

[CasperJT]

Hi Ahmed,

You have a few different ways of limiting the Dependency view, such as predefined filters.

You can also limit the types of CI's or relationships you want to show, so if you are not interested in the infrastructure CI's, either remove the relationship types or the CI classes from your view.

Lastly you can of course also limit the the amount of levels you want to see. So if you only want to see sender, scenario and recipient, then focusing the map on the integration scenario and setting the max levels to one will only show the primary relationships.

Regards,
Casper

[Kristoffer Pari]

Hi, Casper. Are you using the OOB "Receives data from::Sends data to" as i cannot find any "sends data to::receives data from" from OOB system. Or is this a custom one?

This is also a little weird as CSDM documentations talks about Depends on/ Sends data to. From this i would assume that there would be a "sends data to::receives data from" relation type OOB.