CSDM - CMDB table for non-business technical applications/tools

[Uncle B]

Hello Community,

Looking for some advice on how best to represent Non business facing Applications (e.g infrastructure, cyber tools used by IT such as Teams, Active Directory etc.) in the CMDB.

We currently use applications table and are migrating to the CSDM 3.0 model. We could put the tools in the business application table and roll them up to a business service/capability or offering, however, the set of fields are different for tools and business apps, hence we'd rather keep and manage them in separate tables.

Is there an OOB table that can be leveraged for this purpose? should we extend the business application table for the tools? Appreciate any thoughts toward this.

Thanks in advance

[Yashsvi]

Hi @Uncle B,

To manage non-business-facing applications (infrastructure and cyber tools) in the CMDB while migrating to the CSDM 3.0 model in ServiceNow, you have a few options:

1. Use Existing Infrastructure Service Table:
- Add tools like Active Directory and Teams to the 'cmdb_ci_infra_service' table.

2. Extend the Infrastructure Service Table:
- If needed, extend this table to include additional fields specific to your tools.

3. Create a Custom Table:
- As a last resort, create a custom table tailored to these tools, but be mindful of maintenance and upgrades.

4. Align with Technical Services and Service Offerings:
- Categorize these tools under technical services and define service offerings to differentiate from business-facing applications.

This approach ensures a clean, organized CMDB that aligns with CSDM best practices.

Thank you, please make helpful if you accept the solution. 

[Uncle B]

Thanks @Yashsvi for the suggestions.

If we were to go technical services route, does that mean we would use business services in lieu of business applications as well? Currently, we are using the Application service table (cmdb_ci_service_auto) to represent environments (dev test prod) of the business apps.

Per my understanding, technical services and app services are on a similar hierarchy, as to our purposes, the infra tools should be at the same level or hierarchy as a business application.

Do you have any thoughts regarding this?

[Andreas Borell · Accepted solution]

First of all I would have you consider viewing the "next step", as CSDM 4 is already there and v5 is in the pipeline - so don't build a model now based on 3.0 as it will be less future proof.

Assuming you do look at CSDM 4, on the system level, all systems are systems (and systems are represented as Application Services in CSDM 4). Hand in hand with this goes digital portfolio management (DPM).

CSDM 4 Link, DPM Link.

Leveraging CSDM 4,  MS TEAMs is one potential application service (AS), and so is active directory.

As with all application services (AS), they can then roll up into Business Applications (BA) that have relationships to business capabilities. This allows you to have "business capabilities" that are IT related (IT is part of the business!) which gives you several interesting opportunities to view your whole ecosystem using the different enterprise portfolios in DPM.

With CSDM 4, you also have the difference between technical services and business services more detailed. Technical Services (TS), and their offerings (TSO), are inherently related to managing IT in the background; these activities are often invisible to the average end user, and what you need to keep in mind is that IT staff are also end users in most cases. Lets take MS TEAMs as an application services.

This AS needs to be managed, this is orchestrated through a TS and TSO. But if your MS TEAMs is strictly managed, you may want some Self Service Catalog Item to request e.g. archiving of a TEAMs. I would not map this Catalog Item to a TSO, because asking for archiving, even if done by someone working in IT, is not done as a provider, but rather as a consumer - and consumption in CSDM 4 is mapped through Business Services (BS) and their offerings (BSO). Just like you would have a TS / TSO to manage the AS, you would have one or more BS / BSO to provide it for use. Maybe you have one BSO for IT (which you limit subscription to through groups/company or something), and another BSO for other company employees (so not IT). This allows you to model different BSO towards different consumer groups, and keeps the management (through TSO) separate from end user provisioning / consumption (through BSO), which I believe is what you are looking for.

The above allows for a richer OotB CSDM 4 view of your ecosystem than custom tables, but also force you and your organisation to keep and maintain multiple portfolios (different Service Portfolios, Application Service portfolios, Business Application portfolios) which may seem like overhead but really is there to allow for the kind of scenarios you are looking at.