01

Continuar fiel

Todo modelo que você já viu esteve certo um dia.

O CMDB estava correto na semana em que entrou no ar. O diagrama de arquitetura estava certo na revisão. O catálogo de dados estava completo na entrega. Depois a organização mudou, e nada em nenhum deles percebeu. Se você está se perguntando se isto termina da mesma forma, essa é a pergunta certa a se fazer.

O CMDB

correto na semana em que entrou no ar

O diagrama de arquitetura

certo na revisão

O catálogo de dados

completo na entrega

02

O modo de falha

Nasce obsoleto, e só parece estar bem por um tempo.

Todo mundo que vende inteligência oferece a você uma fonte única da verdade. A única fonte da verdade é a realidade. Todo modelo, catálogo e registro — o nosso incluído — é uma cópia dela, e uma cópia sem nenhum mecanismo para acompanhar a realidade enquanto ela se move não vai ficar desatualizada algum dia: ela nasce obsoleta, e só parece estar bem porque a diferença demora a aparecer.

Um modelo que ninguém pode mudar se calcifica; um modelo que qualquer um pode mudar se deteriora.

ninguém pode mudá-lo

calcifica

Tranque-o atrás de um comitê de governança e ele vira um documento sobre a organização como ela era em março.

qualquer um pode mudá-lo

deteriora

Abra-o para todos e ele vira uma wiki com tipos — as mesmas contradições de antes, agora com um schema.

~1 ano

A armadilha é que as duas falhas parecem sucesso por cerca de um ano. A calcificação parece estabilidade. A deterioração parece adoção.

O que aponta para qual é, de fato, o problema. A deterioração não é um problema de dados. É um problema de encaminhamento da responsabilização.

A organização sempre soube que a coisa tinha mudado — alguém sabia. Nada levou esse conhecimento até o modelo, e ninguém foi consultado.

03

Metade do modelo

O que é lido de um sistema não pode se desviar desse sistema.

Boa parte do seu modelo não é escrita por ninguém. Ela é lida — do catálogo que você já curou, do sistema de RH, do provedor de identidade, dos próprios schemas. Esses nós não ficam desatualizados, porque ninguém está mantendo uma segunda cópia que possa ficar para trás. Eles são o estado atual da fonte, tipado.

E, quando algo desaparece da fonte, isso não é silêncio. O nó passa para Ausente na origem — um status da família Inativo. Ele não é apenas sinalizado: é rebaixado, e todo percurso que passa por ele agora diz isso.

Esta é a metade barata da resposta, e vale deixar claro que é a metade barata. Ela cobre sistemas, conjuntos de dados, pessoas e acessos. Não cobre o que só uma pessoa sabe.

04

A outra metade

O resto tem um responsável. E o responsável é consultado.

Todo tipo de nó carrega sua própria matriz de responsabilidades — quem é o proprietário, quem faz a curadoria, quem aprova uma mudança, quem é o especialista. Não é uma convenção que alguma equipe segue. É parte do tipo, então um nó desse tipo não pode existir sem que a questão de quem responde por ele já tenha sido resolvida.

Sobre isso ficam casos de uso com seus próprios fluxos de trabalho: o que “revisar isto”, “repassar isto” ou “aprovar esta mudança” realmente significa para aquele tipo de coisa. Revisar um contrato de fornecedor não é o mesmo ato que revisar uma habilidade técnica, e o modelo sabe a diferença.

Então, quando algo se move, as pessoas que respondem por aquilo são acionadas — pelo fluxo de trabalho adequado, não por uma notificação. Quatro coisas disparam isso:

01

Uma fonte mudou

O sistema de registro já não diz o que o modelo diz.

reação

02

Alguém propôs uma mudança

Uma proposta governada, com trilha de auditoria — não uma edição.

reação

03

Um estado de ciclo de vida mudou

Um nó que entra em Em revisão ou Desativação em andamento arrasta consigo os nós que dependem dele.

reação

04

Uma verificação periódica venceu

Nada se moveu, e esse é o ponto: silêncio não é evidência.

o modelo perguntando

O quarto é o que separa isto de todos os catálogos que você já usou. Os outros são reações. Esse é o modelo perguntando se ainda é verdadeiro, à única parte que pode responder.

01

Algo se move, ou uma verificação vence

02

A matriz de responsabilidades diz quem responde

03

O fluxo de trabalho do caso de uso faz a pergunta certa a essas pessoas

04

A resposta se torna uma mudança de estado, com sua trilha

Metamodelo

Produto de dados

Tipos de Responsabilidade

4

Atribuir Tipo de Responsabilidade

Proprietário

É de propriedade de

A parte com responsabilidade final pelo nó e plena autoridade sobre cada decisão a seu respeito. Responde pela sua existência, correção e destino de ponta a ponta.

Curador de dados

É administrado por

A parte responsável por curar o significado de negócio e a qualidade dos dados do nó no dia a dia. Mantém a sua definição, exatidão e adequação ao uso, mas não detém autoridade final de decisão sobre ele.

Aprovador

É aprovado por

A parte que detém a autoridade para aprovar formalmente o nó, ou as suas alterações, de modo a torná-lo válido ou liberado. Responde pela decisão de aprovação em si, distinta da avaliação contínua ou da responsabilidade final de ponta a ponta.

Especialista no assunto

Recebe o conhecimento especializado fornecido por

A pessoa designada para fornecer esclarecimento sobre o assunto que o nó representa, em quem se confia pelo conhecimento profundo e de primeira mão dele. Aporta o contexto e a perspectiva que os registros e a documentação do nó não captam — uma autoridade consultiva sobre o assunto em si, não sobre como o nó é mantido.

a matriz de responsabilidades em um tipo de nó — proprietário, curador de dados, aprovador, especialista

Nada disso é o agente mudando a sua organização. Ele identifica, reporta, monitora e escala — autonomia de atenção, não de autoridade. Uma pessoa ainda decide. O que mudou é que a decisão chega a ela enquanto ainda é barata.

05

Ausência, tornada visível

A ausência é um estado que você consegue ver, não um campo vazio.

Modelos apodrecem em silêncio porque a ausência parece não ser nada. Um responsável em branco, um limite nunca escrito, um nó cuja fonte desapareceu — nenhum deles levanta a mão. O mesmo princípio atravessa três lugares aqui, e é o mesmo princípio a cada vez.

Atribuído · ainda não Informado

Uma responsabilidade que foi distribuída e nunca comunicada. Não é um campo em branco — é um degrau de uma escada em que o modelo consegue ver onde você está.

Ausente na origem

Um status da família Inativo. O nó é rebaixado, não anotado.

Certificado Bronze · Prata · Ouro

Na família Ativo. A verificação é uma forma de estar em dia — e a sua ausência é igualmente legível.

O que torna a saúde do modelo um percurso como qualquer outro. Não um relatório de maturidade que alguém monta uma vez por trimestre: uma pergunta que você faz ao mesmo grafo, com a mesma sintaxe que usa para todo o resto.

06

O que isto não resolve

Nada aqui modela o que nunca foi modelado.

o limite do ciclo

Se uma capacidade, uma obrigação ou uma dependência nunca foi tipada, nenhum encaminhamento vai trazê-la à tona. O ciclo mantém fiel o que está no modelo. Não descobre o que está fora dele.

o limite da metade lida

Um nó lido de um sistema permanece fiel a esse sistema. Se o sistema estiver errado, o modelo estará fielmente errado. O que o modelo acrescenta é que a divergência entre dois sistemas se torna visível, porque ambos estão tipados no mesmo grafo.

É por isso que a cobertura cresce por decisão, não por ambição. Você estende o modelo onde estar errado lhe custaria algo — e tudo o que você estendeu continua fiel pelo mesmo mecanismo de tudo o que veio antes.

07

Verifique você mesmo

Tudo o que está acima pode ser verificado sem falar conosco.

As famílias de ciclo de vida, a matriz de responsabilidades em um tipo, uma responsabilidade parada em Atribuído sobre a qual ninguém nunca foi avisado — está tudo em um tenant de demonstração com a Adventure Works totalmente modelada. A mesma organização sobre a qual você vem lendo.

sem a nossa ajuda

Vá verificar.

Entre com uma conta corporativa e pergunte algo ao modelo. Sem ligação, sem formulário, sem período de teste para iniciar.

Abrir a demo

com a nossa ajuda

Ou modele a sua.

O Design Partner Program é para organizações que querem o próprio modelo construído junto com a nossa equipe, antes da disponibilidade geral.

Design Partner Program →

Uma dessas opções leva dois minutos e não nos envolve. Comece por ela.