CSDM tables recommendation to use or not to use certain attributes

[Lakshmi46]

My client has customized CSDM like The Business Service table contains all business applications and using custom fields on other service tables too.  Can someone provide recommendation:

1. Any attributes they are using currently they should not be using 

2. Any attributes they are not using that we think they should be using

3. How to evaluate their custom attributes

on tables: Business Application ,  Application Service,  Information Objects,  Technical Services, Business Service  and  Technical Service Offerings 

[Jonathan Schnei]

Without knowing what custom attributes it is not possible to talk on specific attributes (ootb or custom) that they should or should not use. But I can speak to some general guidance on a path to realign them with the CSDM. Your description also leads me to believe you may be looking for a way to continue to further incorrectly leverage the Business Service table for Business Apps, but add/remove ootb or custom attributes to more strongly mirror the Business Service records with Business App records. If that is the case, I would recommend against doing that.

The reason is that the Business Apps aren't so so divorced conceptually from Business Services (which is likely why they made this mistake initially) that a lift of those to become Business Services, and a shift of the current App records to the correct Business App table, should be straightforward. 

• Use 'What is a Business Application' community article by Mark Castoe to identify which Business Service records should be Business Apps.
• Use CSDM definitions to lift & shift the existing Business Service records to their correct tables. You'll likely be seeing a mix of Business Service, Business Service Offering, and Business Apps. Especially since Business Service Offerings are often nearly 1:1 with Business App in naming (BSO are what the end user should be requesting via catalog).
  • Example1.: Business App = Ariba, App Services = Ariba PROD/QA/DEV, Business Service = Procurement Services, Business Service Offering = Ariba Contracts.
  • Example 2: BA = MS Teams, AS = MS Teams SaaS, BS = Messaging Services, BSO = Teams. Note that in both of those cases, several BSO may reference a single BS, but it's likely that a single BA (through it's app services) would relate to a BSO. 
• It's likely that they've connected process such as catalogs, IPC, etc to the Business Services. Those connections will need to be updated (likely to the new BSO) so make sure that is done as part of lift & shift or things will break.
• Those new Business Apps will need to connect to Business Service Offerings via the App Services. Every Business App should have at least 1 App Service. A trick to make this starting point simple is to create a single PROD or SaaS Application Service for every Business App where the AS is called App Name PROD or App Name SaaS. Future work can add the other instantiations (sub prod, location, etc).
• A comment on fields: These are all CI tables, so they share the base set of CI fields, but the Business Apps in particular have a number of fields just for them. ServiceNow does a great job of showing what they consider to be a solid set of recommended fields OOTB. Simply go to the BA table in a developer or demo instance and see what fields the table is showing by default. You can also do a mapping exercise against the entire table by comparing what is available vs what they have and map them (check to see if they are actually populating the fields too). You can create the same custom fields on the BA table if required. When in doubt - always point out that there is a cost to maintaining data, so if they don't need the field or it's poorly maintained, then they should not use it.

I am not sure if that helped - but hopefully you can take some of that away to best help your client along their journey back to CSDM alignment.

[Mathew Hillyard]

Hi @Lakshmi46,

Even simpler than the reply from @Jonathan Schnei - read and understand each of these concepts in the CSDM v4.0 whitepaper. It accurately describes what each element of CSDM is, and what it is not. From this you should be able to look at any attribute and work out where it should belong. As mentioned, if you have Enterprise Architecture subscribed then the Business Application table will have extra OOTB fields.

Resist the temptation to store data just because you can, or because you cannot find a better place for it. The "DM" part of CSDM is "Data Model" for a reason.

I hope this helps!

Mat