Por Techopedia Staff, 16 de novembro de 2016
Resumo: O anfitrião Eric Kavanagh discute a importância da modelagem de dados no desenvolvimento ágil com Robin Bloor, Dez Blanchfield e Ron Huizenga da IDERA.
No momento, você não está logado. Faça o login ou inscreva-se para ver o vídeo.
Eric Kavanagh: Ok, senhoras e senhores. Bem-vindo de volta mais uma vez. É quarta-feira às 16:00 EST. Isso significa que é hora das Tecnologias Quentes. Sim, de fato. Meu nome é Eric Kavanagh, serei seu anfitrião.
Para o tópico de hoje, é uma coisa antiga, mas boa. Está melhorando a cada dia porque está moldando nosso mundo de gerenciamento de dados, “Modelagem de Dados em um Ambiente Ágil”. Há um slide sobre o seu verdadeiramente, me dê uma olhada no Twitter @eric_kavanagh. Deveríamos realmente colocá-lo nesse slide. Eu vou ter que lidar com isso.
Então, o ano está quente. A modelagem de dados existe desde sempre. Ele realmente está no coração e na alma dos negócios de gerenciamento de informações, projetando modelos de dados, tentando entender os modelos de negócios e alinhá-los aos seus modelos de dados. É isso mesmo que você está tentando fazer, certo?
O modelo de dados representa os negócios de uma maneira fundamental. Então, como todas essas novas fontes de dados estão mudando o jogo? Nós vamos descobrir sobre isso. Vamos descobrir como você pode acompanhar as coisas de maneira ágil. E, claro, essa é a palavra do ano.
Robin Bloor está conosco, nosso analista-chefe, Dez Blanchfield, telefonando de Sydney, Austrália, e Ron Huizenga, gerente sênior de produtos da IDERA - meu amigo de longa data, excelente palestrante neste espaço, conhece suas coisas, por isso não se acanhe, pergunte ele as perguntas difíceis, pessoal, as difíceis. Com isso, vou fazer de Robin o apresentador e levá-lo embora.
Dr. Robin Bloor: Ok. Bem, obrigado por isso, Eric. Eu tenho que dizer sobre modelagem que eu acho, eu estava no mundo da TI antes que ela existisse, no sentido de que eu lembro na companhia de seguros em que eu trabalhava, que tínhamos um cara entrando e nos dando todo tipo do workshop sobre como modelar dados. Então, estamos olhando cerca de 30 anos, são 30 anos? Talvez até mais do que isso, talvez 35 anos atrás. A modelagem de muito, muito tempo, na verdade, fez parte da indústria e, claro, não tem nada a ver com mulheres nas passarelas.
O que eu queria dizer, porque o que normalmente fazemos, eu e Dez conversamos sobre coisas diferentes e pensei em dar uma visão geral da modelagem, mas existe uma realidade nisso, que agora está se tornando aparente.
Temos a realidade do big data, temos mais dados, mais fontes de dados, temos fluxos de dados que entraram na equação nos últimos três ou quatro anos e estão começando a ter uma parte maior dela, e existe uma maior necessidade de entender os dados e um aumento na taxa de mudança, com mais dados sendo adicionados e também mais estruturas de dados sendo usadas.
É um mundo difícil. Aqui está uma imagem dele, que na verdade é algo que desenhamos cerca de três anos atrás, mas basicamente, quando você inclui o streaming no mix e obtém essa ideia de refinaria de dados, hub de dados, link de dados ou qualquer outra coisa, você vê que existem dados que são genuinamente em repouso, no sentido de que não está se movendo muito. E há os dados, os fluxos e você tem todo o aplicativo transacional, além de hoje em dia ter eventos, fluxos de dados de eventos que acontecem em aplicativos e que podem precisar, e hoje em dia com as arquiteturas lambda de que todos falam, são genuinamente impactando apenas todo o campo de dados.
E hoje em dia pensamos em termos de haver uma camada de dados. A camada de dados existe de uma maneira virtual, no sentido de que uma boa parte dela pode estar na nuvem e pode se espalhar pelos datacenters, pode existir nas estações de trabalho. A camada de dados está, em certa medida, em toda parte e nesse sentido, há processos em toda parte que estão tentando, de uma maneira ou de outra, processar os dados e movimentá-los. Mas também é importante saber o que é quando você está se movendo.
Se observarmos a modelagem de dados no sentido mais geral, na parte inferior desse tipo de pilha, você terá arquivos e bancos de dados. Você tem elementos de dados, que possuem chaves, definições de elementos, aliases, sinônimos, formatos físicos específicos e, em seguida, temos essa camada de metadados.
O interessante sobre os metadados é que os metadados são inteiramente como os dados obtêm seu significado. Se você realmente não possui metadados, na melhor das hipóteses, você pode adivinhar o significado dos dados, mas terá muitas dificuldades. Os metadados precisam estar lá, mas o significado tem estrutura. Não quero entrar na filosofia do significado, mas mesmo na maneira como lidamos com dados, há muita sofisticação no pensamento humano e na linguagem humana, que não se expressa facilmente nos dados. Mas mesmo em termos dos dados que realmente processamos no mundo, os metadados têm significado e a estrutura dos metadados - um dado em relação ao outro e o que isso significa quando eles são reunidos e o que isso significa quando eles ' se juntar a outros dados, exige que modelemos. Não é bom o suficiente apenas gravar tags de metadados para as coisas; você realmente precisa registrar o significado por estruturas e o relacionamento entre as estruturas.
Em seguida, temos na camada superior, as definições de negócios, que normalmente são uma camada que tenta transferir significado entre os metadados, que é uma forma de definição de dados que acomoda a maneira como os dados são organizados no computador e o significado humano. Portanto, você tem termos de negócios, definições, relacionamentos, conceitos de nível de entidade que existem nessa camada. E se vamos ter uma incoerência entre essas camadas, precisamos modelar os dados. Não é realmente opcional. Quanto mais você conseguir fazer isso em termos de automação, melhor. Mas porque tem a ver com significado, é realmente difícil alternar. É fácil capturar os metadados em um registro e obtê-lo de uma série de significados, mas não informa a estrutura dos registros ou o que os registros significam ou o contexto do registro.
Então, é disso que trata a modelagem de dados. Pontos a serem observados: quanto mais complexo o universo de dados se torna, mais você precisa modelá-lo. Em outras palavras, é como se estivéssemos adicionando não apenas mais instâncias de coisas ao mundo, o que corresponderia a registros de dados, mas na verdade estamos adicionando mais significado ao mundo, capturando dados de mais e mais coisas. Está se tornando uma sensação cada vez mais complexa que precisamos entender.
Em teoria, existe um universo de dados e precisamos de uma visão dele. Na prática, os metadados reais fazem parte do universo de dados. Portanto, não é uma situação simples. O início da modelagem é de cima para baixo e de baixo para cima. Você precisa construir em ambas as direções e a razão disso é que os dados têm significado para o computador e o processo, que precisam processá-los, mas têm significado por si só. Portanto, você precisa de um significado de baixo para cima, que satisfaça o software que precisa acessar os dados e o significado de cima para baixo para que os seres humanos possam entendê-lo. A construção de modelos de metadados não é e nunca pode ser um projeto; é uma atividade contínua - deve ser uma atividade contínua em todos os ambientes em que existem. Felizmente, existem muitos ambientes em que esse não é o caso e as coisas ficam fora de controle de acordo.
No futuro, a modelagem aumenta com importância à medida que a tecnologia avança. Essa é a minha opinião. Mas se você olhar para a IoT, podemos entender os dispositivos móveis mais do que costumávamos, embora tenham introduzido novas dimensões: a dimensão da localização com dispositivos móveis. Quando você chega à IoT, observamos problemas extraordinários de dados que nunca precisávamos fazer antes e precisamos, de uma maneira ou de outra, entender corretamente exatamente o que temos, exatamente como podemos agregá-lo, o que podemos fazer em termos de obter significado da agregação e, é claro, o que podemos fazer com isso, quando o processamos.
Eu acho que sou eu quem disse o suficiente. Vou passar para Dez Blanchfield, que dirá algo completamente diferente.
Dez Blanchfield: Obrigado. Sempre é um ato difícil de seguir, mas este é um tópico que concordamos e falamos sobre isso brevemente na brincadeira pré-show, e se você discou mais cedo, provavelmente pegou um monte de boas jóias. Uma das sugestões, e eu não quero roubar o trovão desta em particular, mas uma das sugestões de nossas brincadeiras pré-show que eu quero compartilhar, caso você não tenha entendido, foi apenas o tópico de a jornada dos dados, e me ocorreu anotá-la pensando na jornada que os dados levam em um contexto diferente em torno da vida útil geracional - ano, meses, semana, dia, hora, minuto, segundo - e o contexto em torno dos dados é posicionado dentro desse contexto. Seja um desenvolvedor executando um código ou um especialista em dados, estou pensando na estrutura, no formato e nos metadados em torno de cada um dos elementos ou na maneira como os sistemas e os negócios interagem com ele.
É uma pequena lição interessante apenas para observar, mas, de qualquer forma, deixe-me aprofundar. Design de dados, em particular, é uma frase que eu uso para falar sobre todos os dados importantes e especificamente sobre o desenvolvimento de aplicativos ou infraestrutura de banco de dados. Eu acho que design de dados é um termo que apenas captura tudo muito bem em minha mente. Hoje em dia, quando falamos sobre design de dados, falamos sobre design moderno de dados ágeis, e minha opinião é que não faz muito tempo que desenvolvedores e especialistas em dados trabalhavam sozinhos; eles estavam em seus próprios silos e as peças de design foram de um silo para outro. Mas hoje em dia sou muito da opinião de que não é só o caso que mudou, mas precisa mudar; é uma espécie de necessidade, e é esse aplicativo - desenvolvedores e tudo o que fazer em torno do desenvolvimento que lida com dados, os projetistas que realizam os elementos de design relevantes de esquemas e campos e registros e sistemas e infra-estruturas de localização e banco de dados, modelagem e gerenciamento inteiro desafio em torno disso. Esse é um esporte de equipe agora e, portanto, minha imagem de um monte de pessoas pulando de um avião agindo como um time para representar essa imagem visualmente interessante de pessoas caindo do céu.
Terceiro, o que aconteceu para provocar isso? Bem, há um artigo em 1986 escrito por alguns cavalheiros cujos nomes eu tentei desesperadamente fazer justiça, Hirotaka Takeuchi e Ikujiro Nonaka, acho que é pronunciado, produziram um artigo intitulado "Movendo o Scrum Downfield". Eles introduziram essa idéia de uma metodologia de ganhar um jogo de rugby saindo dessa atividade de scrum, onde todos se movimentam em um só lugar e duas equipes essencialmente bloqueiam a cabeça em algo chamado scrum para tentar controlar a bola e jogá-la no campo para chegar à linha de tentativa e tocar o chão com a bola e obter um ponto, chamado trígono, e você repete esse processo e obtém mais pontos para a equipe.
Este artigo foi publicado em 1986 na Harvard Business Review e, curiosamente, recebeu muita atenção. Ele chamou muita atenção porque introduziu novos conceitos incríveis e aqui está uma captura de tela da frente dele. Então eles tiraram esse conceito de scrum do jogo de rugby e o trouxeram aos negócios e, particularmente, no jogo de design e entrega de projetos, especificamente entrega de projetos.
O que o scrum fez foi nos deu uma nova metodologia em comparação com os tipos de PRINCE2 ou PMBOK que tínhamos usado anteriormente no que chamamos de metodologia waterfall, você sabe, faz isso e aquilo e aquilo e segue-os em sequência e conecte-os todos os pontos ao redor, o que depende do que você tinha ou não faz a parte dois até que você tenha feito a parte um porque dependia da parte um. O que isso nos deu é uma nova metodologia para ser um pouco mais ágil, que é a origem do termo, sobre como entregamos as coisas e, especificamente, sobre a entrega de projetos de base de design e desenvolvimento.
Alguns dos principais inquilinos - apenas para que eu continue com isso - estão relacionados aos principais inquilinos do scrum. Introduziu a idéia de criar instabilidade, que efetivamente, se você pensar no medo do caos, o mundo existe em um estado de caos, mas o planeta se formou, o que é interessante, criando assim instabilidade, a capacidade de saltar um pouco e na verdade, ainda faz as coisas funcionarem, equipes de projeto auto-organizadas, favores sobrepostos por meio de um desenvolvimento muito responsável, diferentes tipos de aprendizado e controle durante a jornada de entrega do projeto, a transferência organizacional de aprendizado. Então, como coletamos informações de uma parte da empresa e as transferimos para outra de pessoas que têm uma idéia, mas não desenvolvem código ou não desenvolvem bancos de dados e infra-estruturas, mas dados para essas pessoas? E resultados especificamente pontuais. Em outras palavras, vamos fazer isso por um período de tempo, um dia como em 24 horas ou uma semana ou algumas semanas e ver o que podemos fazer e, em seguida, dar um passo atrás e olhar para ele.
Então, se você perdoa o trocadilho, este é realmente um jogo novo na entrega do projeto e os três componentes principais que farão sentido à medida que avançarmos um pouco mais adiante - há o produto: todas essas pessoas têm a idéia e têm uma necessidade de fazer algo e a história que os rodeia. Desenvolvedores que operam no modelo ágil de obter suas histórias e por meio de standups diários, usando a metodologia scrum para discuti-la e entender o que precisam fazer, e então basta seguir em frente e fazê-la. Então, pessoal, ouvimos falar de mestres de scrum que supervisionam tudo isso e entendem a metodologia suficientemente bem para conduzi-la. Todos nós vimos essas imagens que eu peguei no lado direito aqui de paredes e quadros brancos cheios de post-its e eles foram servidos como paredes Kanban. Se você não sabe quem é Kanban, convido você ao Google quem era o Sr. Kanban e por que houve uma mudança na maneira como movemos as coisas de um lado para o outro em uma parede, literalmente, mas em um projeto.
De relance, o fluxo de trabalho do scrum faz isso: é preciso uma lista de coisas que uma organização deseja fazer, executá-las através de uma série de coisas que chamamos de sprints que são divididas em períodos de 24 horas, períodos de um mês e nós obtenha essa série incremental de saídas. É uma mudança significativa na maneira como os projetos são entregues, foram entregues até esse estágio, porque parte disso flui como o exército dos EUA, que teve grande parte do desenvolvimento de algo chamado PMBOK, como a idéia de não levar o tanque para o campo. até você colocar balas na coisa, porque se um tanque no campo não tiver balas, é inútil. Portanto, a primeira parte coloca balas no tanque, a segunda parte coloca o tanque no campo. Infelizmente, no entanto, o que aconteceu com os desenvolvedores no mundo do desenvolvimento de alguma forma se apoderou dessa metodologia ágil e a seguiu, se você perdoa o trocadilho, em um sprint.
Invariavelmente, o que aconteceu é que, quando pensamos em agilidade, geralmente pensamos em desenvolvedores e não em bancos de dados e qualquer coisa a ver com o mundo dos bancos de dados. Foi um resultado infeliz, porque a realidade é que o ágil não se limita aos desenvolvedores. De fato, na minha opinião, o termo ágil geralmente é associado erroneamente exclusivamente a desenvolvedores de software e não a designers e arquitetos de banco de dados. Invariavelmente, os mesmos desafios que você enfrenta no desenvolvimento de software e aplicativos estão relacionados com o design, desenvolvimento, operação e manutenção e, portanto, da infraestrutura de dados e, particularmente, dos bancos de dados. Os atores nesse conjunto de dados específico incluem arquitetos, modeladores, administradores, gerentes das infraestruturas de banco de dados e os próprios bancos de dados reais, até analistas e arquitetos de negócios e sistemas, pessoas que pensam sobre como os sistemas e negócios operam e como chegamos ao fluxo de dados através deles.
É um tópico que trago regularmente porque é uma constante frustração minha, pois sou da opinião de que os especialistas em dados não devem - devem agora estar intimamente envolvidos em todos os componentes da entrega do projeto, realmente, particularmente no desenvolvimento. Para nós, não estamos realmente nos dando a melhor chance de obter um bom resultado. Muitas vezes, temos que voltar atrás e pensar novamente sobre essas coisas, porque existe um cenário, chegamos a um aplicativo que está sendo construído e descobrimos que os desenvolvedores nem sempre são especialistas em dados. Trabalhar com bancos de dados requer habilidades muito especializadas, principalmente em torno de dados, e cria uma experiência. Você não se torna instantaneamente um guru de banco de dados ou especialista em conhecimento de dados da noite para o dia; isso geralmente é algo que vem de uma experiência única e certamente com os gostos do Dr. Robin Bloor no Code Today, que escreveu o livro com bastante riqueza.
Em muitos casos - e é lamentável, mas é uma realidade - que há duas partes dessa moeda, ou seja, os desenvolvedores de software têm um blecaute próprio como especialista em banco de dados e criaram as habilidades necessárias na modelagem de design de banco de dados, sendo o desenvolvimento do modelo apenas o fundamental para a engenharia dos gurus de como os dados entram e como a organização da jornada leva e como deve ou não ser, ou sem dúvida que ingeriu e entendeu que é geralmente obtido nas habilidades nativas definidas para desenvolvedores de software. E alguns dos desafios comuns que enfrentamos, apenas para contextualizar, incluem apenas a criação básica, manutenção e gerenciamento do próprio design do banco de dados principal, documentando os dados e a infraestrutura do banco de dados e, em seguida, reutilizando esses ativos de dados, designs de esquema, gerações de esquemas, administração e manutenção de esquemas e seu uso, o compartilhamento do conhecimento sobre por que esse esquema é projetado de uma maneira específica e os pontos fortes e fracos que acompanham isso ao longo do tempo causam alterações nos dados ao longo do tempo, modelagem de dados e tipos de modelos que aplicamos aos sistemas e dados que fluimos através deles. Geração de código do banco de dados, integração e modelagem de dados em torno deles e acesso mais rápido para controlar a segurança dos dados, a integridade dos dados que estamos movendo os dados enquanto mantemos sua integridade, existem metadados suficientes as vendas devem ver todos os registros da tabela ou devem apenas ver o endereço, o primeiro nome e o sobrenome que enviam as coisas para você na postagem? E, claro, o maior desafio de todos é a modelagem de plataformas de banco de dados, que é uma conversa completamente diferente.
Sou da opinião de que, com tudo isso em mente para tornar possível esse nirvana, é absolutamente essencial que tanto os especialistas em dados quanto os desenvolvedores tenham as ferramentas apropriadas e que essas ferramentas sejam capazes de fornecer projetos focados na equipe, projeto, desenvolvimento e manutenção operacional contínua. Você sabe, coisas como colaborar em projetos entre especialistas em dados e desenvolvedores de software, ponto único de verdade ou fonte única de verdade para tudo sobre documentação dos próprios bancos de dados, dados, esquemas, de onde vêm os registros, proprietários desses registros . Eu acho que hoje em dia é absolutamente crítico, nós vamos ter esse nirvana de dados rei, que as ferramentas certas precisam estar em vigor porque o desafio é grande demais agora para que façamos manualmente, e se as pessoas Ao entrar e sair de uma organização, é muito fácil não seguirmos o mesmo processo ou metodologia que uma pessoa pode configurar que seja boa e que não necessariamente transfira essas habilidades e capacidades daqui para frente.
Com isso em mente, vou falar com o nosso bom amigo da IDERA e ouvir sobre essa ferramenta e como ela lida com essas coisas.
Ron Huizenga: Muito obrigado e obrigado a Robin e Dez por realmente preparar o palco bem, e você verá um pouco de sobreposição em algumas coisas sobre as quais eu falei. Mas eles realmente estabeleceram uma base muito sólida para alguns dos conceitos dos quais falarei da perspectiva da modelagem de dados. E muitas das coisas que eles disseram ecoam minha própria experiência quando eu era consultor trabalhando em modelagem de dados e arquitetura de dados, junto com equipes - tanto em cascata nos primeiros dias quanto evoluindo para produtos mais modernos com projetos nos quais estávamos usando o Agile metodologias para fornecer soluções.
Então, o que vou falar hoje é baseado nessas experiências, bem como em uma visão das ferramentas e alguns dos recursos das ferramentas que utilizamos para nos ajudar nessa jornada. O que vou abordar brevemente é que não vou entrar no scrum com muitos detalhes; nós apenas tivemos uma boa visão geral do que é isso. Vou falar sobre isso em termos de, o que é um modelo de dados e o que realmente significa para nós? E como habilitamos o conceito de modelador de dados ágil em nossas organizações, em termos de como envolvemos os modeladores de dados, qual a participação de modeladores e arquitetos durante o sprint, quais são os tipos de atividades nas quais eles devem se engajar e, como pano de fundo, quais são alguns dos recursos importantes da ferramenta de modelagem que utilizamos para realmente ajudar a facilitar esse trabalho? Então, vou fazer um resumo e falar um pouco sobre alguns dos valores e benefícios comerciais de ter um modelador de dados envolvido, ou a maneira como vou contar a história, os problemas de não ter um modelador de dados totalmente envolvido nos projetos e mostrarei isso com base na experiência e no gráfico de defeitos de uma imagem antes e depois de um projeto real com o qual estive envolvido há muitos anos. E então resumiremos mais alguns pontos e, em seguida, teremos perguntas e respostas.
Muito brevemente, o ER Studio é um conjunto muito poderoso que possui muitos componentes diferentes. O Data Architect, que é onde os modeladores e arquitetos de dados passam a maior parte do tempo fazendo sua modelagem de dados. Também existem outros componentes sobre os quais não falaremos hoje, como o Business Architect, onde fazemos modelagem de processos e o Software Architect, para algumas das modelagens UML. Depois, há o Repositório, onde fazemos check-in e compartilhamos os modelos e permitimos que as equipes colaborem com eles e os publiquem no servidor da equipe, para que vários públicos de interesse envolvidos em um projeto possam realmente ver os artefatos que nós '' estamos criando a partir de uma perspectiva de dados, bem como de outras coisas que estamos fazendo na entrega do projeto.
O que eu vou focar hoje será algumas coisas que veremos no Data Architect e porque é realmente importante que tenhamos a colaboração dos aspectos baseados no Repositório. Particularmente quando começamos a falar de conceitos como gerenciamento de mudanças que são imprescindíveis, não apenas para projetos de desenvolvimento ágil, mas para qualquer tipo de desenvolvimento daqui para frente.
Então, vamos falar sobre o Agile Data Modeler por um momento. Como já mencionamos anteriormente na apresentação, é imperativo que tenhamos modeladores de dados e / ou arquitetos totalmente envolvidos nos processos de desenvolvimento ágil. Agora, o que aconteceu historicamente é que sim, nós realmente pensamos sobre o ágil do ponto de vista do desenvolvimento, e há algumas coisas que aconteceram que realmente fizeram com que isso acontecesse. Parte disso foi devido apenas à natureza da maneira como o desenvolvimento se desenrolou. Quando o desenvolvimento ágil começou e começamos com esse conceito de equipes auto-organizadas, se você bebesse o Kool-Aid um pouco puro demais e estivesse no lado extremo da programação, havia uma interpretação muito literal de coisas como o equipes auto-organizadas, que muitas pessoas interpretaram como significando, tudo o que precisamos é de um grupo de desenvolvedores que possam criar uma solução inteira. Se isso significa desenvolver o código, os bancos de dados ou os datastores por trás dele e tudo foi relegado aos desenvolvedores. Mas o que acontece com isso é que você perde as habilidades especiais que as pessoas têm. Descobri que as equipes mais fortes são aquelas que são compostas por pessoas de diferentes origens. Como uma combinação de fortes desenvolvedores de software, arquitetos de dados, modeladores de dados, analistas de negócios e partes interessadas, todos colaborando juntos para obter uma solução final.
O que também estou falando hoje é que farei isso no contexto de um projeto de desenvolvimento em que estamos desenvolvendo um aplicativo que obviamente também terá o componente de dados associado a ele. No entanto, precisamos dar um passo atrás antes de fazer isso, porque precisamos perceber que existem muito poucos projetos de desenvolvimento greenfield por aí, onde temos foco total na criação e no consumo de dados limitados apenas dentro desse próprio projeto de desenvolvimento. . Precisamos dar um passo atrás e observar o ponto de vista organizacional geral de uma perspectiva de dados e de perspectiva de processo. Porque o que descobrimos é que as informações que estamos utilizando podem já existir em algum lugar nas organizações. Como modeladores e arquitetos, trazemos isso à tona para que saibamos de onde obter essas informações nos próprios projetos. Também conhecemos as estruturas de dados envolvidas porque temos padrões de design, assim como os desenvolvedores têm padrões de design para seu código. E também precisamos adotar essa perspectiva organizacional geral. Não podemos apenas olhar para os dados no contexto do aplicativo que estamos criando. Precisamos modelar os dados e garantir que os documentemos porque eles duram muito além dos próprios aplicativos. Esses aplicativos vão e vêm, mas precisamos analisar os dados e garantir que sejam robustos e bem estruturados, não apenas para aplicativos, mas também para decisões que relatam atividades, relatórios de BI e integração a outros aplicativos, internos e externos. externo a nossas organizações também. Portanto, precisamos analisar toda essa visão geral dos dados e qual é o ciclo de vida desses dados e entender a jornada de informações em toda a organização, do começo ao fim.
Agora, voltando às equipes reais e como realmente precisamos trabalhar, a metodologia em cascata foi percebida como lenta demais para gerar resultados. Porque, como apontado no exemplo do tanque, era um passo após o outro e muitas vezes levava muito tempo para fornecer um resultado final viável. O que fazemos agora é que precisamos ter um estilo de trabalho iterativo, onde estamos desenvolvendo componentes de forma incremental e elaborando-o ao longo do tempo em que produzimos código utilizável ou artefatos utilizáveis, vou dizer, para cada sprint. O importante é a colaboração entre as partes interessadas técnicas da equipe e as partes interessadas nos negócios, pois estamos colaborando para levar essas histórias de usuários a uma visão implementável do código e dos dados que também suportam esse código. E o próprio Agile Data Modeler geralmente descobre que não temos modeladores suficientes nas organizações, portanto, um modelador ou arquiteto de dados pode simultaneamente apoiar várias equipes.
E o outro aspecto disso é que, mesmo que tenhamos vários modeladores, precisamos ter um conjunto de ferramentas que estamos utilizando, que permita a colaboração de vários projetos que estão em andamento ao mesmo tempo e o compartilhamento desses artefatos de dados e os recursos de check-in e check-out. Vou revisar isso muito rapidamente, porque já o abordamos na seção anterior. A premissa real do ágil é que você está baseando as coisas no backlog, nas histórias ou nos requisitos. Dentro das iterações, estamos colaborando como um grupo. Normalmente, um sprint de duas semanas ou um mês, dependendo da organização, é muito comum. E também reuniões diárias de revisão e stand-up, para eliminar os bloqueadores e garantir que todos os aspectos avancem sem ser interrompido em diferentes áreas à medida que avançamos. E nesses sprints, queremos ter certeza de que estamos produzindo produtos utilizáveis como parte de cada sprint.
Apenas uma visão um pouco diferente disso, expandindo ainda mais, o scrum é a metodologia sobre a qual vou falar mais especificamente aqui e basicamente aumentamos a imagem anterior com algumas outras facetas. Normalmente, há um backlog de produto e, em seguida, um backlog de sprint. Portanto, temos uma lista de pendências geral que, no início de cada reiteração do sprint, paramos para dizer: "O que vamos construir esse sprint?" E isso é feito em uma reunião de planejamento do sprint. Depois, dividimos as tarefas associadas a isso e executamos nesses sprints de uma a quatro semanas com essas revisões diárias. Enquanto fazemos isso, estamos acompanhando nosso progresso através de gráficos de queima e gráficos de queima para rastrear basicamente o que resta construir versus o que estamos construindo para estabelecer coisas como qual é a nossa velocidade de desenvolvimento, vamos fazer o nosso agenda, todos esses tipos de coisas. Tudo isso é elaborado continuamente durante o sprint, em vez de passar alguns meses no caminho e descobrir que você ficará com falta de tempo e precisará estender o cronograma do projeto. E muito importante, como parte disso, para todas as equipes, há uma revisão de sprint no final e uma retrospectiva do sprint; portanto, antes de iniciar a próxima iteração, você está revendo o que fez e procurando maneiras de melhorar na próxima vez.
Em termos de entregas, este é basicamente um slide que resume os tipos típicos de coisas que acontecem nos sprints. E é muito centrado no desenvolvimento, então muitas das coisas que vemos aqui, como projetos funcionais e casos de uso, fazem testes de código de design, quando olhamos para essas caixas aqui e não vou passar por elas em qualquer nível de detalhe, eles são muito orientados para o desenvolvimento. E enterrado aqui embaixo está o fato de que também precisamos ter as entregas de dados que andam de mãos dadas com isso para apoiar esse esforço. Portanto, toda vez que vemos coisas como os registros em atraso, os requisitos e as histórias dos usuários, conforme analisamos, precisamos examinar quais são as peças de desenvolvimento que precisamos fazer, quais são as peças de análise que precisamos fazer, e quanto à design de dados ou modelo de dados, o que dizer de coisas como os glossários de negócios para que possamos associar o significado dos negócios a todos os artefatos que estamos produzindo? Porque precisamos produzir esses produtos utilizáveis em cada sprint.
Algumas pessoas dirão que precisamos produzir código utilizável no final de cada sprint. Esse não é necessariamente o caso, é uma perspectiva de desenvolvimento mais pura, mas muitas vezes - especialmente no início - podemos ter algo como o zero de sprint, onde estamos focados puramente em levantar as coisas, fazendo coisas como obter nossas estratégias de teste. Lugar, colocar. Um design de alto nível para iniciá-lo antes de começarmos a preencher os detalhes e garantir que tenhamos um conjunto limpo de histórias ou requisitos de partida antes de começarmos a envolver outros públicos e a avançar como equipe à medida que avançamos. Sempre há um pouco de tempo de preparação, portanto, com frequência, teremos um zero de sprint ou mesmo zero e um. Pode ser um pouco de fase de inicialização antes de começarmos a fornecer a solução.
Vamos falar sobre modelos de dados neste contexto muito brevemente. Quando as pessoas pensam em modelos de dados, geralmente pensam em um modelo de dados como uma imagem de como as diferentes informações se unem - isso é apenas a ponta do iceberg. Para incorporar totalmente o espírito de como você realmente deseja abordar a modelagem de dados - seja no desenvolvimento ágil e outras coisas - é necessário perceber que o modelo de dados, se feito corretamente, se torna sua especificação completa do que esses dados significam na organização e como é implantado nos bancos de dados de back-end. Quando digo bancos de dados, quero dizer não apenas os bancos de dados relacionais que podemos estar usando, mas nas arquiteturas atuais, onde temos big data ou plataformas NoSQL, como prefiro chamá-los. Também esses grandes armazenamentos de dados, porque podemos combinar vários armazenamentos de dados diferentes em termos de consumo de informações e trazê-las para nossas soluções, além de como persistimos ou salvamos essas informações também.
Podemos estar trabalhando com vários bancos de dados ou fontes de dados simultaneamente no contexto de um determinado aplicativo. O que é muito importante é que queremos ter uma especificação completa; portanto, uma especificação lógica do que isso significa para uma perspectiva organizacional do sprint, quais são as construções físicas em termos de como realmente definimos os dados, os relacionamentos entre eles no seus bancos de dados, suas restrições de integridade referencial, restrições de verificação, todas as peças de validação em que você normalmente pensa. Os metadados descritivos são extremamente importantes. Como você sabe como utilizar os dados em seus aplicativos? A menos que você possa defini-lo e saber o que significa ou de onde veio para garantir que você está consumindo os dados corretos nesses aplicativos - verifique se temos convenções de nomenclatura corretas, definições completas, o que significa um dicionário de dados completo não apenas para as tabelas, mas as colunas que as compõem - e detalha as notas de implantação sobre como utilizamos isso porque precisamos construir essa base de conhecimento, porque mesmo quando esse aplicativo é concluído, essas informações serão usadas para outras iniciativas, por isso precisamos garantir que temos tudo isso documentado para futuras implementações.
Novamente, chegamos a coisas como tipos de dados, chaves, índices, o próprio modelo de dados incorpora muitas das regras de negócios que entram em jogo. Os relacionamentos não são apenas restrições entre tabelas diferentes; eles geralmente nos ajudam a descrever quais são as verdadeiras regras de negócios sobre como esses dados se comportam e como eles funcionam juntos como uma unidade coesa. E, claro, restrições de valor são muito importantes. Agora, é claro, uma das coisas com as quais estamos constantemente lidando, e está se tornando cada vez mais predominante, são coisas como governança de dados. Portanto, de uma perspectiva de governança de dados, também precisamos observar o que estamos definindo aqui? Queremos definir coisas como classificações de segurança. Com que tipos de dados estamos lidando? O que será considerado gerenciamento de dados mestre? Quais são os armazenamentos transacionais que estamos criando? Quais dados de referência estamos utilizando nesses aplicativos? Precisamos garantir que isso seja capturado corretamente em nossos modelos. E também considerações sobre a qualidade dos dados, existem certas informações que são mais importantes para uma organização do que outras.
Estive envolvido em projetos nos quais substituímos mais de uma dúzia de sistemas legados por novos processos de negócios e projetamos novos aplicativos e armazenamentos de dados para substituí-los. Precisávamos saber de onde vinha a informação. Para as informações mais importantes, do ponto de vista comercial, se você olhar para este slide de modelo de dados específico que eu tenho aqui, verá as caixas inferiores dessas entidades específicas, que são apenas um pequeno subconjunto, realmente consegui capturar o valor comercial. Seja alto, médio ou baixo para esses tipos de coisas, para essas diferentes construções dentro da organização. E também capturei coisas como as classes de dados mestre, sejam tabelas mestre, referência ou se são transacionais. Portanto, podemos estender nossos metadados em nossos modelos para nos dar muitas outras características fora dos próprios dados, o que realmente nos ajudou com outras iniciativas fora dos projetos originais e os levou adiante. Agora, isso foi muito em um slide, vou analisar o restante rapidamente.
Agora vou falar muito rapidamente sobre o que um modelador de dados faz quando estamos passando por esses diferentes sprints. Primeiro de tudo, um participante completo das sessões de planejamento do sprint, onde estamos levando as histórias dos usuários, comprometendo-nos com o que vamos entregar nesse sprint e descobrindo como vamos estruturá-lo e entregá-lo. O que também estou fazendo como modelador de dados é que sei que vou trabalhar em áreas separadas com diferentes desenvolvedores ou com pessoas diferentes. Portanto, uma das características importantes que podemos ter é quando estamos criando um modelo de dados, podemos dividi-lo em diferentes visões, sejam elas de áreas ou submodelos, é a nossa terminologia. Portanto, à medida que construímos o modelo, também o mostramos nessas diferentes perspectivas do submodelo, para que os diferentes públicos apenas vejam o que é relevante para eles, para que possam se concentrar no que estão desenvolvendo e apresentando. Então, posso ter alguém trabalhando em uma parte do agendamento de um aplicativo, ou alguém trabalhando em uma entrada de pedido em que estamos fazendo todas essas coisas em um único sprint, mas posso dar a eles os pontos de vista por meio dos submodelos que apenas aplicam-se à área em que estão trabalhando. E então eles se acumulam no modelo geral e em toda a estrutura dos submodelos para fornecer ao público diferentes visualizações do público-alvo.
Noções básicas de uma perspectiva de modelagem de dados que queremos ter, sempre tenha uma linha de base para a qual possamos voltar, porque uma das coisas que precisamos ser capazes de fazer é, seja no final de um sprint ou no final de vários sprints, queremos saber por onde começamos e sempre ter uma linha de base para saber qual foi o delta ou a diferença do que produzimos em um determinado sprint. Também precisamos garantir um retorno rápido. Se você entrar como modelador de dados, mas no papel tradicional de gatekeeper de dizer "Não, não, você não pode fazer isso, precisamos fazer tudo isso primeiro", você será excluído da equipe quando realmente precisar ser um participante ativo de todas as equipes de desenvolvimento ágil. Isso significa que algumas coisas caem do vagão fazendo um determinado sprint e você as pega nos sprints posteriores.
Como exemplo, você pode se concentrar nas estruturas de dados apenas para iniciar o desenvolvimento, por exemplo, a parte da entrada de pedidos que eu estava falando. Em uma sprint posterior, você pode voltar e preencher os dados como parte da documentação do dicionário de dados em torno de alguns dos artefatos que você criou. Você não vai concluir essa definição em um único sprint; você continuará realizando as entregas, porque haverá momentos em que você poderá preencher essas informações trabalhando com analistas de negócios quando os desenvolvedores estiverem ocupados construindo os aplicativos e a persistência em torno desses armazenamentos de dados. Você quer facilitar e não ser o gargalo. Existem diferentes maneiras pelas quais trabalhamos com desenvolvedores. Para algumas coisas, temos padrões de design, por isso somos um participante completo, portanto, podemos ter um padrão de design em que digamos que o colocaremos no modelo, o enviaremos aos bancos de dados de sandbox dos desenvolvedores e eles poderão comece a trabalhar com ele e solicite alterações.
Pode haver outras áreas nas quais os desenvolvedores estão trabalhando, eles têm algo em que estão trabalhando e estão criando protótipos para algumas coisas, para que tentem algumas em seu próprio ambiente de desenvolvimento. Pegamos o banco de dados com o qual eles estão trabalhando, o trazemos para a nossa ferramenta de modelagem, comparamos com os modelos que temos e, em seguida, resolvemos e enviamos as alterações de volta para eles, para que eles possam refatorar seus códigos e seguir as estruturas de dados apropriadas. que precisamos. Como eles podem ter criado algumas coisas que já tínhamos em outros lugares, garantimos que eles estejam trabalhando com as fontes de dados corretas. Continuamos repetindo isso até o nosso sprint, para obter os resultados completos dos dados, a documentação completa e a definição de todas as estruturas de dados que estamos produzindo.
Os projetos ágeis de maior sucesso com os quais me envolvi em termos de entregas muito boas são: tínhamos uma filosofia, modelamos todas as alterações na especificação completa do banco de dados físico. Em essência, o modelo de dados se torna os bancos de dados implantados com os quais você está trabalhando para algo novo que estamos criando e possui referências completas dos outros armazenamentos de dados, se estiver consumindo de outros bancos de dados externos. Como parte disso, estamos produzindo scripts incrementais em vez de gerar uma geração completa todas as vezes. E estamos utilizando nossos padrões de design para nos dar esse impulso rápido em termos de fazer as coisas correrem com as diferentes equipes de desenvolvimento com as quais estamos trabalhando.
Também nas atividades de sprint, é novamente essa linha de base para comparação / mesclagem, portanto, tomemos a idéia de modelar cada alteração. Toda vez que fazemos uma mudança, o que queremos fazer é modelar a mudança e o que é muito importante, o que faltava na modelagem de dados até recentemente, na verdade, até a reintroduzirmos, é a capacidade de associar a modelagem tarefas e suas entregas com as histórias de usuário e as tarefas que realmente causam essas alterações. Queremos poder verificar as alterações de nosso modelo, da mesma forma que os desenvolvedores verificam seus códigos, referenciando as histórias de usuários que possuímos, para que saibamos por que fizemos alterações em primeiro lugar, isso é algo que fazemos. Quando fazemos isso, geramos nossos scripts DDL incrementais e os publicamos para que possam ser coletados com os outros produtos de desenvolvimento e verificados em nossa solução de compilação. Novamente, podemos ter um modelo ou trabalhar com várias equipes. E, como já falei, algumas coisas são originadas pelo modelador de dados, outras são originadas pelos desenvolvedores e nos reunimos no meio para criar o melhor design geral, avançar e garantir que ele seja adequadamente projetado em nosso estruturas gerais de dados. Temos que manter a disciplina de garantir que tenhamos todas as construções adequadas em nosso modelo de dados à medida que avançamos, incluindo coisas como valores nulos e não nulos, restrições referenciais, basicamente restrições de verificação, todas as coisas em que normalmente pensamos .
Vamos falar agora de apenas algumas capturas de tela de algumas das ferramentas que nos ajudam a fazer isso. O que eu acho importante é ter esse repositório colaborativo, então o que podemos fazer como modeladores de dados - e este é um trecho de parte de um modelo de dados em segundo plano - é quando estamos trabalhando em coisas que queremos ter certeza de que podemos trabalhe apenas nos objetos que precisamos mudar, faça as modificações, gere nossos scripts DDL para as alterações que fizemos ao verificar as coisas novamente. Portanto, o que podemos fazer é, no ER Studio, ser um exemplo, podemos verificar objetos ou grupos de objetos para trabalhar, não precisamos verificar um modelo ou submodelo inteiro, podemos verificar apenas as coisas que nos interessam. O que queremos depois é no check-out ou no check-in - fazemos isso nos dois sentidos, porque diferentes equipes de desenvolvimento trabalham de maneiras diferentes. Queremos garantir que associamos isso à história ou tarefa do usuário que está gerando os requisitos para isso e que será a mesma história ou tarefa que os desenvolvedores estão desenvolvendo e verificando seu código.
Então, aqui está um trecho muito rápido de duas telas de um de nossos centros de gerenciamento de mudanças. O que isso faz, não vou descrever detalhadamente aqui, mas o que você está vendo é a história ou tarefa do usuário e recuado embaixo de cada um dos que você está vendo os registros de alterações reais - criamos um registro de alterações automatizado quando fazemos o check-in e o check-out e também podemos descrever mais esse registro de alterações. Está associado à tarefa, podemos ter várias alterações por tarefa, como você esperaria. E quando entramos nesse registro de mudança, podemos olhar para ele e, mais importante, ver, o que realmente mudamos? Para esta em particular, a história destacada ali, eu tive um tipo de alteração que foi feita e, quando olhei para o próprio registro de mudança, ele identificou as peças individuais no modelo que foi alterado. Mudei alguns atributos aqui, os refizeram e trouxeram para o passeio as visualizações que precisavam ser alteradas e dependentes delas, para que elas fossem geradas na DLL incremental. Não é apenas modelagem nos objetos de base, mas uma ferramenta de modelagem de alta potência como essa também detecta as alterações que precisam ser alteradas pelos objetos dependentes no banco de dados ou no modelo de dados.
Se estivermos trabalhando com desenvolvedores, e fizermos isso de várias maneiras diferentes, isso está fazendo algo em sua caixa de proteção e queremos comparar e ver onde estão as diferenças, usamos os recursos de comparação / mesclagem no lado direito e esquerdo lado. Podemos dizer: “Aqui está o nosso modelo no lado esquerdo, aqui está o banco de dados no lado direito, mostre-me as diferenças.” Podemos então escolher como resolver essas diferenças, se colocamos as coisas no banco de dados ou se existem algumas coisas que eles têm no banco de dados que trazemos de volta ao modelo. Podemos ir bidirecionais para seguir as duas direções, atualizando simultaneamente a origem e o destino e, em seguida, produzir os scripts DDL incrementais para implantar essas alterações no próprio ambiente de banco de dados, o que é extremamente importante. O que também podemos fazer é que também podemos usar esse recurso de comparação e mesclagem a qualquer momento. Se estivermos tirando instantâneos no caminho, sempre podemos comparar o início de um sprint com o início ou o final de outro sprint para que possamos ver a mudança incremental completa do que foi feito em um determinado sprint de desenvolvimento ou em uma série de sprints.
Este é um exemplo muito rápido de um alter script, qualquer um de vocês que trabalhou com bancos de dados já viu esse tipo de coisa; é isso que podemos extrair do código como um script alter, para garantir que possamos reter as coisas aqui. O que tirei daqui, apenas para reduzir a desordem, é o que também fazemos com esses scripts alter: assumimos que também existem dados nessas tabelas; portanto, também geraremos o DML que extrairá as informações das tabelas temporárias e empurre-o de volta para as novas estruturas de dados também, para que possamos observar não apenas as estruturas, mas também os dados que já podemos ter contido nessas estruturas.
Vamos falar muito rapidamente sobre sistemas de compilação automatizados porque, quando estamos desenvolvendo um projeto ágil, frequentemente trabalhamos com sistemas de compilação automatizados, nos quais precisamos verificar os diferentes produtos juntos para garantir que não quebremos nossas compilações. O que isso significa é que sincronizamos as entregas, os scripts de alteração sobre os quais falei com o script DDL precisam ser registrados, o código do aplicativo correspondente precisa ser verificado ao mesmo tempo e muitos desenvolvedores agora não precisam sendo feito com SQL direto nos bancos de dados e esse tipo de coisa. Muitas vezes, estamos usando estruturas de persistência ou construindo serviços de dados. Precisamos garantir que as alterações nessas estruturas ou serviços sejam verificadas exatamente ao mesmo tempo. Eles entram em um sistema de compilação automatizado em algumas organizações e, se a compilação for interrompida, em uma metodologia ágil, tudo será consertado antes de avançarmos, para que saibamos que temos uma solução funcional antes de prosseguir. E um dos projetos nos quais eu participei, levamos isso ao extremo - se a compilação quebrasse, na verdade anexávamos a vários computadores em nossa área onde estávamos colocados com os usuários corporativos, tínhamos luzes vermelhas piscando como o topo dos carros da polícia. E se a construção quebrasse, aquelas luzes vermelhas piscavam e nós sabíamos que tudo estava no convés: conserte a construção e prossiga com o que estávamos fazendo.
Eu quero falar sobre outras coisas, e esse é um recurso exclusivo do ER Studio, realmente ajuda quando estamos tentando criar esses artefatos como desenvolvedores para esses limites de persistência, temos um conceito chamado objetos de dados de negócios e o que isso nos permite O que fazer é se você olhar para este modelo de dados muito simplista como exemplo, ele permite encapsular entidades ou grupos de entidades para onde estão os limites de persistência. Onde nós, como modeladores de dados, podemos pensar em algo como um cabeçalho de pedido de compra e o alinhamento de pedidos e outras tabelas detalhadas que se encaixariam nisso na maneira como os construímos e nossos desenvolvedores de serviços de dados precisam saber como as coisas persistem nesses dados diferentes estruturas. Nossos desenvolvedores estão pensando em coisas como o pedido de compra como um objeto geral e qual é o contrato deles com a forma como eles criam esses objetos específicos. Podemos expor esses detalhes técnicos para que as pessoas que constroem os servidores de dados possam ver o que está por baixo e podemos proteger os outros públicos das complexidades, para que apenas vejam os diferentes objetos de nível superior, o que também funciona muito bem para a comunicação com os negócios. analistas e partes interessadas nos negócios quando falamos sobre a interação de diferentes conceitos de negócios.
O bom disso também é que construtivamente os expandimos e reduzimos para que possamos manter os relacionamentos entre os objetos de ordem superior, mesmo que eles se originem em construções contidas nos próprios objetos de dados de negócios. Agora, como modelador, chegue ao final do sprint, no final do encerramento do sprint, tenho muitas coisas que preciso fazer, que chamo de minha limpeza para o próximo sprint. A cada sprint que eu crio o que chamo de Release Nomeado - isso me dá minha linha de base para o que tenho agora no final do lançamento. Portanto, isso significa que é minha linha de base daqui para frente; todas essas linhas de base ou Liberações nomeadas que eu crio e salvo no meu repositório podem ser usadas para fazer uma comparação / mesclagem, para que eu possa sempre comparar com qualquer final de sprint de qualquer outro sprint, que é muito importante saber quais foram suas alterações no modelo de dados no caminho de sua jornada.
Também crio um script DDL delta usando a comparação / mesclagem novamente do início ao fim do sprint. Talvez eu tenha verificado um monte de scripts incrementais, mas se precisar, agora tenho um script que posso implantar para suportar outras caixas de areia, para que eu possa apenas dizer que é isso que tínhamos no início de um sprint, pressione através disso, crie um banco de dados como uma sandbox para começar com o próximo sprint e também podemos usar essas coisas para fazer instâncias de controle de qualidade stand-by e, finalmente, é claro que queremos levar nossas alterações à produção para que haja várias coisas acontecendo ao mesmo tempo. Novamente, participamos totalmente do planejamento e das retrospectivas do sprint, as retrospectivas são realmente as lições aprendidas e isso é extremamente importante, porque você pode avançar muito rapidamente durante o ágil, precisa parar e comemorar os sucessos, como agora. Descubra o que está errado, melhore na próxima vez, mas também celebre as coisas que deram certo e construa nelas à medida que você avança nos próximos sprints daqui para frente.
Agora vou falar muito rapidamente sobre o valor comercial. Havia um projeto com o qual me envolvi há muitos anos que começou como um projeto ágil, e era um projeto extremo, por isso era uma equipe pura de auto-organização, na qual apenas desenvolvedores estavam fazendo tudo. Para encurtar a história, esse projeto estava parado e eles descobriram que estavam gastando cada vez mais vezes corrigindo e corrigindo os defeitos identificados do que pressionando mais funcionalidade e, de fato, quando o analisavam com base nas paradas de queimadas, eles teriam que estender o projeto seis meses a um custo enorme. E, quando analisamos, a maneira de remediar o problema era utilizar uma ferramenta de modelagem de dados adequada com um modelador de dados qualificado envolvido no próprio projeto.
Se você olhar para esta barra vertical neste gráfico específico, isso mostra defeitos cumulativos versus objetos cumulativos, e estou falando de objetos ou construções de dados que foram criados, como as tabelas com restrições e esses tipos de coisas, se você olhou para Antes da introdução do modelador de dados, o número de defeitos estava realmente excedendo e começando a criar uma brecha em relação ao número real de objetos que foram produzidos até aquele momento. Após a semana 21, foi quando o modelador de dados entrou, refatorou o modelo de dados com base no que havia para corrigir várias coisas e, em seguida, começou a modelar como parte da equipe do projeto daqui para frente, as mudanças conforme esse projeto estava sendo promovido . E você viu uma resposta muito rápida que, em cerca de um sprint e meio, vimos um grande aumento no número de objetos e construções de dados que estavam sendo gerados e construídos porque estávamos gerando a partir de uma ferramenta de modelagem de dados, e não de um desenvolvedor. construí-los em um ambiente e eles estavam corretos porque tinham a integridade referencial adequada e as outras construções que deveria ter. O nível de defeitos em relação àqueles quase lineares. Ao tomar a ação apropriada e garantir que a modelagem de dados esteja totalmente envolvida, o projeto foi entregue dentro do prazo com um nível de qualidade muito mais alto e, de fato, não teria sido entregue se essas etapas não tivessem ocorrido. Existem muitas falhas ágeis por aí, também existem muitos sucessos ágeis se você envolver as pessoas certas nas funções certas. Sou um grande defensor do ágil como disciplina operacional, mas você precisa ter as habilidades de todos os grupos certos envolvidos como equipes de projeto à medida que avança em um tipo de empreendimento ágil.
Para resumir, arquitetos e modeladores de dados devem estar envolvidos em todos os projetos de desenvolvimento; eles realmente são a cola que mantém tudo unido porque, como entendemos por modeladores e arquitetos de dados, não apenas as construções de dados de um projeto de desenvolvimento, mas também onde os dados existem na organização e onde podemos obter esses dados e também como eles será usado e utilizado fora do aplicativo específico em que estamos trabalhando. Entendemos as complexas relações de dados e é fundamental poder avançar e também de uma perspectiva de governança para mapear documentos e entender como é o cenário de dados completo.
É como fabricar; Eu vim de um fundo de fabricação. Você não pode inspecionar a qualidade em algo no final - você precisa incorporar qualidade ao seu design desde o início e durante o processo, e a modelagem de dados é uma maneira de incorporar essa qualidade ao design de maneira eficiente e econômica durante todo o processo. . E, novamente, algo para lembrar - e isso não deve ser trivial, mas é a verdade - os aplicativos vêm e vão, os dados são o ativo corporativo vital e transcendem todos esses limites de aplicativos. Toda vez que você está inserindo um aplicativo, provavelmente você está sendo solicitado a preservar os dados de outros aplicativos que vieram antes, portanto, precisamos apenas lembrar que esse é um ativo corporativo vital que continuamos mantendo ao longo do tempo.
E é isso! A partir daqui, vamos fazer mais perguntas.
Eric Kavanagh: Tudo bem, bom, deixe-me passar para Robin primeiro. E então, Dez, tenho certeza que você tem algumas perguntas. Tira isso, Robin.
Dr. Robin Bloor: Ok. Para ser sincero, nunca tive nenhum problema com métodos de desenvolvimento ágil e me parece que o que você está fazendo aqui faz sentido eminente. Lembro-me de observar algo na década de 1980 que indicava realmente que o problema que você realmente encontra em termos de um projeto saindo de controle é normalmente se você deixar um erro persistir além de um estágio específico. Torna-se cada vez mais difícil consertar se você não acertar nesse estágio, então uma das coisas que você está fazendo aqui - e acho que esse é o slide -, mas uma das coisas que você está fazendo aqui no sprint zero, na minha opinião, é absolutamente importante, porque você está realmente tentando fixar as entregas. E se você não obtiver entregas fixadas, as entregas mudarão de forma.
Essa é a minha opinião. Também é minha opinião - eu realmente não tenho nenhum argumento com a idéia de que você precisa ajustar a modelagem de dados a um certo nível de detalhe antes de prosseguir. O que eu gostaria que você tentasse e porque não entendi completamente, é apenas descrever um desses projetos em termos de tamanho, em termos de como fluía, em termos de quem, você sabe, onde os problemas surgiram, eles foram resolvidos? Porque acho que esse slide é o coração dele e, se você puder elaborar um pouco mais sobre isso, ficaria muito grato.
Ron Huizenga: Claro, e usarei alguns exemplos de projetos. Aquele que, de certa forma, saiu dos trilhos que foi trazido de volta ao realmente envolver as pessoas certas e fazer a modelagem de dados e tudo foi realmente uma maneira de garantir que o design fosse entendido melhor e que obviamente tivéssemos um design de implementação melhor no caminho, modelando-o. Porque quando você o modela, você sabe, você pode gerar seu DDL e tudo por trás e por fora da ferramenta, em vez de ter que continuar construindo isso como as pessoas normalmente fazem indo diretamente para um ambiente de banco de dados. E coisas típicas que acontecerão com os desenvolvedores é que eles vão lá e dizem, ok, eu preciso dessas tabelas. Digamos que estamos fazendo entradas de pedidos. Portanto, eles podem criar o cabeçalho do pedido, as tabelas de detalhes do pedido e esses tipos de coisas. Mas muitas vezes esquecem ou negligenciam para garantir que as restrições existem para representar os relacionamentos de chave estrangeira. Eles podem não ter as chaves corretas. As convenções de nomenclatura também podem ser suspeitas. Não sei quantas vezes entrei em um ambiente, por exemplo, onde você vê várias tabelas diferentes com nomes diferentes, mas os nomes das colunas nessas tabelas são como ID, Nome ou qualquer outra coisa, então eles realmente perdi o contexto sem a tabela do que exatamente é isso.
Portanto, normalmente quando estamos modelando dados, garantimos que estamos aplicando convenções de nomenclatura adequadas a todos os artefatos que estão sendo gerados na DDL também. Mas para ser mais específico sobre a natureza dos projetos em si é, de um modo geral, estou falando de iniciativas razoavelmente grandes. Um deles foi o projeto de transformação de negócios de US $ 150 milhões, onde substituímos mais de uma dúzia de sistemas legados. Tínhamos cinco equipes ágeis diferentes acontecendo simultaneamente. Eu tinha uma equipe de arquitetura de dados completa; portanto, havia modeladores de dados da minha equipe incorporados em todas as outras equipes da área de aplicativos, e estávamos trabalhando com uma combinação de especialistas internos em negócios que conheciam o assunto e que estavam fazendo o processo. histórias de usuários para os próprios requisitos. Tivemos analistas de negócios em cada uma das equipes que estavam modelando o processo de negócios, com os diagramas de atividades ou diagramas de processos de negócios, ajudando a aprofundar mais as histórias de usuários com os usuários antes de serem consumidos pelo restante da equipe.
E então, é claro, os desenvolvedores que estavam construindo o código do aplicativo além disso. E também estávamos trabalhando, acho que eram quatro fornecedores de integração de sistemas diferentes que estavam construindo partes diferentes do aplicativo, onde uma equipe estava construindo os serviços de dados, a outra construindo a lógica do aplicativo em uma área, outra que possuía experiência em outra área de negócios, estava construindo a lógica do aplicativo nessa área. Então tivemos toda uma colaboração de pessoas que estavam trabalhando neste projeto. Nesse, em particular, tínhamos 150 pessoas em terra na equipe e outros 150 recursos no exterior da equipe que estavam colaborando em sprints de duas semanas para expulsar essa coisa. E para fazer isso, você precisa ter certeza de que está disparando em todos os cilindros, e todos estão bem sincronizados em termos de quais são os produtos a serem entregues, e você teve essas redefinições frequentes para garantir que estávamos concluindo nossas entregas de todos os artefatos necessários no final de cada corrida.
Dr. Robin Bloor: Bem, isso é impressionante. E apenas para um pouco mais de detalhes sobre isso - você terminou com um mapa completo do que eu chamaria de MDM de toda a área de dados no final do projeto?
Ron Huizenga: Tínhamos um modelo de dados completo que foi quebrado com a decomposição entre todas as diferentes áreas de negócios. O próprio dicionário de dados em termos de definições completas ficou um pouco aquém. Nós tínhamos a maioria das tabelas definidas; tínhamos a maioria das colunas definidas exatamente para o que elas significavam. Havia algumas que não estavam lá e, curiosamente, muitas eram informações fornecidas pelos sistemas legados em que, após o final do escopo do projeto, ainda estavam sendo documentadas como um conjunto de artefatos, por assim dizer, fora do próprio projeto, porque era algo que precisava ser sustentado pela organização no futuro. Então, ao mesmo tempo, a organização teve um ponto de vista muito maior da importância da governança de dados, porque vimos muitas deficiências nesses sistemas legados e nas fontes de dados legadas que estávamos tentando consumir porque não estavam documentadas. Em muitos casos, só tínhamos bancos de dados que precisávamos fazer engenharia reversa e tentar descobrir o que havia lá e para que serviam as informações.
Dr. Robin Bloor: Não me surpreende esse aspecto particular. A governança de dados é, vamos chamá-la, uma preocupação muito moderna e acho que realmente há muito trabalho que, digamos, deveria ter sido feito historicamente na governança de dados. Nunca foi porque você poderia, meio que, se safar de não fazer isso. Mas, como o recurso de dados cresceu e cresceu, você não conseguiu.
Enfim, vou passar para Dez porque acho que tive meu tempo previsto. Dez?
Dez Blanchfield: Sim, obrigado. Durante toda essa coisa, estou observando e pensando comigo mesmo que estamos falando de ver o ágil usado na raiva de várias maneiras. Embora isso tenha conotações negativas; Eu quis dizer isso de uma maneira positiva. Você poderia nos dar um cenário de, quero dizer, há dois lugares em que posso ver esse cenário perfeito: um são novos projetos que precisam ser realizados desde o primeiro dia, mas acho que, invariavelmente, na minha experiência, geralmente é o caso em que, quando os projetos são grandes o suficiente para que isso seja necessário de várias maneiras, há um desafio interessante entre colar os dois mundos, certo? Você pode nos dar algum tipo de insight sobre algumas histórias de sucesso que você viu onde ingressou em uma organização, ficou claro que elas têm um ligeiro choque entre os dois mundos e você conseguiu colocar com sucesso isso no lugar e reunir grandes projetos onde eles poderiam ter ido nos trilhos? Sei que é uma pergunta muito ampla, mas estou me perguntando se há um estudo de caso específico que você pode apontar para onde você disse que colocamos tudo no lugar e reuniu toda a equipe de desenvolvimento com a equipe de dados e, de certa forma, abordamos algo que poderia ter afundado o barco?
Ron Huizenga: Claro, e de fato o único projeto que passou a ser um pipeline foi o que eu aludei, onde mostrei esse gráfico com os defeitos antes e depois do envolvimento do modelador de dados. Muitas vezes, e existem noções preconcebidas, principalmente se tudo é feito de uma perspectiva puramente de desenvolvimento, são apenas os desenvolvedores envolvidos nesses projetos ágeis para entregar os aplicativos. Então, o que aconteceu lá, é claro, é que eles saíram dos trilhos e seus artefatos de dados em particular, ou os entregáveis de dados que estavam produzindo, ficaram aquém da marca em termos de qualidade e realmente abordaram as coisas em geral. E muitas vezes há um equívoco de que os modeladores de dados atrasarão os projetos, e o farão se o modelador de dados não tiver a atitude correta. Como eu disse, você precisa perder a - às vezes existem modeladores de dados que têm essa atitude tradicional de gatekeeper em que "estamos aqui para controlar como são as estruturas de dados" e essa mentalidade precisa desaparecer. Qualquer pessoa envolvida no desenvolvimento ágil, e particularmente os modeladores de dados, deve assumir o papel de facilitadora para realmente ajudar as equipes a avançar. E a melhor maneira de ilustrar isso é mostrar rapidamente às equipes o quão produtivas elas podem ser modelando as mudanças primeiro. E, novamente, foi por isso que falei sobre a colaboração.
Há algumas coisas que podemos modelar primeiro e gerar o DDL para enviar aos desenvolvedores. Também queremos garantir que eles não sintam que estão sendo restringidos. Portanto, se há coisas nas quais eles estão trabalhando, deixe-os continuar trabalhando em suas caixas de proteção de desenvolvimento, porque é aí que os desenvolvedores estão trabalhando em seus próprios desktops ou outros bancos de dados para fazer algumas alterações nos testes. E colabore com eles e diga: "Ok, trabalhe com isso". Vamos trazê-lo para a ferramenta, resolvê-lo e, em seguida, avançamos e fornecemos os scripts que você pode implantar para atualizar seu bancos de dados para atualizá-los para qual será a verdadeira visão de produção sancionada, à medida que continuarmos avançando. E você pode mudar isso de uma maneira muito rápida. Eu descobri que meus dias estavam preenchidos, onde eu estava indo e voltando iterando com diferentes equipes de desenvolvimento, olhando para mudanças, comparando, gerando scripts, fazendo com que eles continuassem, e eu consegui me manter com quatro equipes de desenvolvimento com bastante facilidade quando alcançou um momento.
Dez Blanchfield: Uma das coisas que me vem à mente é que, muitas das conversas que tenho diariamente, são sobre esse trem de carga que chega até nós da espécie de máquina para -máquina e IoT. E se achamos que temos muitos dados agora em nossos ambientes atuais na empresa, se afastarmos os unicórnios por um momento em que sabemos que os Googles, os Facebooks e os Ubers têm petabytes de dados, mas em uma empresa tradicional, estamos falando de centenas de terabytes e muitos dados. Mas há esse trem de carga chegando às organizações, na minha opinião, e o Dr. Robin Bloor fez alusão a ele mais cedo, da IoT. Você sabe, temos muito tráfego na Web, temos tráfego social, agora temos mobilidade e dispositivos móveis, a nuvem meio que explodiu, mas agora temos infraestrutura inteligente, cidades inteligentes e há todo esse mundo de dados que explodiu.
Para uma organização cotidiana, uma organização de médio a grande porte que está sentada lá e vendo esse mundo de dor chega até eles e não tem um plano imediato em mente, quais são algumas das sugestões, em apenas algumas frases, que você colocaria para eles sobre quando e onde precisam começar a pensar em conversação sobre a implementação de algumas dessas metodologias. Com que antecedência eles precisam começar a planejar quase sentar e prestar atenção e dizer que este é o momento certo para instalar algumas ferramentas, treinar a equipe e conversar com vocabulário sobre esse desafio? Quão tarde na história é tarde demais ou quando é cedo demais? Como é isso para algumas das organizações que você está vendo?
Ron Huizenga: Eu diria para a maioria das organizações que, se ainda não o fizeram e adaptaram a modelagem e a arquitetura de dados com ferramentas poderosas como essa, o tempo necessário para fazê-lo é ontem. Como é interessante que, ainda hoje, quando você analisa dados em organizações, temos muitos dados em nossas organizações e, de um modo geral, com base em algumas pesquisas que vimos, estamos usando menos de cinco por cento desses dados com eficiência quando analisamos as organizações. E com a IoT ou mesmo NoSQL, big data - mesmo que não seja apenas IoT, mas apenas big data em geral - onde agora estamos começando a consumir ainda mais informações originárias de fora de nossas organizações, esse desafio está se tornando cada vez maior. o tempo todo. E a única maneira de conseguirmos resolver isso é nos ajudar a entender do que se trata esses dados.
Portanto, o caso de uso é um pouco diferente. O que nos encontramos fazendo é quando olhamos para esses dados, estamos capturando, precisamos fazer engenharia reversa, ver o que há neles, seja em nossos lagos de dados ou mesmo em nossos bancos de dados internos, sintetizando o que os dados são, aplique significados a ele e definições a ele para que possamos entender o que são os dados. Porque até entendermos o que é, não podemos garantir que o estamos usando correta ou adequadamente. Então, realmente precisamos entender o que são esses dados. E a outra parte disso é, não faça isso porque, em termos de consumo de todos esses dados externos, você pode ter um caso de uso que suporte o consumo desses dados externos. Concentre-se nas coisas que você precisa, em vez de apenas tentar puxar e utilizar as coisas que você pode precisar mais tarde. Concentre-se nas coisas importantes primeiro e, à medida que for avançando, você começará a consumir e a tentar entender as outras informações de fora.
Um exemplo perfeito disso é que eu sei que estamos falando de IoT e sensores, mas o mesmo tipo de problema já existe em muitas organizações há muitos anos, mesmo antes da IoT. Qualquer pessoa que possua um sistema de controle de produção, seja uma empresa de dutos, manufatura, qualquer empresa baseada em processos que possua coisas em que está realizando muita automação com controles e que esteja usando fluxos de dados e coisas assim, essas explosões de dados que eles estão tentando descobrir, quais são os eventos que ocorreram no meu equipamento de produção para sinalizar - o que aconteceu e quando? E entre esse enorme fluxo de dados, existem apenas informações ou tags específicas nas quais eles estão interessados e precisam peneirar, sintetizar, modelar e entender. E eles podem ignorar o resto até chegar a hora de realmente entendê-lo e, em seguida, podem expandir seu escopo para atrair cada vez mais isso, se isso faz sentido.
Dez Blanchfield: É verdade. Há uma pergunta que vou abordar que veio de um cavalheiro chamado Eric, e conversamos sobre isso em particular. Acabei de pedir a permissão dele, que ele recebeu, para pedir a você. Porque isso leva muito bem a isso, apenas para encerrar, porque estamos passando um pouco do tempo agora, e vou devolver ao Eric. Mas a pergunta de outro Eric era: é razoável supor que os proprietários de uma startup estejam familiarizados e compreendam os desafios únicos em torno da terminologia de modelagem e assim, ou deveriam ser entregues a outra pessoa para interpretação? Então, em outras palavras, uma startup deve ser capaz, pronta, disposta e capaz de focar e cumprir isso? Ou é algo que eles provavelmente deveriam comprar e trazer especialistas a bordo?
Ron Huizenga: Eu acho que a resposta curta é que realmente depende. Se é uma startup que não possui alguém interno que seja um arquiteto ou modelador de dados que realmente entenda o banco de dados, a maneira mais rápida de começar é trazer alguém com experiência em consultoria que seja muito versado nesse espaço e possa obter eles indo. Porque o que você encontrará - e, de fato, eu fiz isso em muitos compromissos antes de chegar ao lado negro do gerenciamento de produtos - é que eu iria para as organizações como consultor, liderava as equipes de arquitetura de dados, para que eles pudessem, de alguma forma, se reorientar e treinar seu pessoal sobre como fazer esse tipo de coisa, de modo a sustentá-lo e levar a missão adiante. E então eu continuaria no meu próximo compromisso, se isso fizer sentido. Existem muitas pessoas por aí que fazem isso, que têm uma experiência de dados muito boa que pode levá-los a funcionar.
Dez Blanchfield: Esse é um ótimo argumento e eu concordo totalmente com isso, e tenho certeza que o Dr. Robin Bloor também o faria. Particularmente em uma startup, você está focado em ser uma PME com o valor específico da proposta que deseja construir como parte do próprio negócio de startups e provavelmente não precisa ser um especialista em tudo, um ótimo conselho. Mas muito obrigado, uma apresentação fantástica. Realmente ótimas respostas e perguntas. Eric, vou devolvê-lo porque sei que ficamos provavelmente dez minutos ao longo do tempo e sei que você gosta de ficar perto das janelas do tempo.
Eric Kavanagh: Tudo bem. Temos pelo menos algumas boas perguntas. Deixe-me jogar um para você. Eu acho que você respondeu algumas das outras. Mas uma observação e uma pergunta muito interessantes de um participante que escreve, às vezes projetos ágeis, fazem com que o modelador de dados não tenha toda a imagem a longo prazo e, por isso, eles acabam projetando algo no sprint um e depois reprojetando no sprint três ou quatro. Isso não parece contraproducente? Como você pode evitar esse tipo de coisa?
Ron Huizenga: É da natureza do ágil que você não vai conseguir tudo absolutamente certo em um determinado sprint. E isso na verdade faz parte do espírito do ágil é: trabalhe com ele - você fará protótipos onde estiver trabalhando no código em um determinado sprint e fará refinamentos. E uma parte desse processo é quando você entrega as coisas que o usuário final vê e diz: "Sim, está próximo, mas eu realmente preciso fazê-lo um pouco mais também". Portanto, isso não afeta apenas o design funcional do código em si, mas muitas vezes precisamos modificar ou adicionar mais estrutura de dados abaixo dessas coisas para fornecer o que o usuário deseja. E é tudo um jogo justo e é por isso que você realmente deseja usar as ferramentas de alta potência, porque é possível modelar muito rapidamente e fazer essa alteração em uma ferramenta de modelagem e, em seguida, gerar o DDL para o banco de dados no qual os desenvolvedores podem trabalhar para fornecer isso. mude ainda mais rapidamente. Você está evitando que eles tenham que fazer a codificação manual das estruturas de dados e permitindo que eles se concentrem na lógica de programação ou aplicativo em que eles são mais proficientes.
Eric Kavanagh: Isso faz todo sentido. Tínhamos outras pessoas fazendo perguntas específicas sobre como tudo isso se relaciona com a ferramenta. Sei que você passou algum tempo analisando exemplos e exibindo algumas capturas de tela sobre como realmente implementa algumas dessas coisas. Em termos de todo esse processo de sprint, com que frequência você vê isso nas organizações versus com que frequência vê processos mais tradicionais, onde as coisas apenas meio que avançam e levam mais tempo? Qual a predominância da abordagem no estilo sprint da sua perspectiva?
Ron Huizenga: Acho que estamos vendo cada vez mais. Eu sei que, eu diria, provavelmente nos últimos 15 anos em particular, eu vi muito mais a adoção de pessoas reconhecendo que elas realmente precisam adotar uma entrega mais rápida. Então, eu tenho visto mais e mais organizações pularem na onda ágil. Não necessariamente inteiramente; eles podem começar com alguns projetos-piloto para provar que funciona, mas há alguns que ainda são muito tradicionais e seguem o método da cascata. Agora, as boas notícias são, é claro, que as ferramentas funcionam muito bem nessas organizações e também para esse tipo de metodologias, mas temos a adaptabilidade da ferramenta para que aqueles que saltam a bordo tenham as ferramentas na caixa de ferramentas em as pontas dos dedos. Coisas como comparar e mesclar, coisas como os recursos de engenharia reversa, para que eles possam ver quais são as fontes de dados existentes, para que possam realmente comparar e gerar os scripts DDL incrementais rapidamente. E quando eles começam a adotar isso e vêem que podem ter a produtividade, sua inclinação para adotar o ágil aumenta ainda mais.
Eric Kavanagh: Bem, isso é ótimo, pessoal. Acabei de publicar um link para os slides na janela de bate-papo, então verifique isso; é um pouco de um Bitly lá para você. Temos todos esses webcasts para visualização posterior. Sinta-se livre para compartilhá-los com seus amigos e colegas. E Ron, muito obrigado pelo seu tempo hoje, é sempre agradável ter no programa - um verdadeiro especialista no campo e é óbvio que você conhece suas coisas. Então, obrigado a você e à IDERA e, é claro, a Dez e ao nosso próprio Robin Bloor.
E com isso vamos despedir vocês, pessoal. Mais uma vez obrigado pelo seu tempo e atenção. Agradecemos por ficar por 75 minutos, esse é um bom sinal. Bom show pessoal, falaremos com você na próxima vez. Tchau tchau.
