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.