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.