🚀 De Application Service para Service Instance: O que muda na Yokohama e CSDM 5.0

tiagomacul · a week ago

Se você acompanha a evolução do CSDM (Common Service Data Model), sabe que a jornada do "Design" ao "Consume" está em constante refinamento. Com a chegada da Release Yokohama e a prévia do CSDM v.5, estamos presenciando uma mudança de paradigma: o Application Service agora passa a se chamar Service Instance.

Este artigo é uma tradução adaptada do conteúdo original de [David Skowronek / ServiceNow Community], complementada com insights da nossa comunidade brasileira para ajudar você a se preparar para essa transição.

1. Por que a mudança de nome?

Historicamente, a classe cmdb_ci_service_auto (Application Service) era focada em representar o "stack" de uma aplicação instalada. Mas o mundo mudou. Hoje, precisamos modelar muito mais do que apenas software:

Como representar componentes de rede?
Como modelar um serviço de limpeza (Facility) ou um serviço de IA?
Como tratar conexões lógicas que não são necessariamente "aplicações"?

Ao renomear para Service Instance, a ServiceNow remove a barreira semântica. Agora, podemos modelar qualquer tipo de serviço — seja ele de Rede, Conexão, Dados ou Instalações físicas — mantendo a estrutura de dependências.

2. Novas Classes na CMDB (Store 1.64.0+)

Com o update do modelo de classes (novembro de 2024), foram introduzidas subclasses especializadas:

Data Service Instance: Para focar em fluxos de dados.
Network Service Instance: Para topologias de rede.
Connection Service Instance: Para integrações e links.
Facility Service Instance: Para serviços prediais e de infraestrutura física.
Operational Process Service Instance: Para fluxos de processos de negócio.

3. O Desafio Atual: A Tabela `svc_ci_assoc`

Aqui entra um ponto técnico crucial que adicionamos a este guia: A limitação de visibilidade.

Atualmente, processos críticos como Event Management, Incident e Change utilizam a tabela svc_ci_assoc para identificar rapidamente quais serviços são impactados quando um CI (Item de Configuração) falha.

O cenário atual: Até o momento, as novas classes de Service Instance ainda não populam automaticamente essa tabela. Apenas as classes legadas (Mapped, Calculated, Tag-Based) o fazem.

⚠️ Recomendação: Se o seu negócio depende fortemente de cálculo de impacto automático no ITOM ou ITSM, não migre seus registros para as novas classes ainda. Continue usando as classes de Application Service mapeadas até que o novo mecanismo de população seja liberado.

4. O Futuro: Desacoplamento da Lógica de População

No CSDM 5.0, a ServiceNow planeja desacoplar a "classe" do "método de população". No futuro, você não precisará escolher uma classe baseada em como ela é populada (Tags vs. Relacionamentos). Você escolherá a classe pelo que ela é (ex: um Network Service Instance) e configurará o método de população (Service Map Population Configuration) separadamente.

5. Como se preparar hoje? (Dicas Práticas)

Para estar "Future-Ready" (Pronto para o Futuro):

Refatoração de Scripts: Se você possui scripts, workflows ou relatórios que apontam especificamente para a tabela cmdb_ci_service_discovered (Mapped Application Service), comece a apontá-los para a classe pai: cmdb_ci_service_auto.
Mapeamento de Serviços: Continue mapeando seus serviços, mas foque na integridade dos relacionamentos (cmdb_rel_ci). O CSDM 5.0 será muito mais dependente de relacionamentos transversais.
Governance: Comece a educar seu time de Governança de Dados sobre o conceito de Digital Product (Produto Digital), que é o nível hierárquico acima do Service Instance no CSDM 5.0.

Conclusão

A mudança para Service Instance reflete a maturidade da ServiceNow em entender que o TI não é mais uma ilha, mas o motor de serviços que abrangem toda a empresa.

Links de Referência:

Créditos da Adaptação Brasileira

Este guia foi traduzido e complementado por:

Tiago Macul
Karin Zan Huke
Com o apoio da Comunidade NowBridge.

#ServiceNow #CSDM #YokohamaRelease #ServiceInstance #CMDB #ITOM #ITSM #NowBridge #TiagoMacul #KarinZanHuke