Melhores Práticas para o IBM InfoSphere Blueprint Director, Parte 2: Projetando blueprints de informações do zero

Este artigo fornece as melhores práticas no uso do InfoSphere® Blueprint Director. O entendimento e a aplicação dessas melhores práticas possibilitam a criação de blueprints de arquitetura novos, efetivos e acionáveis. Destina-se a usuários especialistas do InfoSphere Blueprint Director.

Brian Byrne, STSM, Asset Development, Industry Solutions, IBM

Brian Byrneの写真Brian Byrne foi o Lead Architect por trás do InfoSphere Blueprint Director, proporcionando 15 anos de experiência em arquitetura, design e implementação de arquiteturas e conjuntos de ferramentas de dados de larga escala à criação de um novo paradigma para o design e a especificação de arquiteturas de integração de dados. Sua função atual envolve trazer essa experiência em gerenciamento de informações para o IBM Industry Solutions.



Martin Oberhofer, Senior IT Architect, Enterprise Information Architecture, IBM

Martin Oberhofer é senior IT architect em arquitetura de informações corporativas com grandes clientes em todo o mundo. Ele ajuda os clientes a definirem suas estratégias e arquiteturas de informações corporativas, resolvendo problemas de negócios com grande intensidade de informações. Suas áreas de conhecimento incluem o gerenciamento de dados principais com base em SOA, data warehousing, integração de informações e tecnologias de banco de dados. Gosta especialmente de trabalhar com empresas que executam aplicativos SAP. Como especialista de laboratório, Martin oferece conselhos para o gerenciamento de informações a grandes clientes da IBM. Começou sua carreira na IBM no IBM Silicon Valley Lab, no início de 2002, e atualmente trabalha no IBM Research & Development Lab, na Alemanha. Ele é coautor dos livros Enterprise Master Data Management: An SOA Approach to Managing Core Information e The Art of Enterprise Information Architecture: A Systems-Based Approach for Unlocking Business Insight, além de vários artigos de pesquisa e artigos no developerWorks. Como inventor, contribuiu com mais de 30 aplicativos de patente para a IBM. Ele também é Master Certified IT Architect pelo The Open Group e possui mestrado em matemática pela Universidade de Constança, na Alemanha.



Harald Smith, Software Architect, IBM

Harald SmithCom quase 30 anos de experiência nas áreas de TI e desenvolvimento de software, Harald Smith se concentra no design e na entrega de integração de informações e soluções e produtos de qualidade de informações, incluindo métodos e melhores práticas.


nível de autor Contribuidor do
        developerWorks

26/Nov/2012

Introdução

O IBM InfoSphere Blueprint Director faz parte do portfólio IBM InfoSphere Foundation Tools. O Blueprint Director se destina ao arquiteto de informações que projeta arquiteturas de solução para projetos com uso intensivo de informações. Para uma apresentação aprofundada ao Blueprint Director, consulte o tutorial preliminar chamado "Planejando um Cenário de Integração." Com base no entendimento da funcionalidade do Blueprint Director, oferecemos um primeiro artigo de melhores práticas para trabalhar com modelos de blueprints aqui: "Melhores Práticas para o IBM InfoSphere Blueprint Director, Parte 1: Trabalhando no ciclo de vida de um projeto." Nós supomos, para os fins deste artigo, que você conhece o conteúdo do tutorial introdutório e tem experiência prática com o Blueprint Director.

Nosso propósito aqui é mostrar melhores práticas para que os usuários do Blueprint Director criem seus próprios blueprints do zero. Também explicamos como usar o Blueprint Director para incorporar cenários de metadados e de servidor de informações físico como parte do cenário de informações específica. As melhores práticas contidas neste artigo são necessárias para:

  • Criação de blueprints legíveis do zero— Como um dos principais objetivos do uso do Blueprint Director é comunicar efetivamente uma arquitetura de solução específica, arquiteturas de solução alternativas e suas várias vantagens e desvantagens ou o impacto das solicitações de alteração em uma arquitetura de solução, a clareza nos blueprints é fundamental. Nós oferecemos uma lista abrangente de melhores práticas para criar blueprints legíveis e efetivos do zero. Também incluímos melhores práticas para a inclusão de extensões de paleta.
  • Cenários de metadados— Projetos com uso intenso de informações são geralmente complexos e envolvem metadados de negócios, técnicos e operacionais, que são interligados e interconectados. Um desafio, da perspectiva do gerenciamento de projeto, é entender como a solicitação de mudança de um recurso em um nível do processo afeta as estruturas de informações que suportam os processos de negócios. Sem a capacidade de entender se está chegando uma solicitação de mudança que afetaria modelos de dados, trabalhos de ETL etc, é difícil controlar e gerenciar mudanças efetivamente ao longo do tempo. O uso do Blueprint Director para visualizar o cenário de metadados (como um cenário de informações em si) ajuda o arquiteto de informações a entender rapidamente o que é necessário olhar para entender o impacto dessa mudança. Nós oferecemos melhores práticas para cenários de metadados.
  • Cenários de implementação física— Plataformas como IBM InfoSphere Information Server ou InfoSphere Master Data Management (MDM) são geralmente implementadas em mais de um nó físico (consulte Recursos) para um único ambiente usado para sandbox, desenvolvimento, teste, pré-produção e produção. Além disso, em cenários mais complexos, como projetos de consolidação SAP, o gerenciamento de artefatos de código para Information Server também exige esse gerenciamento para códigos ABAP correspondentes e configurações SAP de forma consistente entre ambientes de desenvolvimento, teste e produção de SAP e Information Server (consulte Pacotes SAP em Recursos). Para garantir melhores práticas apropriadas de propagação do código, backup e restauração, migração e implementação de fix pack entre essas infraestruturas, é útil informar os administradores, desenvolvedores e gerentes de projeto sobre o layout da infraestrutura. Nós oferecemos melhores práticas para usar o Blueprint Director para desenvolver esses blueprints.

Este artigo vai ajudá-lo a:

  • Saber como criar blueprints eficientes do zero.
  • Ver como aplicar Blueprint Director para entender e gerenciar cenários de metadados.
  • Ver como usar Blueprint Director para visualizar o cenário de implementação física.

Melhores práticas para criar e modificar blueprints

Quando se chega à conclusão de que não é possível reutilizar um modelo de blueprint existente e que é necessário criar um do zero, surge a questão de como decompor a solução geral em um conjunto de diagramas de blueprint em camadas. Para ilustrar, vamos usar um exemplo simples. Como um arquiteto de informação,é possível que você precise de integração de informações entre os sistemas da sua empresa. Para os arquitetos de solução no departamento de TI que lidam com o design dos projetos específicos nas unidades de negócios, você gostaria de dar orientação prescritiva sobre o uso do padrão de integração de informações e, para os padrões identificados, quais variações existem e quando elas se aplicam em geral. Ao identificar esses padrões, pode ser necessário detectar a necessidade de três áreas de padrão distintas para ETL, federação e replicação de dados. Concentrando-se por ora na replicação de dados, as seguintes características do padrão de arquitetura podem ser identificadas:

  • Captura de mudanças da replicação de dados em uma ou mais origens e sua replicação em um ou mais destinos.
  • Para a captura das mudanças, existem ao menos duas técnicas no nível do banco de dados, com vantagens e desvantagens:
    • Captura das mudanças baseada em acionadores
    • Captura das mudanças baseada em log transacional
  • Existem ao menos quatro topologias reconhecidas de replicação de dados:
    • Replicação unidirecional entre um sistema de origem e outro de destino
    • Replicação bidirecional entre um sistema de origem e outro de destino, que exige levar em conta possíveis conflitos e sua resolução
    • A replicação de sintetização é um cenário típico em ambientes de data warehousing, no qual dados de mais de uma origem são replicados para um único destino: o sistema de data warehousing
    • A replicação distribuída ocorre em cenários típicos, como replicação de um data warehouse central para data marts locais, ou de um sistema central de gerenciamento de dados principais para vários destinos que consomem os dados principais
  • Volume de dados: essa métrica determina quando agentes de captura e aplicativo precisam operar em paralelo nas origens e destinos para atingir o rendimento necessário. Também pode afetar a estrutura física e a localização dos sistemas

As Figuras 1 e 2 mostram um resultado possível da decomposição do padrão de arquitetura de replicação. Como é possível ver, nem todas as características acima foram colocadas em um único diagrama. Apenas a ideia principal de mover dados de uma ou mais origens para um ou mais destinos é mostrada no nível alto.

Figura 1. Estrutura básica do padrão de replicação
Estrutura básica do padrão de replicação

Em seguida, ao criar um subdiagrama relacionado à função de replicação, continuamos com o próximo diagrama (veja a Figura 2). Aqui, foi feita a decisão de mostrar que as topologias de replicação podem ser diferentes dependendo do caso de uso. No entanto, detalhes sobre técnicas de captura e aplicativo, sistemas concretos envolvidos etc. ainda não foram incluídos, portanto, o diagrama concentra-se claramente na ideia da topologia. Com esses dois diagramas, é criada uma estrutura reutilizável para o padrão de arquitetura de replicação, que pode ser customizado em qualquer projeto concreto com diagramas adicionais para sistemas concretos e considerações físicas sobre a paisagem da solução.

Figura 2. Subdiagrama que apresenta as quatro topologias
Subdiagrama que apresenta as quatro topologias

Portanto, para o arquiteto de informações, surge a pergunta de como colocar todas essas características em um ou vários diagramas em um blueprint com o Blueprint Director. Para o diagrama-raiz, o principal ponto do design é a simplicidade. Essa é a primeira impressão da solução proposta. Detalhes em excesso evitam que outras pessoas percebam a ideia central da solução.

Seguindo esse exemplo, vamos considerar as melhores práticas aplicadas aqui, apresentadas uma a uma:

  • Gerenciando detalhes
  • O que deve ser incluído em um blueprint?
  • Usando contêineres de agrupamento
  • Reutilizando elementos através de referências
  • Criando um layout legível
  • Abstraindo do tempo de execução
  • Considerações para cenários de metadados
  • Considerações para cenários físicos

Gerenciando detalhes

Ao criar um blueprint, o primeiro diagrama mostrado (o diagrama-raiz) causa a primeira impressão. Como dito, o segredo para esse primeiro diagrama é a simplicidade. No exemplo com o padrão de arquitetura de replicação, como mostra a Figura 1, essa melhor prática foi aplicada porque a arquitetura de solução foi reduzida a seu número mínimo de constituintes: um ou mais sistemas de origem e de destino, entre os quais um padrão de replicação de dados é aplicado. Portanto, no diagrama-raiz, é necessário aplicar as seguintes considerações:

  • Evite detalhes excessivos — Reduza os constituintes principais (veja a Figura 3).
  • Identifique os componentes principais detalhados nos subdiagramas subsequentes.
  • Pense sobre pontos de decomposição — em qual local do rascunho de raiz é possível incluir um ponto de entrada de subdiagrama que pode ser expandido para o próximo nível conceitual mais detalhado?

Observe que o conselho para evitar detalhes excessivos também se aplica a subdiagramas. Se um diagrama em um nível estiver ocupado demais, ele ainda não está bem estruturado, e a simplificação com decomposição em diagramas em camadas pode ainda estar pendente.

Figura 3. Evite detalhes excessivos
Evite detalhes excessivos

Fluxos de processamento de informações podem ser longos. Considere o que é necessário para extrair dados de várias origens em um ambiente de temporariedade no qual são aplicados análise de dados, alinhamento estrutural, padronização de dados, correspondência e deduplicação e transformações finais, antes do carregamento no destino.

Em geral, consideramos uma melhor prática evitar fluxos de dados longos e complexos entre vários interesses funcionais (extração, criação de perfil, purificação etc.) em um único diagrama. Esses processos são bagunçados e difíceis de entender. Em vez disso, se possível, abstraia os detalhes com a identificação de áreas funcionais de alta granularidade, que oferecem uma visão geral de alto nível do fluxo de processamento de informações gerais e decompõem cada área funcional com subdiagramas. Conceitualmente, considere essa uma abordagem do tipo "dividir e conquistar" na fase de design. Essa melhor prática é ilustrada nas Figuras 4 e 5.

Figura 4. Evite fluxos longos de processamento de informações
Evite fluxos longos de processamento de informações
Figura 5. Projete o diagrama básico com grupos de função lógicos e decomponha-os em subdiagramas
Projete o diagrama básico com grupos de função lógicos e decomponha-os em subdiagramas

Design para modelo vs. design para blueprint

É necessário aplicar mais uma consideração no caso de projetar um modelo para uso amplo em oposição a um blueprint para um projeto específico. Ao criar um modelo para um padrão de replicação de dados comum, como nas Figuras 1 e 2, é recomendável não se aprofundar demais, especialmente nos subdiagramas. O melhor é expressar os padrões e opções, permitindo que o usuário remova rapidamente o que é externo e se concentrar no que é necessário. Mas muitos níveis de subdiagramas restringirão e poderão limitar os usuários subsequentes do modelo. Se um usuário não precisar de algo no segundo nível, mas apenas em níveis abaixo do segundo, ele não pode excluir o segundo nível sem remover tudo abaixo dele, um fator que pode gerar um volume significativo de retrabalho.

Outras considerações para gerenciar detalhes:

  • Nem sempre é fácil manter um diagrama limpo, especialmente após longas discussões. Portanto, use as notas e recursos do subdiagrama para capturar mais detalhes. Por exemplo, o número de setas pode ser reduzido ao agrupar os elementos excessivos de origem de dados. Isso torna o diagrama mais fácil de ler.
  • Também é necessário prestar atenção na consistência dos conceitos. Esse problema surge se um elemento é usado como origem e destino. Como não é possível um elemento aparecer duas vezes no mesmo diagrama, pode ser necessário criar um subdiagrama para incluir a referência, ou incluir outro elemento que possa ter seu próprio subdiagrama para conter a referência. A inclusão de métodos em elementos também ajuda a entender o que precisa ser feito.
  • Há documentação disponível em vários formatos, de várias fontes. Quando o trabalho é realizado, é útil compartilhar com os outros o que foi documentado e relatado. Crie links de ativos para esses documentos, que podem ser links de arquivo ou URLs se a documentação estiver em um website, para ajudar as pessoas a entenderem corretamente. Em nosso exemplo do padrão de arquitetura de replicação, pode ser útil recomendar um documento com uma lista de todos os projetos nos quais essa técnica tenha sido aplicada, ou um artigo de melhores práticas discutindo em maiores detalhes as várias topologias e sua aplicação.
  • Para auxiliar o consumidor do blueprint, oriente visualmente o usuário, explorando a presença ou ausência de links nos elementos:
    • A ausência de um indicador de subdiagrama em um elemento pode indicar que o trabalho de design nessa área ainda não foi concluído.
    • A ausência de links de ativos pode indicar que não foram realizados requisitos, design ou desenvolvimento (por exemplo, tarefas DataStage®) até o momento.
    • Use o recurso de notas para incluir listas de verificação e anotações sobre o que ainda precisa ser feito nos diagramas.
  • Após o desenvolvimento do blueprint e a criação de alguns diagramas, a função de procura do Blueprint Director permite a identificação informações com o seu uso. Isso é particularmente útil quando não se sabe onde um certo detalhe está localizado.

O que deve ser incluído em um blueprint?

Há algumas armadilhas comuns que devem ser evitadas na criação de um blueprint. (As seções a seguir contêm uma discussão mais detalhada sobre cenários de metadados e de implementação física.)

Geralmente, não é apropriado mostrar artefatos de desenvolvimento como elementos de forma independente em um diagrama. O meio apropriado de incorporá-los é usando o recurso de link de ativo, conectando-os a um blueprint. Em um diagrama, é necessário concentrar-se em artefatos de implementação conceituais, como armazenamentos de dados e etapas de processamento funcional. A Figura 6 mostra um exemplo dessa armadilha.

Figura 6. Evite colocar artefatos de desenvolvimento em blueprints
Evite colocar artefatos de desenvolvimento em blueprints

Evite colocar no blueprint ferramentas usadas para criar a solução, como mostra a Figura 7. Basicamente, são irrelevantes da perspectiva de fluxo de informações, aumentando a complexidade e a confusão. Observe também que pode ser possível desenvolver a mesma arquitetura mostrada em uma solução com ferramentas de fornecedores de software diferentes. Por isso, especialmente para blueprints que capturam arquiteturas reutilizáveis, é uma melhor prática evitar associar os blueprints a software em particular. A discussão sobre ferramentas aplicáveis deve ser feita com um método que descreve melhores práticas de realização, e os artefatos criados pelas ferramentas mencionadas no método devem ser ligados usando o recurso de link de ativos.

Figura 7. Evite colocar ferramentas em blueprints
Evite colocar ferramentas em blueprints

Recomenda-se colocar no blueprint um método ou processo que descreva a sequência de tarefas para desenvolver a solução, como mostra a Figura 8. A melhor maneira de capturar etapas de método e processo é usando o método de link. Novamente, esse erro viola o conceito de concentrar-se em fluxos de informações nos blueprints e apenas inclui detalhes confusos, que distraem o usuário e dificultam a compreensão sobre o modo como a informação flui, pois mistura detalhes sobre como criar a solução.

Figura 8. Evite colocar etapas de método no blueprint
Evite colocar etapas de método no blueprint

Usando contêineres de agrupamento

A criação de um diagrama legível pode exigir o agrupamento visualmente artefatos relacionados. Alguns elementos de paleta servem para apoiar esse requisito, como Domain e Asset Set, como mostra a Figura 9.

Figura 9. Elementos de contêiner como Asset Set na paleta de desenho
Elementos de contêiner como Asset Set na paleta de desenho

Os elementos na Paleta Groups são Asset Set, Domain e Project. Se for necessário selecionar entre eles, considere os seguintes aspectos:

  • Visibilidade dos elementos contidos:
    • Domain — Todos os elementos são visíveis dentro do agrupamento de domínio. Observe que subdiagramas não podem se basear no próprio Domínio.
    • Asset Set — Os constituintes do conjunto de ativos são definidos em um subdiagrama e não são visíveis para o diagrama que contém o conjunto, mas subdiagramas podem ser conectados ao conjunto de ativos.
      • Exemplo: nos exemplos de replicação de dados nas Figuras 1 e 2, os constituintes das origens e dos destinos não foram nomeados explicitamente. Ainda é uma tarefa em um subdiagrama, e não há problema nisso, pois esses dois diagramas oferecem o conceito de base no qual as origens e destinos individuais ainda não são relevantes.
    • Project — Todos os elementos são visíveis dentro do agrupamento do projeto. Não é possível basear subdiagramas no próprio projeto.
  • Elementos recomendados que devem ser colocados nesse contêiner de agrupamento:
    • Domain — Qualquer um
    • Asset Set — Nesse contêiner de agrupamento devem ser colocados apenas ativos, como bancos de dados, aplicativos e entidades semelhantes.
    • Project — Qualquer um
  • Uso principal dos contêineres de agrupamento:
    • Domain — Esse contêiner de agrupamento é ideal para identificar camadas de arquitetura, importantes áreas funcionais ou um agrupamento de elementos relacionados.
    • Asset Set — Abstração para lista de ativos em um diagrama, como listas de sistemas de origem ou de destino etc.
    • Project — Esse contêiner de agrupamento é ideal para identificar projetos ou fases de projeto que formam uma paisagem de informações em constante mudança. Pode ser útil associar os marcos específicos a contêineres de projeto específico.

Reutilizando elementos através de referências

O tutorial de introdução ao Blueprint Directory (consulte "Planejando um Cenário de Integração" na seção Recursos) mostra como usar o recurso de referências do Blueprint Director. Ao decompor uma arquitetura de solução em uma série de diagramas e subdiagramas, é necessário reutilizar elementos entre ele. O recurso de referência trata disso, evitando a necessidade de recriar os mesmos itens. Uma das vantagens de usar referências é a redução de manutenção quando as propriedades de um elemento são alteradas, pois há apenas um lugar no qual a mudança precisa ser aplicada. Além disso, o uso de referências melhora a consistência entre diagramas, pois não há conceitos representados de forma diferente se uma mudança em uma propriedade do elemento for aplicada apenas em alguns diagramas e subdiagramas. Uma certa função usada em diferentes áreas da arquitetura também pode ser vinculada quando aplicável através de referências. Da perspectiva de melhores práticas, ao trabalhar com referências, é necessário considerar o seguinte:

  • Evite referências recursivas.
    • É possível criar um subdiagrama em um elemento (por exemplo, um Conjunto de Ativos) e, em seguida, incluir esse mesmo elemento como referência nos subdiagramas. O elemento no subdiagrama conterá o ponteiro para o subdiagrama atual, e clicar nele cria um relacionamento recursivo.
  • Não é possível ter a mesma referência duas vezes no mesmo diagrama (como uma referência a um elemento de banco de dados a ser usado para origem e destino).
  • Evite elementos pendentes no contexto de marcos.
    • O uso de referências em conjunto com marcos requer uma consideração cuidadosa para decidir o que aparece quando. O uso de referências em elementos com subdiagramas conectados que aparecem apenas em um marco posterior podem criar outros elementos pendentes. Pode ser necessário planejar rotas alternativas nesse caso.

Criando um layout legível

Antes de começar a usar Blueprint Director, lembre-se de que seus clientes internos e as partes interessadas estão acostumados a ver arquiteturas de soluções mostradas em Microsoft® PowerPoint® e Visio®, ou desenhadas em quadros. Quando começar a usar o Blueprint Director, os consumidores dos blueprints de soluções ainda precisam ter a capacidade de relacionar-se com eles da mesma maneira como faziam com essas outras ferramentas. Portanto, da perspectiva de melhores práticas, o layout deve ser claro e simples, — especialmente importante no diagrama-raiz. Para conseguir isso, é necessário evitar os erros mostrados na Figura 10:

  • Amontoar itens — Use subdiagramas
  • Sobrepor itens — Use subdiagramas
  • Cruzar conectores — Use linhas ortogonais
  • Uso excessivo de contêineres — Aplique-os apenas quando realmente adicionarem valor
  • Elementos com tamanho inadequado — Redimensione
Figura 10. Evite esses erros
Evite esses erros

Abstraindo do tempo de execução

A criação de um blueprint exige a capacidade de diferenciar entre aspectos funcionais da solução e considerações do tempo de execução. Um erro comum é a captura dos detalhes do tempo de execução no blueprint. A Figura 11 ilustra as melhores práticas a seguir:

  • Capture no blueprint a função de um componente da solução, e não a sua implementação interna. É possível usar o recurso de link de ativos para conectar os artefatos do tempo de execução do componente ao elemento correspondente, mas os artefatos em si não devem ser manifestados como elementos no blueprint da solução.
  • Capture a estrutura lógica e o relacionamento dos componentes usando elementos e seus relacionamentos através de conectores. As entradas e saídas de elementos podem, mais uma vez, ser conectadas a eles usando o recurso de link de ativos.
Figura 11. Evite capturar o tempo de execução
Evite capturar o tempo de execução

Decompondo fluxos de dados

Um fluxo de dados entre dois sistemas pode envolver um número maior de tarefas, como extração, alinhamento estrutural, alinhamento semântico, padronização, correspondência e deduplicação, e uma transformação final para o modelo de dados de uma interface de carregamento técnica. Tentar colocar todas as etapas em um único blueprint pode resultar em detalhes em excesso. Uma solução pode envolver vários fluxos de dados entre vários sistemas, exacerbando ainda mais esse problema de um fluxo de dados entre dois sistemas. Portanto, da perspectiva de melhores práticas, recomendamos o seguinte:

  • Decompor a solução geral em blocos de criação lógicos, de alta granularidade, representando os principais requisitos.
    • Os blocos de criação lógicos de alta granularidade tornam-se os componentes de nível superior do primeiro diagrama de blueprint.
  • Use subdiagramas de forma incremental para decompor os componentes de nível superior.
  • Ao aplicar a decomposição, use as técnicas de referência mencionadas anteriormente para ilustrar melhor o contexto da definição mais detalhada.

A Figura 12 mostra como o componente Integrate Sources é decomposto usando um subdiagrama que mostra todas as etapas detalhadas, necessárias para realizar a integração de origens.

Figura 12. Decomposição de fluxos de dados
Decomposição de fluxos de dados

Definindo visualizações conceituais

Para muitas soluções, como data warehousing ou gerenciamento de dados principais, um aspecto essencial durante a fase de design é oferecer insight sobre os relacionamentos de certas entidades de negócios e como elas são gerenciadas em um nível conceitual. Nesse caso, pode ser útil decompor um data warehouse em componentes para processamento (carga ETL etc.) e em uma visualização conceitual dos esquemas. Os esquemas podem ser decompostos incrementalmente para conceitos com granularidade mais baixa com propriedades anotadas. Esse processo é mostrado nas Figuras 13 e 14.

Da perspectiva de melhores práticas, há algumas diretrizes para seguir ao usar visualizações conceituais:

  • A decomposição de visualizações conceituais é uma abordagem de forma livre para os esquemas e não deve ser usada para substituir a criação de modelos de dados necessários usando técnicas de modelagem de relacionamento de objeto ou entidade apropriadas. Essa modelagem deve continuar acontecendo em ferramentas como IBM InfoSphere Data Architect.
    • Se tiver o Blueprint Director instalado e em compartilhamento de shell com o InfoSphere Data Architect, é possível, após criação da visualização conceitual do esquema no Blueprint Director, iniciar o trabalho de modelagem de dados no InfoSphere Data Architect (e também alternar para o Blueprint Director caso seja constatado, durante a modelagem, que é necessário alterar a visualização conceitual).
  • De forma ideal, a decomposição e a criação de visualizações conceituais para um esquema devem ser conduzidas e controladas por definições de glossário padrão. Portanto, as entidades em uma visualização conceitual devem ser vinculadas aos termos apropriados no InfoSphere Business Glossary.

Como resultado da criação de visualizações conceituais, o arquiteto cria e captura os principais conceitos dessa parte da solução e pode repassá-las ao público apropriado.

Figura 13. Criando um esquema conceitual
Criando um esquema conceitual
Figura 14. Decompondo um esquema conceitual
Decompondo um esquema conceitual

Estendendo a paleta

O design de blueprints de soluções sempre tem o objetivo de comunicar aspectos importantes da solução a outros usuários. Portanto, pode ser necessário criar elementos para operações específicas ou sistemas em um ambiente de TI que possam ser facilmente distinguidos dos outros. O Blueprint Director permite estender os elementos da paleta de desenho. O processo é simples:

  1. Acesse o Menu Blueprint e selecione Extend Palette.
  2. Selecione Add Element, como mostra a Figura 15. Observe a presença de outros elementos customizados já incluídos nas listas Drawer.
  3. Dê um nome ao novo elemento, como mostra a Figura 16. Selecione o Drawer relevante e informe a localização de um arquivo de 16x16 pixels para o ícone pequeno e de um arquivo de 32x32 pixels para o ícone grande (esses ícones representarão o novo elemento graficamente).
  4. Opcionalmente, atribua outras propriedades, como Name ou Description, para a instância específica (veja a Figura 17).
  5. Clique em Finish quando concluir.

Se você salvar e distribuir o blueprint, esses novos elementos de paleta serão distribuídos com eles ou os modelos automaticamente. Observe que também é possível alterar e estender elementos existentes na paleta.

Figura 15. Estendendo a paleta
Estendendo a paleta
Figura 16. Identificando o novo elemento
Identificando o novo elemento
Figura 17. Incluindo propriedades de atributos no novo elemento
Incluindo propriedades de atributos no novo elemento

Da perspectiva de melhores práticas, recomendamos não estender a paleta de forma arbitrária. A principal decisão é tomar decisões lógicas entre clareza visual contra informações em excesso (por exemplo, imagens demais para as pessoas acompanharem). O propósito de um elemento na paleta é:

  • Proporcionar ícones distintos para ajudar a diferenciar entre elementos que não são iguais.
  • Evitar ter ícones demais, o que frustra o objetivo, pois o usuário não poderá reconhecer todos eles.

É necessário ter um equilíbrio entre incluir para maior clareza e incluir para ter algo diferente.


O blueprint de informações

Soluções de grande escala que fazem uso intenso de informações geralmente processam dados em várias formas persistentes, como arquivos, diferentes tipos de bancos de dados, content stores etc. e também processam esses dados por meio de diversas técnicas de integração de dados, como federação, ETL, serviço de informações e captura dos dados de mudança.

O conjunto de tecnologias e padrões em uso poderia ser considerado ilimitado, cada um com seu próprio conjunto de ferramentas, métodos e abordagem ao gerenciamento de metadados. Um blueprint de informações pode ser considerado uma representação lógica da solução com uso intenso de informações e de todas as suas partes. Um blueprint de informações geralmente expressa uma abstração de nível superior de toda a solução, apoiada por várias camadas de decomposição de segmentos, ilustrando a interação dos componentes na solução, como mostra a Figura 18.

Figura 18. Analisando um blueprint de informações
Analisando um blueprint de informações

Esse blueprint de informações pode oferecer valor limitado simplesmente como um diagrama. Um verdadeiro blueprint de informações deve ser, ao mesmo tempo, vinculado e proativo. Ser vinculado e proativo significa que o blueprint está conectado e interagindo com o conjunto de ferramentas usado para desenvolver os componentes da solução com uso intenso de informações.

Em teoria, um blueprint de informações pode ser vinculado e estar interagindo com qualquer artefato ou ferramenta, mas, por simplicidade, podemos considerar duas formas principais de vinculação:

  • Link para os artefatos de metadados da solução
  • Link para o conjunto de ferramentas de implementação e artefatos de desenvolvimento que suportam a solução

É importante notar que há uma certa sobreposição aqui. Conjunto de ferramentas com conhecimento de metadados, por exemplo, geralmente contém os metadados dos componentes da solução (para qualquer uma das três formas de metadados discutidas anteriormente) e os artefatos de desenvolvimento sendo usados para desenvolver componentes específicos da solução.

Vinculando para um cenário de metadados

O termo metadados, também chamados de dados sobre dados, descreve estruturas de dados de várias perspectivas diferentes, incluindo metadados de negócios (termos de negócios e regulamentos que se aplicam a informações de um tipo específico, como funcionário, por exemplo), metadados técnicos (a estrutura lógica e física de dados em termos de modelos lógicos e físicos, por exemplo) e metadados operacionais (detalhes do tempo de execução de uma tarefa ETL, como o tempo de execução, duração e número de linhas processadas, por exemplo). É importante notar que esses metadados não devem ser encarados como um conjunto de estruturas interessantes, porém desconectadas. Pelo contrário, os metadados tornam-se mais úteis quando são encarados como uma teia interconectada de artefatos, na qual as extremidades entre eles têm uma semântica conhecida dependendo dos artefatos envolvidos e do tipo de relacionamento considerado.

Por exemplo, as informações de cliente existem em várias empresas e em muitos sistemas de TI, com modelos de dados lógicos e físicos diferentes, que podem ser vinculados ao mesmo termo de negócios "cliente" em um glossário corporativo. Um sistema MDM central pode agir como uma fonte confiável de informações da qual as informações do cliente são repassadas para os vários sistemas consumidores, com diferentes transformações que as mapeiam do modelo de dados do cliente no MDM para os vários modelos dos consumidores. A decisão de mudar o modelo de dados de MDM nesse ambiente não pode ser feita sem considerar o impacto nos artefatos relacionados. Por isso, ao olhar para o cenário de metadados, os seguintes aspectos devem ser considerados separadamente:

  • Gerenciamento de ciclo de vida— Quando o gerenciamento de mudanças é um aspecto importante, recursos como linhagem de dados (os dados que eu estou vendo estão vindo de onde?), análise de impacto (quantos artefatos são afetados se uma certa mudança for aplicada?) e exploração de metadados são técnicas essenciais para controlar o gerenciamento de mudanças.
  • Aspecto de design e desenvolvimento— Os metadados são, obviamente, uma parte fundamental de qualquer projeto de design ou desenvolvimento de dados. Modelos de dados (as informações sobre os dados do sistema que supostamente são criados ou alterados), desenvolvidos durante a fase de design, são uma entrada importante para o trabalho de desenvolvimento de tarefas de ETL etc.

Com isso em mente, o cenário de metadados pode ser caracterizado como um cenário de informações em si, abaixo do nível de uma visualização de negócios comum, pois representa insight sobre como as informações são agrupadas e gerenciadas. Da perspectiva das melhores práticas, recomendamos a incorporação de um cenário de metadados como um subdiagrama abaixo de um dado cenário de informações. Isso ajuda a entender como glossários e modelos suportam uma certa estrutura de dados e onde o gerenciamento de mudanças/ciclo de vida precisa ser aplicado na visualização de destino. Com esse diagrama de cenário de metadados disponível, surgem também as seguintes vantagens:

  • Há um lugar disponível para vincular diretamente aos ativos que representam esses componentes de metadados.
  • É possível desenvolver mapas conceituais nesse cenário de metadados.

Observe que essa estrutura pode exigir o encapsulamento em um objeto de referência, se o cenário de metadados tiver suporte para mais de um componente. A Figura 19 mostra um exemplo de cenário de metadados.

Figura 19. Um cenário de metadados de exemplo
Um cenário de metadados de exemplo

No cenário de metadados mostrado acima, não são os elementos de glossário individuais, entidades lógicas ou modelos físicos que são incluídos. É o armazenamento desses itens, tratados como dados, que é incluído, o que transforma esse cenário de metadados em outra instância de um blueprint de informações. A modelagem continua sendo a área das ferramentas de modelagem, mas assim captura-se e entende-se o modo como os metadados, como informações, fluem ou semovem de ponto a ponto.

Cenário de implementação física

O cenário de implementação física é outra visualização do cenário de informações. Essa visualização traz informações sobre os produtos utilizados para gerenciar o cenário de informações ou os ativos de informações implementados em um cenário de produção. Observe que é considerada uma melhor prática a descrição das ferramentas usadas para desenvolver a solução através do método e a vinculação dos artefatos de ferramentas aos diagramas de blueprint com os vinculadores de ativos. No entanto, do ponto de vista de gerenciamento de ciclo de vida e de mudanças, é importante entender as estruturas físicas de uma solução.

Como parte da solução representada no Blueprint Director com o uso de diagramas, pode ser necessário incluir um subdiagrama para exibir a visualização de implementação em termos de ambientes de desenvolvimento, teste e produção, ilustrando como os ativos vinculados ao blueprint de solução desenvolvido no ambiente de desenvolvimento são propagados através dos processos de teste para o ambiente de produção. Da perspectiva de melhores práticas, pode ser útil aplicar as seguintes considerações de design:

  • Criar um blueprint mostrando todos os ambientes
  • Criar um blueprint por ambiente mostrando os detalhes

A Figura 20 mostra que, para um projeto de consolidação SAP, há um ambiente do InfoSphere Information Server para cada ambiente SAP configurado para desenvolvimento, teste e produção. As tarefas que extraem ou carregam dados em sistemas SAP podem ter componentes de código ABAP. Como mostra a Figura 20, esses componentes de código ABAP podem ser transferidos por upload para o sistema de desenvolvimento SAP apenas a partir do sistema de desenvolvimento do Information Server (IIS). São propagados a partir do lado do SAP do desenvolvimento para o teste, e do teste para a produção. Essa abordagem é seguida a partir do lado do Information Server para garantir que, nos ambientes de teste e produção, todos os artefatos de código sejam somente leitura, e que qualquer mudança deve ser feita no ambiente de desenvolvimento e propagada usando o ciclo de teste apropriado para o sistema de produção SAP. Como mostra esse exemplo, é possível usar o Blueprint Director para estabelecer uma visualização arquitetural que ofereça suporte à maneira como o código (ou configuração de parâmetro, patches etc.) deve ser propagado para ambientes de teste e produção.

A propósito, o ícone de aplicativo SAP mostrado na Figura 20, que é uma extensão de paleta desenvolvida para um caso de uso de consolidação de SAP, é um exemplo de como usar extensões de paleta em blueprints.

Figura 20. Ambientes
Ambientes

Na Figura 20, para cada ambiente, a topologia de implementação física efetiva ainda não é mostrada, para evitar excesso de detalhes no blueprint. Para cada ambiente, é possível ver o símbolo + amarelo, indicando que incluímos subdiagramas para maiores detalhes. A Figura 21 mostra os detalhes para o sistema de implementação InfoSphere Information Server (IIS). Como é possível ver, o Information Server está instalado em cinco nós físicos:

  • Um nó de aplicativo (ISD)
  • Três nós para três instâncias do mecanismo paralelo do DataStage (PX1 a PX3)
  • Um nó para o repositório de metadados (XMETA)

Todos os cinco nós do sistema primário estão em um único datacenter (Local de TI 1). Para o sistema primário, por motivos de high availability and disaster recovery (HADR), um sistema secundário está configurado em um datacenter diferente (Local de TI 2). Essa configuração para um sistema de implementação IIS pode ser necessária se a equipe de desenvolvimento de migração de dados consistir em várias dezenas de desenvolvedores (já vimos projetos com 50 a 150 desenvolvedores em um sistema de desenvolvimento IIS) distribuídos entre várias geografias, exigindo um ambiente com disponibilidade 24 horas pelo menos de segunda a sexta.

Figura 21. Topologia física para sistema de desenvolvimento IIS
Topologia física para sistema de desenvolvimento IIS

Ao capturar essa arquitetura de implementação em um blueprint, é fácil comunicar o seguinte:

  • Para a equipe de administração, existe o requisito de educação para configurar e operar uma implementação HADR do IIS.
  • É necessário tomar precauções para as partes interessadas de negócios para tornar os sistemas disponíveis e resilientes de acordo com requisitos de uso, por exemplo, recursos em outros países por razões econômicas.
  • Os procedimentos de backup e restauração devem ser mais avançados devido à topologia de implementação avançada.
  • É possível comunicar as mudanças em alterações e seu impacto na topologia de implementação física.

Esses são apenas exemplos, mas eles demonstram a utilidade de usar o Blueprint Director para comunicar a topologia de implementação física de uma arquitetura de solução e de um blueprint de informações para diferentes públicos, como administradores, desenvolvedores, gerentes de projeto e partes interessadas de negócios.


Conclusão

O IBM InfoSphere Blueprint Director fornece a capacidade de comunicar uma visão do seu cenário de informações à sua organização e à equipe em geral. Neste artigo, você:

  • Revisou as melhores práticas para criar blueprints efetivos do zero.
  • Aprendeu os benefícios de criar e gerenciar blueprints, visualizando o cenário de metadados com base em melhores práticas.
  • Aprendeu que é possível incorporar o cenário de implementação físico no blueprint de informações com base em melhores práticas.

Ao seguir essas melhores práticas, é possível concentrar-se melhor no aspecto crítico da comunicação para fazer seus projetos avançarem. A clareza na apresentação, entendimento consistente e a capacidade de visualizar todos os aspectos do cenário de informações para seu projeto em níveis variados ajudam a facilitar esse processo.

Recursos

Aprender

Obter produtos e tecnologias

  • Desenvolva seu próximo projeto com software de avaliação IBM, disponível para download diretamente do developerWorks.
  • Agora é possível usar o DB2 de graça. Faça o download do DB2 Express-C, uma versão gratuita do DB2 Express Edition para a comunidade que oferece os mesmos recursos de dados centrais que o DB2 Express Edition e fornece uma base sólida para desenvolver e implementar aplicativos.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Information Management
ArticleID=846878
ArticleTitle=Melhores Práticas para o IBM InfoSphere Blueprint Director, Parte 2: Projetando blueprints de informações do zero
publish-date=11262012