How to model the CMDB (following the CSDM) when you need to take business criticality and environment into account

[S_renPriisholm]

Hi guys - I hope you can help me with a bit of advice on this one 🙂

When we look into the CSDM (3.0) - Business Application (BA) is related to (1 or more) Application Service (AS) which again is related to (1 or more) eg. Application or other CIs (APPCI). This is as CSDM describe it.

If you look top-down a specific BA and assume that this BA has a "very high" business criticality, then every component related downwards from this BA must also have a high business criticality, so AS and APPCIs will inherit the criticality some how. Which again mean that if the APPCI is not working our BA and AS is in danger of not working either = its very critical to the business.

In the CMDB you will model a lot of BA-AS-APPCIs divided into PROD, TEST and DEV environments.

I think we can also assume that PROD environments normally will have a higher business criticality compared to TEST and DEVs.

----

In all the CSDM examples videos etc., I have found until now, they always add environment to the AS not to the BA - and if our assumption is right, then the "business criticality" is highly dependent of the type of "environment".

From my point of view you can model this in 2 ways:

1.
One BA for each environment the BAs are named: BA-PROD, BA-TEST and BA-DEV

Each BA is related to one AS (where the Environment field is set to PROD, TEST or DEV).

Each AS is then related to the proper APPCI - like a server running the production.

Benefit:
In this way the criticality on the BA can be inherited to the proper AS and APPCIs
Disadvantage:
Extra work on mapping and maintenance

or

2.
One BA (here we don't tell if its PROD,TEST or DEV - is just a BA for each "system")

The BA is related to 3 AS (where the Environment field is set to PROD, TEST or DEV).

Each AS is then related to the proper APPCI - like a server running the production.

Benefit:
In this way you save some time on working with mapping and later maintenance.
Disadvantage:
You will not be able to tell if this specific BA has a "very high" business criticality as the underlying AS is a mix of environments)

----

What would you have done 🙂 ?

Thanks in advance
Soren

[SteveMac1]

To extend what others have said: We have the same use case as you (and many others I'm sure). To account for this we use a combination of AS and BA to determine the priority of issues. If it is a business critical application and production it has different SLAS than those that aren't and it also affects what can be set for impact and urgency. As far as downlime components where you have redundancy, if I recall correctly you can deal with this in the Event Management Dashboard by indicating how many components of a cluster affect up line impact. Steve

[Stig Brandt]

Hi Søren

Option 2:

- You will never have Versions, Environment etc. in the BA, this is a meta record for applications supporting a business capability.

Wrt: Business criticality - be aware of that on BA, they only use - High - Medium - Low and on Services they have 1-4 or 5, so I don't know why this inconsistence, but agree the criticality differs depending on environment, unless all environments is external exposured ;-).

Remember though, in BA, you can have a hierarchy, using the platform host value and link BA's to a platform ->