Depois
da discussão sobre DAD de Scott Ambler,
numa espécie de Agile com mais disciplina, vamos continuar analisando outras
visões atualizadas sobre GD-Governança e Gestão de dados existentes, que tocam
no assunto, com maior ou menor intensidade.
Agile DG-FSFP-First San Francisco
Partners
A
consultora Kelle O´Neal, da FSFP, hoje contando também com a parceria de reconhecido John Ladley, usa o label Agile
DG para definir o seu método de implantação de GD nas empresas , embora
os conceitos apresentados sejam próximos dos de qualquer programa de GD,
digamos “tradicional” e não ágil, conforme visto na figura 02. A sua visão centra nos P´s tradicionais da GD,
com Politicas, Padrões, Processos, Pessoas e Papeis, Comunicação(Propaganda),
Tecnologia(Plataformas), Monitoração e medidas (Performance ), além de Estratégia.
Na essência, muito do que temos trazido à discussão neste blog, nos cursos de
Pós da Puc-MG e Fumec e nos treinamentos
específicos nas empresas. Alguns
conceitos estão abaixo decompostos:
Estratégia: Relativo à Visão e Missão, Objetivos gerais e específicos, alinhamento com objetivos
de negócios e Princípios. No fundo, o estabelecimento das linhas mestres da
Governança de dados, necessárias para se conhecer a direção e esclarecer os
objetivos que devem justificar a implementação de um programa como este. Tem o
“mote” tradicional de se agregar valor à empresa através da melhor solução de
dados, usado em todas as abordagens;
Organização: Aqui veremos o Modelo
de operação da GD, com os P´s de Papeis e Pessoas, os pontos de arbitragem
sobre pendências (“issues”) de dados e o devido escalonamento, em casos de
itens sem resolução. Mostra a estrutura da GD, seus membros, os papeis e responsabilidades
definidos, como os gestores de dados, os owners e suas respectivas
responsabilidades e “accountabilities”(responsabilidades finais);
Políticas, Processos e Padrões: Aqui entram outros P´s da GD, sobre os quais temos
discutidos intensamente: Políticas,
Processos, Padrões, além de Regras e Controles, Definições, uso de metadados, taxonomia
e classificação e glossário de negócios;
Medidas e Monitoramento: Nesse ponto aparece o P de Performance
(Desempenho). Ponto fundamental para se acompanhar o andamento do processo de
GD. Uso de medidas, medições e análise com monitoramento do progresso do
programa e com acompanhamento numérico das pendências apresentados
amistosamente em dashboards, scorecrds,etc. É elemento fundamental de
balizamento do programa de GD, a fim de justificar a sua adoção;
Tecnologia: Parte mais tecnológica, envolve as ferramentas de
colaboração e de ciclo de vida da Informação/Dados, acompanhamento de Dados
Mestres e compartilhamentos, Arquitetura de Dados, Segurança, Qualidade de
dados e fluxo de gestão (stewardship), além
de repositório de Metadados e glossário de negócios. Tem um certo sabor das
disciplinas de DM(Data Management), encontradas no diagrama DMBOK e em outros
modelos correlatos ;
Comunicação: Elemento fundamental, por vezes negligenciado,
envolve o plano de Comunicação de GD, com divulgação em massa, atualizações
individuais e personalizadas, além de mecanismos e estratégia de treinamento. É
também parte fundamental da estratégia, visando a uma GD bem sucedida.
Figura 2-Visão de GD Ágil da FSFP-First San Francisco Partners
GD
e os princípios da Agilidade
Robert
(Bob) Seiner, experiente consultor de dados, um dos mais antigos do EUA, editor
do conhecido TDAN(The Data Administration Newsletter), sugere uma aproximação
diferente, quando se discute os aspectos de conjugação de agilidade e de dados.
Ele incentiva a avaliação dos 12 princípios da Agilidade, hoje já com algumas
alterações, para identificar pontos de convergência e de divergência entre a
Agilidade e GD-Governança de dados. Essa comparação, na minha visão, pode ser
desenvolvida e balizar algumas orientações de planejamento de dados, antes do
desdobramento dos requisitos, que acontece dentro dos sprints, no ciclo Scrum. Afinal, qualquer sistema em desenvolvimento (seja
via ágil ou cascata), terá um conjunto de dados que circulará por eles. Esses
dados não necessariamente somente serão usados por aquele sistema em
desenvolvimento, naquele Sprint. Alguns dos princípios de Agilidade são
obviamente compatíveis com os de GD e outros o serão, desde que haja
alinhamento e convergência entre as duas linhas de pensamento. Por exemplo, entregas
rápidas e incrementais sugerem que pequenas partes da solução(estórias ou um
conjunto delas) sejam entregues ao invés de esperar pelo todo. Um projeto de
BD, dentro do contexto de GD, poderá também ser feito em pequenas construções,
desde que alinhavados por um modelo conceitual maior, que costure essas partes,
feitas em separado. As tabelas que atendem aquele pedaço do sistema deverão
estar coerentes com a visão maior de um modelo organizacional. A Agilidade
sugere que os requisitos podem surgir ou evoluir dentro de um release, ou de
sprints. Caso os requisitos que alteram estórias, impliquem em alterações de
Bancos de dados(inclusões ou refactoring), esses mesmos elementos de dados
deverão ser alterados em outros partes
de código (onde já estão sendo usados) e que poderão estar fora do
contexto daquele Sprint, gerando os chamados débitos técnicos. Lembre-se que a
premissa de agilidade, normalmente é de time-box, com tempo fechado. Isso normalmente
impossibilita extensões de escopos e gera transferência de requisitos para
outros ciclos. Outro aspecto fundamental de ser discutido é a presença dos
usuários em direta interação com os desenvolvedores. Os representantes do
negócio poderão estar presentes com a visão de dados (da mesma forma que no
Scrum tradicional), mas isso, sabemos, não é tão trivial. Provavelmente, a área
de dados estará representada na equipe pela figura de um gestor técnico de
dados(DBA,DA, Arquiteto), etc para opinar sobre esse domínio. O Gestor técnico,
por sua vez, deverá fazer parte da estrutura formal de GD, com as atribuições
de ações operacionais, mas alinhado por um Comitê de gestores de dados, por
exemplo. Essas discussões de dados, entretanto, muito provavelmente, merecerão
momentos especiais, do tipo “Sprint exclusivo de requisitos de dados”, para que
o alinhamento aconteça entre a Agilidade e a GD. Nas figuras 3.1 e 3.2, apresento
uma análise dos princípios canônicos da Agilidade, com as devidas considerações
sobre GD.
Figura 3.1-Paralelo entre os princípios da Agilidade e considerações de GD
Figura 3.2-Paralelo entre os princípios da Agilidade e considerações de GD
A
figura 3.3, mostra o tradicional ciclo de Scrum, com a sugestão da participação
de gestores de dados durante os trabalhos, conforme anteriormente discutido.
Esses gestores deverão estar completamente alinhados com a estrutura de GD
definida, não somente se atendo a trabalhos de BD, mas também como elementos
com visões de gestão, qualidade e integração dos dados
Outros
autores continuam também pensando em
formas de aproximar Dados e Agilidade, além de Scott Ambler, Kelle O´Neal e Bob
Seiner, discutidos anteriormente.
Especificamente esses autores (Collier, Core e Hughes) partiram, já há um
tempo, para a adoção do termo Ágil, mas com um foco bem específico em uma das
áreas de conhecimento da Gestão de dados - Os Projetos de BI. Surgiu assim o
conceito de Agile BI.
Agile BI
Collier escreveu o livro Agile Analytics(Value driven
approach to Business Intelligence and DW) em 2012. Lawrence Corr (junto com Jim Stagnitto) escreveu Agile
Data Warehouse Design em 2012 também. Ralph Hughes,
o pioneiro do BI Ágil, escreveu Agile Data Warehousing em 2008. Os
três livros partem de premissas de adoção de agilidade, dentro dos projetos,
nesse caso de DW/BI e inovam com a
adoção de conceitos iterativos(releases,sprints, PO,etc) nesses cenários de
projetos de depósitos informacionais. Entretanto é fundamental que os dados,
antes de se tornarem insumos para os projetos de BI, deverão estar alinhados no
contextos de gestão e governança de dados, para que o todo funcione. Muitos
projetos de BI tem demonstrado, no seu resultado final, as consequências dessa
inobservância. Empresas tem gasto milhões em projetos de BI, se esquecendo que
essa camada nada mais é do um ponto de transformação. Lapsos gerenciais nesses
projetos esquecem da máxima: “garbage in, garbage out”, seduzidos por
interfaces e vitrines espetaculares, mas com dados pobres e inconsistentes.
Depois choram lágrimas de esguicho, devido aos dados mal governados na sua
origem, produzindo resultados pífios, porém com uma plástica de vitrine
sedutora. Ai já é tarde...
Resumo
da ópera:
O
resumo da ópera é que essas abordagens de agilidade, independentemente de sua
gênese, deverão estar perfeitamente alinhadas com os P´s da GD, daqui pra
frente. Políticas, Processos, Padrões, Planos, etc farão toda a diferença nesse
casamento de duas linhas fundamentais, que vieram pra ficar. O mapeamento dos
princípios mostra que as equipes Ágil e de Dados deverão definir um estilo de
projeto que poderá trazer alterações aos aspectos canônicos da Agilidade. Fica
a pergunta: O que poderá ser ajustado na Agilidade para se encaixar a GD e
vice-versa. Há desafios pela frente neste domínio. Se prepare para enfrentá-los.
