ServiceNow Discovery e CMDB formam uma base essencial para operações de TI mais confiáveis, porque conectam descoberta automatizada, identificação de Configuration Items, relacionamentos e governança de dados. Quando Discovery é tratado apenas como varredura de infraestrutura, a CMDB tende a perder qualidade, contexto e valor estratégico.
Na prática, o ServiceNow Discovery deve ser planejado como parte da arquitetura da CMDB. Ele impacta diretamente processos de ITOM, Hardware Asset Management, Software Asset Management, gestão de mudanças, análise de impacto e governança operacional. A diferença entre uma CMDB útil e uma base cheia de registros inconsistentes está menos na coleta de dados e mais no desenho de identificação, reconciliação e relacionamentos.
Discovery não é apenas descoberta de infraestrutura
Um erro comum em projetos de ServiceNow é habilitar Discovery antes de definir o modelo de dados da CMDB. Quando isso acontece, a ferramenta começa a inserir registros sem critérios claros de qualidade, classificação e relacionamento. O resultado pode ser uma base com CIs duplicados, atributos incompletos e baixa confiança para decisões operacionais.
Discovery é poderoso, mas não substitui arquitetura. Antes de ativar varreduras, credenciais e schedules, a organização precisa entender quais classes serão usadas, quais atributos são obrigatórios, quais fontes terão prioridade e quais regras de governança vão orientar a qualidade dos dados.
O papel da arquitetura da CMDB
ServiceNow Discovery e CMDB funcionam melhor quando existe uma arquitetura definida para orientar a entrada e a manutenção dos dados. Essa arquitetura deve estabelecer padrões para classes de Configuration Items, atributos, relacionamentos, ownership, ciclo de vida e critérios de reconciliação.
- Classes de Configuration Items que serão usadas no modelo.
- Atributos obrigatórios para cada classe relevante.
- Relacionamentos necessários para análise de impacto.
- Estratégias de identificação por tipo de ativo e ambiente.
- Regras de governança, qualidade e saneamento dos dados.
Sem essa estrutura, o Identification and Reconciliation Engine, conhecido como IRE, passa a operar com critérios frágeis. Isso aumenta o risco de duplicidade, sobrescrita incorreta de atributos e inconsistência histórica entre fontes de dados.
A importância de uma estratégia de identificação
Em ambientes corporativos maduros, a identificação de um CI não depende de apenas um atributo. Cada tipo de ativo exige critérios próprios para que o IRE consiga reconhecer, reconciliar e atualizar registros com precisão.
Entre os identificadores mais comuns estão hostname, serial number, UUID, MAC address, cloud instance ID, IP address e dados de fabricante. Cada atributo possui validade em contextos específicos. O serial number tende a ser mais confiável para hardware físico, enquanto o cloud instance ID é essencial em ambientes de nuvem.
Uma estratégia de identificação bem definida evita que o ServiceNow Discovery crie registros redundantes ou misture informações de ativos diferentes. Esse cuidado é decisivo para que a CMDB sustente processos de ITSM, ITOM, HAM, SAM, segurança e governança.
Discovery orientado a relacionamentos
O valor da CMDB não está apenas nos CIs individuais. O verdadeiro ganho aparece quando aplicações, servidores, bancos de dados, serviços, máquinas virtuais e componentes de rede estão conectados por relacionamentos consistentes.
- Runs On: aplicações executando em servidores.
- Hosted On: máquinas virtuais hospedadas em hypervisors.
- Depends On: dependências entre aplicações, bancos de dados e serviços.
- Connected To: conexões entre componentes de infraestrutura.
Sem relacionamentos, os CIs se tornam registros isolados. Com relacionamentos confiáveis, a CMDB passa a apoiar análise de impacto, priorização de incidentes, gestão de mudanças, continuidade de serviços e decisões sobre risco operacional.
Como Discovery fortalece HAM, SAM e governança
ServiceNow Discovery também influencia diretamente práticas de Hardware Asset Management e Software Asset Management. Ao descobrir dispositivos, softwares instalados, ambientes e dependências, a plataforma ajuda a enriquecer dados que sustentam controle de ativos, conformidade de licenças e planejamento de ciclo de vida.
Quando esses dados são conectados à CMDB, a empresa ganha uma visão mais confiável sobre o que existe no ambiente, quais ativos sustentam serviços críticos e onde há riscos de obsolescência, exposição, duplicidade ou desalinhamento com contratos e políticas internas.
Governança contínua da CMDB
Mesmo com uma arquitetura bem definida, a qualidade dos dados depende de governança contínua. A CMDB não é um projeto que termina na implantação. Ela precisa ser monitorada, auditada e ajustada conforme a infraestrutura muda, novos serviços entram em operação e fontes de dados evoluem.
- Auditorias periódicas da CMDB.
- Revisão das regras de identificação e reconciliação.
- Validação de relacionamentos críticos.
- Monitoramento da completude e qualidade dos atributos.
- Definição de responsáveis por dados, classes e processos.
Esse processo garante que Discovery continue sustentando dados confiáveis ao longo do tempo, mesmo com mudanças em infraestrutura física, cloud, aplicações, integrações e modelos operacionais.
Checklist para implementar ServiceNow Discovery com CMDB
Antes de avançar com uma implementação de Discovery, a organização deve validar se a base de governança está pronta para receber e sustentar dados em escala.
- Definir objetivos de negócio e processos que serão sustentados pela CMDB.
- Mapear classes de CIs, atributos obrigatórios e relacionamentos prioritários.
- Configurar regras de identificação e reconciliação alinhadas ao IRE.
- Planejar credenciais, schedules, MID Servers e escopo de descoberta.
- Validar dados descobertos antes de expandir para ambientes críticos.
- Estabelecer indicadores de qualidade, completude, duplicidade e atualização.
Conclusão
ServiceNow Discovery não deve ser tratado apenas como um mecanismo de descoberta de infraestrutura. Ele é um componente fundamental da arquitetura da CMDB, da governança de dados e da confiabilidade operacional da plataforma.
Quando orientado por arquitetura, identificação consciente, relacionamentos consistentes e governança contínua, Discovery deixa de ser apenas um coletor de dados e passa a sustentar decisões confiáveis dentro da operação de TI.
Artigo produzido por Bruno Ferreira, Diretor Técnico da 4MATT.