CMDB – Não basta ter. É preciso manter.

Com o passar dos anos, o conceito de CMDB tem vindo a tornar-se um tanto ou quanto “pesado” e algo difícil de manter. Ora, neste novo ecossistema digital os desafios são diferentes, as necessidades mudaram, a rapidez de mudança é cada vez maior, e portanto, considero que ter uma CMDB (Configuration Management Database) continua a ser relevante e pode ser diferenciador numa organização, no entanto, é preciso manter esta base de dados – de itens de configuração e respetivas relações e camadas de abstração.

CMDB do “futuro”
Atualmente, considero que as grandes mudanças relacionadas com a forma como devemos encarar a CMDB são:

• a arquitetura cloud, em que os Produtos/Aplicações/Soluções são assentes em conceitos diferentes, refletindo-se assim num novo modelo de arquitetura (containers, microservices, etc…) de suporte aos serviços e produtos. Além disso, continuamos a ter CMDBs com modelos de arquitetura mistos, em que existem soluções assentes em Cloud e outras soluções assentes em modelos anteriormente mais tradicionais com servidores físicos e virtuais. Ou seja, nalgumas circunstâncias o modelo tradicional mantêm-se, e por outro lado, noutras circunstâncias a rapidez de mudança e a criação/alterações de novos itens de configuração e/ou relações torna-se muito mais complexa, de rápida mudança e difícil de gerir; e

• metodologia Agile, cada vez mais utilizada no desenvolvimento de software (produtos/soluções), permitindo uma abordagem mais interativa e ágil, dando origem a mais alterações num curto espaço de tempo. Ora, isso reflete-se numa CMDB com mais alterações, adições/remoções de itens de configuração.

Definição do modelo de dados da CMDB

A construção do modelo de dados da CMDB de uma organização deve adotar uma abordagem de “ponta a ponta”, incluindo os Serviços de Negócio (Business Services layer), Produtos e Soluções (Applications/Solutions layer) e Tecnologia (IT infrastructure layer). Aliando a estas três camadas mais informações como contratos (Contract and Licensing Management) e Níveis de Serviço (Service Level Agreements) estamos a criar uma estrutura que suporta todas as dependências e interfaces (Clientes e Vendors) na organização. Além disso, adicionando uma taxonomia de Produtos e Serviços assentes na infraestrutura, permite ter uma visão desde o Portefólio de Serviços até à infraestrutura.

Coordenação da CMDB

Idealmente, a função de CMDB coordinator deverá existir, no entanto, sabemos que por vezes as organizações não estão preparadas ou disponíveis para ter alguém dedicado a esta posição. A função de coordenador de CMDB tem como propósito a orquestração de todos os diferentes processos que impactam a CMDB, e, portanto, inclui o seguinte tipo de atividades de coordenação:

• relação com os vendors e responsáveis das múltiplas fontes de dados e processos de sincronização;
• alinhamento e coordenação com os responsáveis das ferramentas de ticketing, Service Catalog, automação de processos e auto-discovery;
• alinhamento com as equipas de DevOps, que desenvolvem Produtos e Soluções;
• alinhamento e coordenação com os responsáveis do modelo de Suporte ao cliente (uma das entidades mais interessados na utilização e fiabilidade da CMDB).