1.3 Relevância da pesquisa
2.3.2 Alinhamento via Arquitetura Corporativa
2.3.2.3 Framework arquitetural do Open Group (TOGAF)
Influenciada por Zachman (1987), a primeira tentativa de desen- volvimento de uma arquitetura corporativa foi feita pelo Departamento de Defesa dos EUA, em 1994, no sentido de criar um alinhamento entre os projetos técnicos das agências americanas e a necessidade dos seus
negócios (SESSIONS, 2007).
Essa nova arquitetura ficou conhecida como a Technical Archi- tecture Framework for Information Management (TAFIM). Rapidamen- te, em 1996, o Congresso Americano aprovou a Lei Clinger-Cohen, denominada como a lei de reforma do gerenciamento da tecnologia da informação, que determinou a todas as agências de governo providên- cias para aprimorar a eficiência dos investimentos em TI (SESSIONS, 2007). A aprovação da lei impulsionou, de forma significativa, o desen- volvimento de uma arquitetura corporativa abrangente e integrada,para as agências e o governo americano.
No ano de 1998, o TAFIM foi repassado ao Open Group8, que
modificou seu conteúdo e estabeleceu para ele um novo padrão, hoje conhecido como framework Arquitetural do Open Group ou TOGAF9,
apresentada na Figura 13.
Figura 13: Estrutura da arquitetura corporativa – TOGAF. Fonte: Adaptado de Open Group10.
O Open Group divide a arquitetura corporativa em quatro catego- rias: a “Arquitetura de negócio”, que descreve os processos que o negó- cio usa para cumprir suas metas; a “Arquitetura de aplicativo”, que des- creve como os aplicativos específicos são programados e como intera- gem; a “Arquitetura de dados”, que descreve como é feito o armazena- mento dos dados, sua organização e acesso; e a “Arquitetura técnica”, que descreve as infraestruturas de hardware e software que suportam os
8 Maiores informações sobre o Open Group são encontradas em <http://www.opengroup.org>.
9 Informações detalhadas do framework em: <http://www.opengroup.org/togaf>. 10 Disponível em <http://www.opengroup.org/togaf>.
aplicativos e suas interações.
O TOGAF é constituído pelos componentes: Architecture Dev lopment Method
(
ADM); continuum corporativo; e a base de recursos. O método de desenvolvimento da arquitetura, conhecido como ADM, é o núcleo do framework TOGAF e base para a criação da arquitetura, a parte visível. O desenvolvimento dessa arquitetura usa o conceito de processo.Figura 14: Representação do continuum corporativo do TOGAF. Fonte: Open Group11.
O segundo componente, o continuum corporativo,
processo de criação de uma arquitetura específica a partir de um amb ente genérico, até chegar a uma definição bem detalhada, como obse vado na Figura 14. Esse componente é fundamental para manter uma integração das arquiteturas desenvolvidas, especialmente por fornecer uma taxonomia específica, utilizada em todos os processos de comun cação, que permite uma compreensão única dos termos utilizados no nível da organização e no seu relacionamento com os clientes e fornec
11 Disponível em: <http://www.opengroup.org/architecture/togaf9-doc/arch/chap39.html Acesso em: 17 ago. 2009.
Architecture Deve- base de recursos. O método de desenvolvimento da arquitetura, conhecido como ADM, é o TOGAF e base para a criação da arquitetura, a sua a arquitetura usa o conceito de
corporativo do TOGAF.
corporativo, considera o tetura específica a partir de um ambi- te genérico, até chegar a uma definição bem detalhada, como obser- vado na Figura 14. Esse componente é fundamental para manter uma
ração das arquiteturas desenvolvidas, especialmente por fornecer ecífica, utilizada em todos os processos de comuni- cação, que permite uma compreensão única dos termos utilizados no nível da organização e no seu relacionamento com os clientes e fornece-
dores.
Na Figura 14, a manutenção do padrão de arquitetura, da tax nomia, dos componentes, e a possibilidade de sua reutilização, estão disponíveis no “repositório corporativo”. O continuum corporativo é alimentado pelo ambiente, que fornece requisitos e o contexto no qual a arquitetura corporativa será desenvolvida. O continuum corporativo possui um feedback a partir da solução arquitetônica em uso
zação. A partir disso, é gerada a arquitetura, que atualiza o repositório e serve de base para o desenvolvimento da solução arquitetônica.
Figura 15: Representação do processo de desenvolvimento do TOGAF. Fonte: Open Group12.
O TOGAF define as várias bases de conhecimento que residem na arquitetura de fundamento, dentre as quais está o modelo de referê cia técnica e a fase de informações padrão. Embora ajudem na implant ção da arquitetura, essas bases são tendenciosas, favorecendo a portab lidade em detrimento da interoperabilidade e da autonomia do aplicativo (SESSIONS, 2007). O desenvolvimento da arquitetura corporativa s guindo o método ADM é realizado pelo processo apresentado na Figura 15, composto por uma fase preliminar e seguido de oito fases
12 Disponível em: <http://www.opengroup.org/architecture/togaf9-doc/arch/chap05.html Acesso em: 17 ago. 2009.
a manutenção do padrão de arquitetura, da taxo- mia, dos componentes, e a possibilidade de sua reutilização, estão
corporativo é alimentado pelo ambiente, que fornece requisitos e o contexto no qual a corporativo na organi- zação. A partir disso, é gerada a arquitetura, que atualiza o repositório e serve de base para o desenvolvimento da solução arquitetônica.
ção do processo de desenvolvimento do TOGAF.
O TOGAF define as várias bases de conhecimento que residem na arquitetura de fundamento, dentre as quais está o modelo de referên-
ão. Embora ajudem na implanta- são tendenciosas, favorecendo a portabi- lidade em detrimento da interoperabilidade e da autonomia do aplicativo
rporativa se- esso apresentado na Figura , composto por uma fase preliminar e seguido de oito fases, que for-
mam cada um dos ciclos de desenvolvimento de novas versões da arqui- tetura corporativa.
Na fase preliminar, o método sugere reuniões com os participan- tes, para conhecimento do processo do TOGAF, com base em três me- tas: garantir que todos estejam satisfeitos com o processo; modificar o processo do TOGAF para adaptá-lo à cultura organizacional; e definir o sistema de governança que supervisionará o trabalho de desenvolvimen- to da arquitetura do TOGAF.
Para desenvolver essa arquitetura, é necessário compreender a filosofia do negócio, seus modelos e os motivadores estratégicos da organização (SESSIONS, 2007). Nessa fase, serão definidos os princí- pios arquiteturais que orientam as arquiteturas tecnológicas, bem como a documentação desses princípios, dentro do formato recomendado pela arquitetura.
Na “Fase A” é apresentado aos participantes o esboço prévio sugerido para a arquitetura, sendo esta aprovada pelos participantes, para seu desenvolvimento inicial. O resultado dessa fase é a criação de uma visão arquitetural de referência na primeira passagem pelo ciclo ADM (o qual está baseado nos princípios estabelecidos na fase prelimi- nar e considera as necessidades e problemas dos envolvidos).
A “Fase B” utiliza a visão arquitetural criada na Fase A e desen- volve as arquiteturas detalhadas do negócio (básicas e finais). Esta fase envolve a modelagem e análise altamente detalhadas do negócio, bem como a documentação das exigências técnicas. O resultado desta fase é a descrição detalhada dos objetivos do negócio (básicos e finais) e a des- crição das lacunas existentes na arquitetura do negócio.
Na “Fase C” será desenvolvida a arquitetura dos sistemas de informações, cujo método sugere nove etapas específicas: descrever a arquitetura básica de dados; analisar e validar princípios, modelos de referência, pontos de vista e ferramentas; produzir modelos de arquitetu- ra, inclusive modelos de dados lógicos, de processos de gerenciamento de dados e de relacionamento que mapeiam as funções do negócio para operações de dados CRUD (Criar, Ler, Atualizar e Excluir); selecionar blocos de construção da arquitetura de dados; realizar revisões formais do ponto de controle do modelo de arquitetura e dos blocos de constru- ção com os participantes; revisar os critérios qualitativos (desempenho, confiabilidade, segurança, integridade); completar a arquitetura de da- dos; realizar análise de ponto de controle/impacto; e executar análise de lacunas. Os resultados dessa fase serão as informações finais e a arquite- tura de aplicativos.
necessária para dar suporte à nova arquitetura proposta, envolvendo, principalmente, a área técnica da organização. Na “Fase E” são avalia- das as várias possibilidades de desenvolvimento, sendo identificados os principais projetos que poderiam ser desenvolvidos, mediante a avalia- ção das oportunidades de negócio associadas a cada um deles. O método sugere a implantação incremental por área específica e que apresente o maior benefício, em curto prazo, para a organização.
Na “Fase F”, a equipe de governança vai priorizar os projetos identificados na Fase E, os quais incluem, além de custos e benefícios, os fatores de risco inerentes ao processo. Na “Fase G”, de posse dos projetos ordenados e priorizados, são criadas as especificações arquite- turais para os projetos de implementação. Essa fase inclui, portanto, os critérios de aceite e a listagem de riscos e possíveis problemas. Na fase final, a “Fase H”, o processo arquitetural de gerenciamento da mudança para os novos artefatos criados (nesta última interação do ciclo ADM) é modificado de acordo com as novas informações disponibilizadas.
A partir desse ciclo, composto por todas essas fases, a equipe já terá conhecimento adquirido para o próximo ciclo de desenvolvimento da arquitetura corporativa TOGAF. A aplicação desse método, contudo, depende decisivamente do envolvimento da equipe, não sendo produzi- da nenhuma solução mágica (SESSIONS, 2007), uma vez que ele utiliza especificações e definições genéricas que precisam ser adaptadas às situações de cada organização.
Assim, com esse método se obtém como resultado, segundo Ses- sions (2007), uma arquitetura específica para as necessidades da organi- zação, visto que não é um modelo prescritivo, mas que utiliza somente uma sugestão de entradas e saídas possíveis para cada uma das fases do processo ADM.