Por Techopedia Staff, 28 de setembro de 2016
Resumo : A anfitriã Rebecca Jozwiak discute as soluções de arquitetura de dados com Eric Little, da OSTHUS, Malcolm Chisholm, da First San Francisco Partners, e Ron Huizenga, da IDERA.
No momento, você não está logado. Faça o login ou inscreva-se para ver o vídeo.
Rebecca Jozwiak: Senhoras e Senhores Deputados, olá, e sejam bem-vindos às Hot Technologies de 2016. Hoje estamos discutindo "Construindo uma arquitetura de dados orientada a negócios", definitivamente um tópico importante. Meu nome é Rebecca Jozwiak, serei o anfitrião do webcast de hoje. Nós twittamos com uma hashtag # HotTech16, portanto, se você já está no Twitter, sinta-se à vontade para participar também. Se você tiver perguntas a qualquer momento, envie-as para o painel de perguntas e respostas na parte inferior direita da tela e garantiremos que sejam respondidas. Caso contrário, garantiremos que nossos convidados as recebam para você.
Hoje, temos uma programação realmente fascinante. Muitos rebatedores pesados estão conosco hoje. Temos Eric Little, vice-presidente de ciência de dados da OSTHUS. Temos Malcolm Chisholm, diretor de inovação, que é um título muito legal, para a First San Francisco Partners. E temos Ron Huizenga, gerente de produtos sênior da IDERA. E, você sabe, o IDERA tem um conjunto realmente completo de soluções de modelagem e gerenciamento de dados. E hoje ele vai nos dar uma demonstração sobre como sua solução funciona. Mas antes de chegarmos a isso, Eric Little, vou passar a bola para você.
Eric Little: Ok, muito obrigado. Então, vou abordar alguns tópicos aqui que acho que vão se relacionar um pouco com a palestra de Ron e, esperançosamente, preparar o cenário para alguns desses tópicos, algumas perguntas e respostas.
Então, o que me interessou com o que a IDERA está fazendo é que eu acho que eles apontam corretamente que ambientes complexos realmente estão gerando muitos valores de negócios hoje em dia. E por ambientes complexos queremos dizer ambientes de dados complexos. E a tecnologia está realmente se movendo rapidamente e é difícil acompanhar o ambiente de negócios atual. Portanto, as pessoas que trabalham em espaços de tecnologia frequentemente verão que você tem clientes com problemas com: “Como uso o big data? Como incorporar semântica? Como vinculo algumas dessas coisas novas aos meus dados mais antigos? ”E assim por diante, e isso meio que nos leva atualmente a esses quatro vs de big data com os quais muitas pessoas estão familiarizadas, e eu entendo que pode haver mais de quatro às vezes - eu já vi oito ou nove -, mas normalmente, quando as pessoas falam sobre coisas como big data ou se você está falando sobre big data, geralmente você está olhando para algo que é do tipo de escala corporativa. E assim as pessoas dirão, ok, bem, pense no volume de seus dados, que normalmente é o foco - é o quanto você tem. A velocidade dos dados tem a ver com a rapidez com que posso movê-los ou com a rapidez com que posso consultá-los ou obter as respostas, e assim por diante. E, pessoalmente, acho que o lado esquerdo disso está sendo resolvido e tratado de forma relativamente rápida por várias abordagens diferentes. No lado direito, porém, vejo muita capacidade de aprimoramento e muitas novas tecnologias que realmente estão surgindo em primeiro plano. E isso realmente tem a ver com a terceira coluna, a variedade de dados.
Portanto, em outras palavras, a maioria das empresas hoje em dia está analisando dados estruturados, semiestruturados e não estruturados. Os dados da imagem estão começando a se tornar um tópico importante; portanto, é possível usar a visão computacional, observar pixels, raspar texto, PNL, extração de entidades e obter informações gráficas que saem dos modelos estatísticos ou da semântica. modelos, você tem dados relacionais existentes em tabelas e assim por diante. Portanto, reunir todos esses dados e todos esses tipos diferentes realmente representa um grande desafio e você verá isso no Gartner e em outras pessoas que estão seguindo as tendências do setor.
E a última coisa que as pessoas falam em big data é frequentemente essa noção de voracidade, que é realmente a incerteza dos seus dados, a imprecisão deles. Quão bem você sabe sobre o que são seus dados, como você entende o que há lá e, você sabe? A capacidade de usar estatísticas e a capacidade de usar algum tipo de informação em torno do que você pode saber ou usar em algum contexto, pode ser útil. E, assim, a capacidade de analisar os dados dessa maneira em termos de quanto você tem, a rapidez com que precisa movê-los ou alcançá-los, todos os tipos de dados que você pode ter em sua empresa e a certeza de que está onde é, qual é, qual é a qualidade e assim por diante. Isso realmente exige um grande esforço coordenado agora entre muitas pessoas para gerenciar seus dados com eficiência. A modelagem de dados, portanto, é cada vez mais importante no mundo de hoje. Portanto, bons modelos de dados estão realmente gerando muito sucesso em aplicativos corporativos.
Você tem fontes de dados de várias fontes, como estávamos dizendo, o que realmente requer muitos tipos diferentes de integração. Portanto, reunir tudo isso é realmente útil para poder executar consultas, por exemplo, em vários tipos de fontes de dados e recuperar informações. Mas para fazer isso, você precisa de boas estratégias de mapeamento e, portanto, mapear esses tipos de dados e acompanhar esses mapeamentos pode ser um desafio real. E então você tem esse problema: como vincular meus dados herdados a todas essas novas fontes de dados? Então, suponha que eu tenha gráfico, pego todos os meus dados relacionais e os coloco em gráfico? Geralmente isso não é uma boa ideia. Então, como é que as pessoas conseguem gerenciar todos esses tipos de modelos de dados em andamento? A análise realmente precisa ser executada em vários tipos diferentes de fontes e combinações de dados. Portanto, as respostas que surgem disso, as respostas que as pessoas precisam para realmente tomar boas decisões de negócios são críticas.
Portanto, não se trata apenas de construir tecnologia para o bem da tecnologia, é realmente o que vou fazer, o que posso fazer com ela, que tipo de análise posso executar e a capacidade, portanto, como já fiz. estive falando, juntar essas coisas, integrá-las é muito, muito importante. E um desses tipos de análise é executado em coisas como pesquisa e consulta federada. Isso está realmente se tornando uma obrigação. Suas consultas normalmente precisam ser encadeadas em vários tipos de fontes e extrair informações de forma confiável.
O único elemento-chave que frequentemente, especialmente as pessoas, analisam coisas importantes como tecnologias semânticas - e isso é algo que eu espero que Ron fale um pouco sobre a abordagem IDERA - é como você separa ou gerencia o camada de modelo dos seus dados a partir da própria camada de dados, a partir desses dados brutos? Então, na camada de dados, você pode ter bancos de dados, dados de documentos, dados de planilhas, dados de imagem. Se você estiver em áreas como as indústrias farmacêuticas, terá grandes quantidades de dados científicos. E, além disso, as pessoas normalmente procuram uma maneira de criar um modelo que permita integrar rapidamente esses dados e, na verdade, quando você está procurando dados, agora não está procurando atrair todos os dados para a camada de modelo, o que você está procurando na camada de modelo é fornecer uma boa representação lógica do que são as coisas, vocabulários comuns, tipos comuns de entidades e relacionamentos e a capacidade de realmente acessar os dados onde estão. Então, tem que dizer o que é, e tem que dizer onde está, e tem que dizer como buscá-lo e trazê-lo de volta.
Portanto, essa tem sido uma abordagem bem-sucedida em impulsionar as tecnologias semânticas, que é uma área em que trabalho muito. Então, uma pergunta que eu queria fazer para Ron, e que acho que será útil na seção de perguntas e respostas, é ver como isso é realizado pela plataforma IDERA? Então, a camada do modelo é realmente separada da camada de dados? Eles são mais integrados? Como isso funciona e quais são alguns dos resultados e benefícios que eles estão vendo de sua abordagem? Portanto, os dados de referência também estão se tornando críticos. Portanto, se você tiver esses tipos de modelos de dados, se conseguir federar e pesquisar entre outras coisas, precisará realmente ter bons dados de referência. Mas o problema é que os dados de referência podem ser realmente difíceis de manter. Muitas vezes, nomear padrões por si só é um desafio difícil. Um grupo chamará algo de X e um grupo chamará de Y e agora você tem o problema de como alguém encontra X e Y quando procura esse tipo de informação? Como você não deseja fornecer apenas uma parte dos dados, você deseja fornecer tudo relacionado a eles. Ao mesmo tempo em que os termos mudam, o software fica obsoleto e assim por diante, como você mantém e mantém esses dados de referência ao longo do tempo?
E, novamente, as tecnologias semânticas, especificamente usando coisas como taxonomias e vocabulários, dicionários de dados, forneceram uma maneira padrão de fazer isso, que é realmente altamente robusta, utiliza certos tipos de padrões, mas a comunidade de bancos de dados fez isso por um longo período. muito tempo também, apenas de maneiras diferentes. Acho que uma das chaves aqui é pensar em como usar talvez modelos de relação de entidade, como usar talvez modelos de gráfico ou algum tipo de abordagem aqui que realmente dará a você uma maneira espaçada padrão de lidar com seus dados de referência. E, é claro, depois de obter os dados de referência, as estratégias de mapeamento precisam gerenciar uma grande variedade de nomes e entidades. Portanto, especialistas no assunto geralmente gostam de usar seus próprios termos.
Portanto, um desafio é sempre: como você fornece informações a alguém, mas as torna relevantes para a maneira como elas falam sobre isso? Portanto, um grupo pode ter uma maneira de ver alguma coisa, por exemplo, você pode ser um químico trabalhando em um medicamento e um biólogo estrutural trabalhando no mesmo medicamento, e você pode ter nomes diferentes para os mesmos tipos de entidades que se relacionam com o seu campo. Você precisa descobrir maneiras de reunir essas terminologias personalizadas, porque a outra abordagem é forçar as pessoas a abandonar seu mandato e usar o de outra pessoa, da qual geralmente não gostam. Outro ponto aqui é que lidar com um grande número de sinônimos fica difícil; portanto, existem muitas palavras diferentes nos dados de muitas pessoas que podem se referir à mesma coisa. Você tem um problema de referência usando um conjunto de relações muitos-para-um. Os termos especializados variam de setor para setor; portanto, se você tiver uma solução abrangente para esse tipo de gerenciamento de dados, com que facilidade é portátil de um projeto ou de um aplicativo para outro? Esse pode ser outro desafio.
A automação é importante e também é um desafio. É caro manipular manualmente os dados de referência. É caro ter que continuar mapeando manualmente e é caro ter especialistas no assunto para de fazer seus trabalhos do dia-a-dia e precisa entrar e consertar constantemente dicionários de dados e atualizar definições novamente e assim por diante. Vocabulários replicáveis realmente mostram muito valor. Portanto, esses são os vocabulários que você pode achar externos à sua organização. Se você trabalha com petróleo bruto, por exemplo, haverá certos tipos de vocabulários que você pode emprestar de espaços de código aberto, o mesmo com produtos farmacêuticos, o mesmo com o setor bancário e financeiro, o mesmo com muitos desses tipos de áreas. As pessoas estão lançando vocabulários reutilizáveis, genéricos e replicáveis para as pessoas usarem.
E, novamente, olhando para a ferramenta IDERA, estou curioso para ver como eles estão lidando com isso em termos de uso de tipos de padrões. No mundo da semântica, você costuma ver coisas como os modelos SKOS que fornecem padrões pelo menos mais amplos que / mais estreitos que os relacionamentos e essas coisas podem ser difíceis de fazer nos modelos de ER, mas você sabe, não é impossível, depende apenas de quanto disso máquinas e links que você pode manipular nesses tipos de sistemas.
Por fim, eu só queria fazer uma comparação com alguns mecanismos semânticos que vejo na indústria, e pedir a Ron e falar um pouco com ele para falar sobre talvez como o sistema do IDERA foi usado em conjunto com qualquer tecnologia semântica. É capaz de ser integrado a lojas triplas, bancos de dados de gráficos? Quão fácil é usar fontes externas, porque esses tipos de coisas no mundo semântico geralmente podem ser emprestados usando os pontos de extremidade do SPARQL? Você pode importar modelos RDF ou OWL diretamente para o seu modelo - consulte-os - para, por exemplo, a ontologia de genes ou a ontologia de proteínas, que podem viver em algum lugar do seu próprio espaço com sua própria estrutura de governança e eu posso simplesmente importar todos ou parte disso como eu preciso nos meus próprios modelos. E estou curioso para saber como o IDERA aborda esse problema. Você precisa manter tudo internamente ou existem maneiras de usar outros tipos de modelos padronizados e inseri-los e como isso funciona? E a última coisa que mencionei aqui é quanto trabalho manual está realmente envolvido para criar os glossários e os repositórios de metadados?
Então eu sei que Ron vai nos mostrar algumas demos sobre esse tipo de coisa que será realmente interessante. Mas os problemas que costumo ver consultando os clientes é que muitos erros ocorrem se as pessoas escrevem em suas próprias definições ou em seus próprios metadados. Então você recebe erros de ortografia, erros de dedos grossos, isso é uma coisa. Você também recebe pessoas que podem tirar algo de, você sabe, apenas a Wikipedia ou uma fonte que não seja necessariamente da qualidade que você pode querer em sua definição, ou sua definição é apenas da perspectiva de uma pessoa, por isso não está completa e não está claro como o processo de governança funciona. Governança, é claro, ser um problema muito, muito grande sempre que você estiver falando sobre dados de referência e sempre que estiver falando sobre como isso pode se encaixar nos dados mestre de alguém, como eles usarão seus metadados e em breve.
Então, eu só queria colocar alguns desses tópicos por aí. Esses são os itens que vejo no espaço comercial em vários tipos diferentes de compromissos de consultoria e em muitos espaços diferentes, e estou realmente interessado em ver o que Ron nos mostrará com a IDERA para apontar alguns desses tópicos. . Então, muito obrigado.
Rebecca Jozwiak: Muito obrigado, Eric, e eu realmente gosto do seu comentário, pois muitos erros podem ocorrer se as pessoas estiverem escrevendo suas próprias definições ou metadados. Eu sei que no mundo do jornalismo há um mantra que “muitos olhos cometem poucos erros”, mas quando se trata de aplicações práticas, muitas mãos no pote de biscoitos tendem a deixá-lo com muitos biscoitos quebrados, certo?
Eric Little: Sim, e germes.
Rebecca Jozwiak: Sim. Com isso, vou em frente e passar para Malcolm Chisholm. Malcolm, o chão é seu.
Malcolm Chisholm: Muito obrigado, Rebecca. Eu gostaria de olhar um pouco sobre o que Eric está falando e adicionar algumas observações que, você sabe, Ron pode querer responder também, falando sobre “Rumo à arquitetura de dados orientada a negócios ”- o que significa ser direcionado aos negócios e por que isso é importante? Ou é apenas alguma forma de hype? Eu não acho que é.
Se olharmos para o que está acontecendo desde então, você sabe, os computadores mainframe realmente se tornaram disponíveis para as empresas - digamos, por volta de 1964 - até hoje, podemos ver que houve muitas mudanças. E essas mudanças eu resumiria como sendo uma mudança da centralidade do processo para a centralizada em dados. E é isso que torna as arquiteturas de dados direcionadas aos negócios tão importantes e relevantes para hoje. E eu acho que você sabe, não é apenas uma palavra da moda, é algo absolutamente real.
Mas podemos apreciá-lo um pouco mais se mergulharmos na história, voltando no tempo, desde os anos 1960 e, durante algum tempo, os mainframes dominaram. Eles deram lugar aos PCs onde você realmente se rebelou quando os PCs chegaram. A rebelião contra a TI centralizada, que eles pensavam não estar atendendo às suas necessidades, não era suficientemente ágil. Isso rapidamente deu origem à computação distribuída, quando os PCs foram conectados. E então a internet começou a acontecer, o que obscureceu os limites da empresa - ela agora podia interagir com partes externas a ela em termos de troca de dados, o que não havia acontecido antes. E agora entramos na era da nuvem e big data, onde a nuvem é plataformas que realmente estão comoditizando infraestrutura e, portanto, estamos deixando, por assim dizer, a TI da necessidade de executar grandes centros de dados, porque, você sabe, nós temos a capacidade de nuvem disponível para nós e concomitantemente com o big data que Eric discutiu com tanta eloquência. No geral, como vemos, à medida que a mudança na tecnologia ocorreu, ela se tornou mais centrada em dados, nos preocupamos mais com os dados. Como na internet, como os dados estão sendo trocados. Com big data, os quatro ou mais vs dos dados em si.
Ao mesmo tempo, e talvez mais importante, os casos de uso de negócios mudaram. Quando os computadores foram introduzidos pela primeira vez, eles foram usados para automatizar coisas como livros e registros. E qualquer coisa que fosse um processo manual, que envolvesse livros ou coisas assim, era programada, essencialmente, internamente. Isso mudou nos anos 80 para a disponibilidade de pacotes operacionais. Você não precisava mais escrever sua própria folha de pagamento, poderia comprar algo que fizesse isso. Isso resultou em um grande downsizing na época, ou reestruturação, em muitos departamentos de TI. Mas então a inteligência de negócios, com coisas como data warehouses, apareceu principalmente nos anos 90. Seguido por modelos de negócios pontocom, que foram, obviamente, um grande frenesi. Então MDM. Com o MDM, você começa a perceber que não estamos pensando em automação; na verdade, estamos apenas focando na curadoria de dados como dados. E, em seguida, análises, representando o valor que você pode obter dos dados. E na análise, você vê empresas com muito sucesso cujo modelo de negócios principal gira em torno de dados. Google, Twitter e Facebook seriam parte disso, mas você também pode argumentar que o Walmart é.
E agora os negócios estão realmente pensando em dados. Como podemos obter valor dos dados? Como os dados podem impulsionar os negócios, a estratégia e estamos na era de ouro dos dados. Portanto, o que está acontecendo em termos de nossa arquitetura de dados, se os dados não forem mais considerados simplesmente o escapamento que sai do back-end dos aplicativos, mas são realmente essenciais para nossos modelos de negócios? Bem, parte do problema que temos para alcançar a TI é realmente travada no passado com o ciclo de vida de desenvolvimento de sistemas, que foi uma conseqüência de ter que lidar rapidamente com essa fase de automação de processo na tenra idade da TI e trabalhar em projetos é uma coisa semelhante. Para a TI - e isso é um pouco de caricatura -, mas o que estou tentando dizer é que algumas das barreiras para obter uma arquitetura de dados direcionada aos negócios são porque aceitamos, de forma acrítica, uma cultura em TI que deriva de uma época passada.
Então, tudo é um projeto. Diga-me suas necessidades em detalhes. Se as coisas não funcionam, é porque você não me disse quais são seus requisitos. Bem, isso não funciona hoje com dados, porque não estamos começando com processos manuais não automatizados ou, você sabe, uma conversão técnica de processos de negócios, estamos começando frequentemente com dados de produção já existentes que estamos tentando para obter valor. Mas ninguém que está patrocinando um projeto centrado em dados realmente entende esses dados em profundidade. Temos que fazer descoberta de dados, temos que fazer análise de dados de origem. E isso realmente não combina com o desenvolvimento dos sistemas, você sabe - cascata, ciclo de vida do SDLC - do qual o Agile, eu manteria, é uma espécie de versão melhor disso.
E o que está sendo focado é tecnologia e funcionalidade, não dados. Por exemplo, quando fazemos testes em uma fase de testes, normalmente, minha funcionalidade funciona, digamos, meu ETL, mas não estamos testando os dados. Não estamos testando nossas suposições sobre a entrada de dados de origem. Se o fizéssemos, estaríamos talvez em melhor forma e, como alguém que fez projetos de data warehouse e sofreu com as alterações upstream, impedindo meus ETLs, eu apreciaria isso. De fato, o que queremos ver é o teste como uma etapa preliminar do monitoramento contínuo da qualidade dos dados de produção. Portanto, temos aqui muitas atitudes em que é difícil alcançar a arquitetura de dados orientada aos negócios, porque estamos condicionados à era da centralização no processo. Precisamos fazer uma transição para a centralização de dados. E essa não é uma transição total, sabe, ainda há muito trabalho de processo a ser feito por aí, mas não estamos realmente pensando em termos centrados em dados quando precisamos, e nas circunstâncias que ocorrem quando estamos realmente obrigado a fazer isso.
Agora que a empresa percebe o valor dos dados, eles querem desbloqueá-los. Então, como vamos fazer isso? Então, como fazemos a transição? Bem, colocamos os dados no centro dos processos de desenvolvimento. E deixamos a empresa liderar com requisitos de informação. E entendemos que ninguém entende os dados de origem existentes no início do projeto. Você poderia argumentar que a estrutura de dados e os próprios dados chegaram lá por meio de TI e operações, respectivamente; portanto, devemos saber isso, mas realmente não. Este é um desenvolvimento centrado em dados. Portanto, ao pensar sobre onde e como fazemos a modelagem de dados em um mundo centrado em dados, precisamos fazer loops de feedback para os usuários em termos de refino de seus requisitos de informações, assim como a descoberta de dados e a criação de perfil de dados., prevê a análise de dados de origem e, à medida que gradualmente obtemos mais e mais certeza sobre nossos dados. E agora estou falando de um projeto mais tradicional, como um hub MDM ou um data warehouse, não necessariamente os projetos de big data, embora, ainda assim, eu ainda esteja bem próximo disso. E assim, esses ciclos de feedback incluem os modeladores de dados, você sabe, avançando gradualmente seu modelo de dados e interagindo com os usuários para garantir que os requisitos de informações sejam refinados com base no que é possível, no que está disponível, a partir dos dados de origem, como eles o entendem melhor, então não é mais um caso do modelo de dados estar, você sabe, em um estado que não existe ou está completo, é uma gradual inserção no foco dele.
Da mesma forma, mais a jusante disso, temos garantia de qualidade, onde desenvolvemos regras para o teste de qualidade dos dados para garantir que os dados estejam dentro dos parâmetros sobre os quais estamos fazendo suposições. Ao entrar, Eric estava se referindo a alterações nos dados de referência, que podem acontecer. Você não quer ser uma vítima a jusante de uma espécie de mudança não gerenciada nessa área, para que as regras de garantia de qualidade possam entrar no monitoramento contínuo da qualidade dos dados após a produção. Portanto, você pode começar a ver se vamos focar em dados, como o desenvolvimento centrado em dados é bem diferente do SDLC e do Agile, baseados em funcionalidade. E então temos que prestar atenção às visões de negócios também. Temos - e novamente isso ecoa o que Eric estava dizendo - temos um modelo de dados que define um plano de história de dados para nosso banco de dados, mas, ao mesmo tempo, precisamos desses modelos conceituais, daquelas visões de negócios de dados que tradicionalmente não eram feitas em o passado. Às vezes, penso, pensamos que o modelo de dados pode fazer tudo, mas precisamos ter a visão conceitual, a semântica e analisar os dados, renderizá-los através de uma camada de abstração que traduz o modelo de armazenamento nos negócios Visão. E, novamente, todas as coisas sobre as quais Eric estava falando em termos de semântica tornam-se importantes, portanto, na verdade, temos tarefas de modelagem adicionais. Eu acho que isso é interessante se você aparecer como um modelador de dados como eu, e novamente algo novo.
E, finalmente, gostaria de dizer que a arquitetura maior também deve refletir essa nova realidade. O MDM tradicional do cliente, por exemplo, é tipo, ok, vamos colocar os dados de nossos clientes em um hub onde podemos, você sabe, entender isso em termos de qualidade de dados realmente apenas para aplicativos de back office. Que, do ponto de vista da estratégia de negócios, é uma espécie de bocejo. Hoje, no entanto, estamos analisando os hubs do MDM do cliente que contêm dados adicionais do perfil do cliente, não apenas os dados estáticos, que na verdade têm uma interface bidirecional com os aplicativos de transação do cliente. Sim, eles ainda oferecem suporte ao back office, mas agora também sabemos sobre esses comportamentos de nossos clientes. Isso é mais caro de construir. Isso é mais complexo de construir. Mas é direcionado aos negócios de uma maneira que o cliente tradicional MDM não é. Você está trocando uma orientação para os negócios contra projetos mais simples, mais fáceis de implementar, mas para os negócios, é isso que eles querem ver. Estamos realmente em uma nova era e acho que temos vários níveis para responder à arquitetura de dados que impulsiona os negócios e acho que é um momento muito emocionante para fazer as coisas.
Então, obrigado, de volta para você Rebecca.
Rebecca Jozwiak: Obrigado Malcolm, e eu realmente gostei do que você disse sobre modelos de dados deve alimentar a visão de negócios, porque, ao contrário do que você estava dizendo, onde a TI mantinha as rédeas por tanto tempo e não é mais esse o caso, que a cultura precisa mudar. E tenho certeza de que havia um cachorro em segundo plano que concordou com você 100%. E com isso eu vou passar a bola para Ron. Estou muito animado para ver sua demonstração. Ron, o chão é seu.
Ron Huizenga: Muito obrigado e, antes de entrarmos nisso, analisarei alguns slides e, em seguida, um pouco de demonstração, porque, como Eric e Malcolm apontaram, este é um tópico muito amplo e profundo, e com o que estamos falando hoje, estamos apenas raspando a superfície, porque há muitos aspectos e tantas coisas que realmente precisamos considerar e observar a partir de uma arquitetura orientada a negócios. E nossa abordagem é realmente tornar esse modelo baseado em modelos e obter verdadeiro valor dos modelos, porque você pode usá-los como um veículo de comunicação e também como uma camada para habilitar outros sistemas. Esteja você fazendo arquitetura orientada a serviços ou outras coisas, o modelo realmente se torna a força vital do que está acontecendo, com todos os metadados ao seu redor e os dados que você tem nos seus negócios.
O que eu quero falar, no entanto, está quase dando um passo atrás, porque Malcolm havia abordado um pouco da história de como as soluções evoluíram e esse tipo de coisa. Uma maneira de realmente destacar o quão importante é ter uma arquitetura de dados sólida é um caso de uso que eu costumava encontrar com muita frequência quando fazia consultoria antes de assumir uma função de gerenciamento de produtos, ou seja, entrava nas organizações se eles estavam fazendo transformação nos negócios ou apenas substituindo alguns sistemas existentes e esse tipo de coisa, e ficou evidente rapidamente como as organizações mal entendem seus próprios dados. Se você usar um caso de uso específico como este, seja um consultor entrando ou talvez seja uma pessoa que acabou de começar uma organização ou sua organização tenha sido criada ao longo dos anos com a aquisição de empresas diferentes, o que você acaba O ambiente é muito complexo, muito rapidamente, com diversas novas tecnologias, além de tecnologias herdadas, soluções de ERP e tudo mais.
Então, uma das coisas que realmente podemos fazer com a nossa abordagem de modelagem é responder à pergunta de como faço para entender tudo isso? Podemos realmente começar a reunir as informações, para que a empresa possa aproveitar as informações que temos adequadamente. E acontece, o que é que temos lá fora nesses ambientes? Como posso usar os modelos para extrair as informações necessárias e entendê-las melhor? E então temos os tipos tradicionais de metadados para todas as coisas diferentes, como os modelos de dados relacionais, e estamos acostumados a ver coisas como definições e dicionários de dados, você sabe, tipos de dados e esse tipo de coisa. Mas e os metadados adicionais que você deseja capturar para realmente dar ainda mais significado a eles? Por exemplo, quais entidades são realmente as candidatas que devem ser objetos de dados de referência, quais devem ser objetos de gerenciamento de dados mestre e esses tipos de coisas e amarrá-los. E como as informações fluem pela organização? Os dados fluem de como são consumidos, tanto do ponto de vista do processo, como também da linhagem de dados em termos da jornada de informações por meio de nossos negócios e de como ela percorre os diferentes sistemas ou os armazenamentos de dados. quando estamos construindo as soluções I, ou esses tipos de coisas, estamos consumindo as informações corretas para a tarefa em questão.
E, o que é mais importante, como podemos colaborar com todas essas partes interessadas, e principalmente as partes interessadas nos negócios, porque são elas que nos dão o verdadeiro significado do que são esses dados. A empresa, no final do dia, possui os dados. Eles fornecem as definições para os vocabulários e coisas sobre as quais Eric estava falando, então precisamos de um lugar para amarrar tudo isso. E a maneira como fazemos isso é através de nossas arquiteturas de modelagem e repositório de dados.
Vou tocar em algumas coisas. Vou falar sobre o ER / Studio Enterprise Team Edition. Principalmente, eu vou falar sobre o produto de arquitetura de dados em que fazemos a modelagem de dados e esse tipo de coisa, mas há muitos outros componentes do conjunto que abordarei brevemente. Você verá um trecho do arquiteto de negócios, no qual podemos fazer modelos conceituais, mas também podemos fazer modelos de processos de negócios e podemos amarrá-los para vincular os dados reais que temos em nossos modelos de dados. Isso realmente nos ajuda a juntar esse laço. O arquiteto de software nos permite fazer construções adicionais, como modelagem UML e esses tipos de coisas, para fornecer lógicas de suporte a alguns desses outros sistemas e processos dos quais estamos falando. Mas, muito importante, à medida que avançamos, temos o repositório e o servidor da equipe, e vou falar sobre isso como duas metades da mesma coisa. O repositório é onde armazenamos todos os metadados modelados, bem como todos os metadados de negócios em termos de glossários e termos de negócios. E como temos esse ambiente baseado em repositório, podemos juntar todas essas coisas diferentes no mesmo ambiente e, na verdade, podemos disponibilizá-las para consumo, não apenas para o pessoal técnico, mas também para os empresários. E é assim que realmente começamos a impulsionar a colaboração.
E a última parte sobre a qual falarei brevemente é que, quando você entra nesses ambientes, não são apenas os bancos de dados que você tem por aí. Você terá vários bancos de dados, armazenamentos de dados, e também muitos, o que eu chamaria de artefatos herdados. Talvez as pessoas tenham usado o Visio ou outros diagramas para mapear algumas coisas. Talvez eles tenham outras ferramentas de modelagem e esse tipo de coisa. Portanto, o que podemos fazer com o MetaWizard é realmente extrair algumas dessas informações e trazê-las para nossos modelos, atualizá-las e poder usá-las, consumi-las da forma atual novamente, em vez de apenas deixá-las lá fora. Torna-se agora uma parte ativa de nossos modelos de trabalho, o que é muito importante.
Quando você entra em uma organização, como eu disse, existem muitos sistemas diferentes, muitas soluções de ERP, soluções departamentais incompatíveis. Muitas organizações também estão usando soluções SaaS, que também são controladas e gerenciadas externamente; portanto, não controlamos os bancos de dados e esses tipos de coisas nos hosts, mas ainda precisamos saber como são esses dados e, é claro, os metadados em torno disso. O que também descobrimos são muitos sistemas legados obsoletos que não foram limpos por causa da abordagem baseada em projetos sobre a qual Malcolm falou. É incrível como nos últimos anos as organizações ativam projetos, substituem um sistema ou uma solução, mas muitas vezes não há orçamento suficiente para descomissionar as soluções obsoletas, então agora elas estão apenas no caminho. E temos que descobrir do que realmente podemos nos livrar em nosso ambiente, bem como o que é útil daqui para frente. E isso está vinculado à fraca estratégia de descomissionamento. Isso faz parte da mesma coisa.
O que também descobrimos, porque muitas organizações foram criadas com todas essas soluções diferentes, é que vemos muitas interfaces ponto a ponto com muitos dados circulando em vários lugares. Precisamos ser capazes de racionalizar isso e descobrir a linhagem de dados que mencionei brevemente antes, para que possamos ter uma estratégia mais coesa, como utilização da arquitetura orientada a serviços, barramentos de serviço corporativos e esses tipos de coisas, para fornecer as informações corretas. a um tipo de modelo de publicação e assinatura que usamos corretamente em toda a empresa. E então, é claro, ainda precisamos fazer algum tipo de análise, seja usando data warehouses, data marts com ETL tradicional ou usando alguns dos novos lagos de dados. Tudo se resume à mesma coisa. São todos os dados, sejam big data, sejam dados tradicionais em bancos de dados relacionais, precisamos reunir todos esses dados para que possamos gerenciá-los e saber com o que estamos lidando em nossos modelos.
Novamente, a complexidade que faremos é que temos várias etapas que queremos poder executar. Primeiro de tudo, você entra e pode não ter essas plantas da aparência desse cenário de informações. Em uma ferramenta de modelagem de dados como o ER / Studio Data Architect, você primeiro fará muita engenharia reversa em termos de apontar para as fontes de dados existentes, trazê-las para dentro e, em seguida, juntá-las em mais representativas modelos que representam todo o negócio. O importante é que queremos ser capazes de decompor esses modelos também ao longo das linhas de negócios, para que possamos nos relacionar com eles em partes menores, com as quais nossos funcionários também podem se relacionar e com nossos analistas de negócios e outras partes interessadas que estão trabalhando. nele.
Os padrões de nomeação são extremamente importantes e eu estou falando sobre isso de várias maneiras aqui. Nomear padrões em termos de como nomeamos as coisas em nossos modelos. É bastante fácil de fazer em modelos lógicos, onde temos uma boa convenção de nomenclatura e um bom dicionário de dados para nossos modelos, mas também vemos convenções de nomenclatura diferentes para muitos desses modelos físicos que estamos trazendo. engenheiro reverso, muitas vezes vemos nomes abreviados e esse tipo de coisa sobre o qual falarei. E precisamos convertê-los em nomes significativos em inglês que sejam significativos para os negócios, para que possamos entender quais são todas essas partes de dados que temos no ambiente. E, então, os mapeamentos universais é como os unimos.
Além disso, documentaríamos e definiríamos mais e é aí que podemos classificar ainda mais nossos dados com algo chamado Anexos, que mostrarei alguns slides. E, fechando o ciclo, queremos aplicar esse significado comercial, que é o ponto em que vinculamos nossos glossários comerciais e podemos vinculá-los a nossos diferentes artefatos de modelo, para que possamos saber, quando falamos de um determinado termo comercial, onde é implementado em nossos dados em toda a organização. E, finalmente, eu já falei sobre o fato de que precisamos de tudo isso para ser repositório com muitos recursos de colaboração e publicação, para que nossos stakeholders possam utilizá-lo. Vou falar sobre engenharia reversa rapidamente. Eu já lhe dei um destaque muito rápido disso. Vou mostrar isso a você em uma demonstração real apenas para mostrar algumas das coisas que podemos trazer para lá.
E quero falar sobre alguns dos diferentes tipos e diagramas de modelos que produziríamos nesse tipo de cenário. Obviamente, faremos os modelos conceituais em muitos casos; Não vou gastar muito tempo nisso. Eu realmente quero falar sobre modelos lógicos, modelos físicos e os tipos especializados de modelos que podemos criar. E é importante que possamos criar tudo isso na mesma plataforma de modelagem para podermos costurá-los. Isso inclui modelos dimensionais e também modelos que utilizam algumas das novas fontes de dados, como o NoSQL que mostrarei a você. E então, como é o modelo da linhagem de dados? E como costuramos esses dados em um modelo de processo de negócios, é sobre o que falaremos a seguir.
Vou mudar para um ambiente de modelagem aqui apenas para fornecer uma visão geral muito alta e rápida. E acredito que você deve poder ver minha tela agora. Antes de tudo, quero falar apenas sobre um tipo tradicional de modelo de dados. E a maneira como queremos organizar os modelos quando os incorporamos, é que queremos poder decompô-los. Então, o que você está vendo aqui no lado esquerdo é que temos modelos lógicos e físicos nesse arquivo de modelo específico. A próxima coisa é que podemos decompô-lo nas decomposições de negócios, e é por isso que você vê as pastas. Os azuis claros são modelos lógicos e os verdes são modelos físicos. E também podemos fazer uma busca detalhada, portanto, no ER / Studio, se você tiver uma decomposição comercial, poderá ir a quantos níveis ou submodelos desejar, e as alterações que você fizer nos níveis mais baixos refletem automaticamente nos níveis mais altos níveis. Portanto, ele se torna um ambiente de modelagem muito poderoso muito rapidamente.
Algo que também quero salientar que é muito importante começar a reunir essas informações é que podemos ter vários modelos físicos que também correspondem a um modelo lógico. Muitas vezes você pode ter um modelo lógico, mas pode ter modelos físicos em plataformas diferentes e esse tipo de coisa. Talvez uma seja uma instância do SQL Server, talvez outra seja uma instância do Oracle. Temos a capacidade de unir tudo isso no mesmo ambiente de modelagem. E lá novamente, o que eu tenho aqui é um modelo de data warehouse real que pode, novamente, estar no mesmo ambiente de modelagem ou podemos tê-lo no repositório e vinculá-lo a diferentes coisas também.
O que eu realmente queria mostrar é algumas das outras coisas e outras variantes dos modelos nos quais entramos. Então, quando entramos em um modelo de dados tradicional como este, estamos acostumados a ver as entidades típicas com as colunas, os metadados e esse tipo de coisa, mas esse ponto de vista varia muito rapidamente quando começamos a lidar com algumas dessas tecnologias NoSQL mais recentes., ou como algumas pessoas ainda gostam de chamá-las, as tecnologias de big data.
Então agora vamos dizer que também temos o Hive em nosso ambiente. Se fizermos engenharia reversa a partir de um ambiente Hive - e podemos fazer engenharia reversa e reversa a partir da Hive com essa mesma ferramenta de modelagem -, veremos algo um pouco diferente. Ainda vemos todos os dados como construções lá, mas nossos TDL são diferentes. Aqueles que estão acostumados a ver o SQL, o que veriam agora é o Hive QL, que é muito parecido com o SQL, mas com a mesma ferramenta, agora você pode começar a trabalhar com as diferentes linguagens de script. Para que você possa modelar nesse ambiente, gerá-lo no ambiente Hive, mas da mesma forma que, no cenário que descrevi, você pode fazer a engenharia reversa de tudo isso, entender o sentido e começar a costurá-lo também .
Vamos dar outra que é um pouco diferente. O MongoDB é outra plataforma que apoiamos nativamente. E quando você começa a entrar nos tipos de ambientes JSON em que você possui repositórios de documentos, o JSON é um animal diferente e há construções nisso que não correspondem a modelos relacionais. Você logo começa a lidar com conceitos como objetos incorporados e matrizes incorporadas de objetos quando começa a interrogar o JSON e esses conceitos não existem na notação relacional tradicional. O que fizemos aqui é que, na verdade, estendemos a notação e nosso catálogo para poder lidar com isso no mesmo ambiente.
Se você olhar aqui à esquerda, em vez de ver coisas como entidades e tabelas, estamos chamando-as de objetos. E você vê notações diferentes. Você ainda vê os tipos típicos de notações de referência aqui, mas essas entidades azuis que estou mostrando neste diagrama em particular são na verdade objetos incorporados. E mostramos diferentes cardinalidades. A cardinalidade de diamante significa que é um objeto de um lado, mas a cardinalidade de um significa que temos, dentro do editor, se seguirmos esse relacionamento, um objeto de endereço incorporado. Ao interrogar o JSON, descobrimos que é exatamente a mesma estrutura de objetos incorporada no usuário, mas na verdade incorporada como uma matriz de objetos. Estamos vendo isso, não apenas através dos próprios conectores, mas se você observar as entidades reais, verá que vê endereços sob patrono que também o classificam como uma matriz de objetos. Você tem um ponto de vista muito descritivo de como você pode trazer isso.
E, novamente, agora o que vimos até agora em apenas alguns segundos são modelos relacionais tradicionais com vários níveis, podemos fazer a mesma coisa com o Hive, podemos fazer a mesma coisa com o MongoDB e outras fontes de big data como bem. O que também podemos fazer, e eu vou lhe mostrar isso muito rapidamente, falei sobre o fato de trazer coisas de outras áreas diferentes. Vou assumir que vou importar um modelo de um banco de dados ou fazer engenharia reversa, mas vou trazê-lo de metadados externos. Apenas para lhe dar uma visão muito rápida de todos os diferentes tipos de coisas que podemos começar a trazer.
Como você vê, temos uma infinidade de coisas com as quais podemos realmente trazer os metadados para o nosso ambiente de modelagem. Começando com coisas como o Amazon Redshift, o Cassandra, muitas outras plataformas de big data, você vê muitas delas listadas. Isso está em ordem alfabética. Estamos vendo muitas fontes de big data e esse tipo de coisa. Também estamos vendo muitos ambientes de modelagem tradicionais ou mais antigos pelos quais podemos trazer esses metadados. Se eu passar por aqui - e não vou gastar tempo com cada uma delas -, vemos muitas coisas diferentes das quais podemos extrair, em termos de plataformas de modelagem e plataformas de dados. E algo que é muito importante perceber aqui é outra parte que podemos fazer quando começarmos a falar sobre a linhagem de dados. No Enterprise Team Edition, também podemos interrogar fontes de ETL, sejam como mapeamentos Talend ou SQL Server Information Services, podemos na verdade, traga isso para iniciar também nossos diagramas de linhagem de dados e faça uma imagem do que está acontecendo nessas transformações. No total, temos mais de 130 dessas pontes diferentes, que na verdade fazem parte do produto Enterprise Team Edition, por isso nos ajuda a reunir todos os artefatos em um ambiente de modelagem muito rapidamente.
Por último, mas não menos importante, também quero falar sobre o fato de que não podemos perder de vista o fato de que precisamos de outros tipos de construções se estivermos fazendo data warehousing ou qualquer tipo de análise. Ainda queremos ter a capacidade de fazer coisas como modelos dimensionais em que temos tabelas de fatos e dimensões e esses tipos de coisas. Uma coisa que quero mostrar também é que também podemos ter extensões em nossos metadados que nos ajudam a categorizar quais são os tipos de dimensões e tudo mais. Portanto, se eu olhar a guia de dados dimensionais aqui, por exemplo, em uma delas, ela realmente detectará automaticamente, com base no padrão de modelo que vê, e fornecerá um ponto de partida para pensar se é uma dimensão ou uma tabela de fatos. Além disso, o que podemos fazer é dentro das dimensões e, nesse tipo de coisa, temos até diferentes tipos de dimensões que podemos usar para classificar os dados em um ambiente de armazenamento de dados. Recursos muito poderosos com os quais estamos costurando isso.
Vou pular para este, já que estou no ambiente de demonstração agora e mostrar algumas outras coisas antes de voltar aos slides. Uma das coisas que adicionamos recentemente ao ER / Studio Data Architect é que encontramos situações - e esse é um caso de uso muito comum quando você está trabalhando em projetos - os desenvolvedores pensam em termos de objetos, enquanto nossos dados os modeladores tendem a pensar em termos de tabelas e entidades e esse tipo de coisa. Este é um modelo de dados muito simplista, mas representa alguns conceitos básicos, nos quais os desenvolvedores ou mesmo analistas de negócios ou usuários de negócios podem pensar neles como objetos ou conceitos de negócios diferentes. Tem sido muito difícil classificá-los até agora, mas o que realmente fizemos no ER / Studio Enterprise Team Edition, na versão 2016, é que agora temos um conceito chamado Business Data Objects. E o que isso nos permite fazer é encapsular grupos de entidades ou tabelas em verdadeiros objetos de negócios.
Por exemplo, o que temos aqui nessa nova visualização é o cabeçalho do pedido e a linha do pedido foi reunida agora, eles estão encapsulados como um objeto, nós pensamos neles como uma unidade de trabalho quando persistimos os dados, e os reunimos para que agora seja muito fácil relacionar isso a diferentes públicos. Eles são reutilizáveis em todo o ambiente de modelagem. Eles são um objeto real, não apenas uma construção de desenho, mas também temos o benefício adicional de que, quando estamos nos comunicando da perspectiva da modelagem, podemos recolhê-los ou expandi-los seletivamente, para que possamos produzir uma visão resumida para diálogos com determinados públicos de interesse, e também podemos, é claro, manter uma visão mais detalhada como a que estamos vendo aqui para mais audiências técnicas. Realmente nos dá um bom veículo de comunicação. O que vemos agora é a combinação de vários tipos diferentes de modelos, aprimorando-os com o conceito de objetos de dados de negócios, e agora vou falar sobre como realmente aplicamos mais significado a esses tipos de coisas e como os juntamos em nosso ambientes gerais.
Só estou tentando encontrar meu WebEx aqui para poder fazer isso. E lá vamos nós, de volta aos slides da Hot Tech. Vou avançar alguns slides aqui porque você já os viu na demonstração do modelo. Eu quero falar sobre padrões de nomes muito rapidamente. Queremos aplicar e aplicar diferentes padrões de nomenclatura. O que queremos fazer é que temos a capacidade de realmente armazenar modelos de padrões de nomenclatura em nossos repositórios para basicamente construir esse significado por meio de palavras ou frases ou abreviações e vinculá-los a um tipo significativo de palavra em inglês. Vamos usar termos de negócios, as abreviações de cada um, e podemos especificar a ordem, os casos e adicionar prefixos e sufixos. O caso de uso típico para isso é normalmente quando as pessoas estão construindo um modelo lógico e, na verdade, avançando para criar um modelo físico no qual possam estar usando abreviações e tudo mais.
O mais bonito é que é igualmente poderoso, ainda mais poderoso ao contrário, se pudermos dizer o que alguns desses padrões de nomes estavam em alguns desses bancos de dados físicos que fizemos engenharia reversa, podemos usar essas abreviações, transformá-las em mais palavras e trazê-las para trás em frases em inglês. Agora, na verdade, podemos derivar nomes próprios para a aparência de nossos dados. Como eu disse, o caso de uso típico é que avançaríamos, lógico para físico, e mapearíamos os armazenamentos de dados e esse tipo de coisa. Se você observar a captura de tela no lado direito, verá que há nomes abreviados dos nomes de origem e, quando aplicamos um modelo de padrões de nomenclatura, na verdade temos mais nomes completos. E poderíamos colocar espaços e tudo mais, se quisermos, dependendo do modelo de padrões de nomenclatura que usamos. Podemos fazer com que pareça da maneira que queremos que seja incorporada aos nossos modelos. Somente quando sabemos o que é chamado de algo, podemos realmente começar a anexar definições a ele, porque, a menos que saibamos o que é, como podemos aplicar um significado a ele?
O bom é que podemos realmente invocar isso quando estamos fazendo todo tipo de coisa. Eu falei sobre engenharia reversa, podemos realmente invocar modelos de padrões de nomeação simultaneamente quando estamos fazendo engenharia reversa. Portanto, em um conjunto de etapas de um assistente, o que podemos fazer é, se soubermos quais são as convenções, podemos fazer engenharia reversa de um banco de dados físico, ele o trará de volta como modelos físicos em um ambiente de modelagem. também vai aplicar essas convenções de nomenclatura. Portanto, veremos quais são as representações de nomes em inglês no modelo lógico correspondente no ambiente. Também podemos fazê-lo e combiná-lo com a geração do XML Schema, para que possamos pegar um modelo e até mesmo divulgá-lo com nossas abreviações, seja fazendo estruturas de SOA ou esse tipo de coisa, para que também possamos divulgar diferentes convenções de nomenclatura que realmente armazenamos no próprio modelo. Isso nos dá muitos recursos muito poderosos.
Novamente, aqui está um exemplo de como seria se eu tivesse um modelo. Este está realmente mostrando que eu tinha EMP para "funcionário", SAL para "salário", PLN para "plano" em uma convenção de padrões de nomenclatura. Também posso aplicá-los para executá-los de maneira interativa, enquanto estou criando modelos e inserindo coisas. Se eu estivesse usando essa abreviação e digitasse “Plano de salário dos funcionários” no nome da entidade, ele atuaria com o modelo de padrões de nomenclatura. Eu defini aqui, isso teria me dado EMP_SAL_PLN quando eu estava criando as entidades e me dado os nomes físicos correspondentes imediatamente.
Novamente, muito bom para quando estamos projetando e desenvolvendo a engenharia também. Temos um conceito muito único e é aqui que realmente começamos a reunir esses ambientes. E se chama Mapeamentos Universais. Depois de incorporar todos esses modelos em nosso ambiente, o que podemos fazer, assumindo que agora aplicamos essas convenções de nomenclatura e são fáceis de encontrar, agora podemos usar uma construção chamada Universal Mappings in ER /Estúdio. Podemos vincular entidades entre modelos. Onde quer que vejamos "cliente" - provavelmente teremos "cliente" em muitos sistemas diferentes e muitos bancos de dados diferentes - podemos começar a vincular todos eles para que, quando estiver trabalhando com ele em um modelo, pode ver onde estão as manifestações dos clientes nos outros modelos. E como temos a camada de modelo que representa isso, podemos até vinculá-la às fontes de dados e reduzi-la às consultas onde foram usadas em quais bancos de dados esses residem também. Isso realmente nos dá a capacidade de amarrar tudo isso de forma muito coesa.
Eu mostrei os objetos de dados corporativos. Também quero falar sobre as extensões de metadados, que chamamos de anexos, muito rapidamente. O que isso faz é fornecer a capacidade de criar metadados adicionais para nossos objetos de modelo. Freqüentemente, eu configurava esses tipos de propriedades para extrair muitas coisas diferentes da perspectiva de governança e qualidade dos dados e também para nos ajudar com o gerenciamento de dados mestre e as políticas de retenção de dados. A idéia básica é que você crie essas classificações e possa anexá-las onde quiser, no nível da tabela, no nível da coluna, desses tipos de coisas. O caso de uso mais comum, é claro, é que as entidades são tabelas e, em seguida, posso definir: quais são meus objetos de dados mestre, quais são minhas tabelas de referência, quais são minhas tabelas transacionais? Do ponto de vista da qualidade dos dados, posso fazer classificações em termos de importância para os negócios, para que possamos priorizar os esforços de limpeza de dados e esse tipo de coisa.
Algo que geralmente é esquecido é: qual é a política de retenção para diferentes tipos de dados em nossa organização? Podemos configurá-los e, na verdade, podemos anexá-los aos diferentes tipos de artefatos de informações em nosso ambiente de modelagem e, é claro, em nosso repositório também. A vantagem é que esses anexos estão em nosso dicionário de dados; portanto, quando estamos utilizando dicionários de dados corporativos no ambiente, podemos anexá-los a vários modelos. Só precisamos defini-los uma vez e podemos aproveitá-los repetidamente nos diferentes modelos em nosso ambiente. Esta é apenas uma captura de tela rápida para mostrar que você pode realmente especificar quando você faz um anexo, em quais partes você deseja anexá-lo. E este exemplo aqui é na verdade uma lista de valores; portanto, quando eles entram, você pode escolher em uma lista de valores, você tem muito controle no ambiente de modelagem do que está sendo escolhido e pode até definir qual é o padrão value é se um valor não for escolhido. Muito poder lá. Eles moram no dicionário de dados.
Algo que quero mostrar um pouco mais abaixo nesta tela. Além disso, você vê os anexos aparecendo na parte superior, embaixo, as informações de segurança dos dados. Na verdade, também podemos aplicar políticas de segurança de dados às diferentes informações no ambiente. Para diferentes mapeamentos de conformidade, classificações de segurança de dados, enviamos vários deles imediatamente que você pode gerar e começar a usar, mas também é possível definir seus próprios mapeamentos e padrões de conformidade. Esteja você fazendo HIPAA ou qualquer outra iniciativa existente. E você pode realmente começar a criar esse conjunto muito rico de metadados no seu ambiente.
E então o Glossário e os Termos - é aqui que o significado do negócio está vinculado. Muitas vezes temos dicionários de dados por aí que muitas vezes uma organização está usando como ponto de partida para começar a eliminar glossários, mas a terminologia e a verbosidade são frequentemente muito técnico. Então, o que podemos fazer é que podemos, se desejar, usá-los como ponto de partida para gerar glossários, mas realmente queremos que a empresa os possua. O que fizemos no ambiente de servidor de equipe é que permitimos às pessoas criar definições de negócios e, em seguida, podemos vinculá-las aos diferentes artefatos de modelo aos quais eles correspondem no ambiente de modelagem. Também reconhecemos o ponto discutido anteriormente, ou seja, quanto mais pessoas você digita, maior o potencial de erro humano. O que também fazemos em nossa estrutura de glossário é: apoiamos uma hierarquia de glossário, para que possamos ter diferentes tipos de glossário ou diferentes tipos de coisas na organização, mas, o mais importante, é se você já possui algumas dessas fontes lá fora, com os termos e tudo definido, podemos realmente fazer uma importação de CSV para inseri-los em nosso ambiente de modelagem e também no servidor da equipe ou no glossário e começar a vincular a partir daí. E toda vez que algo é alterado, há uma trilha de auditoria completa do que eram as imagens antes e depois, em termos de definições e tudo mais, e o que você verá em um futuro muito próximo também é mais um fluxo de trabalho de autorização para que possamos realmente controlar quem está encarregado, aprovações de comitês ou indivíduos e esse tipo de coisa, para tornar o processo de governança ainda mais robusto à medida que avançamos.
O que isso também faz para nós é quando temos esses termos do glossário no glossário do servidor de equipe; este é um exemplo de edição em uma entidade no próprio modelo que eu trouxe aqui. Pode ter termos vinculados, mas o que fazemos também é que, se houver palavras no glossário que apareçam nas notas ou descrições do que temos em nossas entidades aqui, elas serão mostradas automaticamente em uma cor mais clara de hiperlink e, se passando o mouse sobre eles, também podemos ver a definição no glossário comercial. Até nos fornece informações mais ricas quando consumimos as informações em si, com todos os termos do glossário disponíveis. Realmente ajuda a enriquecer a experiência e aplicar o significado a tudo o que estamos trabalhando.
Então, novamente, esse foi um sobrevôo muito rápido. Obviamente, poderíamos passar dias nisso enquanto nos aprofundamos nas diferentes partes, mas esse é um sobrevôo muito rápido sobre a superfície. O que realmente estamos nos esforçando para fazer é entender como são esses ambientes de dados complexos. Queremos melhorar a visibilidade de todos esses artefatos de dados e colaborar para expulsá-los com o ER / Studio. Queremos permitir uma modelagem de dados mais eficiente e automatizada. E estamos falando de todos os tipos de dados, sejam big data, dados relacionais tradicionais, repositórios de documentos ou qualquer outra coisa. E, novamente, conseguimos isso porque temos recursos avançados de engenharia avançada e reversa para as diferentes plataformas e as outras ferramentas que você pode ter por aí. E trata-se de compartilhar e se comunicar em toda a organização com todas as partes interessadas envolvidas. É aí que aplicamos significado por meio de padrões de nomeação. Em seguida, aplicamos as definições nos glossários de negócios. Além disso, podemos fazer classificações adicionais para todos os outros recursos de governança com as extensões de metadados, como extensões de qualidade de dados, classificações para gerenciamento de dados mestre ou qualquer outro tipo de classificação que você deseja aplicar a esses dados. E então podemos resumir ainda mais e aprimorar a comunicação ainda mais com os objetos de dados corporativos, com os diferentes públicos das partes interessadas, principalmente entre modeladores e desenvolvedores.
E, novamente, o mais importante é que, por trás de tudo, existe um repositório integrado com recursos de gerenciamento de mudanças muito robustos. Hoje não tive tempo de mostrá-lo porque fica bastante complexo, mas o repositório possui recursos de gerenciamento de alterações muito robustos e trilhas de auditoria. Você pode fazer versões nomeadas, versões nomeadas e também temos a capacidade para aqueles que estão gerenciando mudanças, podemos vincular isso diretamente às suas tarefas. Hoje, temos a capacidade de colocar tarefas e associar as alterações do modelo às tarefas, assim como os desenvolvedores associariam as alterações de código às tarefas ou histórias de usuários com as quais eles estão trabalhando.
Novamente, essa foi uma visão geral muito rápida. Espero que tenha sido suficiente para aguçar seu apetite, para que possamos iniciar conversas muito mais profundas sobre a divisão de alguns desses tópicos à medida que avançarmos no futuro. Obrigado pelo seu tempo, e de volta para você, Rebecca.
Rebecca Jozwiak: Obrigado, Ron, isso foi fantástico e tenho muitas perguntas da platéia, mas quero dar aos nossos analistas a chance de afundar no que você tem a dizer. Eric, eu vou em frente e, talvez, se você quiser abordar este slide, ou outro diferente, por que você não vai em frente primeiro? Ou qualquer outra pergunta.
Eric Little: Claro. Desculpe, qual foi a pergunta, Rebecca? Você quer que eu pergunte algo específico ou …?
Rebecca Jozwiak: Eu sei que você teve algumas perguntas inicialmente para Ron. Se você deseja pedir agora que ele trate de algum deles, ou alguns deles fora do seu slide ou qualquer outra coisa que despertou seu interesse, sobre o qual você deseja perguntar? Sobre as funcionalidades de modelagem do IDERA.
Eric Little: Sim, então uma das coisas, Ron, então, como vocês parecem os diagramas que você estava mostrando são tipos gerais de diagramas de relacionamento de entidades como você normalmente usaria na construção de bancos de dados, correto?
Ron Huizenga: Sim, de um modo geral, mas é claro que temos os tipos estendidos para as lojas de documentos e esse tipo de coisa também. Na verdade, variamos apenas da notação relacional pura; na verdade, adicionamos notações adicionais também para essas outras lojas.
Eric Little: Existe uma maneira de vocês usarem tipos de modelagem baseados em gráficos, então existe uma maneira de integrar, por exemplo, suponha que eu tenha algo como um quadrante superior, uma ferramenta de composição TopBraid ou eu fiz algo no Protégé ou, sabe, como o pessoal da área financeira da FIBO, eles estão fazendo muito trabalho em semântica, material RDF - existe uma maneira de incluir esse tipo de modelagem de tipo de gráfico de relação de entidade nessa ferramenta e utilizar isto?
Ron Huizenga: Na verdade, estamos vendo como podemos lidar com gráficos. Atualmente, não estamos lidando explicitamente com bancos de dados gráficos e esse tipo de coisa, mas estamos procurando maneiras de fazer isso para estender nossos metadados. Quero dizer, podemos trazer coisas através do XML e esse tipo de coisa agora, se pelo menos podemos fazer algum tipo de versão de XML para trazê-lo como ponto de partida. Mas estamos procurando maneiras mais elegantes de introduzir isso.
Também mostrei a você a lista de pontes de engenharia reversa que temos lá, por isso estamos sempre procurando obter extensões dessas pontes para plataformas específicas. É um esforço contínuo e contínuo, se isso faz sentido, começar a adotar muitas dessas novas construções e as diferentes plataformas existentes. Mas posso dizer que estamos definitivamente na vanguarda de fazer isso. As coisas que mostrei, por exemplo, o MongoDB e esse tipo de coisa, somos o primeiro fornecedor de modelagem de dados a fazer isso nativamente em nosso próprio produto.
Eric Little: Ok, sim. Então a outra pergunta que eu tinha para você, então, era em termos de governança e manutenção da - como quando você usou o exemplo, quando mostrou o exemplo da pessoa que é um "funcionário", acredito que era um " salário "e, em seguida, você tem um" plano "; existe uma maneira de como gerenciar, por exemplo, diferentes tipos de pessoas que possam ter - vamos supor que você tenha uma arquitetura grande, certo, vamos supor que você tenha uma grande empresa as pessoas começam a juntar as coisas nesta ferramenta e você tem um grupo aqui que tem a palavra "funcionário" e um grupo aqui que tem a palavra "trabalhador". E uma pessoa aqui diz "salário" e outra pessoa diz "salário."
Como vocês reconciliam, gerenciam e governam esse tipo de distinção? Como eu sei como faríamos isso no mundo dos gráficos, você usaria listas de sinônimos ou diria que há um conceito e ele tem vários atributos, ou você poderia dizer que no modelo SKOS eu tenho uma etiqueta preferida e tenho várias etiquetas alternativas que posso usar. Como vocês fazem isso?
Ron Huizenga: Nós fazemos isso de duas maneiras diferentes, e principalmente vamos falar sobre a terminologia primeiro. Uma das coisas que fazemos, é claro, é que queremos ter os termos definidos ou sancionados e, no glossário comercial, obviamente, é onde os queremos. Além disso, permitimos links para sinônimos no glossário comercial. O que você pode fazer é dizer: aqui está o meu termo, mas você também pode definir quais são todos os sinônimos para eles.
Agora, o mais interessante, é claro, é quando você começa a examinar esse vasto cenário de dados com todos esses sistemas diferentes que existem, não pode simplesmente ir lá e alterar as tabelas correspondentes e esses tipos de coisas para correspondem a esse padrão de nomenclatura, pois pode ser um pacote que você comprou, portanto, você não tem controle sobre a alteração do banco de dados ou qualquer outra coisa.
O que poderíamos fazer lá, além de poder associar as definições do glossário, é por meio desses mapeamentos universais sobre os quais eu falei, o que faríamos e o tipo de abordagem recomendada é ter um modelo lógico abrangente que estabeleça o que esses diferentes conceitos de negócios são dos quais você está falando. Associe os termos do glossário de negócios a eles, e o mais interessante é que agora que você conseguiu essa construção que representa uma entidade lógica, você pode começar a vincular essa entidade lógica a todas as implementações dessa entidade lógica em os diferentes sistemas.
Então, onde você precisa disso, pode ver, oh, "pessoa" aqui é chamada "funcionário" neste sistema. "Salário" aqui é chamado de "salário" aqui neste outro sistema. Porque você verá isso, verá todas as diferentes manifestações daquelas porque as vinculou.
Eric Little: Ok, ótimo, sim, entendi. Nesse sentido, é seguro dizer que é como algumas das abordagens orientadas a objetos?
Ron Huizenga: Um pouco. É um pouco mais intenso que, acho que você poderia dizer. Quero dizer, você pode adotar a abordagem de vincular manualmente, passar e inspecionar e executar todos eles também. A única coisa sobre a qual não tive oportunidade de falar - porque, novamente, temos muitos recursos - também temos uma interface de automação completa na própria ferramenta Data Architect. E um recurso de macro, que é realmente uma linguagem de programação na ferramenta. Assim, podemos fazer coisas como escrever macros, fazer com que elas sejam interrogadas e criem links para você. Usamos isso para importar e exportar informações, podemos alterá-las ou adicionar atributos, evento baseado no próprio modelo, ou podemos usá-lo para executar em lotes para realmente sair e interrogar coisas e preencher diferentes construções no modelo. Portanto, há uma interface de automação completa da qual as pessoas também podem se beneficiar. E utilizar os mapeamentos universais com esses seria uma maneira muito poderosa de fazer isso.
Rebecca Jozwiak: Ok, obrigado Ron e obrigado Eric. Essas foram ótimas perguntas. Sei que estamos um pouco atrasados, mas gostaria de dar a Malcolm a chance de fazer algumas perguntas à maneira de Ron. Malcolm?
Malcolm Chisholm: Obrigado, Rebecca. Então, Ron, é muito interessante, vejo que há muitos recursos aqui. Uma das áreas em que estou muito interessado é, digamos, se temos um projeto de desenvolvimento, como você vê o modelador de dados usando esses recursos e trabalhando talvez de forma mais colaborativa com analistas de negócios, com um criador de perfil de dados, com um analista de qualidade de dados, e com os patrocinadores da empresa que serão responsáveis pelos requisitos de informações reais no projeto. Como o modelador de dados realmente torna o projeto mais eficaz e eficiente com os recursos que estamos analisando?
Ron Huizenga: Eu acho que uma das primeiras coisas que você precisa fazer é como modelador de dados - e não pretendo escolher alguns dos modeladores, mas, de qualquer maneira -, algumas pessoas ainda têm a impressão de que o modelador de dados é realmente o tipo de função de gatekeeper, estamos definindo como funciona, somos os guardas que garantem que tudo esteja correto.
Agora, há um aspecto disso: você precisa ter certeza de que está definindo uma arquitetura de dados sólida e tudo mais. Mas o mais importante é como modelador de dados - e eu achei isso bastante óbvio quando estava consultando - é que você precisa se tornar um facilitador, portanto, é necessário reunir essas pessoas.
Não será mais um projeto inicial, gerar, criar bancos de dados - o que você precisa ser capaz de fazer é trabalhar com todos esses diferentes grupos de partes interessadas, fazendo coisas como engenharia reversa, importação de informações, outras pessoas colaboram, seja nos glossários ou na documentação, tudo assim - e seja um facilitador para colocar isso no repositório, vincular os conceitos no repositório e trabalhar com essas pessoas.
Realmente é muito mais um tipo de ambiente colaborativo, onde, mesmo através da definição de tarefas ou de tópicos de discussão ou do tipo de coisa que temos no servidor de equipe, as pessoas podem realmente colaborar, fazer perguntas e chegar aos produtos finais finais que eles necessário para sua arquitetura de dados e sua organização. Esse tipo de resposta?
Malcolm Chisholm: Sim, eu concordo. Sabe, acho que a habilidade de facilitação é algo realmente desejável nos modeladores de dados. Concordo que nem sempre vemos isso, mas acho que isso é necessário e sugiro que às vezes haja uma tendência de permanecer no seu canto fazendo a modelagem de dados, mas você realmente precisa estar lá trabalhando com os outros grupos de partes interessadas ou você simplesmente não entende o ambiente de dados com o qual está lidando, e acho que o modelo sofre como resultado. Mas essa é apenas a minha opinião.
Ron Huizenga: E é interessante porque você mencionou algo no início do slide sobre a história de como as empresas se afastam da TI porque não estavam fornecendo as soluções em tempo hábil e esses tipos de coisas.
É muito interessante que nos meus trabalhos de consultoria posteriores, antes de me tornar gerente de produtos, a maioria dos projetos que eu fiz nos últimos dois anos antes eram patrocinados por empresas, onde eram realmente os negócios que os impulsionavam e os arquitetos de dados e modeladores não faziam parte da TI. Fazíamos parte de um grupo patrocinado por empresas e estávamos lá como facilitadores, trabalhando com o restante das equipes do projeto.
Malcolm Chisholm: Então eu acho que é um ponto muito interessante. Acho que estamos começando a ver uma mudança no mundo dos negócios em que os negócios estão perguntando, ou pensando talvez, não tanto quanto o que faço, sendo processados, mas eles também estão começando a pensar sobre quais são os dados com quem trabalho, quais são as minhas necessidades de dados, quais são os dados com os quais estou lidando como dados e até que ponto podemos obter os produtos e recursos da IDERA para suportar esse ponto de vista, e acho que as necessidades dos negócios, mesmo embora ainda seja um pouco incipiente.
Ron Huizenga: Eu concordo com você e acho que estamos vendo isso acontecer cada vez mais. Vimos um despertar e você o tocou anteriormente em termos da importância dos dados. Vimos a importância dos dados no início da TI ou na evolução dos bancos de dados; então, como você diz, meio que entramos em todo esse ciclo de gerenciamento de processos - e o processo é extremamente importante, não me entenda mal - mas agora o que aconteceu é quando isso acontece, os dados perdem o foco.
E agora as organizações estão percebendo que os dados realmente são o ponto focal. Os dados representam tudo o que estamos fazendo em nossos negócios, portanto, precisamos ter certeza de que temos dados precisos, para que possamos encontrar as informações corretas necessárias para tomar nossas decisões. Porque nem tudo vem de um processo definido. Algumas das informações são um subproduto de outras coisas e ainda precisamos encontrá-las, saber o que elas significam e traduzir os dados que vemos lá em última análise em conhecimento que podemos usar para impulsionar melhor nossos negócios.
Malcolm Chisholm: Certo, e agora outra área com a qual estou lutando é o que eu chamaria de ciclo de vida dos dados, que é, você sabe, se olharmos para o tipo de cadeia de suprimento de dados que atravessa uma empresa, começaríamos com aquisição de dados ou captura de dados, que pode ser a entrada de dados, mas também pode ser, estou recebendo dados de fora da empresa de algum fornecedor de dados.
E depois da captura de dados, vamos para a manutenção de dados, onde estou pensando em padronizar esses dados e enviá-los para os locais onde eles são necessários. E então o uso dos dados, os pontos reais em que os dados estão, você obterá valor dos dados.
Nos velhos tempos, tudo isso era feito em um estilo individual, mas hoje pode ser, você sabe, um ambiente de análise, por exemplo, e além disso, um arquivo, uma loja, onde colocamos os dados quando não mais precisa e, finalmente, um tipo de processo de limpeza. Como você vê a modelagem de dados adequada ao gerenciamento de todo esse ciclo de vida dos dados?
Ron Huizenga: Essa é uma pergunta muito boa e uma coisa que eu realmente não tive tempo de me aprofundar em detalhes aqui hoje, é sobre o que realmente estamos começando a falar sobre a linhagem de dados. Então, o que realmente podemos fazer é ter um recurso de linhagem de dados em nossas ferramentas e, como eu disse, podemos extrair alguns deles das ferramentas ETL, mas você também pode mapeá-lo apenas desenhando a linhagem. Qualquer um desses modelos de dados ou bancos de dados que capturamos e trouxemos para modelos pode referenciar as construções a partir disso em nosso diagrama de linhagem de dados.
O que podemos fazer é desenhar um fluxo de dados, como você diz, da origem ao destino, e ao longo do ciclo de vida geral de como esses dados transitam pelos diferentes sistemas e o que você vai encontrar é: vamos levar os funcionários 'data - é um dos meus favoritos com base em um projeto que fiz anos atrás. Trabalhei com uma organização que possuía dados de funcionários em 30 sistemas diferentes. O que acabamos fazendo lá - e Rebecca exibiu o slide da linhagem de dados - este é um slide da linhagem de dados bastante simplista aqui, mas o que conseguimos fazer foi trazer todas as estruturas de dados, referenciá-las no diagrama e depois pode realmente começar a analisar quais são os fluxos entre e como essas diferentes entidades de dados estão vinculadas em um fluxo? E podemos ir além disso também. Isso faz parte de um fluxo de dados ou diagrama de linhagem que vemos aqui. Se você quiser ir além, também temos o arquiteto de negócios que faz parte dessa suíte e o mesmo se aplica a ele.
Qualquer uma das estruturas de dados que capturamos no ambiente de modelagem de dados, elas podem ser referenciadas na ferramenta de modelagem de negócios para que, mesmo nos diagramas de modelo de negócios ou nos diagramas de processos de negócios, você possa referenciar armazenamentos de dados individuais, se desejar o ambiente de modelagem de dados e, enquanto você os usa nas pastas do seu modelo de processo de negócios, você pode até especificar o CRUD, também, sobre como essas informações são consumidas ou produzidas, e então podemos começar a gerar coisas como relatórios e diagramas de impacto e análise a partir disso.
O que pretendemos alcançar e já temos muitos recursos, mas uma das coisas que temos como uma espécie de meta que estamos vendo, à medida que continuamos a desenvolver nossas ferramentas daqui para frente, é capaz de mapear essa linhagem de dados organizacional de ponta a ponta e o ciclo de vida completo dos dados.
Malcolm Chisholm: Ok. Rebecca, posso mais uma?
Rebecca Jozwiak: Vou permitir mais uma, Malcolm, vá em frente.
Malcolm Chisholm: Muito obrigado. Pensando em governança de dados e pensando em modelagem de dados, como conseguimos que esses dois grupos trabalhem efetivamente juntos e se entendam?
Eric Little: Bem, é interessante, acho que realmente depende da organização, e remonta ao meu conceito anterior: naquelas organizações em que as iniciativas eram direcionadas aos negócios, estávamos vinculadas. Por exemplo, eu estava liderando uma arquitetura de dados equipe, mas estávamos diretamente ligados aos usuários corporativos e, na verdade, estávamos ajudando-os a desenvolver seu programa de governança de dados. Novamente, é mais uma abordagem consultiva, mas é realmente mais uma função comercial.
O que você realmente precisa ser capaz de fazer isso é que precisa de modeladores de dados e arquitetos que realmente entendam os negócios, possam se relacionar com os usuários e, em seguida, os ajudaram a sustentar os processos de governança em torno deles. A empresa quer fazê-lo, mas de um modo geral, temos o conhecimento de tecnologia para poder ajudá-los a se destacar nesses tipos de programas. Realmente precisa ser uma colaboração, mas precisa ser de propriedade da empresa.
Malcolm Chisholm: Ok, isso é ótimo. Obrigado.
Dr. Eric Little: Ok.
Rebecca Jozwiak: Ok, muito obrigada. Membros da platéia, receio que não tenhamos respondido às suas perguntas, mas assegurarei que elas sejam encaminhadas para o convidado apropriado que tínhamos na fila hoje. Quero agradecer muito a Eric, Malcolm e Ron por serem nossos convidados hoje. Isso foi ótimo, pessoal. E se você gostou do webcast do IDERA de hoje, o IDERA também estará presente na Hot Technologies na próxima quarta-feira, se você quiser participar, discutindo os desafios da indexação e do Oracles, outro tópico fascinante.
Muito obrigado, pessoal, se cuidem, e nos vemos na próxima vez. Tchau tchau.
