Governança de dados e a Agilidade-III-final

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. 

                                       

Governança de Dados e a Agilidade-II (continuação)

DAD-Disciplined Agile Delivey

Scott Ambler acaba de lançar em 2015, o seu livro Introduction to Disciplined Agile Delivery(co-autoria de Mark Lines) , chamado coloquialmente de DAD. A ideia é apresentar algumas arquiteturas alternativas à tradicional Agilidade basicona. O objetivo do livro, parece estar marcado pela presença da palavra Disciplined(disciplinado) contido na proposição, mandando uma mensagem que remete a um maior controle, conforme queríamos sugerir. Procura preencher alguns gaps deixados pela camada Ágil tradicional e sugere  quatro possíveis abordagens ou ciclos de vidas, expandindo a visão ágil hoje consolidada, através do uso do eufemismo  “escalando a agilidade”. DAD traz uma mistura de várias abordagens, como Modelagem ágil, Extremme Programming, UP do velho RUP, Kanban, Lean Software development,etc, tudo centrado na visão por objetivos. Os 4 ciclos propostos são:

1-Versão básica do Scrum, enriquecida com genoma do RUP. Contém os aspectos básicos do Scrum, com releases, sprints/iterações, retrospectivas ao final desses pontos, reuniões diárias nos sprints,etc e introduz as fases “rupianas”  de Inception (Concepção) Construction(Construção)  e Transition(Transição);

2-Um ciclo de vida avançado com Lean. Contem a proposição Lean com desenvolvimento contínuo, sem, obrigatoriamente,  os protocolos de releases, sprints,etc do item anterior, que se transformam em opções. Exige claramente maior controle da equipe;

3-Um ciclo de vida de entrega contínua. Contém ênfase na entrega contínua e pode ser visto como uma decorrência/extensão  natural do ciclo anterior, casado com os aspectos  atuais de DEVOPS, fincado nas premissas de desenvolvimento, testes e integrações continuas;

4-Um ciclo de vida exploratório, baseado no lean-start-up . Contém elementos para uma  abordagem quando não se conhece claramente os problemas a serem resolvidos  e portanto nem as soluções imaginadas. Favorece experimentos e laboratórios, minimizando investimentos em soluções e priorizando a descoberta. É a base das ações de P&D já existentes nas empresas;

Essas novas visões do agilismo poderão contribuir para um encaixe maior  com a gestão de dados necessária. Na fase de Inception, os aspectos de dados poderão ser amplamente discutidos, como por exemplo  a criação de modelos de dados de domínios, alinhando-os com direções estratégicas de dados já definidas em níveis acima.

A proposição de Ambler, por ter tido certa moradia na IBM(onde ele atuou por um  período e também pela incorporação de genoma do RUP), acabou deixando espaço para a criação de algo mais neutro, mas que mantém o mesmo sabor de proposta. Dessa forma, surgiu o SAFE, uma nova proposta com visão mais corporativa, centrada nos mesmos princípios de visão organizacional, mas sem reminiscências da IBM.

SAFE-Scaled Agile Framework

Enquanto o Scrum era considerado algo mais focado na construção, o Safe-Scaled Agile Framework se volta para a empresa, numa visão organizacional. A visão mostrada no link –  scaledagileframework.com  -   permite claramente a observação de novos elementos que trazem um conteúdo mais estratégico, necessário para se colocar a agilidade em consonância com aspectos de negócios e por consequência, com os de dados, centro das nossas discussões nesse pedaço aqui.  Nitidamente se observam três grandes camadas. Na primeira camada(chamada Portfólio)  há a tradicional gerência de Portfólios, com  “temas”  estratégicos(lembre-se que em Agilidade, “Temas e Épicos” são sinônimos de requisitos em granularidades diferentes), há owners de épicos(requisitos de alto nível, onde dados deverão ser considerados), há a presença do arquiteto corporativo(onde a arquitetura de dados deverá ser considerada), há épicos de negócios(requisitos de negócios, que se associam com requisitos de dados), há épicos de arquitetura(requisitos de arquitetura, onde também entram as arquiteturas de dados), backlog de portfólios  e há uma nítida visão do planejamento dos releases.  A camada seguinte (denominada Programa) se apresenta com a Gerência de Produtos, com roadmaps (no mineirês, oncotô-proncovõ), a Gerência de Releases com épicos de programa(requisitos daquele conjunto de projetos/releases), há portfólio de programas, etc. Na terceira camada, chamada de Equipe(Team), chegamos aos ciclos de iterações (sprints)  hoje conhecidos dentro do Scrum tradicional. Há as equipes ágeis, a figura do PO, do Scrum Master, dos desenvolvedores e testadores e as estórias encaixadas nas iterações.

Conclusão: Embora as palavras gestão de dados, governança de dados,etc não sejam explicitamente citadas nesses novos frameworks que estendem o Agilismo, não há dúvida, que há um novo espaço para se discutir em conjunto,  o cruzamento dessas duas linhas fundamentais(Agilidade e Dados). A Agilidade não pode prescindir da Gestão de dados. A figura 01 mostra uma possível visão de Scrum com uma camada superior onde aspectos de dados deverão ser considerados.

Governança de Dados e a Agilidade

Lean Data Governance: Outro assunto emergente, dentro do tema de Governança de dados, se refere ao seu encontro com os métodos ágeis. Há uma clara necessidade de se aproximar os dois conceitos, na medida em que os métodos ágeis facilitam o desenvolvimento de soluções, mas os dados deverão ser preservados via políticas, padrões e processos, a fim de se evitar o “data-chaos”, que hoje se aproxima das empresas. Não interessa o caos de dados, produzido por agilidade. Ambas as abordagens devem ser importantes para a organização. Scrum, consagrada e com adoção sem volta , garante desenvolvimentos rápidos e entregas frequentes e precisas. Entretanto, é fundamental que tais entregas de códigos estejam acompanhadas de dados corretos. Simples assim.? Nem tanto.. Os métodos ágeis, tradicionalmente refratários a certos níveis de controle que comprometam a rapidez de suas ações, deverão abrir espaço para que os aspectos de dados sejam considerados como um ativo e não como uma peça absolutamente colateral do processo Scrum. Um ponto de convergência entre as duas abordagens deverá ser buscado, com o apoio e a aprovação da alta gerência. Conceitos atrelados a um Sprint inicial de  dados são possíveis  modificações a pensar. Embora os rótulos “agile”, “lean”, etc estejam na moda, há poucos autores pensando sobre o tema, quando o cenário é Gestão de dados. Há Scott Ambler, Ken Collier, Lawrence Corr e Ralph Hughes  e os mais destacados que são : Kelle O´Neal da First San Francisco Partners(empresa de Consultoria, agora em parceria com John Ladley e a sua IMCue Solutions) e Robert Seiner(da KIK Consulting). Esses são os que eu conheço e acompanho.

O primeiro(Scott Ambler) é um velho conhecido da área de Bancos de dados que se apaixonou pelos movimentos ágeis já no seu nascedouro(quando os primeiros sinais dos manifestos ágeis foram publicados)  e promoveu o conceito de “Agile Data”, com diversas proposições para a mistura dos dois genomas(Agilidade e Dados). Entretanto, o foco inicialmente  dado por Scott Ambler(veja link  http://agiledata.org/) é muito mais de “Agile Data Base Governance”, do que “Agile Data Governance”. E isso faz certa diferença, que deverá ser observada com o devido cuidado. Todas as suas ideias são centradas na linha de que a “Governança de TI” é a que deve ser a prevalente, e que a de dados é uma componente dela, como  é a de sistemas, por exemplo. Sua visão, de certa forma,  se choca, com os conceitos de dados vistos como ativo organizacional(portanto pertencente à organização) e não mais um recurso de exclusividade da TI(anos 60-70-80). Embora a aplicação de preceitos de agilidade seja válida em projetos de BD, levantando aspectos de aderência  para padrões, modelos, metadados,etc, isso deverá ser costurado e alinhado  com visões acima dos projetos, coerentes com modelos, arquiteturas e estratégias. Por exemplo, dentro da visão do Release Planning , poderia se ter algo que se alinhe em níveis de Estratégia de dados. Isso também certamente adicionará na receita Scrum, novas etapas(sprints, atividades,etc), hoje normalmente desconsideradas em função da prioridade tempo. Além disso, Scott baseava  algumas de suas premissas em pesquisas antigas(uma mostrada no site, data de 2006, feita pelo Dr Dobbs), portanto já ultrapassadas em muitas de suas diretivas. Scott Ambler faz afirmações generalistas que se encaixam perfeitamente no conceito de GD Ágil, mas a sua essência é claramente voltada para o estágio físico dos dados. Isso deixa dúvida sobre a amplitude e completude dos conceitos de GD, como se busca nesse momento. O mundo, hoje, se preocupa com os dados, desde o seu nascedouro (o seu ciclo de vida, o seu significado via glossário, gestores tomando conta e ownerships com “accountability”, prestando contas sobre eles)  e não somente quando eles se tornam inquilinos de tabelas relacionais. Nesse momento, sem as devidas observações acima, os erros de dados já podem ter acontecidos e  não tem “recovery”. Ai mora a diferença. Entretanto, parece haver luzes recentes sobre a necessidade de se aproximar dados e agilidade. Numa espécie de evolução dos métodos ágeis tradicionais, estão surgindo novas propostas do Agilismo.  DAD(Disciplined Agile Delivery)  e SAFE(SCALED Agile Framework) são duas delas, que certamente auxiliarão nesta aproximação fundamental de dados e agilidade. Voltaremos depois...

PMBOK e DMBOK-Quando dois corpos se aproximam

“Quando dois corpos se aproximam” poderia ser o nome de uma previsão de colisões de astros ou de um livro qualquer de Nicholas Sparks. Na realidade, nesse contexto, é um truque de marketing “in-bound” com o objetivo de se analisar a convergência e afinidade entre os frameworks do PMBOK e do DMBOK. Dois dos mais conhecidos “BOK”-Body Of Knowledge (BOK), esses conceitos há muito somente estavam tendo encontros marcados pela simples presença das letras B-O-K, em seus logotipos. Andavam de mãos dadas com BABOK e outras proposições semelhantes, integradas somente pelo nome e não pela afinidade de objetivos. Na realidade, há muito mais aproximação entre esses dois elementos do que sugerem os seus manuais e guias. Pelo simples fato de que a Gerência de projetos (foco do PM-BOK) não pode prescindir da gerência de dados (foco do DM-BOK), nem vice-versa, esses dois elementos já deveriam ter se encontrado há tempos. Entretanto, só recentemente o PMBOK trouxe para o seu âmbito, essa discussão de dados de projetos, com detalhes mais evoluídos. Falta ainda um pouco mais sobre a conexão entre ele e os conceitos  de projetos de dados. Dados de projetos e Projetos de dados, embora soe como um aparente jogo de palavras, são elementos com alta afinidade. Na última edição do PMBOK-Guide 5th edition, houve o desenvolvimento de alguns conceitos em direção ao patamar de Conhecimento, trilhando a hierarquia clássica de Dados, Informação, Conhecimento (Knowledge) e Sabedoria (Wisdom), que recebeu o acrônimo DIKW. Os dados foram segregados em três níveis:

·         Dados de desempenho de trabalho (Work performance data): Essa camada de refere às observações e medidas identificadas durante o desempenho dos trabalhos do projeto;

·         Informações de desempenho de trabalho (Work performance information): Essa camada representa os resultados da análise dos dados de desempenho, integrados através de diversas áreas, como o “status” de implementação de solicitações de mudanças, ou previsões para completar atividades, por exemplo; 

·         Relatórios de desempenho de trabalho (Work performance reports): Nessa camada, o PMBOK não define “conhecimento” diretamente e estabelece que aqui esteja a representação física ou eletrônica das informações de desempenho de trabalho, compiladas em documentos de projetos, com o objetivo de gerar decisões, ações ou alertas. Entender as informações nesses veículos (relatórios) e traduzi-las em decisões precisas e ricas é função da competência de gerentes que leem os relatórios. Aqui, na realidade, estariam os conhecimentos gerados, observados, aprendidos e registrados por agentes partícipes do projeto, em pontos do seu ciclo, mas o conceito ficou um pouco camuflado.

Depois dessa primeira incursão do PMBOK em direção ao DIKW gerados em contextos de projetos que seguem processos, o PMBOK precisa pensar na importância do seu casamento com Projetos de Dados. Isso se dará pelo entrelace com corpos de conhecimentos do DMBOK, como DW/BI, MDM, Qualidade e Metadados. E isso discutiremos em outra oportunidade.