Enterprise Architecture V - Framework Zachman para EA

Pessoal, vamos começar a abordar as metodologias de EA no contexto do nosso estudo de caso iniciando com o Framework Zachman.

A primeira idéia que precisamos entender do Framework Zachman é que não se trata de um framework, pelo menos no meu entendimento.

Segundo a American Heritage, a definição de framework é a seguinte :

“Estrutura para suporte ou confinamento de algo, Suporte de armação usado como base para algo em construção; plataforma de trabalho externa; andaime; estrutura fundamental como aquela para um trabalho escrito; conjunto de premissas, conceitos, valores e práticas que constituem um modo de observar a realidade”

Por outro lado, temos a definição de taxonomia :

“Classificação de organismos em um sistema ordenado que indica relacionamentos naturais; ciência, leis ou princípios de classificação; sistemáticas; divisão em grupos ou categorias ordenadas. “

Entendo que o “Framework” Zachman na verdade é uma taxonomia para organização de objetos arquiteturais que considera a quem se destina o artefato e qual problema específico está sendo abordado.

John Zachman descreveu retrospectivamente seu trabalho da seguinte forma:

“O Framework, conforme aplicado às empresas é simplesmente uma estrutura lógica para classificação e organização das representações descritivas de uma empresa, significativa à administração da empresa, assim como ao desenvolvimento dos sistemas corporativos.”

Muitas pessoas que propõe o Framework Zachman o consideram interdisciplinar e sua influencia estende-se muito alem da área de abrangência da TI.

Um livro conhecido de Zachman cita o seguinte :

“No devido tempo você descobrira que o framework existe em tudo que se faz, não apenas nos projetos de TI. Ao entender perfeitamente o framework, você se torna mais eficiente em tudo o que faz, tudo. Esta não é uma afirmação leviana.”

O próprio Zachman afirmou em entrevista :

“O esquema de framework faz parte do nosso mundo há milhares de anos e, estou certo, continuará assim por mais alguns milhares de anos. O que muda é a nossa compreensão do framework e de como usá-lo para as áreas da engenharia e fabricação da empresa.”

Zachman explicou sua taxonomia de TI fazendo analogia ao setor de Construção. Artefatos arquiteturais no setor de Construção são implicitamente sistematizados por meio de uma organização bidimensional. Uma dimensão representa vários participantes do jogo. Em um edifício alguns desses participantes são o proprietário, o construtor e o conselho de zoneamento.

O Arquiteto de edificações elabora artefatos para cada um dos participantes. Cada participante necessita de informações completas, sendo que o que constitui “completo” varia de acordo com cada participante. O proprietário muitas vezes não necessita de informações que são pertinentes somente ao construtor, e vice versa.

Zachman citou em seu artigo original :

“....Cada uma das representações arquiteturais difere das outras em essência, não somente no nível do detalhe”.

A segunda dimensão do artefato arquitetural é o enfoque descritivo do artefato: o que, como, onde, quem e o porque do projeto. Esta dimensão é independente da primeira. Construtor e proprietário precisam conhecer o quê, porem a resposta para a pergunta, O que? Depende de quem pergunta.

Zachman propôs a existência de seis enfoques descritivos : dados, função, rede, pessoas, tempo e motivação, e seis perspectivas de participantes : planejador, proprietário, programador, construtor, subcontratado e empresa, em seu primeiro artigo e na elaboração subseqüente de 1992.

Na perspectiva do proprietário do negócio, os dados são as entidades de negócio. Podem incluir informações sobre as próprias entidades, como clientes, produtos, bem como informações sobre o relacionamento dessas entidades, como grupos, etc. Quando falar com um proprietário de negócio sobre dados, esta é a linguagem adotada.

Na perspectiva da pessoa que programa o Banco de Dados, dados não significam entidades de negócio, mas sim linhas e colunas organizadas em tabelas que se relacionam entre si por uniões e projeções matemáticas. Se estiver falando com o programador do banco de dados sobre os dados, não mencione grupos ou entidades, mas tabelas relacionais na terceira forma normal.

Uma dessas perspectivas não é melhor do que a outra, nem mais elevada ou de maior prioridade. As duas são criticas para uma compreensão holística da arquitetura do Sistema.

Zachman disse:

“Estamos tendo dificuldades de comunicação interpessoal sobre a arquitetura dos sistemas de informação porque existe um conjunto de representações arquiteturais, em lugar de uma única arquitetura. Uma não esta certa e a outra errada. As arquiteturas são diferentes. São aditivas e complementares. Existem razoes para preferir despender os recursos para o desenvolvimento de cada representação arquitetural. E existem riscos associados ao não desenvolvimento de nenhuma das representações arquiteturais.”

Discutiremos aqui como o Framework Zachman pode ajudar a construir o GSys-EA.

Como pode ser notado na figura acima, existem 36 células convergentes em uma rede zachman : uma para cada ponto de encontro entre a perspectiva de um participante e um enfoque descritivo. Navegando no sentido horizontal encontramos descrições diferentes no sistema mas sempre na perspectiva do participante, navegando no sentido vertical, temos o mesmo enfoque, porem alternamos entre participantes.

Temos 3 sugestões da rede Zachman que podem ajudar a Gyn Supermarket a desenvolver a GSys-EA.

A primeira sugestão da taxonomia Zachman é que todos os artefatos arquiteturais devem residir em apenas uma célula. Não deve existir nenhuma ambigüidade sobre onde reside um determinado artefato. Caso não esteja claro em qual célula um determinado artefato reside, provavelmente o próprio artefato estará com problema.

Na medida em que a Gyn Supermarket acumula artefatos para o desenvolvimento da GSys-EA, pode-se utilizar a rede Zachman com o intuito de esclarecer o enfoque de cada artefato. Por exemplo : Artefatos relacionados a serviços residem na terceira linha (Perspectiva do Programador). Em geral não despertaram interesse no proprietário do negócio.

A segunda sugestão da taxonomia Zachman é que uma arquitetura só pode ser considerada completa quando cada célula dessa arquitetura estiver completa. Cada célula estará completa quando contiver artefatos suficientes para definir plenamente o sistema para um participante específico, pelo prisma de um específico enfoque descritivo.

Com todas as células preenchidas, com os artefatos adequados, existirá volume suficiente de detalhes para descrever plenamente o sistema pela perspectiva de cada participante (Conhecido também como stakeholder) observando o sistema de todos os ângulos possíveis. Dessa forma, a Gyn Supermarket poderá utilizar a rede Zachman para assegurar que discussões adequadas ocorram entre todos os participantes destacados na GSys-EA.

A terceira sugestão da rede Zachman é que as células das colunas deveriam se relacionar entre si. Considerando a coluna de Dados da rede Zachman, pela perspectiva do proprietário do negócio os dados são informações sobre o negócio, já pela perspectiva do administrador do Banco de Dados, dados são linhas e colunas do banco de dados.

Apesar da diferencia de visão dos dados entre o proprietário e o administrador do banco de dados, deveria existir algum relacionamento entre essas perspectivas. Alguém deveria ter condições de acompanhar as necessidades de Juliana para os negócios e mostrar que o projeto do banco de dados, na verdade, usa essas exigências como o caminho a seguir. Se Juliana tinha exigências que não podiam ser acompanhadas até o projeto do banco de dados, temos que fazer a pergunta se as necessidades de negócios serão atendidas por essa arquitetura. De outra forma, havendo elementos do projeto de banco de dados que não possam ser rastreados retroativamente até as exigências do negócio, deveríamos nos perguntar se não incluímos itens de projeto desnecessários no nível do banco de dados.

Desta forma, temos 5 maneiras através das quais a rede Zachman ajuda no desenvolvimento da GSys-EA, seguidos :

1) Garantia de que a perspectiva de cada participante seja considerada em cada ponto do enfoque descritivo.

2) Aprimoramento dos próprios artefatos do GSys-EA, enfatizando cada um dos respectivos pontos de enfoque para um determinado interesse, de um determinado publico alvo.

3) Garantia de que todas as exigências de Juliana para o negócio sejam acompanhadas até algum tipo de implementação técnica.

4) Convencer Juliana que a equipe técnica de José não pretende construir diversas funcionalidades inúteis.

5) Convencer José que o pessoal comercial está incluindo o pessoal de TI no seu planejamento.

A rede Zachman por si só não representa uma solução completa para a Gyn Supermarket. Existem muitas questões, criticas para o sucesso do GSys-EA, que a rede Zachman não aborda. Como exemplo : A rede Zachman não nos oferece um processo incremental, passo a passo, para criar uma nova arquitetura, também não nos ajuda muito a decidir se a arquitetura futura sendo criada será a melhor arquitetura possível. Nesse ponto, a rede Zachman sequer oferece uma abordagem para mostrar a necessidade de uma arquitetura futura.

Como podemos notar, esse é um assunto interessante e que merece atenção por parte dos profissionais voltados a TI.

Espero que o texto tenha sido de valia para você!!!

Para quem quizer mais informações sobre o framework, segue o link do site oficial :
http://www.zifa.com/

Até o próximo Post, abraços!


"Escolha o trabalho de que gostas e não terás de trabalhar um único dia em tua vida." [Confucio]

Enterprise Architecture IV - Estudo de Caso

Para que possamos analisar as 4 principais abordagens de EA, utilizaremos um cenário similar e veremos como cada uma delas se aplica nesse cenário.

Para o cenário, utilizaremos uma rede de Supermercados, Gyn SuperMarket.

A Gyn Supermarket desenvolveu um inovador sistema de software que lhe permitia administrar as lojas com muita eficiência. O Sistema era chamado de GynSystem, ou GSys.

O GSys incorporou algumas funcionalidades inovadoras que permitiam gerenciar o relacionamento com os clientes, administração de inventário, faturamento automático, e otimização dos serviços de infra-estrutura.

O GSys era composto por 3 programas. GSys/Loja, executado nos computadores dispostos nas lojas, GSys/Depósito, executado no servidor de aplicações e o GSys/Sede, executado em um servidor de grande porte na sede da Gyn Supermarket.

A Comunicação desses 3 programas era provida através de arquivos transferidos entre os locais (Loja è Depósito, por exemplo). Se houvessem uma linha de comunicação confiável, a transferência dos arquivos poderiam ser realizadas via FTP. O Sistema também era suficiente flexível para suportar transferências realizadas por courier, quando necessário.

Em 2000, a Gyn Supermarket estava muito bem, muito em função da redução de custos realizada devido a eficiência do sistema GSys.

Com isso, a Gyn Supermarket decidiu expandir seus negócios e fez a aquisição de mais 3 cadeias de Supermercados regionais. Com isso a Gyn Supermarket ampliou seu alcance através da região centro oeste do Brasil.

Em 2002 os sistemas de software haviam fomentado o sucesso da Gyn Supermarket, porem atualmente atrasavam seu progresso de forma agressiva. Entre os problemas que a Gyn Supermarket atravessava, estavam :

· O GSys Depósito, exigia especializações Regionais. Por exemplo, era necessário ter suporte a vários tipos de tributação por região, e isso exigia mudanças no módulo GSys/Depósito.

· Os Depósitos regionais adquiridos tinham diferentes formas de receber os pedidos das lojas e vários procedimentos de compras dos atacadistas. Cada uma dessas diferenças também exigiam mudanças no módulo GSys/Depósito.

· A Abordagem de transferência de arquivos para compartilhamento de informações que funcionava tão bem, quando a cadeia da Gyn Supermarket possuía 30 lojas, um depósito Regional e Sede, tornava-se de difícil coordenação agora que a cadeia era composta por 200 lojas, 4 depósitos regionais, 2 escritórios geográficos e a Sede. Com isso ocorriam atraso nos envios do arquivo, muitas vezes os arquivos sequer eram enviados, ocorria duplicidade de envio, entre outros transtornos. Esse tipo de ocorrência dificultavam o acesso da sede a informações financeiras confiáveis e atualizadas, especialmente as informações relativas a venda e estoque.

A administração do Gyn Supermarket constatou que o sistema GSys precisava de muitos aprimoramentos. Entretanto a atualização do sistema era de difícil execução , por se tratar de módulos enormes, ineficientes e complicados.

As linhas de código atingiram um número exorbitante para cada módulo, tornando difícil modificar alguma função sem que houvesse efeitos colaterais em outras partes do sistema. Como as funções acessavam a mesma base de dados as mudanças em definição de registram poderiam se propagar através do sistema de modo imprevisível. Alterar uma única linha de código poderia demandar um refactoring enorme na aplicação.

O GSys tornou-se um problema, pois a depuração era difícil, as compilações complicadas e a instalação de novas funcionalidades causariam muitas interrupções.

Logo os problemas técnicos criaram conflitos internos na sede da Gyn Supermarket, pois a gestão comercial da corporação desejava adquirir outras redes de supermercados, enquanto a área de TI ainda tentava tornar on-line as aquisições realizadas.

Isso criou um divisor de águas entre a área comercial e técnica da Gyn Supermarket. A área comercial considerava que os recursos de TI retardavam a agilidade do negócio, e em contra partida a área de TI considerava as demandas da área comercial impossíveis de serem cumpridas e as culpava por não terem sido consultados antes das tratativas de aquisição ser iniciadas.

A desconfiança chegou a tal ponto que o CIO da Gyn Supermarket não era mais considerado parte da equipe executiva. A área comercial não confiava no pessoal de TI e sempre que possível esquivava-se, e a área técnica por sua vez construía sistemas sem informações do pessoal da área comercial tornando esses aplicativos muitas vezes ignorados pela área comercial, e muitas vezes, abandonados.

Em 2009 a Gyn Supermarket enfrentava uma crise. A reforma dos sistemas era nitidamente necessária para flexibilização dos mesmos no intuito de atender as necessidades do negócio. Essa era uma proposta cara e a Gyn Supermarket não poderia fracassar.

Outro ponto tão importante quanto a reforma dos seus sistemas, a Gyn Supermarket precisava reconstruir seus relacionamentos internos. As disputas e desconfianças entre a área comercial e técnica da corporação afetavam o moral, eficiência e rentabilidade da empresa que há apenas alguns anos era líder do setor em rentabilidade, muito em função da utilização inovadora da TI, e agora lutava para manter-se fora do vermelho, também muito em função da inflexibilidade dos sistemas de TI.

Marcos, o CEO da Gyn Supermarket, precisava muito de uma solução. Em uma conferência de executivos ele soube como muitos de seus pares utilizavam EA para criar parcerias fortes entre suas equipes técnicas e comerciais no intuito de construir soluções com relação positiva entre custo e eficiência possibilitando a agilidade do negócio.

Marcos entendeu que esta abordagem merecia uma atenção mais detalhada. Orientou a seu CIO, José, que elaborasse uma recomendação sobre o uso de EA para a Gyn Supermarket. José vislumbrou que essa abordagem era muito consistente, e entendeu que uma iniciativa desse tipo precisaria começar de cima e envolver a área comercial desde o início.

Por recomendação de José, Marcos agendou uma reunião com Juliana, Vice presidente de negócios e com o próprio José. Marcos informou que havia decidido criar uma EA comum para a Gyn Supermarket e que proporcionaria a união entre a equipe técnica e comercial. Essa EA seria denominada EA Gyn Supermarket ou GSys-EA. Após concluída, a GSys-EA conduziria todos os novos investimentos em TI para garantir que cada tostão investido em TI revertesse em valor máximo para o negócio.

Marcos sabia que a GSys-EA era a melhor decisão para a Gyn Supermarket. A visão da GSys-EA tinha que funcionar, e Marcos dependia de José e Juliana para que tudo corresse bem.

Logo, esta é a situação, agora veremos como cada uma das 4 abordagens de EA pode fornecer uma solução para Gyn Supermarket.


Não posso dar-me ao luxo da política. Numa ocasião, fiquei cinco minutos a escutar um político e morreu-me um velhinho em Calcutá. (Madre Teresa de Calcutá)

Enterprise Architecture III - Histórico

O marco zero da EA ocorreu em 1987 com a publicação no IBM Systems Journal do artigo intitulado “A Framework for Information System Architecture”, concebido por J.A. Zachman.

Nele foi apresentado o desafio e a visão de EA que serviriam de orientação para o futuro dessa área.

O Desafio era gerenciar a complexidade de sistemas cada vez mais distribuídos.

Zachman citou : “O custo envolvido e o sucesso do negócio dependendo cada vez mais de seus sistemas de informação exigem uma abordagem disciplinada do gerenciamento desses sistemas.”

Zachman notou que o valor e a agilidade do negócio poderiam ser realizados de melhor forma se a arquitetura de sistemas possuísse uma visão holística, considerando todas as questões importantes de todas as perspectivas também importantes.

Essa abordagem multiperspectiva dos sistemas de arquitetura foi originalmente descrita como um “Framework Arquitetural dos Sistemas da Informação” e que logo passou a ser “Framework EA”.

Zachman foi a influência de uma das primeiras tentativas realizadas por alguma agencia do governo americano, o Departamento de Defesa, para criação de uma arquitetura corporativa.

Tentativa essa conhecida como TAFIM(Technical Architecture Framework for Information Management), introduzida em 1994.

A promessa de EA, criar um alinhamento entre os projetos técnicos e as necessidades de negócio, foi percebida por ninguém menos do que uma entidade do congresso norte americano. O Congresso, influenciado pelos benefícios providos pela TAFIM, aprovou em 1996 um projeto lei que passou a ser conhecido como Lei Clinger-Cohen, conhecida também como lei da reforma do gerenciamento da tecnologia formado pelos CIOs de todas as principais entidades governamentais, para supervisionar essa iniciativa.

Em abril de 1998, o conselho de CIOs começou a trabalhar no seu primeiro e mais importante projeto, o framework de arquitetura corporativa federal (FEAF –Federal Enterprise Architecture Framework). A Versão 1.1 desse framework foi lançada em setembro de 1999. O Documento continha algumas idéias inovadoras, como as “Arquiteturas Segmentadas”, ou seja, enfoque arquitetural em subconjuntos segmentados da empresa maior.

Com o tempo a responsabilidade da FEAF passou para a OMB (Office of Management and Budget). Em 2002 a OMB evoluiu e renomeou a FEAF que passou a se chamar FEA (Federal Enterprise Architecture).

Apesar da atividade arquitetural corporativa muito significativa do governo federal, o progresso foi lento e as histórias de sucesso foram ofuscadas por falhas de perfil mais elevado. Em 2004, após 8 anos da Lei Clinger-Cohen, o GAO (General Accounting Office) informou o seguinte :

“Apenas 20 das 96 agências analisadas estabeleceram, no mínimo, o fundamento para o gerenciamento efetivo da arquitetura. Além disso, enquanto 22 agências cresceram em maturidade desde 2001, 24 outras agências perderam maturidade e 47 agências permaneceram inalteradas.”

Desde janeiro de 2005 o GAO (General Accounting Office) puniu severamente diversas agências do governo americano por deixarem de adotar ou utilizar arquitetura corporativa, como : FBI, Nasa, Departamento de Defesa e Departamento de Segurança Interna.

Em 1998, 4 anos após a introdução do TAFIM (Techinical Architecture Framework for Information Management) e 2 anos após sua codificação como Clinger-Cohen, a TAFIM foi oficialmente apresentada pelo Departamento de Defesa.

O trabalho realizado pelo TAFIM foi entregue ao Open Group, que modificou esse conteúdo em um novo padrão, conhecido hoje como Framework Arquitetural do Open Group, mais conhecido pelo seu acrônimo TOGAF.

Em 2005 a OMB tornava-se a força dominante no campo da arquitetura corporativa do setor público, e o grupo Gartner caminhava no mesmo sentido, só que na arquitetura corporativa do setor privado.

O Grupo Gartner já era uma das organizações mais influentes, especializada em consultoria de nível CIO. Porém, na área de Arquitetura Corporativa, o grupo de consultoria e pesquisa de TI mais conhecido não era o Gartner e sim o Meta Group.

O Grupo Gartner trabalhou no intuito de criar uma arquitetura corporativa mas jamais conseguiu atingir o status do Meta Group. Em 2005, como o Grupo Gartner notou que não conseguiria atingir o status do Meta Group, decidiu partir para outra estratégia, comprou o Meta Group.

Após a aquisição do Meta Group, durante 1 ano foi realizada uma analise para identificar o que cada Grupo tinha de melhor quanto a experiência e às metodologias para a Arquitetura Corporativa.

Ao final, decidiram por uma solução bastante simples: Se o Meta Group gostava, estaria OK, se não gostava, estaria fora de cogitação. O Grupo Gartner gostava dos Frameworks Arquiteturais, já o Meta Group optava pelo processo Arquitetural. Dessa forma, foi decidido que os frameworks estariam fora, e os processos seriam priorizados.

Bem pessoal, esse foi um breve histórico sobre EA.
No próximo post vou apresentar o estudo de caso fictício que utilzaremos para abordar as 4 metodologias mais conhecidas sobre EA.

"Desconfie do destino e acredite em você. Gaste mais horas realizando que sonhando, fazendo que planejando, vivendo que esperando... Porque, embora quem quase morre esteja vivo, quem quase vive, já morreu..."