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

[s4scott]

In my shop we created a new table to store criticality assessments. It is connected to the applicable application services in a related list.  It is essentially a survey the application service owner (or team) completes. It is reviewed and when approved results in a score that is applied to the related application services setting the criticality field. In our shop it is common for a single application team to support multiple application service CIs. The team/group approach is more efficient than taking a CI based approach and it makes it simpler to update when there are changes to the platform. Additionally, criticality is defaulted to a low value for non-production environments, so they are essentially excluded from analysis.

[S_renPriisholm]

Hi Barry, s4scott, Christian, Geoff, SteveMac and Stig 

Thank you all for some very good clarifications!

I really liked the "realized solutions" part and the "share platform" argument - that is a very good explanation to me and that also correspond to what Stig Brandt is writing later "...BA, this is a meta record for applications supporting a business capability" (so here you don't apply environment, version and I guess he would also had said business criticality).

Christians remark on looking at "BA's from a financial point of view" also added extra clarification 🙂

---

OOTB we don't find business criticality and environment on the BA form, but we do find them in the BA-table, although the first does not correspond to the business criticality in the AS (3 versus 5 choices). I guess that's just the normal ServiceNow "mess" with to many redundant fields - "better safe than sorry - add the field and at some point in the future we may use it".

 (had to correct my self - "business criticality" is also found on the BA-form - it just doesn't correspond to the "business criticality" in the AS)

Thanks!! 🙂

Soren

[Christian Osbah]

Hi Søren,

I'd go with option 2. If you split the Dev/Test/Prod environments in your example into separate BA's, you will loose the central point from which to look at you BA's from a financial point of view, e.g. like using APM. Here you should be able to calculate/estimate your total cost of operating the chosen BA and since each environment likely has a cost associated with it you will need all 3 environments linked to the same BA to get to the total cost of maintaining the BA.

As far as your idea of inheriting criticality from either BA or AS to individual CI's below goes, I'm not sure I'd do that either. If your Prod environment is in fact critical, I'd assume it to be redundant, in which case the individual infrastructure component is not really critical. Of course you may have a mix of redundant and non-redundant components, in which case the non-redundant would be critical, unless it provides a non-critical part of the overall service. Bottom line is I don't believe you can simply infer infrastructure CI criticality based on AS criticality.

Hope this helps 🙂

/Christian

[S_renPriisholm]

Hi Christian

When you look at it from the financial point of view (eg. using APM).

What if you build a hierarchy of BAs. A BA on the top, related to 3 BAs (PROD, TEST, DEV).. Will you still be able to calculate/estimate your total cost of operating the top BA? (Can SN do that for you).

/Soren

[Christian Osbah]

Hi Søren,

Technically I suppose it would be possible to do this - however, I think this might be a case of "just because you can doesn't mean you should" 🙂

First of all the CSDM 3.0 whitepaper describes Business Applications as

"Business applications are the logical representation of all instances, used to increase productivity and to provide functionality to perform business functions accurately." ... "They can span multiple environments and / or deployed per geography (For example dev, test, prod or Americas, APJ, EMEA)."

To me it seems clear that a Business Application is intended to encompass all environments whether they be production, sub-production, location of otherwise specialized. So while you technically can create pretty much any structure/hierarchy you want in the tables, this is what ServiceNow will have in mind when building new functionality, so my advice would be to adhere to it.

Second, looking at BA's as the foundation for financial planning (which I think APM promotes) means that it does not really make sense to me to want to evaluate Dev/Test/Prod environments individually. You could evaluate BA1 against BA2 to decide which to use, but you would not evaluate BA1(Dev) individually against BA2(Dev) as it does not make sense anyway to choose Dev environment from BA1 and Prod environment from BA2 - it's either BA1 or BA2 in its entirety.

Hope it makes sense 🙂
/Christian