Tag-Based Service Mapping Approach

[abhijee]

Hello Team,

I am currently working on tag-based Service Mapping. In our CMDB, each CI has multiple tags stored in the cmdb_key_value table. The available tags include environment, description, app_id, project, and several others.

I have a basic question regarding the tagging strategy:

• Do we need to create tag categories for every available tag, or
• Should we define only a selective set of tags under tag categories?

Additionally, I would like guidance on:

• How to decide which tags are most appropriate for Service Mapping
• How to identify the best service candidates while defining services in the service family

Please advise on the recommended approach and best practices.

Thank you in advance.

[vaishali231]

Hey @abhijee 

For tag-based Service Mapping, the recommended approach is not to create tag categories for every tag available in the cmdb_key_value table. Instead, focus on a selective set of tags that provide meaningful service identification and can reliably group infrastructure components into a business or application service.

1. Should all tags be created as Tag Categories?

Generally, no.

Creating tag categories for every available tag (such as description, comments, temporary metadata, etc.) can introduce unnecessary complexity and may result in poor service candidate generation.

Instead, create tag categories only for tags that:

1. Are consistently populated across CIs
2. Have standardized values
3. Represent business or application ownership
4. Help distinguish one service from another
5. Are governed and maintained over time

Typical examples include:

1. app_id
2. application
3. service
4. environment
5. business_unit
6. owner (depending on organizational standards)

Tags such as description are usually not ideal because they are often free-text values and may vary significantly between records.

2. How to Decide Which Tags Are Best for Service Mapping?

A useful evaluation checklist is:

1. Is the tag present on most relevant infrastructure CIs?
2. Does the tag uniquely identify an application or service?
3. Are the values standardized and controlled?
4. Can operations teams trust the accuracy of the tag?
5. Will the tag remain stable over time?

The best tags typically have:

1. High coverage
2. High accuracy
3. Clear business meaning
4. Strong application ownership alignment

For example:

Good Candidates

1. app_id
2. application
3. service
4. environment

Usually Poor Candidates

1. description
2. notes
3. comments
4. created_by
5. last_updated_by

3. How to Identify the Best Service Candidates?

Before defining services within a Service Family, perform a tag quality assessment.

Look for applications where:

1. Infrastructure components share a common application identifier
2. Ownership is clearly defined
3. Production resources are consistently tagged
4. Relationships between servers, databases, and cloud resources are well understood

A common process is:

1. Identify a business application.
2. Verify that associated infrastructure shares common tags (for example, the same app_id).
3. Review the discovered CIs for consistency.
4. Create a Service Family using the selected tag category.
5. Validate the generated service candidates before promoting them to production services.

4. Recommended Best Practices

1. Start with a small number of high-quality tag categories.
2. Prioritize application-centric tags over infrastructure-centric tags.
3. Use combinations of tags when necessary (for example, app_id + environment).
4. Establish tag governance before large-scale implementation.
5. Regularly review tag coverage and data quality.
6. Align the tagging strategy with CSDM and your service portfolio structure.
7. Avoid creating tag categories solely because a tag exists in the CMDB.

Example

If your organization has the following tags:

1. app_id = FIN001
2. environment = PROD
3. project = FinanceModernization
4. description = Finance Application Server

A strong tagging strategy would use app_id as the primary service identification tag and optionally use environment as a secondary qualifier. The description tag would generally not be used for Service Mapping because it is descriptive rather than service-defining.

In most implementations, organizations begin with only a few well-governed tags such as app_id, application, service, and environment. This usually results in cleaner service candidates, easier maintenance, and more accurate Service Mapping outcomes.

************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb

[abhijee]

Hello @vaishali231 

Thank you for your reply.

I have one quick question. If we ignore the Description tag, will the system also ignore the associated CI? Currently, three CIs are associated with the Description tag. If we exclude this tag, my understanding is that those CI components will not appear on the service map.

Am I correct in my understanding? If not, could you please clarify?

Thank you.