UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO

CENTRO DE CINCIAS EXATAS E TECNOLOGIA

PROGRAMA DE PS-GRADUAO EM INFORMTICA

UMA ABORDAGEM PARA IDENTIFICAO E REPRESENTAO DOS

INTERESSES TRANSVERSAIS NA ARQUITETURA EMPRESARIAL

Fabiana Jack Nogueira Santos

Orientadora

Flvia Maria Santoro

Co-orientadora

Claudia Cappelli

RIO DE JANEIRO, RJ BRASIL

JUNHO DE 2012

RIO DE JANEIRO, RJ BRASIL

JUNHO DE 2012

JUNHO DE 2012

Santos, Fabiana Jack Nogueira.

S237 Uma abordagem para identificao e representao dos interesses transver-

sais na arquitetura empresarial / Fabiana Jack Nogueira Santos, 2012.

190f. ; 30 cm

Orientador: Flvia Maria Santoro.

Coorientador: Claudia Cappelli.

Dissertao (Mestrado em Informtica) Universidade Federal do Estado do Rio de Janeiro, Rio de Janeiro, 2012.

1. Arquitetura empresarial. 2. Modularidade. 3. Interesses transversais.

4. Metodologia DEMO. 5. Abordagem orientada a aspecto. I. Santoro, Fl-

via Maria. II. Cappelli, Claudia. III. Universidade Federal do Estado do Rio

de Janeiro. Centro de Cincias Exatas e Tecnologia Curso de Mestrado em

Informtica. IV. Ttulo.

CDD 005.32

minha me Maria Aparecida e ao meu marido Alexandre

por todo amor e apoio incondicionais.

AGRADECIMENTOS

Agradeo Deus por guiar todos os passos de minha vida, ench-la de oportunidades e

pessoas espetaculares e permitir que mais essa etapa fosse concluda. Agradeo ao pai que

tive e ME maravilhosa que tenho, a quem devo os mais sinceros agradecimentos por tudo

que sempre fez e faz por mim. O grande incentivador de toda essa jornada, meu marido e

companheiro que muito admiro Alexandre, no s incentivou, mas participou ativamente do

curso sempre que precisei. Alm disso, me ajuda a ver que a vida no perfeita, mas que

ainda assim podemos ser muito felizes. Obrigada por tudo!

Aventurar-me pelo mestrado s foi se tornando uma possibilidade para mim graas

muitas conversas com o Professor Sean Siqueira, a quem devo muita gratido por ter me

apresentado esse mundo, at ento, desconhecido. Ningum disse que seria fcil, mas cada

instante valeu muito a pena.

Agradeo imensamente minhas queridas orientadora e co-orientadora Flvia e Cludia,

pessoas pelas quais tenho muito carinho e admirao. Vocs foram minhas grandes guias,

foram mestras e muito pacientes nessa longa jornada, no tenho palavras para agradecer tudo

que vivi, aprendi e por ter conseguido, com a ajuda de vocs, concluir essa empreitada.

Agradeo ao NP2Tec por ter me aceitado como membro e me acolhido de braos

abertos. Aprendi muito com todos e tenho muito carinho por vocs. O mestrado e o NP2Tec

me trouxeram a oportunidade mpar de trabalhar com pesquisa e conhecer os professores Tas

Batista e Jlio Leite que me ensinam muito a cada contato. Agradeo imensamente a vocs

por tudo que aprendi.

Durando o curso estive com grandes pessoas que me acompanharam, algumas desde a

graduao, e sero eternamente amigas: Dbora, Priscila, Luiza, Mnica, Talita e Juliana

Frana. Agradeo tambm a todos os meus amigos e familiares que direta ou indiretamente

estiveram presentes nessa jornada ao meu lado.

Agradeo a todos os meus professores da graduao que me ensinaram muito e esto

sempre com uma palavra amiga quando os encontro pelos corredores, alguns estiveram

presentes no mestrado, outros no, mas todos vocs so especiais para mim: Fernanda,

Renata, Leila, Lo, Luiz Monte, Amncio, Mrcio e Tanaka. Obrigada a todos os meus

professores do mestrado que enriqueceram essa experincia. Agradeo tambm Erclia,

Alessandra, Douglas e todos da secretaria que muito me ajudam sempre quando necessrio.

SANTOS, Fabiana Jack Nogueira. Uma abordagem para identificao e representao dos

interesses transversais na Arquitetura Empresarial. UNIRIO, 2012. 180 pginas.

Dissertao de Mestrado. Departamento de Informtica Aplicada, UNIRIO.

RESUMO

O cenrio atual, no qual as organizaes esto inseridas, requer que mudanas sejam

realizadas rapidamente com baixo custo. Frente a este desafio, as organizaes precisam

conhecer a si mesmas, como John Zachman j observava em 1987 (ZACHMAN, 1987).

Conhecer a si mesma significa entender por que e como as atividades so realizadas, quais

informaes esto relacionadas a elas, quais sistemas as apoiam e qual tecnologia a suporta. A

literatura prope o estabelecimento do conceito de Arquitetura Empresarial para auxiliar as

organizaes a conhecerem a si mesmas. Atualmente existem diversos frameworks que

sugerem artefatos e prticas para o desenvolvimento e a manuteno das diversas

representaes que compem a Arquitetura Empresarial.

Porm ao se analisar as representaes sugeridas e suas formas de desenvolvimento e

manuteno na modelagem convencional da Arquitetura Empresarial propostas por estes

Frameworks, percebe-se a existncia de diversos interesses espalhados e entrelaados aos

interesses essenciais da organizao. Essa questo de baixa modularizao compromete o

reuso e dificulta tanto a manuteno quanto o entendimento das representaes da Arquitetura

Empresarial.

Para auxiliar na soluo de tal questo proposto um mtodo para identificar e representar os

interesses transversais na Arquitetura Empresarial. A soluo baseada na metodologia

DEMO e na abordagem orientada a aspectos. Para analisar o mtodo proposto foi realizado

um estudo de caso em uma empresa real.

Palavras-chave: Arquitetura Empresarial; Modularidade; Interesses Transversais; Aspectos

ABSTRACT

The current scenario where organizations are embedded requires changes to be performed

quickly with low costs. In order to face this challenge, the organizations must know

themselves as John Zachman already observed in 1987 (ZACHMAN, 1987). Knowing itself

means understanding why and how the activities are performed, which information is related

to them, which systems endorses them and which technology support them. The literature

proposes the establishment of Enterprise Architecture concept to help organizations know

themselves. Currently there are many frameworks that suggest artifacts and practices to the

development and maintenance of the several representations that compose the Enterprise

Architecture.

However when analyzing the representations suggested and their development forms in

conventional modeling of the Enterprise Architecture proposed by these Frameworks, it is

possible to perceive the existence of several concerns scattered and tangled to the organization

essential concerns. This low modularity issue compromises reuse and makes it difficult both

to maintain and understand the Enterprise Architecture representations.

In order to solve this issue, we present a method to identify and represent the crosscutting

concerns at Enterprise Architecture level. The solution is based in the DEMO methodology

and in the aspect-oriented approach. To analyze the proposed method we have performed one

case study in a real world organization.

Keywords: Enterprise Architecture; Modularity; Crosscutting concerns; Aspects

NDICE

1. Introduo .......................................................................................................................... 1

1.1. Motivao .................................................................................................................... 1

1.2. Problema ...................................................................................................................... 2

1.3. Enfoque de soluo ...................................................................................................... 3

1.4. Escopo .......................................................................................................................... 4

1.5. Estrutura do trabalho .................................................................................................... 5

2. Arquitetura Empresarial .................................................................................................. 6

2.1. Frameworks de Arquitetura Empresarial ..................................................................... 6

2.1.1. Framework de Zachman ....................................................................................... 7

2.1.2. FEAF .................................................................................................................... 8

2.1.3. TEAF .................................................................................................................... 9

2.1.4. DoDAF ............................................................................................................... 10

2.1.5. TOGAF ............................................................................................................... 11

2.1.6. FEA ..................................................................................................................... 12

2.1.7. IEEE 1471-2000 ................................................................................................. 14

2.1.8. Comparao entre os frameworks ...................................................................... 15

2.2. Problemas encontrados na Arquitetura Empresarial .................................................. 18

2.2.1. Linguagens para modelagem da Arquitetura Empresarial ................................. 20

2.3. Ontologia Empresarial ............................................................................................... 28

2.3.1. Gerao das representaes da Ontologia Empresarial ...................................... 34

2.3.2. Exemplo .............................................................................................................. 37

2.4. Resumo ...................................................................................................................... 40

3. Orientao a Aspectos em Sistemas de Informao ..................................................... 41

3.1. Conceitos gerais ......................................................................................................... 41

3.2. Programao orientada a aspectos ............................................................................. 42

3.3. Anlise de requisitos orientada a aspectos ................................................................. 43

3.4. Modelagem de processos de negcios orientada a aspectos ...................................... 46

3.5. Interesses transversais na Arquitetura Empresarial ................................................... 50

3.6. Resumo ...................................................................................................................... 51

4. Mtodo para identificao e representao dos interesses transversais na

Arquitetura Empresarial ....................................................................................................... 53

4.1. Objetivos .................................................................................................................... 53

4.2. Premissas ................................................................................................................... 53

4.3. Introduo ao mtodo ................................................................................................ 54

4.4. Fase Identificar .......................................................................................................... 56

4.4.1. EIA Obter representaes organizacionais ...................................................... 57

4.4.2. EIA - Definir os tipos de elementos bsicos de cada representao

organizacional ................................................................................................................... 57

4.4.3. EIA - Listar trechos que compem os elementos bsicos .................................. 58

4.4.4. EIA - Identificar transaes ontolgicas ............................................................ 64

4.4.5. EIA - Representar as transaes ontolgicas ...................................................... 64

4.4.6. EIA - Identificar os trechos que operacionalizam as transaes ontolgicas ..... 66

4.4.7. EIA - Descartar os trechos que no operacionalizam as transaes ontolgicas 68

4.4.8. EIA - Identificar os verbos utilizados ................................................................. 72

4.4.9. EIA - Identificar os verbos com significado semelhante .................................... 75

4.4.10. EIA - Calcular ocorrncia dos verbos................................................................. 76

4.4.11. EIA - Descartar verbos com apenas 1 ocorrncia............................................... 77

4.4.12. EIA - Identificar os trechos que compartilham mais de um verbo ..................... 81

4.4.13. EIA - Revisar lista de interesses transversais ..................................................... 81

4.4.14. EIA - Descartar trechos com verbos repetidos apenas na mesma representao

organizacional ................................................................................................................... 82

4.4.15. EIA - Nomear os interesses transversais identificados ....................................... 86

4.5. Fase Representar ........................................................................................................ 87

4.5.1. Passo a passo ...................................................................................................... 87

4.5.2. A Linguagem para especificao de interesses transversais na Arquitetura

Empresarial........................................................................................................................ 90

4.6. Resumo ...................................................................................................................... 96

5. Avaliao da proposta estudo de caso ........................................................................ 97

5.1. Metodologia de pesquisa ........................................................................................... 97

5.2. Caracterizao da Empresa ABCD ............................................................................ 98

5.3. Realizao do estudo de caso ..................................................................................... 98

5.3.1. Obter representaes organizacionais e identificar os tipos de elementos bsicos

de cada uma ....................................................................................................................... 99

5.3.2. Listar os trechos que compem os tipos de elementos bsicos ........................ 100

5.3.3. Identificar as transaes ontolgicas ................................................................ 104

5.3.4. Representar a essncia da organizao ............................................................. 105

5.3.5. Identificar os trechos que operacionalizam as transaes ontolgicas ............. 106

5.3.6. Descartar os trechos que operacionalizam as transaes ontolgicas .............. 107

5.3.7. Identificar os verbos utilizados ......................................................................... 111

5.3.8. Identificar os verbos semelhantes ..................................................................... 115

5.3.9. Calcular ocorrncia dos verbos ........................................................................ 115

5.3.10. Remover da lista os verbos com apenas 1 ocorrncia ...................................... 117

5.3.11. Identificar os trechos que compartilham mais de um verbo ............................. 121

5.3.12. Revisar lista ...................................................................................................... 123

5.3.13. Identificar verbos repetidos somente na mesma representao organizacional 127

5.3.14. Nomear os interesses transversais identificados ............................................... 143

5.3.15. Criar o diagrama de interesses transversais ...................................................... 144

5.3.16. Especificar o relacionamento transversal para cada interesse transversal

identificado ...................................................................................................................... 144

5.3.17. Anlise dos resultados da aplicao do mtodo ............................................... 150

5.3.18. Respostas dos participantes .............................................................................. 151

5.4. Resumo .................................................................................................................... 157

6. Concluses ...................................................................................................................... 158

6.1. Contribuies do trabalho ........................................................................................ 159

6.2. Limitaes ................................................................................................................ 160

6.3. Trabalhos futuros ..................................................................................................... 161

REFERNCIAS ................................................................................................................... 163

ANEXOS ............................................................................................................................... 170

I. Convite para participar da pesquisa ............................................................................. 170

II. Apresentao do mtodo ............................................................................................. 171

III. Artefatos utilizados ...................................................................................................... 172

IV. Resultado ..................................................................................................................... 174

V. Roteiro da entrevista .................................................................................................... 174

LISTA DE FIGURAS

Figura 1 O Framework de Zachman 3.0 (ZACHMAN, 2011) ................................................................ 8

Figura 2 Componentes do planejamento da Arquitetura Empresarial traduzido de (FEAF, 1999) ........ 9

Figura 3 Recursos e produtos de trabalho do TEAF para direcionar, descrever e realizar a Arquitetura

Empresarial traduzido de (TEAF, 2000) ............................................................................................... 10

Figura 4 Pontos de vista arquiteturais do DoDAF v2.0 traduzido de (DoDAF, 2009) ......................... 11

Figura 5 Architecture Development Method TOGAF traduzido de (TOGAF, 2009) ........................ 12

Figura 6 Modelos de referncia do FEA traduzido de (FEA Reference Models) ................................. 13

Figura 7 Modelo Conceitual do Framework IEEE 1471-2000 traduzido de (Hilliard, 2000) ............... 14

Figura 8 Camada de negcio da situao atual da UME (University of Middle England) .................... 21

Figura 9 Objetivo da camada de negcio .............................................................................................. 21

Figura 10 Como o aluno registrado .................................................................................................... 21

Figura 11 Camada de aplicao ............................................................................................................ 22

Figura 12 Refinamento da camada de negcio ..................................................................................... 22

Figura 13 TO-BE da UME .................................................................................................................... 23

Figura 14 Operaes includas no To-Be da Camada de Negcio ........................................................ 23

Figura 15 To-Be da Camada de Aplicao ........................................................................................... 23

Figura 16 Refinamento Camada de Aplicao ...................................................................................... 24

Figura 17 Definio dos fundos da instituio ...................................................................................... 24

Figura 18 Definio dos fundos da instituio ...................................................................................... 24

Figura 19 Diagrama de Contexto de Negcio do USCP ....................................................................... 26

Figura 20 Diagrama do Processo Pagamento por Perodo .................................................................... 27

Figura 21 Diagrama de caso de uso do BAP pessoal ............................................................................ 28

Figura 22 Transao .............................................................................................................................. 31

Figura 23 Padro Transao Bsico ...................................................................................................... 32

Figura 24 Bloco molecular .................................................................................................................... 33

Figura 25 Bloco atmico ....................................................................................................................... 33

Figura 26 Diagrama de Transao de Ator da DAE ............................................................................. 39

Figura 27 Meta-modelo para Integrao de Caractersticas Transversais durante a Definio de

Requisitos (SILVA, 2006)..................................................................................................................... 45

Figura 28 Processo de Gesto de Mudana (CAPPELLI, 2009)........................................................... 49

Figura 29 Processo de Gesto de Mudana com a composio de caractersticas transversais

(CAPPELLI, 2009) ............................................................................................................................... 49

Figura 30 Passo a passo do mtodo para Identificao e Representao dos Interesses Transversais na

Arquitetura Empresarial ........................................................................................................................ 56

Figura 31 Atividades da fase Identificar ............................................................................................... 59

Figura 32 Construction Model da EIA .................................................................................................. 65

Figura 33 Passo a passo da fase Representar ........................................................................................ 87

Figura 34 Exemplo de um diagrama para representar os Interesses Transversais ................................ 88

Figura 35 Interesses transversais na EIA .............................................................................................. 88

Figura 36 Definio do relacionamento transversal Elaborao ........................................................ 89

Figura 37 Componentes usados para representar interesses transversais em modelos da Arquitetura

Empresarial (adaptado de Cappelli (CAPPELLI, 2009) ....................................................................... 90

Figura 38 Sintaxe de LMAEOA (adaptado de Cappelli (Cappelli, 2009)) ........................................... 91

Figura 39 Modelo conceitual da linguagem de modelagem da Arquitetura Empresarial orientada a

aspectos (adaptado de Cappelli (CAPPELLI, 2009)) ............................................................................ 92

Figura 40 Instanciao da sintaxe de LMAEOA para Diagrama de processos de negcio .................. 93

Figura 41 Sintaxe do Relacionamento Transversal (adaptado de Cappelli (CAPPELLI, 2009)) ......... 94

Figura 42 Exemplo do Relacionamento Transversal do aspecto Log ................................................... 95

Figura 43 Construction Model da EIA ................................................................................................ 106

Figura 44 Interesses transversais da rea de informtica da empresa ABCD ..................................... 144

Figura 45 Definio do relacionamento transversal Elaborao ...................................................... 145

Figura 46 Definio do relacionamento transversal Realizao ...................................................... 145

Figura 47 Definio do relacionamento transversal Existncia ....................................................... 146

Figura 48 Definio do relacionamento transversal Definio ........................................................ 146

Figura 49 Definio do relacionamento transversal Mudana ......................................................... 146

Figura 50 Definio do relacionamento transversal Acesso ............................................................ 147

Figura 51 Definio do relacionamento transversal Gerenciamento ............................................... 147

Figura 52 Definio do relacionamento transversal Utilizao ....................................................... 148

Figura 53 Definio do relacionamento transversal Preparao ...................................................... 148

Figura 54 Definio do relacionamento transversal Permisso ....................................................... 149

Figura 55 Definio do relacionamento transversal Detalhamento ................................................. 149

Figura 56 Definio do relacionamento transversal Recuperao ................................................... 149

Figura 57 Definio do relacionamento transversal Contedo ........................................................ 150

Figura 58 Definio do relacionamento transversal Conselho ......................................................... 150

Figura 59 Definio do relacionamento transversal Parametrizao ............................................... 150

Figura 60 Passo a passo do mtodo para Identificar e Representar Interesses Transversais ............... 173

LISTA DE TABELAS

Tabela 1 Comparao entre os frameworks traduzido de (TANG et al., 2004) .................................... 17

Tabela 2 Tipos de elementos bsicos das representaes organizacionais ............................................ 58

Tabela 3 Trechos das representaes organizacionais a serem analisados ............................................ 60

Tabela 4 Transaes ontolgicas da EIA .............................................................................................. 64

Tabela 5 Trechos das representaes organizacionais que operacionalizam as transaes ontolgicas

da EIA .................................................................................................................................................... 67

Tabela 6 Trechos Modelo de Processos de Negcio da EIA que no operacionalizam as transaes

ontolgicas ............................................................................................................................................. 68

Tabela 7 Trechos PDI que no apoiam as transaes ontolgicas ........................................................ 69

Tabela 8 Trechos Manual do SIE que no apoiam as transaes ontolgicas ....................................... 70

Tabela 9 Verbos presentes nos trechos das representaes organizacionais ......................................... 73

Tabela 10 Nmero de ocorrncias dos verbos nos trechos das representaes organizacionais ........... 76

Tabela 11 Candidatos a interesse transversal presente nas representaes organizacionais ................. 77

Tabela 12 Candidatos a interesse transversal agrupados ....................................................................... 82

Tabela 13 Representaes organizacionais e seus respectivos tipos de elemento bsico ...................... 99

Tabela 14 Todos os Trechos das representaes organizacionais ....................................................... 100

Tabela 15 Transaes ontolgicas de parte da empresa ABCD .......................................................... 104

Tabela 16 Trechos das representaes organizacionais que apoiam as transaes ontolgicas .......... 106

Tabela 17 Candidatos a interesse transversal ...................................................................................... 108

Tabela 18 Verbos dos candidatos a interesse transversal .................................................................... 111

Tabela 19 Nmero de ocorrncias dos verbos presentes nos trechos das representaes organizacionais

............................................................................................................................................................. 115

Tabela 20 Candidatos a interesse transversal presente nas representaes organizacionais ............... 117

Tabela 21 Anlise da predominncia dos verbos ................................................................................ 121

Tabela 22 Anlise da predominncia dos verbos ................................................................................ 123

Tabela 23 Candidatos a interesse transversal com verbos separados .................................................. 127

Tabela 24 Candidatos a interesse transversal agrupados por verbo..................................................... 133

Tabela 25 Interesses transversais agrupados por verbo foram removidos os verbos com ocorrncia

em apenas 1 tipo de seo ................................................................................................................... 139

Tabela 26 Definies ........................................................................................................................... 171

1

1. Introduo

Esta dissertao apresenta uma proposta para identificao e representao dos

interesses transversais na Arquitetura Empresarial (AE). Este captulo apresenta a motivao,

o problema, o enfoque de soluo, o escopo e a forma como o trabalho est organizado.

1.1. Motivao

O cenrio atual no qual as organizaes esto inseridas exige que as mudanas sejam

administradas de forma rpida e com o menor custo possvel. So consideradas mudanas

tanto alteraes para atingir novos objetivos quanto aquelas impostas por regulamentaes e

leis. Para isso, necessrio que as organizaes conheam a si mesmas como j previa John

Zachman em 1987 (ZACHMAN, 1987).

Conhecer a si mesma significa entender porque e como as atividades so realizadas,

quais so as informaes relacionadas a essas atividades, quais sistemas as apoiam e a

tecnologia que permite a operao da organizao. As atividades so realizadas pelas

organizaes e descrevem o seu funcionamento. Os sistemas e tecnologia apoiam a execuo

destas atividades. Todos estes elementos fazem parte das abordagens de Arquitetura

Empresarial propostas por diversos autores (ZACHMAN, 1997, LANKHORST et al., 2005,

TOGAF, 2009, BOTTO, 2004 ).

Segundo Lankhorst (2005) a Arquitetura Empresarial um conjunto coerente de

princpios, mtodos e modelos que so usados na concepo e na operao da estrutura

organizacional, dos processos de negcio, dos sistemas de informao e da infraestrutura de

uma organizao. Consideramos como Arquitetura Empresarial o conjunto de artefatos que

descrevem e representam as diversas perspectivas organizacionais de acordo com o

Framework de Zachman (ZACHMAN, 2008), que doravante chamaremos de Representaes

Organizacionais. Existem diversos frameworks propostos para apoiar a construo e a

manuteno das representaes que compem a Arquitetura Empresarial. A organizao da

Arquitetura Empresarial utiliza abstraes de alto nvel chamadas vises. Os frameworks

utilizam pontos de vista (viewpoints) para criar vises que representam diferentes perspectivas

2

da arquitetura (TANG et al., 2004). Pontos de vista comumente utilizados pelos frameworks

so: arquitetura de negcio, arquitetura de informao, arquitetura de sistema e arquitetura de

tecnologia.

Ao analisar as representaes da Arquitetura Empresarial de uma organizao,

percebe-se que existem interesses espalhados e entrelaados com outros interesses nas

diversas representaes. Essa baixa modularizao faz com que seja mais difcil incorporar

mudanas nas representaes e tambm denotam a ausncia de uma viso integrada de onde e

como esto operacionalizados os interesses que representam um mesmo conceito. Isso

compromete o reuso, a manuteno e o entendimento dos elementos da Arquitetura

Empresarial.

1.2. Problema

Existem diversas abordagens e frameworks que apoiam as iniciativas de estruturao

da Arquitetura Empresarial nas organizaes. Ao analisar algumas dessas abordagens,

percebe-se que o foco na representao do contedo de cada viso que compe a

Arquitetura Empresarial e no relacionamento entre as representaes. Nada se comenta sobre

partes que estejam espalhadas ou entrelaadas em diversas representaes, o que permite a

existncia de representaes contendo os mesmos elementos ou partes destes dentro de si.

Isso dificulta a anlise dos impactos causados por necessidade de atualizao ou remoo

destes elementos ou partes espalhadas ou entrelaadas em diversas representaes. Por

exemplo, se uma organizao precisa diminuir o tempo de realizao de seus processos pode

decidir automatizar todos os pontos dos processos onde h atividades de verificao. Mesmo

considerando que essa organizao j tenha uma abordagem estruturada da representao da

Arquitetura Empresarial, ainda assim ser demorado e custoso identificar todos os trechos de

todas as representaes da Arquitetura Empresarial onde existam elementos de verificao.

Neste caso, todos os processos devero ser analisados, pois possvel que as atividades de

verificao tenham nomes diferentes como analisar, examinar e averiguar, aumentando o

tempo gasto na anlise. Alm disso, ainda poder ser necessrio um levantamento de quais

das atividades de verificao j esto automatizadas para escolher a melhor forma de

implementao, o que far com que seja necessrio obter o cdigo de todas as

implementaes deste conceito e ento analis-los.

3

Os elementos espalhados e entrelaados com outros elementos presentes nas

representaes convencionais da Arquitetura Empresarial sero aqui denominados Interesses

Transversais (KICZALES et al., 1997). Neste trabalho a definio deste conceito, que ser

detalhada no Captulo 3, assume o interesse transversal como um elemento que se encontra

espalhado nas representaes da Arquitetura Empresarial e entrelaado com as representaes

da essncia da organizao.

Dessa forma, o problema a ser endereado nessa dissertao :

1.3. Enfoque de soluo

Este trabalho considera a hiptese de que possvel identificar e representar os

interesses transversais entrelaados e espalhados nas diversas representaes da Arquitetura

Empresarial. Para isso, ser desenvolvido um mtodo que permitir identificar e representar

os interesses transversais no nvel da Arquitetura Empresarial.

O mtodo para identificao e representao dos interesses transversais utiliza os

conceitos da orientao a aspectos (KICZALES et al., 1997). Nessa abordagem, um elemento

dito transversal quando afeta diversos outros elementos que implementam as

funcionalidades bsicas do sistema. Trazendo essa definio para a Arquitetura Empresarial,

teremos interesses transversais que afetam os elementos que representam a essncia da

organizao.

A essncia da organizao, segundo a Ontologia Empresarial (DIETZ, 2006), so os

atos realizados pelos papis de ator e os fatos resultantes de tais atos onde h produo de

algo novo ou tomada de deciso relacionada aos objetivos de negcio da organizao. Esses

atos so apoiados por outros atos e fatos onde h computao de informao ou manipulao

de dados que indicam como a realizao e implementao da essncia da organizao.

No mtodo proposto nessa dissertao, uma vez descoberta a essncia da organizao,

atravs da metodologia DEMO, possvel diferenci-la dos demais elementos que fazem

parte da organizao. Tais elementos podem ser interesses transversais ou simplesmente

4

outros elementos. Essas informaes so utilizadas na fase Identificao, onde so elencados

os interesses transversais.

Uma vez identificados, os interesses transversais sero representados utilizando as

ideias da orientao a aspectos na fase Representao do mtodo proposto. Nessa abordagem,

os elementos transversais so encapsulados no componente denominado Aspecto. Nesse

componente representado o cdigo do elemento transversal e em quais locais do cdigo ele

deve ser inserido e quando. No caso da Arquitetura Empresarial, as mesmas informaes

sero representadas.

A maioria dos trabalhos que lida com interesses transversais apresenta abordagens

para solucionar esse problema focadas um nico tipo de representao. Em Silva (2006)

proposta a orientao a aspectos no documento de requisitos de software, em Cappelli (2009)

proposta a orientao a aspectos no modelo de processos de negcio. Nesta dissertao, o

conceito de orientao a aspectos utilizado simultaneamente em diversos tipos de

representaes que compem a Arquitetura Empresarial, como modelos de processos de

negcio, casos de uso de um software, padro de desenvolvimento de um software, diagrama

de classes, modelo de objetivos, arquitetura de aplicaes etc.

Para avaliar a viabilidade do mtodo foram realizados dois estudos de caso. Um deles

na Escola de Informtica Aplicada da UNIRIO e o outro em uma empresa real. No estudo de

caso realizado em uma empresa real foi aplicado um questionrio para analisar o

entendimento de outras pessoas sobre a representao proposta. Todos os participantes atuam

na rea de informtica dessa empresa.

O mtodo para identificao e representao dos interesses transversais permitir aos

arquitetos aprimorar as representaes da organizao de forma modular, permitindo a

visualizao do que transversal essncia da organizao. Alm disso, ser possvel

visualizar de forma consolidada, atravs da representao proposta, os interesses transversais

que previamente apresentavam-se dispersos. Isso possibilita a anlise de impactos causados

por alteraes nos interesses transversais necessria aos gestores organizacionais e a

facilidade de manuteno e reuso dos interesses transversais.

1.4. Escopo

5

Nas abordagens de Arquitetura Empresarial existem a Arquitetura Atual, que indica a

situao atual da organizao, e a Arquitetura Futura, que indica como organizao deseja ser.

O escopo do mtodo a Arquitetura Atual que contm as representaes da organizao

como esto atualmente.

1.5. Estrutura do trabalho

No Captulo 2 apresentada a Arquitetura Empresarial, com a indicao e detalhes de

alguns de seus frameworks que auxiliam sua implantao, bem como as intenes das

organizaes com sua adoo e benefcios trazidos por ela. Ainda nesse captulo

apresentado o conceito de Ontologia Empresarial e a metodologia DEMO.

No Captulo 3 definido o conceito de interesses transversais acompanhado de uma

reviso da literatura com foco nas diversas fases do desenvolvimento de software e

componentes da Arquitetura Empresarial, como modelos de processos, que j incorporam a

orientao a aspectos como meio de contribuir para a melhoria da modularizao de suas

representaes. Tambm relatado o problema da modularizao dos interesses transversais

presentes na Arquitetura Empresarial e alguns trabalhos relacionados. O problema da

modularizao na Arquitetura Empresarial ilustrado atravs de exemplos para facilitar o

entendimento.

O Captulo 4 tem o intuito de detalhar o mtodo proposto para identificao e

representao dos interesses transversais na Arquitetura Empresarial, partindo de seu objetivo

geral at a descrio detalhada de suas fases com um exemplo.

No Captulo 5 apresentado um estudo de caso resultante da aplicao do mtodo

proposto. O estudo de caso foi realizado em uma empresa real, onde o mtodo foi aplicado

pela prpria autora a alguns artefatos da rea de informtica. Para analisar o resultado do

mtodo foram realizadas 2 entrevistas com funcionrios da rea de informtica dessa empresa.

A concluso deste trabalho, suas contribuies e trabalhos futuros so apresentados no

Captulo 6.

6

2. Arquitetura Empresarial

A Arquitetura Empresarial um conjunto coerente de princpios, mtodos e modelos

que so usados no projeto e realizao da estrutura, dos processos de negcio, dos sistemas de

informao e da infraestrutura de uma empresa (LANKHORST, 2009). De acordo com essa

definio, a Arquitetura Empresarial relaciona os elementos que compem os processos de

negcio, informaes, sistemas e infraestrutura que permitem o funcionamento das

organizaes.

Na literatura existem diversos frameworks que apoiam o desenvolvimento e a

manuteno das iniciativas de Arquitetura Empresarial nas organizaes, alguns deles so

apresentados na seo 2.1.

Na seo 2.2 so apresentados alguns problemas encontrados nos frameworks de

Arquitetura Empresarial, mas especificamente nas representaes geradas, onde h

espalhamento e entrelaamento dos interesses transversais que fazem parte das representaes

da Arquitetura Empresarial.

Na seo 2.3 apresentada a Ontologia Empresarial e a metodologia DEMO (DIETZ,

2006) que complementam a noo de Arquitetura Empresarial (DIETZ e HOOGERVORST,

2008). A metodologia DEMO define conceitualmente a Ontologia Empresarial como a

essncia de uma empresa independente de implementao (DIETZ e HOOGERVORST,

2008) possibilitando identificar e representar a essncia de uma organizao. A identificao

da essncia auxilia o mtodo proposto nessa dissertao ao explicitar o conceitos que no so

interesses transversais.

2.1. Frameworks de Arquitetura Empresarial

Os frameworks da Arquitetura Empresarial auxiliam na tarefa de descobrir quais

elementos devem ser utilizados para representar a organizao, mas no so suficientes para

garantir a qualidade destas representaes durante seu ciclo de vida. Para tal, devem ser

adotados mtodos que indiquem as relaes entre os diversos domnios, vises e camadas da

7

arquitetura e as modificaes que devem ocorrer de forma metdica entre elas

(LANKHORST et al., 2005).

Abaixo sero apresentados alguns frameworks de Arquitetura Empresarial, de forma

resumida. Alguns destes possuem tambm um mtodo associado. Nestes casos, sero

apresentados os frameworks com seus componentes e seus mtodos.

2.1.1. Framework de Zachman

O Framework de Zachman, proposto por John Zachman em 1987, influenciou diversos

modelos de arquitetura e a rea de Arquitetura Corporativa (BOTTO, 2004). Este framework,

representado na Figura 1, uma estrutura lgica para classificar e organizar as representaes

descritivas de uma organizao que so relevantes para os stakeholders, desde o nvel

gerencial at os desenvolvedores de software. Ele prov uma forma concisa de estruturar e

modelar a organizao e a arquitetura de sistemas, de informao e de tecnologia (TANG et

al., 2004).

As colunas da matriz indicam as perspectivas (O que? Como? Onde? Quem? Quando?

Por qu?) que devem ser respondidas considerando o nvel de abstrao (contextual,

conceitual, lgico, fsico, implementao e funcionamento) ou de forma semelhante,

considerando o papel de quem faz as perguntas (planejador, proprietrio, projetista, quem vai

construir, quem vai implementar e sub-contratados). As linhas e colunas da matriz se

interceptam para definir um elemento de projeto (design) da arquitetura em uma clula, que

um resultado de uma atividade arquitetural baseada em um aspecto de um sistema para um

grupo particular de pessoas (TANG et al., 2004).

As clulas da matriz relacionam-se da seguinte forma: as clulas das colunas

respondem s interrogativas do nvel mais abstrato at a representao detalhada e as linhas

compem as diversas perspectivas que determinada pessoa precisa saber sobre a organizao,

representam os tipos de vises da corporao (BOTTO, 2004). Este framework no possui um

mtodo associado publicado e as relaes entre as diferentes clulas tambm no so

especificadas formalmente (LANKHORST et al., 2005), nem as primitivas que aparecem na

matriz. Este framework principalmente direcionado pelos requisitos de negcio e possui

prescrio de documentao padronizada no contedo de suas clulas (MCCARTHY, 2006).

Alm disso, este framework tambm no prov suporte para os requisitos no funcionais, nem

para a evoluo da arquitetura (TANG et al., 2004).

8

Figura 1 O Framework de Zachman 3.0 (ZACHMAN, 2011)

2.1.2. FEAF

O FEAF (Federal Enterprise Architecture Framework) foi criado pelo Chief

Information Officer Council e descrito no documento A Practical Guide to Federal

Enterprise Architecture que aponta aspectos de governana e construo de frameworks de

arquitetura. Este documento define os termos importantes para a arquitetura, indica os

benefcios de seu uso, indica quais princpios governam a arquitetura e descreve o processo de

criao da arquitetura, composto pelas seguintes atividades: aprovao e suporte da rea

executiva, estabelecimento de estrutura de gerncia e controle, definio um processo de

abordagem da arquitetura, desenvolvimento da AE corrente, desenvolvimento da AE futura,

desenvolvimento de plano de prioridades, utilizao da AE e manuteno da AE.

Este framework tambm organiza a arquitetura em tipos, so eles: arquitetura de

negcios, arquitetura de dados, arquitetura de aplicaes e arquitetura de tecnologia. Ele

utiliza parte do Framework de Zachman, gerando uma matriz perspectivas x arquiteturas

9

(BOTTO, 2004) e composto pelas 3 primeiras colunas do Framework de Zachman,

orientada organizao como um todo, ao invs de ser orientado TI apenas

(URBACZEWSKI e MRDALJ, 2006).

Segundo Tang et al. (2004), este framework organizado em 4 nveis: nvel I o mais

alto e lida com architecture drivers ou estmulo externo e direcionamento estratgico da

arquitetura, ele facilita a transformao da arquitetura atual em futura atravs dos padres e

gesto do processo arquitetural; o nvel II prov maiores detalhes ao analisar os business

drivers e design drivers da arquitetura e resulta em na arquitetura de negcio e na arquitetura

de design futuras; o nvel III detalha ainda mais a arquitetura ao utilizar as vises de negcios,

dados, aplicaes e tecnologia para modelar a arquitetura futura; j o nvel IV utiliza uma

combinao do Framework de Zachman e do Spewaks Enterprise Architecture Planning

(EAP) para representar a arquitetura de dados, arquitetura de aplicao e arquitetura de

tecnologia. FEAF principalmente um framework de planejamento e no prov suporte para

requisitos no funcionais, exceto segurana (TANG et al., 2004). Os componentes de

planejamento do FEAF so apresentados na Figura 2.

Figura 2 Componentes do planejamento da Arquitetura Empresarial traduzido de

(FEAF, 1999)

2.1.3. TEAF

O TEAF (Treasury Enterprise Architecture Framework) um framework proposto

pelo Tesouro Federal Americano, influenciado pelo Framework de Zachman e pelo FEAF. Os

recursos e produtos de trabalho do TEAF so representados na Figura 3. Neste framework

temos as seguintes perspectivas: planejador, dono, designer e construtor. Para cada uma

dessas perspectivas temos as seguintes vises: viso funcional, viso da informao, viso

organizacional e viso de infra-estrutura. Neste framework, uma perspectiva um ponto de

vista de toda a arquitetura representado em uma entidade organizacional (BOTTO, 2004).

Este framework tambm possui uma matriz onde so indicados os principais produtos gerados

no desenvolvimento da arquitetura (documentao e modelagem). O TEAF permite a

10

flexibilidade de definir vises e perspectivas adicionais com foco nico em reas importantes

para determinados stakeholders (URBACZEWSKI e MRDALJ, 2006).

Figura 3 Recursos e produtos de trabalho do TEAF para direcionar, descrever e

realizar a Arquitetura Empresarial traduzido de (TEAF, 2000)

2.1.4. DoDAF

O DoDAF (Department of Defense Architecture Framework) um framework do

Departamento de Defesa para rgos militares e agncias relacionadas. Este framework foi

criado em 2003 para combinar o framework C4ISR (comando, controle, comunicao,

computadores e inteligncia) com os componentes do modelo FEAF (McCarthy, 2006). Este

framework utiliza o CADM (Core Architecture Data Model) para documentar a arquitetura.

Este modelo uma taxonomia padronizada que define vises e seus elementos em uma base

de dados. Este esquema dependente do domnio para o qual foi criado (operaes de defesa)

(TANG et al., 2004).

O framework possui os seguintes pontos de vista representadas na Figura 4: todas as

vises prov uma viso geral da arquitetura; operacional identifica quais necessidades

precisam ser cumpridas e quem as far; de sistemas relaciona sistemas e caractersticas com

necessidades operacionais; e de padres tcnicos prescreve padres e convenes. Para cada

um desses pontos de vista so listados os artefatos a serem gerados (BOTTO, 2004). A

documentao padronizada, com grande parte dos elementos utilizando UML para alcanar

11

esta padronizao (MCCARTHY, 2006). Este framework no prov capacidade de

modelagem para configurao de sistemas e apoia limitadamente a modelagem de requisitos

no funcionais (TANG et al., 2004).

Figura 4 Pontos de vista arquiteturais do DoDAF v2.0 traduzido de (DoDAF, 2009)

2.1.5. TOGAF

O The Open Group Architecture Framework (TOGAF, 2009) possui um mtodo

detalhado e um conjunto de ferramentas para apoi-lo no desenvolvimento da Arquitetura

Empresarial. Seu objetivo prover um framework para projeto (design), avaliao e

construo das arquiteturas (TANG et al., 2004). A primeira verso do TOGAF foi baseada

em outro framework para Arquitetura Empresarial chamado TAFIM (Technical Architecture

Framework for Information Management), este framework foi desenvolvido pelo

Departamento de Defesa dos Estados Unidos (DoD) para auxiliar o desenvolvimento de seus

sistemas.

O TOGAF formado por vrios componentes: Mtodo de Desenvolvimento

Arquitetural (Architecture Development Method) utilizado para desenvolvimento da

12

arquitetura empresarial; Universo da Arquitetura Empresarial (Enterprise Continuum) um

repositrio de ativos arquiteturais; Framework de Contedo Arquitetural (Architecture

Content Framework) modelo estrutural do contedo gerado pela arquitetura e Framework

de Funcionamento Arquitetural (Architecture Capability Framework) material de referncia

para o funcionamento da arquitetura.

O ciclo do desenvolvimento arquitetural apoiado pelo ADM apresentado na Figura

5. O TOGAF explica as regras para desenvolver bons princpios, ao invs de prover um

conjunto de princpios arquiteturais (URBACZEWSKI e MRDALJ, 2006). O ADM uma

metodologia para enderear a arquitetura tanto no nvel organizacional quanto ao nvel de

sistemas individuais e o Enterprise Continuum, com sua base de conhecimento, auxilia a

evoluo arquitetural (TANG et al., 2004).

Figura 5 Architecture Development Method TOGAF traduzido de (TOGAF, 2009)

2.1.6. FEA

Segundo Urbaczewski e Mrdalj (2006), O FEA (Federal Enterprise Architecture)

pode ser associado ao FEAF, pois ele fornece orientao s agncias federais em relao aos

frameworks e permite flexibilidade no uso de ferramentas, mtodos e produtos a serem

utilizados pelas agncias individualmente. Ele foi desenvolvido pelo OMB (Office of

Management and Budget) com o apoio do GSA (General Services Administration) e do CIO

13

(Federal Chief Information Officers) e construiu um modelo (blueprint) abrangente e voltado

para o negcio do governo federal norte americano (FEA Consolidated Reference Model,

2007).

O FEA composto por modelos de referncia inter-relacionados que facilitam anlises

atravs das agncias e permite a identificao de investimentos duplicados, gaps e

oportunidades de colaborao. Em conjunto, os modelos de referncia compem um

framework que descreve elementos importantes do FEA de forma comum e consistente. Desta

forma, os portflios de TI podem ser melhor gerenciados e alavancados atravs do governo

federal norte americano. Os modelos de referncia, representados na Figura 6, so: PRM

(Performance Reference Model), BRM (Business Reference Model), SRM (Service Reference

Model), TRM (Technical Reference Model) e DRM (Data Reference Model). O PRM um

framework para medio de performance que prov sadas comuns de medies atravs do

governo federal. O BRM prov um framework para facilitar a viso funcional das linhas de

negcio do governo federal, incluindo suas operaes internas e servios prestados aos

cidados de forma integrada, ou seja, independente das agncias ou escritrios que os

disponibilizam. O SRM um framework funcional, orientado a negcio que classifica os

componentes de servios de acordo com a forma com que apoiam o negcio e os objetivos de

performance. O DRM um framework flexvel e baseado em padres que permite o

compartilhamento de informaes e o reuso atravs do governo federal usando descrio

padro e descoberta de dados comuns e a promoo de prticas para gesto uniforme de

dados.

Figura 6 Modelos de referncia do FEA traduzido de (FEA Reference Models)

14

2.1.7. IEEE 1471-2000

Segundo Lankhorst et al. (2005), o padro IEEE 1471-2000 constri uma base terica

para definio, anlise e descrio das arquiteturas de sistemas, com foco em sistemas

apoiados por software. Este framework utiliza a metfora da arquitetura de construo civil

para descrever a arquitetura dos sistemas de software. Ele tambm no padroniza o processo

de desenvolvimento, nem recomenda linguagens de modelagem ou metodologias ou padro a

serem adotados. O framework IEEE 1471-2000 prov um conjunto de definies de termos

chave e um framework conceitual que explica a forma como os termos chave se relacionam

uns com os outros conforme representado na Figura 7, explica o papel dos stakeholders na

criao e uso da descrio arquitetural e prov diversos cenrios nos quais as atividades

arquiteturais podem ocorrer durante seu ciclo de vida. Este padro tambm disponibiliza seis

prticas de descrio arquitetural. Alm disso, ainda lista pontos de vista arquiteturais

relevantes e sua especificao (conceitos, linguagem, modelagem e mtodo de anlise).

Figura 7 Modelo Conceitual do Framework IEEE 1471-2000 traduzido de (Hilliard, 2000)

15

2.1.8. Comparao entre os frameworks

Na literatura existem diversos trabalhos de comparaes entre os frameworks

(URBACZEWSKI e MRDALJ, 2006; TANG et al., 2004; MCCARTHY, 2006). A seguir

alguns destes trabalhos sero apresentados.

Urbaczewski e Mrdalj (2006) apresentam uma comparao entre diversos frameworks

de Arquitetura Empresarial (Framework de Zachman, DoDAF, TEAF, FEAF e TOGAF) com

intuito de fornecer um guia para seleo de um framework que atenda determinados critrios.

Este artigo realiza uma comparao entre os frameworks com base em suas vises e aspectos,

pois eles se diferenciam com relao s necessidades dos stakeholders que endeream e s

questes que preocupam seu mundo (URBACZEWSKI e MRDALJ, 2006). Os autores

estudaram os frameworks e criaram um mtodo para compar-los com base nas perspectivas

dos stakeholders e abstraes. Com base nesta comparao foi feita uma anlise de qual

framework mais adequado s necessidades de um stakeholder em um determinado projeto.

Por haver muitos focos diferentes entre os frameworks listados, os autores optaram por

comparar os frameworks com base em suas vises, abstraes e cobertura do ciclo de vida do

desenvolvimento de sistemas.

Com relao s vises, o Framework de Zachman foi considerado o mais abrangente,

permitindo que as vises dos demais frameworks fossem mapeadas para sua terminologia.

Com base na comparao que realizaram entre diversos frameworks, os autores identificaram

determinadas vises e depois elaboraram uma tabela onde indicado qual framework

enderea qual viso, alguns endeream todas, como o caso do Framework de Zachman e

outros endeream apenas algumas. As seguintes vises foram identificadas pelos autores:

planner (representa os conceitos do produto), owner (representaes do que o proprietrio tem

em mente), designer (produto final do arquiteto com detalhes do plano), builder (define como

ser a construo), sub-contractor (partes das sub-sees do plano de construo) e user

(resultado fsico do produto final). Cada uma destas vises possui determinado nome nos

frameworks analisados e em alguns casos, a viso est representada em mais de um

componente do framework.

Com relao s abstraes tambm foi utilizado o Framework de Zachman e suas

interrogativas, para cada uma delas (O que? Como? Quem? Onde? Quando? Por qu?) foi

identificado nos frameworks o contedo correspondente, por exemplo, O que? no TEAF

representado pela Information View, j no FEAF representado pela Data Architecture,

16

no DoDAF representado pelo Data (mission) Logical Data Model, no Framework de

Zachman representado por Data e no TOGAF no foi identificada uma representao

adequada.

A anlise de cobertura do ciclo de desenvolvimento de software, composto pelas fases

planejamento, anlise, projeto (design), implementao e manuteno resultou na seguinte

concluso: a maioria dos frameworks no enderea a manuteno de sistemas; os frameworks

fornecem orientaes que posteriormente sero incorporadas s fases do desenvolvimento de

software e o forte dos frameworks o planejamento com foco em prover guias com intuito de

evitar que sistemas se tornem obsoletos antes mesmo de serem desenvolvidos.

Em (TANG et al., 2004) tambm realizada uma anlise dos frameworks de AE. Para

os autores, frameworks de arquitetura so mtodos usados na modelagem da arquitetura que

proveem uma abordagem sistemtica e estruturada para projeto de sistemas.

Tang et al. (2004) apresentam um modelo para entendimento dos frameworks de AE

atravs da anlise de objetivos (goals objetivos a serem alcanados com a construo da

arquitetura), entradas (inputs informaes que a modelagem da arquitetura considera) e

resultados (outcomes representa resultados e entregas da arquitetura). Alm disso, os autores

ainda caracterizaram e identificam as deficincias de 2 classes de frameworks: Software

Architecture Frameworks e Enterprise Architecture Frameworks. Os seguintes frameworks

foram analisados: Framework de Zachman, 4+1 View Model Architecture, FEAF, RM-ODP

(Reference Model for Open Distributed Computing), TOGAF e DoDAF. Os frameworks 4+ 1

View e RM-ODP possuem foco no desenvolvimento de arquiteturas de sistemas (TANG et

al., 2004). A inteno dos autores analisar e comparar as semelhanas e diferenas entre

estes frameworks.

Tang et al. (2004) prov maiores detalhes do que considera serem objetivos, entradas e

resultados dos frameworks e com base na definio destes conceitos, os autores apresentam a

anlise dos frameworks. Por exemplo, um dos objetivos considerados pelos autores

architecture definition and understanding. Cada um dos frameworks analisado para

verificar se atende este objetivo, representado pela letra Y na Tabela 1, sendo atendido

parcialmente pelo Framework de Zachman, representado pela letra P na Tabela 1 e pelo 1+4

View Model Architecture. Quando o framework analisado no atende a um dos requisitos, a

letra N indicada na clula correspondente. Este objetivo atendido por todos os demais

frameworks analisados. Em alguns casos, o objetivo, entrada e resultado no so atendidos

17

por nenhum dos frameworks (representado pela letra N na Tabela 1), conforme apresentado

na Tabela 1.

Tabela 1 Comparao entre os frameworks traduzido de (TANG et al., 2004)

A modelagem da arquitetura utiliza abstraes de alto nvel chamadas vises. Os

frameworks utilizam pontos de vista (viewpoints) para criar vises que representam diferentes

perspectivas do modelo de um sistema (TANG et al., 2004). Pontos de vista comumente

utilizados pelos frameworks so: arquitetura de negcio, arquitetura de informao,

arquitetura de software e arquitetura tcnica. O uso de diferentes frameworks para projetar

(design) um sistema pode gerar resultados semelhantes, porm diferentes, pois cada

framework possui diferentes pontos de vista (viewpoints) para a arquitetura. Por outro lado,

utilizar o mesmo framework para projetar sistemas com complexidade variada pode necessitar

diferentes tipos de entradas e produzir resultados diferentes (TANG et al., 2004).

Tang et al. (2004) apontam duas deficincias dos frameworks de Arquitetura

Empresarial: o nvel de detalhe dos modelos geralmente no especificado e a anlise

racional (rationale) da arquitetura no parte obrigatria dos modelos. A anlise racional da

arquitetura est relacionada a como e porque determinada decises foram tomadas, essa

informao proveniente do design rationale da arquitetura que documenta as razes de

projeto (design) com base em anlise e conflitos de escolha (tradeoffs) que envolvem

mltiplas dimenses de entradas (TANG et al., 2004).

18

O resultado destas deficincias que os modelos no podem ser verificados ou

rastreados. Os autores tambm indicam que no h uma fronteira clara entre atividades

arquiteturais e atividades de projeto (design). Para sanar este problema, os autores propem

que sejam analisados os riscos associados ao software a ser desenvolvido, se o risco for alto,

ento deve-se utilizar mais tempo na atividade arquitetural para definio do projeto (design)

do software, seno pode-se dar mais ateno na fase de projeto (design).

McCarthy (2006) discute a importncia da AE, descreve 3 dos frameworks mais

utilizados no mercado e apresenta as implicaes de se ter um nico framework integrado. Os

frameworks citados so FEAF, DoDAF, TOGAF, Framework de Zachman e E2AF (Extended

Enterprise Architecture Framework). O autor aponta os seguintes componentes essenciais a

AE, endereados diretamente ou indiretamente pelos frameworks: alinhamento, integrao,

criao de valor, gesto de mudana e complacncia (compliance). A anlise do autor

reconhece que existem mais semelhanas do que diferenas entre os frameworks. Cada

framework indica a necessidade de mapear os fluxos de informao, aplicaes e infra-

estrutura tcnica. Alm disso, prescrevem uma metodologia especfica para enderear os

requisitos de negcio, fluxos de informao e infraestrutura tcnica.

2.2. Problemas encontrados na Arquitetura Empresarial

Segundo Zachman (1997), o grande desafio das organizaes modernas a mudana.

Segundo o autor, no possvel mudar sem ter a representao do que se deseja mudar. Desta

forma, se faz necessria a criao das representaes da organizao que faro parte da

Arquitetura Empresarial. A Arquitetura Empresarial pode ser vista como um sistema de

sistemas (ARMOUR et al., 1999).

Kaisler et al. (2005) apontam os desafios enfrentados pelas organizaes que esto

desenvolvendo suas Arquiteturas Empresariais. Para tal, os autores basearam-se em sua

experincia na implantao de AEs e em discusses com outros arquitetos de sistemas. Para

os autores, tais desafios esto muito mais relacionados com questes polticas, de gesto de

projetos e problemas e fraquezas organizacionais do que com questes tcnicas, devido ao

fato da criao da Arquitetura Empresarial ser conceitual, assim mais difcil, tanto

qualitativamente quanto quantitativamente, medir e descrever os benefcios de sua criao.

Trs reas onde os problemas crticos no processo de gerar a AE ocorrem so: modelagem,

gesto e manuteno das arquiteturas (KAISLER et al., 2005).

19

A modelagem cria as representaes da Arquitetura Empresarial. Segundo Kaisler et

al. (2005), a modelagem deve ser feita em dois nveis, um onde so criadas as representao

de como a arquitetura e como deveria ser e um outro que permita aos stakeholders entender

os problemas e o impacto das decises. Vale ressaltar que diferentes stakeholders necessitam

diferentes perspectivas atravs das vises da Arquitetura Empresarial (Kaisler et al., 2005),

portanto no adianta gerar um modelo perfeito se no trar vantagem para os times envolvidos

no projeto (KAISLER et al., 2005). O problema a ser solucionado nessa dissertao encontra-

se nas representaes da Arquitetura Empresarial. A soluo proposta nessa dissertao

auxilia no entendimento do impacto das decises, mais especificamente das modificaes,

porque os interesses transversais sero explicitados e representados separadamente das demais

representaes da organizao, qualquer modificao naquele conceito que representa o

interesse transversal dever ser refletida em todos os lugares onde ele ocorre, isso

representado pelo relacionamento transversal.

Uma viso arquitetural um ponto de vista bem definido que descreve um conjunto

especfico de representaes. A maioria dos frameworks de AE reconhece a necessidade de

vises, porm tendem a discordar do que so essas vises e de quantas devem existir

(ARMOUR et al., 2003). Vises arquiteturais diversas auxiliam a gerir a complexidade, a

separao de interesses ou preocupaes e a enderear as diferentes existncias que

atravessam os elementos da arquitetura (ARMOUR et al., 1999). Cada viso composta por

elementos, relacionamentos e restries. As vises fornecem uma imagem de como sistemas

de informao individuais enquadram-se na estrutura maior que suporta as operaes

organizacionais (ARMOUR et al., 2003). Para Armour et al. (2003), as vises arquiteturais

dos frameworks focam em dados ou informao, funes ou processos, estruturas de trabalho

ou organizacional, infra-estrutura tcnica, segurana e aplicaes (ARMOUR et al., 2003).

Segundo Armour et al. (2003), os usurios possuem requisitos funcionais e no

funcionais que so transversais Arquitetura Empresarial, tornando necessria uma

coordenao e gesto mais prxima dos times e localidades. Desta forma, as vises devem

tambm representar os requisitos transversais de forma a auxiliar gesto dos mesmos. Com a

soluo do problema apresentado nessa dissertao, os requisitos podero ser mais facilmente

entendidos no nvel organizacional.

Nessa dissertao, tratado um problema de modelagem na Arquitetura Empresarial,

j que os interesses transversais so repetidos nos diversos artefatos utilizados para

20

representar a Arquitetura Empresarial de uma empresa. Alm de repetidos, esto espalhados e

entrelaados com outros interesses (CAPPELLI et al., 2010a).

2.2.1. Linguagens para modelagem da Arquitetura Empresarial

Clark et al. (2011) propem um framework de AE simples, que v a organizao como

um mecanismo que executado em termos de componentes de comunicao

hierarquicamente decompostos, chamado LEAP. Esta uma linguagem de modelagem da AE

precisa, pois suporta restries escritas em OCL (Object Constraint Language), possui

semntica de domnio e requer a modelagem dos relacionamentos entre diferentes vises. Esta

linguagem pode ser mapeada diretamente para outras tecnologias da AE. O LEAP baseado

em modelos e todos os seus componentes so modelados a partir da camada de negcio que

captura os conceitos de negcio e as restries relativas aos business drivers, diretivas e

processos. A camada de aplicao um refinamento da camada de negcio, ou seja, um

ponto de vista mais detalhado da mesma organizao, nesta camada so adicionados estrutura

organizacional e os processos de negcio associados s informaes presentes na camada de

negcio. A camada de tecnologia um refinamento da camada de aplicao, introduzindo

mais detalhes do mapeamento de componentes lgicos de negcio para sua realizao fsica

na forma de sistemas de TI. Os mapeamentos entre camadas so modelados de forma a

garantir que nenhuma informao ser perdida. O LEAP tambm permite que mudanas na

rea de negcio sejam modeladas, descrevendo em um modelo o estado atual e em outro o

estado futuro. O diferencial desta abordagem, segundo os autores, o requisito de modelar os

relacionamentos entre diferentes camadas e estados da organizao. Alm disso, de acordo

com os autores, esta abordagem tambm possui semntica associada e isso permite que os

modelos sejam verificados.

No ArchiMate, uma outra linguagem para modelagem da Arquitetura Empresarial,

existe um limite de camadas: negcio, aplicao e tecnologia, porm no LEAP os modelos

podem ser refinados inmeras vezes, aumentado cada vez mais o detalhamento dos

elementos. O mapeamento entre LEAP e ArchiMate simples, com base em um UML profile.

Em termos de mtodos da Arquitetura Empresarial, o LEAP pode ser usado para adicionar

preciso aos modelos do ArchiMate ou o ArchiMate pode ser usado para documentar os

modelos baseados no LEAP.

Clark et al. (2011) apresentam um estudo de caso para prover uma viso geral do

framework LEAP. Segundo os autores, este framework no requer uma notao especfica, no

21

estudo de caso a UML foi utilizada. O estudo de caso refere-se a uma instituio de ensino na

Inglaterra, nesta instituio os recursos utilizados para ensino e aprendizagem no esto

alinhados e alguns mdulos de cursos assumem que todos os alunos possuem notebooks, mas

este no o caso. Diante desta situao, a instituio decide adotar um esquema para

emprstimo de notebooks utilizando a AE com objetivo de determinar se a adoo deste novo

esquema est de acordo com suas metas e entender como esta nova arquitetura funcionar.

O primeiro passo na anlise da Arquitetura Empresarial entender o estado atual da

organizao, que neste estudo de caso refere-se descrio das estruturas de informao

relacionadas a aluno, ensino e aprendizagem. O resultado desta fase inicial apresentado na

Figura 8, onde o componente university o nico componente que define as estruturas de

informao e as operaes que sero afetadas pelo esquema de emprstimo de notebooks.

Este modelo descreve a camada de negcio conforme definido pelo ArchiMate.

Figura 8 Camada de negcio da situao atual da UME (University of Middle England)

Os objetivos da camada de negcio e as operaes so especificados utilizando-se

OCL, Os objetivos representados atravs de invariantes so apresentados na Figura 9 e uma

das operaes (como o aluno registrado) apresentada na Figura 10.

Figura 9 Objetivo da camada de negcio

Figura 10 Como o aluno registrado

22

O refinamento da Figura 8 gera a Figura 11, onde est representada a camada de

aplicao da UME. Neste refinamento, dois componentes so identificados: registry e

resource. O primeiro responsvel pela manuteno da base de dados dos alunos e seus

mdulos, j o segundo mantm a base de dados dos agendamentos das salas.

Figura 11 Camada de aplicao

No refinamento tem-se definido como cada operao da camada de negcio

implementada na camada de aplicao. Na Figura 12 apresentado o refinamento das

operaes da camada de negcio implementado por um nmero de operaes de coordenao

da camada de aplicao.

Figura 12 Refinamento da camada de negcio

Para realizar a verificao do refinamento deve haver a satisfao da condio de que

todos os modelos semnticos que satisfazem a camada de aplicao tambm satisfazem a

camada de negcio e vice-versa. O mesmo tambm deve ser vlido para as operaes.

Aps a criao da representao da situao atual so criadas as representaes de

como dever ser a organizao. Na Figura 13 apresentado o modelo To-Be da camada de

negcio, foram includos dois conceitos: Laptop e LaptopBooking. Novas operaes tambm

foram includas e esto representadas na Figura 14.

23

Figura 13 TO-BE da UME

Figura 14 Operaes includas no To-Be da Camada de Negcio

Com o refinamento da camada de negcio, obtm-se a camada de aplicao,

representada na Figura 15. Conforme realizado na camada de negcio, as novas operaes

tambm precisam ser definidas na camada de aplicao (Figura 16).

Figura 15 To-Be da Camada de Aplicao

24

Figura 16 Refinamento Camada de Aplicao

Depois da elaborao dos modelos possvel definir os objetivos de negcio. O LEAP

permite definir os objetivos de forma precisa e verificar se eles so satisfeitos pelos modelos

da arquitetura. Alm disso, por ser um modelo baseado em semntica possvel verificar se

os objetivos so inconsistentes.

A UME precisa garantir que todos os alunos possuam acesso aos laptops. Os laptops

so comprados no incio do ano letivo. Considerando que a renda da instituio proveniente

dos pagamentos dos alunos, os fundos da instituio podem ser expressos pela restrio

apresentada na Figura 17.

Figura 17 Definio dos fundos da instituio

As demais invariantes especificam o clculo do nmero mximo de salas e do nmero

mximo de alunos matriculados e as restries de que o fundo da instituio deve ser maior

que zero e o nmero de laptops deve ser igual ao nmero mximo de alunos matriculados em

determinado mdulo. Estas invariantes esto representadas na Figura 18.

Figura 18 Definio dos fundos da instituio

25

A UME possui os seguintes business drivers: seus fundos devem sempre ser positivos

e sua reputao deve melhorar ao disponibilizar laptops para aluguel para todos os alunos. Se

no houver um modelo preciso que expresse a relao entre ganhos e perdas, no ser

possvel verificar se as metas so atingveis. Deve-se verificar se existe algum caso em que o

resultado da relao entre as variveis envolvidas nos objetivos no satisfaz as condies, se

este caso for identificado a relao deve ser aprimorada de forma a garantir que o objetivo

ser atingido em todos os casos.

Armour et al. (2003) descrevem como utilizar modelos padro da UML para descrever

a viso arquitetural da informao e algumas extenses para enderear limitaes da UML.

Arquitetura define um conjunto de componentes e os relacionamentos entre eles, no caso da

Arquitetura Empresarial de Tecnologia da Informao, um dos componentes so os sistemas.

A criao de uma AE muito complexa, pois envolve mltiplas vises organizacionais, como

processos de negcio, estrutura organizacional, processos funcionais, requisitos de

informao e infra-estrutura tecnolgica. tambm importante manter atualizadas as

representaes e as vises geradas pela AE. Neste trabalho foram apresentadas extenses

desenvolvidas atravs do uso de stereotypes e tagged fields para permitir a representao das

diversas vises da Arquitetura Empresarial.

Os autores descrevem o estudo de caso baseado em seu trabalho desenvolvido no

USCP (United States Capitol Police). O USCP responsvel por diversos sistemas

administrativos que formam uma coleo heterognea de sistemas legados. A manuteno e

operao de tais sistemas difcil e cara. Estes sistemas legados no conseguem acompanhar

o ritmo dos processos de negcio do USCP. Devido a estes problemas, o USCP iniciou um

processo de modernizao dos sistemas de negcio. Esta modernizao far com que os

sistemas se tornem web, algumas aplicaes que possuem interface com sistemas externos

tambm tero seus links modernizados. Por ser um projeto grande e atingir toda a

organizao, o USCP determinou a criao de uma AE.

A viso de negcio da AE permite o entendimento de como a organizao funciona e

como alinhar sistemas de informao para dar suporte s operaes de negcio, os autores

selecionaram as seguintes tcnicas para modelar a viso de negcio: Enterprise Business

Context Diagrams (Figura 19) e Business Activity Diagrams (Figura 20).

26

Figura 19 Diagrama de Contexto de Negcio do USCP

Na Figura 20 so representadas as atividades do processo de pagamento por perodo e

quase todas as atividades possuem a indicao do caso de uso que prov detalhes funcionais

das atividades, esta informao, segundo os autores, relevante e maiores detalhes sero

disponibilizados na viso funcional.

A viso funcional descreve os sistemas de informao do negcio ou atividades que

capturam, manipulam ou gerenciam as informaes de negcio que apoiam as operaes da

organizao. nesta viso tambm que so representadas as dependncias lgicas e os

relacionamentos entre aplicaes e suas funes. A abordagem escolhida pelos autores para

representar esta viso a modelagem de casos de uso. Para cada uma dos BPA (Business

Application Packages) apresentado na viso de negcio ser gerado um modelo de caso de

uso. Na Figura 21 apresentado o diagrama de caso de uso do BAP Pessoal.

27

Figura 20 Diagrama do Processo Pagamento por Perodo

28

Outras vises arquiteturais so apresentadas de forma breve pelos autores, sendo elas:

viso da informao, viso de trabalho e viso de infra-estrutura tecnolgica.

Figura 21 Diagrama de caso de uso do BAP pessoal

2.3. Ontologia Empresarial

Segundo Dietz e Hoogervorst (2008), as cincias organizacionais tradicionais

conseguem ajudar muito pouco as organizaes a implementar suas estratgias de forma

efetiva e controlada, ou seja, as organizaes dificilmente conseguem obter sucesso a partir de

sua estratgia. Ainda segundo Dietz e Hoogervorst (2008), diversas fontes indicam que as

principais razes para esta falha a falta de coerncia e consistncia entre os diversos

componentes de uma empresa. Alm disso, operar de forma integrada tem se tornado cada vez

mais importante com a globalizao e evoluo das tecnologias de informao e

comunicao. Assim as empresas precisam cada vez mais ser geis, adaptativas e

transparentes (DIETZ e HOOGERVORST, 2008).

Os problemas citados acima so endereados tradicionalmente com a forma de pensar

denominada caixa-preta. Essa forma de pensar trata do conhecimento sobre funo e

comportamento das organizaes. De acordo com Dietz e Hoogervorst (2008), esse

29

conhecimento suficiente para gerir uma organizao, mas inadequado para alcanar as

metas estratgicas e para realizar modificaes na organizao. Para que as mudanas sejam

realizadas de forma controlada e sistemtica, o conhecimento caixa-branca se faz necessrio.

Esse conhecimento sobre a construo e operao das organizaes. O novo ponto de vista

para esse conhecimento que as organizaes so sistemas propositalmente projetados,

passam pelo processo de engenharia (engineered) e implementados. Segundo os autores, as

organizaes so artefatos projetados, como carros, sistemas de informao, entre outros. A

propriedade que distingue as organizaes dos demais que os elementos ativos so os seres

humanos, mais especificamente os seres humanos no seu papel de indivduos sociais ou

sujeitos (DIETZ e HOOGERVORST, 2008).

Dietz e Hoogervorst (2008) afirmam que de um lado existem as tecnologias que

habilitam as organizaes forma futura e de outro lado existe uma crescente introspeco

das cincias da computao que a noo central para entender o relacionamento entre

organizao e TI fazer parte e cumprir os compromissos. Esses compromissos ocorrem

atravs da inteno dos atos comunicativos. Aqui a inteno da comunicao colocada

acima de seu contedo. Exemplos de inteno so solicitar, prometer, afirmar e aceitar. Essa

mudana de ponto de vista explica e clarifica as noes de colaborao e cooperao,

autoridade e responsabilidade. Assim, segundo Dietz e Hoogervorst (2008), essa mudana de

ponto de vista marca a transio da engenharia de sistemas de informao para a era da

engenharia da organizao.

Segundo Dietz e Hoogervorst (2008), a premissa bsica para engenharia da

organizao que a organizao um sistema projetado e no algo que vai acontecendo de

qualquer forma. Para garantir que esse projeto seja realizado consistentemente e

coerentemente, de tal forma que o resultado seja um todo integrado, 2 noes so

indispensveis: arquitetura e ontologia .

Segundo Dietz (2006), um artefato algo projetado e construdo, diferentemente de

coisas que existem naturalmente. Arquitetura de um artefato, segundo ele, um conjunto de

princpios de design que guiam ou que guiaro seu projeto.

Ontologia de um sistema teoricamente definida como o entendimento de sua

construo e operao de forma independente de implementao. Praticamente o modelo de

construo de mais alto nvel de um sistema. O modelo de implementao o modelo de mais

baixo nvel. Comparado ao modelo de implementao, o modelo ontolgico oferece uma

30

reduo de complexidade de mais de 90%. Por exemplo, o modelo de implementao de um

sistema de informao o cdigo fonte em alguma linguagem de programao. O modelo de

implementao de uma organizao consiste das funes ou pacotes de tarefas que podem ser

atribudos a seres humanos com base em sua competncia. O modelo mais alto chamado

modelo ontolgico ou ontologia de um sistema, esse modelo completamente independente

de implementao, ele apenas mostra as caractersticas essenciais do sistema.

Essa noo de Ontologia Empresarial, segundo DIETZ e HOOGERVORST (2008),

difere das demais (GMEZ-PREZ, FERNNDEZ-LPEZ e CORCHO, 2004; GRUBER,

1995; GUARINO, 1998) em 2 aspectos: a noo de ontologia de sistema onde o foco

entender a essncia da construo e operao de sistemas complexos, mais especificamente de

organizaes, diferentemente das demais que adotam a noo de ontologia do mundo onde o

foco definir as entidades centrais do mundo em questo e seus relacionamentos de forma

mais clara e extensiva. Vale destacar que a noo de ontologia de sistema engloba a noo de

ontologia do mundo. A noo de ontologia de sistema baseada na teoria da operao de um

sistema, no caso dos autores, a base a teoria PSI (Performance in Social Interaction). Essa

teoria fornece uma modelagem ontolgica para organizaes que cobre questes estruturais,

de processos e de aes de forma que os modelos resultantes podem ser executados ou

simulados, essa a teoria de fundamentao apresentada por Dietz (2006) para construo da

ontologia empresarial. O segundo aspecto diz respeito incapacidade da noo comum de

ontologia empresarial em distinguir de forma precisa e clara entre os nveis de abstrao

ontolgico, infolgico e datalgico. Esses nveis de abstrao esto relacionados com 3

habilidades humanas que so exercidas tanto em atos de coordenao quanto em atos de

produo (DIETZ, 2006). Nos atos de coordenao, a habilidade forma refere-se a aspectos de

forma, a habilidade informa refere-se a aspectos de contedo e a habilidade performa refere-

se a estar engajado em compromissos. Nos atos de produo, a habilidade forma refere-se

produo documental ou datalgica, a habilidade informa refere-se produo informacional

ou infolgica e a habilidade performa refere-se produo essencial de uma organizao

como, por exemplo, realizar novos fatos originais, esse tipo de produo chamada

ontolgica.

O objetivo da ontologia empresarial oferecer um novo entendimento das

organizaes de tal forma que uma pessoa possa ser capaz de olhar atravs de sua aparncia

confusa diretamente para sua essncia profunda (DIETZ e HOOGERVORST, 2008). DEMO

uma abordagem de ontologia empresarial baseada na teoria PSI. De acordo com a distino

31

dessa teoria entre funo e construo de um sistema, os servios coletivos que a empresa

prov ao seu ambiente so denominados como o negcio da organizao, eles representam a

perspectiva da funo. As atividades da empresa nas quais o negcio da organizao

realizado e entregue, incluindo os atores que realizam essas atividades so denominados

coletivamente a organizao da empresa, eles representam a perspectiva da construo.

De acordo com a teoria PSI, os sujeitos realizam atos de produo e atos de

coordenao (DIETZ, 2006). Ao realizar atos de produo, os sujeitos contribuem para

realizar os bens e servios que so entregues ao ambiente da organizao. Um ato de

produo pode ser material, como transporte ou fabricao ou imaterial como deciso,

julgamento e venda de bens. Ao realizar atos de coordenao os sujeitos estabelecem e

respeitam seus compromissos um para com o outro considerando a realizao dos atos de

produo.