Upload
angelo-antonello-borges
View
101
Download
2
Embed Size (px)
Citation preview
1
O SAP EAF e sua relação com o TOGAFSAP EAF and its relationship with TOGAF
ANGELO ANTONELLO BORGES1
RESUMO
O trabalho aqui proposto pretende refletir sobre a utilização e evolução das Frameworks de Arquitetura Empresarial: TOGAF e SAP Enterprise Archtecture Framework. Buscando demonstrar as possibilidades, e falhas ou necessidades de evolução, de cada uma delas, traçando um comparativo entre as duas arquiteturas.
Palavras Chaves: Framework, Arquitetura Empresarial, SAP, TOGAF.
ABSTRACT
The work proposed here is to reflect on the use and development of Enterprise Architecture Frameworks: TOGAF and SAP Enterprise Framework Archtecture. Seeking to demonstrate the possibilities and failures, or evolving needs of each one, drawing a comparison between the two architectures.
Key Words: Framework, Enterprise Architecture, SAP, TOGAF.
1
2
1. INTRODUÇÃO
Para responder questões como “O porquê do TOGAF” ou ainda “Porque utilizar SAP
EAF e não TOGAF”, necessitamos entender porque a arquitetura tem sido um tópico muito
importante para a indústria de TI. Nos anos 80 a vida na indústria de TI era relativamente
simples. Havia sistemas de computador gerenciáveis centralizadamente, com terminais burros
para fazer o trabalho. Então as áreas departamentais e os microcomputadores começaram a
surgir. Pouco após isto, os computadores pessoais e vários aspectos de integração entraram
em cena. O landscape de TI tornou-se mais e mais complexo. A arquitetura foi o termo
encontrado para descrever nossas atividades de gerenciamento dessa complexidade com
sucesso. A arquitetura e a infraestrutura pareciam ter noções intercambiáveis. Podíamos ver
alguns resíduos desse intercambio aqui e ali, mas o link com outros aspectos era óbvio e
necessitava de uma visão mais abrangente.
Com o trabalho dos consultores da da Capgemini, VAN'T WOUT et al. (2010), iniciou-se
uma formalização do que se destinava a arquitetura como parte de um programa de
transformação chamado Snowball; seu objetivo era introduzir a tecnologia cliente-servidor e o
desenvolvimento interativo na organização. A arquitetura era nosso approach, usado para
explicar como nós definimos cada infraestrutura que era necessária para suportar o negócio.
A Architecture Development Method (ADM), da qual falaremos mais abaixo, tornou-se
parte do material de treinamento do programa de transformação. Ele proviê mecanismos
standards e templates para a comunicação com o trabalho de desenvolvimento da arquitetura.
Ainda segundo o trabalho dos consultores da da Capgemini, VAN'T WOUT et al. (2010),
outro motivo que justificava a arquitetura de TI eram os grandes, e cada vez mais complexos
projetos. Que comumente requeriam uma transição de profissionais entre esses projetos. Isto
tornava difícil ter o arquiteto certo no local certo, e como fazer que sua arquitetura trabalhasse
da sua forma, esperando partes da arquitetura da infraestrutura que eram melhores alinhadas
entre os arquitetos daquela área. Era necessário desenvolver um framework que fosse possível
utilizá-lo para cobrir vários aspectos da arquitetura.
2. FUNDAMENTAÇÃO TEÓRICA
3
2.1 Entendendo o TOGAF
Conforme o The Open Group, o TOGAF é um framework – um método detalhado e
um conjunto de ferramentas de apoio – para o desenvolvimento de uma arquitetura
corporativa. Ele pode ser usado livremente por qualquer organização que pretenda
desenvolver uma arquitetura corporativa para uso dentro dessa organização. A chave para o
TOGAF é o ADM – um método confiável e comprovado para o desenvolvimento de uma
arquitetura de TI da empresa que atenda às necessidades do seu negócio (THE OPEN
GROUP, 2009, tradução nossa).
O TOGAF foi desenvolvido pelos membros do Open Group. Tendo sua primeira
versão, em 1995, baseada no Technical Architecture Framework for Information Management
(TAFIM), desenvolvido pelo Departamento USA de Defesa (DoD). O DoD deu ao Open
Group permissão explícita e incentivo para criar o TOGAF, com base no TAFIM, que em si
foi o resultado de muitos anos de esforço de desenvolvimento e muitos milhões de dólares de
investimento do Governo Americano (THE OPEN GROUP, 2009, tradução nossa).
A partir dessa base sólida, os membros do Open Group desenvolveram versões
sucessivas do TOGAF, cada ano publicadas no site público do Open Group. Sendo que até o
momento o TOGAF abraça, mas não estritamente a terminologia da ANSI/IEEE Std 1471-
2000 (THE OPEN GROUP, 2009, tradução nossa).
A estrutura dos componentes, suas inter-relações, bem como os princípios e diretrizes
que regem seu projeto e evolução ao longo do tempo. No TOGAF nós nos esforçamos para
encontrar um equilíbrio entre a promoção dos conceitos e da terminologia da ANSI/IEEE Std
1471-2000 – garantir que o uso de termos definidos pela ANSI/IEEE Std 1471-2000 é
consistente com o padrão – e mantendo a terminologia comumente aceita que é familiar à
maioria dos leitores do TOGAF (THE OPEN GROUP, 2009, tradução nossa).
3. O TOGAF É COMPOSTO POR TRÊS PARTES FUNDAMENTAIS:
3.1. O Architecture Development Method (ADM)
4
O THE OPEN GROUP (2009, tradução nossa) também explica como derivar uma
arquitetura corporativa especifica que atenda aos requisitos do negócio. Para cada iteração da
ADM, uma nova decisão deve ser tomada quanto a:
Escopo corporativo, isto é a amplitude de cobertura da empresa (que determinados
setores de negócio, funções, organizações, regiões geográficas, etc.);
Escopo vertical e o nível de detalhe a ser definido;
A linha de tempo, incluindo o número e extensão de qualquer horizonte de tempo
intermediário;
Os ativos arquitetônicos a serem aproveitados na organização, inclui: Ativos criados
em iterações anteriores do ciclo de ADM na organização e os Ativos disponíveis em outras
indústrias (outros frameworks, modelos de sistema, modelos da vertical da indústria, etc.)
O ADM prove:
Uma maneira confiável e comprovada do desenvolvimento da arquitetura
Visão da arquitetura que permitem que ao arquiteto garantir que um conjunto
complexo de condições são tratadas de forma adequada
Links para estudos de casos práticos
Orientações sobre ferramentas para o desenvolvimento da arquitetura
Além do próprio método iterativo, há também interação dentro do ciclo de ADM,
tanto entre as diferentes fases e entre as etapas de cada fase, iniciada por uma fase preliminar
(Framework and Principles) e dividida em fases subsequentes (no gráfico representadas de
“A” a “H”) onde estas interagem com a sua subsequente e sempre com os requisitos de
gerencimento (Requirements Management).
3.2. A Continum Enterprise
Conforme o THE OPEN GROUP (2009, tradução nossa), a Continum Enterprise é um
repositório “virtual” de todos os ativos de arquitetura – de modelos, padrões, descrições de
5
arquitetura, etc. – que existem tanto dentro da empresa como no setor de TI em geral, que a
empresa considera disponível para o desenvolvimento de arquiteturas. Em lugares pertinentes
em toda a ADM TOGAF, há lembretes para considerar que ativos de arquitetura o arquiteto
deve usar, se existirem.
3.3. O TOGAF Resource Base
O THE OPEN GROUP (2009, tradução nossa), também explica que o TOGAF
Resource Base é um conjunto de recursos – diretrizes, modelos, antecedentes, etc., para ajudar
o arquiteto a utilização do ADM.
4. O TOGAF OFERECE DOIS MODELOS DE REFERÊNCIA:
4.1. O TOGAF Foundation Architecture
Também segundo o THE OPEN GROUP (2009, tradução nossa), o TOGAF
Foundation Architecture é uma arquitetura de serviços gerais e funções que fornece o
fundamento em que arquiteturas especificas e Architecture Building Blocks (ABBs) pode ser
construída. O TOGAF Standards Information Base (SIB), que é um banco de dados de
padrões abertos da indústria que podem ser usados para definir os serviços particulares e
outros componentes de uma arquitetura corporativa especifica.
4.2. O TOGAF Resource Base
Também segundo o THE OPEN GROUP (2009, tradução nossa), o TOGAF Resource
Base é um conjunto de recursos – diretrizes, modelos, antecedentes, etc., para ajudar o
arquiteto a utilização do ADM.
6
4.3. O SAP EAF
Segundo DE WIT (2009, tradução nossa), o SAP EAF (Enterprise Architecture
Framework), surgiu devido a necessidade de uma ferramenta que integrasse e desse suporte a
estratégia de negócios de empresas que usufruíssem dos benefícios da plataforma SAP,
fazendo uso da arquitetura SAP Enterprise SOA (Service Oriented Architecture) e buscando
uma arquitetura de TI mais adequada a atender esse cenário (provendo uma
tradução/comunicação entre os serviços, coesão, gerencia e manutenção...).
Também segundo DE WIT (2009, tradução nossa), desta forma o SAP EAF foi criado
baseado no TOGAF devido a sua já conhecida adoção pelo mercado, por ser uma framework
aberta e livre de licenças, de vendedor neutro, bem como ser considerado pela ASUG
(Americas SAP Users' Group) e pelos participantes do SAP TechEd (conferência técnica para
profissionais de TI SAP) de 2006 como a mais relevante framework (54%), conforme
mostrado a ilustração que segue.
Ilustração 1 – Importance of enterprise architecture frameworks (108 respostas), SAP, TechEd. Resultados
da pesquisa realizada no de 2006 pela ASUG – Americas' SAP Users' Group. 2006, il. color.
SAP EAF é uma metodologia e ferramentas principalmente para apoiar a efetiva
adoção de SOA, e um conjunto complementar, de adições ao TOGAF para suportar as
características específicas do pacote e de serviços baseados em arquiteturas. SAP EAF foi
desenvolvido em 2007, por uma equipe de arquitetos do SAP Enterprise, a maioria dos quais
profissionais credenciados do TOGAF 8.1. SAP EAF foi formalmente lançado na conferência
de usuários SAP SAPPHIRE em Atlanta, EUA em 2007.
Conforme a SAP (2009, tradução nossa), o EAF contém definições mais precisas dos
conceitos, tarefas específicas e terminologia. Em muitas ocasiões, os clientes só querem se
concentrar em "como será" a arquitetura e como eles não veem valor limitado em reascender
7
através da arquitetura atual, eles reconhecem que não é ideal e preferem gastar tempo e
recursos com foco na arquitetura alvo.
4.3.1. O Metamodelo do SAP EAF
Conforme explica RAJAGOPALAN (2010, tradução nossa), o TOGAF 8.1 não
continha um metamodelo enquanto o SAP EAF introduziu esta explicitamente.
Posteriormente, o modelo SAP Meta EAF foi incluído no TOGAF 9.0 em sua maioria "como
está", com pequenas modificações. No entanto, o metamodelo no EAF permite uma
compreensão clara da arquitetura da empresa na sua totalidade. O metamodelo descreve
relações claras entre essas entidades e programas, e as ligações entre a arquitetura de negócios
e do resto dos domínios da arquitetura.
4.3.2. Os Artefatos do SAP EAF
Ainda conforme explica RAJAGOPALAN (2010, tradução nossa), o TOGAF 8.1
forneceu uma lista de exemplos de pontos de vista de arquitetura, mas não define critérios
obrigatórios para o cumprimento. O SAP EAF claramente organiza os artefatos, ou seja,
Catálogos, Matrizes e Visões (Views são conhecidos como diagramas no TOGAF) pela fase
individual de ADM e fornece descrições mais específicas desses artefatos. Os artefatos estão
claramente integrados no processo EAF e ao metamodelo.
4.3.3. Os Mapeamentos SAP específicos
RAJAGOPALAN (2010, tradução nossa), também fala sobre os Mapeamentos SAP
Específicos, onde a SAP oferece orientação EAF de nível distinto de conteúdo para os clientes
que já fizeram ou pensando em fazer um investimento significativo em produtos e serviços
SAP. O mapeamento para o conteúdo SAP pode acelerar os esforços dos clientes para
desenvolver sua arquitetura corporativa. O EAF contém referências e mapeamentos para o
negócio no SAP, aplicativos e conteúdo técnico que pode servir como referência e/ou
modelos reutilizáveis e padrões diretamente ou como um modelo. Também o SAP EAF
contém mapeamento direto de cada entidade metamodelo EAF para cada entidade específica
do SAP proporcionando clareza e orientação. Conforme vemos na ilustração abaixo que
representa a arquitetura do framework EAF e sua ligação com o TOGAF.
8
Ilustração 3 – Overview da Arquitetura da Framework do EAF, HERRMANN, Benjamin. Introduction to the SAP
Enterprise Architecture. 2009, il. color.
Ilustração 4 – Enterprise Architecture Framework for Enterprise SOA, LOPEZ, Franck. SAP Enterprise
Architecture Framework Unveiled: Aligning IT to the Business. SAP EAF and TOGAF 9. 2008.
Nessa tabela, temos na primeira coluna (em laranja) as fases do SAP EAF, e
nas colunas subsequentes (em azul marinho) as fases do processo e suas interações com o
EAF, resultando em padrões para sua implementação.
Estes padrões são definidos como:
Core (Núcleo) = atividade principal foco para a iteração;
Light = atividade foco secundário para a iteração;
Informal = atividade informal potencial na iteração, não formalmente indicados no
método;
9
5. O QUE FALTA PARA O TOGAF?
Também segundo o THE OPEN GROUP (2009, tradução nossa), o TOGAF é
deficiente nos itens abaixo:
O TOGAF ADM não faz distinção entre a Arquitetura de Soluções e a Arquitetura
Empresarial. Como resultado, a ADM não é prescritivo sobre definições de
terminologia, produtos específicos, formato de entrega, meta-modelo conteúdo
ou representação do conteúdo.
Os resultados desta filosofia na maioria das definições dentro TOGAF são vagas e
abertas.
Isto significa que TOGAF está mais perto de um modelo abstrato
para compromissos arquitetura.
6. EVOLUÇÃO SIMULTANEA COLABORATIVA
Segundo RAJAGOPALAN (2010, tradução nossa), como já vimos acima o SAP EAF
herdou muito do TOGAF, e como veremos ainda, para auxiliar no aprimoramento dos dois
frameworks (estratégias, politicas e processos) a SAP tornou-se membro Platinum do Open
Group (responsável pelo TOGAF), juntamente com outras grandes empresas como:
Capgemini, EDS, HP, IBM, SUN, HSBC, NEC... Esta parceria rendeu frutos, como um
documento delta entre o TOGAF 9.0 e o EAF, bem como o próprio TOGAF 9.0 (11/2008)
também foi enriquecido com “notáveis” e “significativas” contribuições do SAP EAF.
Ilustração 5 – Relação TOGAF versus SAP EAF, RAJAGOPALAN, Sri. TOGAF and SAP EAF Relationship.
2010, il. color.
Também segundo o THE OPEN GROUP (2009, tradução nossa), o Open Group
introduziu várias alterações no TOGAF 9.0, incluindo os seguintes:
10
Organizado com seis partes principais (além de introdução) em comparação com três
peças em TOGAF 8.1;
Mudanças estruturais para o conteúdo e organização do conteúdo (o conteúdo era mais
modular);
Modelo de categorização de documentos (classificado como "Core", "Mandatory",
"Recommended" e "Supporting");
Contém mais detalhes e orientação explícita;
O conteúdo do Resource Base do TOGAF 8.1 foi reagrupado em diferentes partes e
capítulos no TOGAF 9 com base no contexto e propósito;
A seguir temos um gráfico da SAP mostrando um pouco da arquitetura do TOGAF
9.0, como a arquitetura da framework é distribuída (a direita) e quais itens foram adicionados
a ele após as colaborações realizadas pelo SAP EAF (a esquerda).
Ilustração 6 – Arquitetura do TOGAF 9.0, RAJAGOPALAN, Sri. TOGAF and SAP EAF Relationship. 2010, il.
color.
E logo abaixo são exibidas as contribuições da SAP para o desenvolvimento do
TOGAF 9.0 (partes II, III e IV). Nela são destacadas as contribuições organizadas pela Parte
do conteúdo que foi adicionado.
11
Ilustração 7 - Conteúdo do SAP EAF incluído no TOGAF 9.0, RAJAGOPALAN, Sri. TOGAF and SAP EAF
Relationship. 2010, il. color.
Percebe-se que na Parte II, relativa a Arquitetura do Metodo de Desenvolvimento que
o SAP EAF colaborou com:
Framework Tailoring (Fase 0). Avaliar as capacidades de negócios (Fase A);
Identificação dos nomeados Catalogos, Metrizes e Diagramas da "Enterprise
Archtecture" (ou "Visão" no EAF em fases B, C e D);
Adição da tarefa “Resolução de impactos através da da Enterprise Continuum” (Fases
B, C e D);
Referencia ao SAP Solution Manager and System Landscape Directory na fase C;
Classificação/Tipos de mudança e linhas base para o gerenciamento destes na fase H.
Na Parte III com:
Conceitos de Interação e estilos de arquitetura do ADM
ADM multi-níveis (variante do SAP EAF) e classes para o engajamento da arquitetura
empresarial;
Serviços de Negócio, Definições de Serviços de Contrato e modelo.
12
No gráfico a seguir vemos a evolução das duas frameworks, partindo do TOGAF 8.1
em 2002, passando pela definição do SAP EAF em 2007 que colaborou com a definição do
TOGAF 9 em 2009.
Ilustração 8 - Evolução das duas frameworks, RAJAGOPALAN, Sri. TOGAF and SAP EAF Relationship. 2010,
il. color.
Podemos perceber também uma linha divisória entre os padrões dos modelos (ou o
que é mais comum entre eles) e as extenções próprias da SAP.
7. COLGATE EA POC (PROOF OF CONCEPT)
Este tópico apresentará alguns gráficos sobre uma prova de conceito de
implementação do SAP Enterprise Architecture na Colgate-Palmolive apresentado em
09/09/2008, no TECHED 08 (conferência técnica para profissionais de TI da SAP) através da
ASUG (Americas SAP Users' Group).
Nele, podemos acompanhar e analisar o mapeamento dos processos da arquitetura
corporativa e ter uma idéia sobre como é importada para dentro do SAP Quanto ao propósito
do POC:
7.1. Da perspectiva da SAP
Construir uma base de referência de clientes que utilizam o SAP EAF
13
Começar com um líder em um dado setor determinado
Demonstrar o Proof Point de se utilizar o SAP EAF
7.2. Do ponto de vista da Colgate
Utilizar o que há de mais novo e melhor do SAP
Calcular o valor de se utilizar o SAP EAF
Começar pequeno e expandir-se para utilizar outros aspectos do SAP EAF
7.3. Escopo
Iteração da Arquitetura de Contexto
Fases Preliminares e de Visão
Iterações da arquitetura de desenvolvimento
Apenas Informação da Arquitetura do Sistema
Arquitetura de Aplicações e de Dados
A seguir temos dois gráficos onde podemos perceber os inputs e outputs da visão de
fases da arquitetura na Colgate e suas informações:
14
Ilustração 9 - Visões de fases preliminaries e de arquitetura, JALAGAM, Navaneeth. Session 2303 - Enterprise
Architecture Planning at Colgate-Palmolive. 2012, il. color.
Ilustração 10 - Visões da arquitetura dos sistemas de informação, JALAGAM, Navaneeth. Session 2303 -
Enterprise Architecture Planning at Colgate-Palmolive. 2012, il. color.
A seguir, temos uma visão da interação do desenvolvimento da arquitetura na Colgate:
15
Ilustração 11 - Visão da interação do desenvolvimento da arquitetura da Colgate, JALAGAM, Navaneeth. Session 2303 - Enterprise Architecture Planning at Colgate-Palmolive.
Já neste outro, temos um resumo dos entregáveis desta POC, que como pode ser visto
gerou um diagrama do núcleo (CORE) da EA, princípios de arquitetura de TI, gols e objetivos
relevantes para a estratégia, foco na arquitetura de sistemas de informação pertinentes apenas
ao POC, a criação de uma matriz e visões da EA para a Colgate e um portal contento
brainstorms e conteúdos definidos:
Ilustração 14 – Resumo dos entregáveis do POC, JALAGAM, Navaneeth. Session 2303 - Enterprise
Architecture Planning at Colgate-Palmolive.
8. CONSIDERAÇÕES FINAIS
Pode-se perceber que as duas frameworks se complementam, o TOGAF servindo de
base para o EAF e este atuando de forma mais específica nas diversas arquiteturas das
empresas que utilizam as plataformas SAP. No entanto, também é possível perceber que a
framework EAF contribui para o amadurecimento do TOGAF e assim, espera-se, que este
venha futuramente a alcançar a abrangência necessária para atender todas as formas de
arquiteturas de negócio das empresas (usuárias de SAP ou não).
16
Percebemos também em termos de Processos, que o SAP EAF define uma
metodologia mais prescritiva estendida reduzindo o esforço. O SAP EAF também inclui
estilos de arquitetura para suportar uma variedade de cenários de clientes. Já o TOGAF é mais
genérico neste aspecto; Em termos de Arquitetura de métodos de Desenvolvimento, o EAF
extende o ADM do TOGAF introduzindo quatro iterações distintas e fornece planilha e
narrativa para cada fase de arquitetura com detalhes sobre as entradas e saídas, etapas por fase
e como conduzir cada fase; Já quanto ao Meta-Modelo, o SAP EAF define explicitamente o
Meta-Modelo que serve propósitos importantes que incluem orientar a criação de artefatos de
arquitetura empresarial e servindo como um esquema para ferramentas de modelagem dessa
arquitetura; Quanto a exemplos de aplicação, o TOGAF não provê exemplos de como aplicar
seus conceitos enquanto o EAF os provê baseados em estudos de caso. E finalizando, o EAF
ao contrário do TOGAF provê um glossário claro sobre os termos e terminologias utilizados
com seu propósito e descrição.
Dessa forma, temos como vantagens do EAF em relação ao TOGAF: permite
definição de arquitetura robusta que podem ser aplicadas de forma consistente para os clientes
existentes ou novos clientes pensando em fazer a transição para soluções SAP; mapeamento
da SAP EAF para os conceitos SAP e de mapeamento desses conceitos para modelos de
referência SAP e produtos; a EAF fornece estrutura para extensões específicas SOA,
introduzindo e definindo conceito de "serviços" em todos os quatro domínios; o Meta-Modelo
EAF permite o desenvolvimento de artefatos de arquitetura empresarial de uma forma mais
prática e tangível; o processo EAF é impulsionado pelo conceito de arquitetura de
desenvolvimento iterativo e incorpora as duas abordagens top-down e bottom-up.
O TOGAF então contribui de forma hábil e eficaz, e genérica, no gerenciamento e
mantenimento da arquitetura empresarial, já o EAF se coloca de forma a (tentar) ser mais
eficiente, atendendo, e distinguindo, os tipos de arquitetura (bem como se integrando com as
arquiteturas e software da SAP). E em se tratando de integração com softwares que
possíbilitem a importação da arquitetura o EAF permite a companhia uma melhor visão de
sua arquitetura, mas alinhada com outras ferramentas de software de gerenciamento de
arquiteturas.
17
REFERÊNCIAS
1. BROCKER, Jop. TOGAF - Summary of the framework. Disponível em:
<http://www.yes2web.nl/files/ebooks/togaf.pdf>. Acesso em: 11 jan. 2013.
2. DE WIT, Pim. SAP RUNS TOGAF: Reconciles all stakeholder views from a Business and IT perspective. 2009. Disponível em: <http://www.lac2009.nl/Uploads/Files/Speaker_20corner_20-_20SAP_2.pdf>. Acesso em: 11 jan. 2013.
3. HERRMANN, Benjamin. Introduction to the SAP Enterprise Architecture Initiative. 2008. Disponível em: <http://www.matthes.in.tum.de/file/Events/2008/080909-Informatik-2008/Published/080907-Herrmann-SAP-Introduction_EA_Initiative.pdf>. Acesso em: 11 jan. 2013.
4. JALAGAM, Navaneeth. Session 2303 - Enterprise Architecture Planning at Colgate-Palmolive. 2012. ASUG Annual Conference Session Presentation. EUA, 2012. Disponível em: <http://events.asug.com/2012AC/2303_Enterprise_Architecture_Planning_at_Colgate-Palmolive.pdf>. Acesso em: 27 fev. 2013.
5. LOPEZ, Franck. SAP Enterprise Architecture Framework Unveiled: Aligning IT to the Business. Palo Alto: Tech Tour, 2007. Disponível em: <http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/c0da74aa-6f2e-2a10-6387-edbf382f3f87?QuickLink=events&overridelayout=true>. Acesso em: 11 jan. 2013.
6. RAJAGOPALAN, Sri. TOGAF and SAP EAF Relationship. 2010. SAP SDN Community. Disponível em: <http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/22328>. Acesso em: 11 jan. 2013.
7. SAP. SAP EAF Overview Guide. 2007. Disponível em: <http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/media/streamingmedia/developer-areas/service-oriented-architecture/Starter%20Kit%20for%20SOA/assets/content/Strategy/Methodology%20Governance%20and%20Architecture/SAP_EAF_Overview_Guide%20v1.2.pdf>. Acesso em: 05 fev. 2013.
8. THE OPEN GROUP CONFERENCE LONDON. SAP EAF and TOGAF 9. 2008. Disponível em: <http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/media/streamingmedia/developer-
18
areas/service-oriented-architecture/Starter%20Kit%20for%20SOA/assets/content/Plan/Methodology%20Governance%20and%20Architecture/SAP%20EAF%20and%20TOGAF%209%2028th%20April%202009%20FINAL.pdf>. Acesso em: 26 fev. 2013.
9. THE OPEN GROUP. TOGAF® Version 9. Netherlands: Van Haren Publishing, 2009.
10. VAN'T WOUT, J., et al. The Integrated Architecture Framework Explained. EUA: Springer, 2010.