Total de visualizações de página

segunda-feira, 11 de novembro de 2013

Maturidade em dados-DMM-Data Maturity Model-Parte V



Plataforma e Arquitetura:
A categoria Plataforma e Arquitetura de GD tem dois grandes componentes, com 6 áreas de processos. O primeiro componente é FRAMEWORK ARQUITETURAL  e o segundo é PLATAFORMA E INTEGRAÇÃO, conforme a figura DMM-07, abaixo.

Figura DMM-07- Plataforma e Arquitetura

O Primeiro componente da Categoria Plataforma e Arquitetura é o Framework Arquitetural. Ele é composto de duas áreas de processos. A primeira é a Padrões Arquiteturais(26). Esse processo objetiva a identificação de padrões de arquitetura que serão usadas na empresa, sob a visão de GD. É  como se olhássemos a arquitetura de dados, nas suas diferentes nuances: modelagem de dados, modelagem de mensagens(SOA, Mensageria), metadados, dados transacionais(legados,ERP), dados analíticos(DW,DM), Big data(Sharding,Sand Box),dados não estruturados(Content Management), distribuição de dados(MPP), integração(ETL),etc. Cria uma visão lógica e ampla da arquitetura de TI com os elementos de dados e inclui sistemas operacionais, ETL-Extração, Transformação e Carga e linguagens. Incluem orientações para adaptações no caso de se ajustar determinadas arquiteturas para certos ambientes operacionais, demandados em projetos. Sugerem padrões que incluem guias relativos a :  escolha de hardware e sistemas operacionais, regras associadas com níveis de manutenção de hardware e software; padrões de criptografia e segurança; expectativas de performance para vários tipos de operações de dados, como “analytics” e transacionais; importação e exportação de dados , auditoria, retenção e métodos de acesso para diferentes tipos de data stores; opções de projeto de bancos de dados; regras de normalização; formatos de armazenamento e acesso; guia para espaço de tabelas e limitações; projetos de MDM(abordagem de registry/index, híbrido, federada, single master,etc); regras de tradução de dados; métodos de interfaces e API; padrões de qualidade,etc. Na essência envolve: Padrões de arquiteturas (relacionadas a dados), políticas e regras de aderência a elas; acompanhamento e manutenção desses padrões; possíveis alterações e evolução deles.
O processo seguinte deste componente é Abordagens Arquiteturais(27). Esse processo define a  arquitetura de processo  e arquitetura técnica usada para adquirir, produzir, armazenar e entregar dados às aplicações consumidoras e unidades de negócios. Objetiva projetar um framework de produto  e  processo que atenderá às necessidades da empresa  e que seja seguro, confiável, adaptável e consistente com os padrões estabelecidos. O output é uma visão lógica que se transforma no “blueprint” desejado para a  abordagem arquitetural usada para as  implementações específicas .  A arquitetura é traduzida em um “roadmap”  de implementações de TI, de acordo com a realidade orçamentária, que incorpora aderência com  as abordagens padrões, definidas anteriormente. Pode ser entendida como a aplicação dos Padrões arquiteturais, vistos anteriormente, em projetos e situações específicas. Em linguajar CMMI e MPS.BR seria algo como a arquitetura padrão adaptada para a criação da arquitetura definida. Na essência envolve:  Foco na arquitetura; arquitetura a ser implantada, documentada, analisada e aprovada contra os padrões definidos; fluxo dos dados por entre os elementos da arquitetura; coerência com as plataformas(PA seguinte) onde será “deployed”.
O outro componente desta categoria é PLATAFORMA e INTEGRAÇÃO. O anterior falava de arquitetura, digamos numa visão mais conceitual e este fala de Plataformas, uma visão mais estrutural. Arquiteturas estabelecidas sobre plataformas e plataformas recebendo arquiteturas de soluções. Nesse componente há 4 PA´s ou processos. A primeira PA é a Plataformas de GD(28). Esse processo visa definir as plataformas em função dos requisitos de dados e das arquiteturas definidas . O processo visa também interpretar o ambiente tecnológico como um sistema único, gerenciado por um conjunto de instruções, por uma entidade de negócios definida. São definidos pontos de como a plataforma será gerenciada e como os sistemas a integrarão. Um passo importante nesse processo é realizar um inventário das plataformas existentes, com sistemas e capacidades para analisar a sua oportunidade de reutilização. A visão de plataformas deve ser um projeto plurianual, dentro de padrões organizacionais definidos e com “blueprint”(esquema/arquitetura) aprovados para facilitar integração. Aspectos de restrições de acesso e de configuração são considerados na gerência das plataformas. A integração das plataformas é um fator a ser considerado. Na essência envolve: conjunto de sistemas de  registros de dados(arquivos,BD) e plataformas como SAP,Oracle,DB2, IBM-InfoSphere,etc

A seguir  vem a PA associada com Integração de Aplicações(29). Esse processo descreve como as aplicações existentes serão reconciliadas e integradas no ambiente arquitetural de dados. Tem como objetivo garantir que o dado mantido pela organização possa ser gerenciado de forma que seja consistente com o seu objetivo original  e numa forma que permita que o ele(dado) seja eficientemente usado pela organização.  Integração é o coração da atividade de GD e é  um fator crítico a ser pensado antes que a organização possa obter os benefícios associados com o investimento no projeto arquitetural. A complexidade dos componentes de integração pode ser grande, tornando crítico que os envolvidos relevantes entendam os componentes, relacionamentos e dependências associadas com as entregas de projeto; mantenham  uma “visão longa”  sobre o estado final; entendam a natureza iterativa do objetivo da integração  e mantenham flexibilidade quando defrontados com obstáculos de integração. Usuários de negócios necessitam entender o processo de integração e a lógica de decisão que precisa ser aplicada na arquitetura. Entender as necessidades de TI para definir o processo de tomada de decisão do negócio, as regras de negócios e a lógica por traz  das regras de negócios se o processo de negócio tiver que ser  efetivo. A falta de clareza nos requisitos e a pobre tradução entre TI e negócios pode causar dano(ruptura) na realização dos benefícios do programa  de GD. Requisitos de negócios, abordagens de TI e múltiplas visões de dados na organização necessitam ser verificados (e reverificados) numa forma contínua para garantir que esses relacionamentos estejam corretamente entendidos. Na essência envolve: Integração de plataformas , arquiteturas e dos dados, em última análise de dados. Envolve planos de integração e de implantação e é uma espécie de ITP do MPS.BR e de PI do CMMI, com foco nos dados.
A seguir, dentro do mesmo componente vem  Gerência de Liberação(30). Esse processo objetiva definir como a organização gerencia as alterações nos “data feeds”(fluxos de atualização de dados), incluindo os procedimentos de “rollback” no caso de “quebras”/ do sistema e  trata da  comunicação para os sistemas “potencialmente” afetados. Objetiva ter uma abordagem definida e aprovada para gerenciar alterações no ambiente operacional (sistemas e  fontes de dados). A Gerência de release(liberação) é realizada como uma parceria entre “proprietários” de negócios, proprietários/responsáveis pelos dados e TI para analisar e endereçar qualquer pendência relacionada ao processo, alterações de fontes, infraestrutura de rede, hardware e  aplicações que suportam a gerência de dados. Há uma forte dependência/relacionamento com a gerência das interfaces de dados. A gerência de release(liberação)  pode ser planejada ou ser uma resposta a um problema. Em qualquer caso, o planejamento formal  e a coordenação com os envolvidos é  essencial para garantir alinhamento ao longo da organização. No fundo, objetiva garantir que a integridade dos dados seja mantida quando ocorrerem alterações em “data feeds” e sistemas. É uma espécie de “como” do processo de gerência de alteração(23). Por último, fechando a categoria de Plataforma e Arquitetura vem a parte de Dados Históricos(31). Esse processo define a abordagem usada para gerenciar a história de dados (alterações de dados) bem como a gerência de dados históricos(archives e informações sobre dados e metadados). Objetiva  garantir que o dado mantido pela organização é gerenciado de forma consistente, alinhado com os requisitos de retenção de dados e mantidos de acordo com os seus objetivos. Deve haver regras(para padrões de campos , regras para modelagem de dados, segurança de dados e permissões) para definir os dados históricos a serem capturados e armazenados. As políticas de arquivos históricos de dados(archives) necessitam ser documentadas para atender os aspectos regulatórios sobre retenção de dados. Fontes autorizadas de arquivos históricos de dados(archives) necessitam ser mantidas incluindo registro de quem fez a alteração e o “racional” para a alteração.