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 Kristoffer,

We are using a custom relation called 'sends data to::receives data from'. Admittedly this is not the ideal approach as it will mean your dependency view will not show the right dependency, however our integration team preferred that the arrow was point the way the data flowed rather than the way the dependency went.

My guess as to why the OOB relation is called 'Depends on::Sends data to' is probably so that it is clear that the receiving service is dependent on the sender, thus you always have a depends on parent rather than having depends on, receives from etc.

Or perhaps it will be amended in 4.0 and they will change it to 'receives data from::sends data to', which would be my preference.

I hope this helps,

//Casper

[Kristoffer Pari]

Hi Casper, thanks for the response.

I'w been also thinking of creating a similar relation.

Just to be clear, the OOB relations seems to be:

• Depends on::Used by
• Receives data from::Sends data to

.. and it has been like this for a while. This for sure feels a little bit odd when you compare it to CSDM documentation.

[Liz Fassone]

That's supremely helpful @CasperJT, by subclass do you mean that you have extended the cmdb_ci_appl table? 

@scott.lemm, what do you think of this approach? And has this been considered for future release? 

[CasperJT]

It is actually the cmdb_ci_service_discovered table that we have extended, as we consider the integration scenarios a form of Application Service.

I will be interesting what Scott's take is on this.

[Daniel Carvalho]

@CasperJT  thanks for sharing! I was browsing for other experiences exactly to this scenario.

Regarding @Sakr original question, I also would expand a little:

I see two different multiple touch situations:

- Focused services such as ADFS, radius etc. on witch the nature of the communication and therefore the exchanged data is very implicit, thou no much additional explaining is necessarily due to be provided/catalogued at the CMDB. (also applicable to log shipping to a central repository as well, as additional example).

- Systems integration between 2 Business Applications, that can be multi touch when using ESB, por example (say for exemple a Risk Management system that gathers data from HR software and Security controls on office doors and building gates). In this case, if someone sees a representation like:

HR SW >> sends data to >> Risk Mgmt 

SecutiryDB  >> sends data to >> Risk Mgmt 

On would not problably, with easy, infer the nature of this "integration" and also what kind o data is being relayed.

So, when I think about having a CI Class "(Data) Integration Service", it hits me with the possibility of a more explicit view, such as (assuming the example integration CI being named as "DIS_PHYSICALACCESSCONTROL_PRD"):

HR SW >> sends data to >> DIS_PHYSICALACCESSCONTROL_PRD >> sends data to >> Risk Mgmt 

SecutiryDB  >> sends data to >> DIS_PHYSICALACCESSCONTROL_PRD >> sends data to >> Risk Mgmt 

Then, the ESB Middleware  CI could be related to the DIS_PHYSICALACCESSCONTROL_PRD as Depends on... (I believe this would reduce the number of direct connections to the ESB multiple touch CI.

And also, it even would be possible to create relations to the "Information Object", from the DIS_PHYSICALACCESSCONTROL_PRD.

So, on daily basis I think these two means of representing integrations should/would be present:

- Direct end-to-end CI relation for specific purpose integrations (authentication, SSO, log shipping)

- Using a middle Integration Service CI for business data related integrations among two business applications

Please folks, do comment on this!

Cordial