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

S_renPriisholm
Tera Contributor

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

1 ACCEPTED SOLUTION

Barry Kant
ServiceNow Employee
ServiceNow Employee

hi Soren,

 

for sure option 2 is the solution. 

Application Services are the realised solutions for a Business Application. For Business Application you don't define DEV, TEST, ..., PROD records. That is really the Application Service level only. 

To cascade the business criticality I wouldn't do that from the Business Application (at most only for the PROD stack)

It is probably not even that straight forward I guess, as a downstream database server includes multiple databases supporting multiple Application (s Services). Where 1 Application can be business critical and another is not. 

 

Best regards,

Barry

View solution in original post

11 REPLIES 11

Barry Kant
ServiceNow Employee
ServiceNow Employee

hi Soren,

 

for sure option 2 is the solution. 

Application Services are the realised solutions for a Business Application. For Business Application you don't define DEV, TEST, ..., PROD records. That is really the Application Service level only. 

To cascade the business criticality I wouldn't do that from the Business Application (at most only for the PROD stack)

It is probably not even that straight forward I guess, as a downstream database server includes multiple databases supporting multiple Application (s Services). Where 1 Application can be business critical and another is not. 

 

Best regards,

Barry

This. The Business Application should be used to represent that Application/Product/Platform exists in your environment, i.e. it is part of your portfolio. The Application Service CIs represent deployments or instances of the Business Application, or in Barry's words the "realized solutions". 

Business Criticality should be defined from the Application Service CI down, as each CI can have different customers/purposes that drive different criticality ratings. As Barry mentioned you will likely find that shared platforms, like database or middleware CIs, could be related to both high and low criticality applications. In those cases you will need to define processes or automations to set the criticality appropriately.

I agree. But the issue we have with this is that as a consequence you suddenly double/triple the amount of  "Criticality Assessments" you need to perform (we have a scale of 1-5 of 'criticality'). We are a pretty large shop - and have ~2.5k Business Applications, so then ~6k Application Services. (by regulations) we now need to perform ~6k criticality assessments! How is this achieved? 

Hi Geoff

So what did you do - are you using "business criticality" and/or environment on BAs anyway ?

BR

Søren