Avaliaçao de Cen˜ arios de Optimizaç´ ao de uma ... · Avaliaçao de Cen˜ arios de...

Avaliacao de Cenarios de Optimizacao de umaArquitectura Empresarial

Francisco Miguel da Silva Cansado

Dissertacao para obter o grau de Mestre em

Engenharia Informatica e de Computadores

JuriPresidente: Professor Doutor Mario Rui Fonseca dos Santos GomesOrientador: Professor Doutor Andre Ferreira Ferrao Couto e VasconcelosCo-Orientador: Engenheiro Goncalo Jose SantosVogal: Professor Doutor Miguel Leitao Bignolas Mira da Silva

Outubro 2012

Agradecimentos

Em primeiro lugar gostaria de agradecer aos meus pais, pelo seu apoio incondicional durante

todo o meu percurso academico e sem os quais esta viagem nao seria possıvel.

Aos meus avos, que durante a realizacao deste trabalho, tiveram de lidar com a minha ausencia

e falta de disponibilidade, mas que sempre me apoiaram.

A minha namorada Andreia, por estar sempre ao meu lado, pelo animo que me transmitiu e ajuda

essencial para a realizacao do trabalho.

Gostaria de agradecer ao Professor Andre Vasconcelos pela orientacao dada ao longo da realizacao

desta dissertacao, pelo seu espırito crıtico e foco na melhoria contınua do trabalho no decorrer desta

investigacao.

Do lado empresarial, gostaria de agradecer ao Goncalo Santos, pela sua orientacao e disponibil-

idade, bem como pelas suas crıticas sempre construtivas ao trabalho em questao.

Ainda dentro do contexto empresarial, um obrigado para os colegas da Deloitte: Sergio Gomes,

Rufo Severino e David Amaro, pela sua amizade e palavras de encorajamento.

Ao meu colega e amigo Daniel Nunes, que acompanhou todo o meu percurso academico, e cuja

ajuda foi essencial na conclusao deste curso e trabalho.

i

Abstract

Today organizations are a complex system, composed of different types of elements, working to-

gether. Given the nature of organizations, they must deal with change, at some point of their lifecycle,

in order to improve their activity. Since they are complex systems, deciding what changes to do or not,

is not a trivial problem to solve. Furthermore, there may be several enterprise scenarios to choose

from in a given situation. In this work we intend to analyse the problem of selecting enterprise sce-

narios, and propose a methodology to guide and formalize, this kind of analysis. Our methodology is

based on the multi criteria analysis, and proposes GQM as a method to select and align metrics with

business objectives, and also incorporates SWING, as weighting method in order to compute a global

scenario score, from the value of single metrics. Regarding the metrics it is also presented in this

thesis a group of metrics that allow to differentiate scenarios based on the quantity of change impact

they produce on the overall architecture. Because there are dependencies between enterprise archi-

tecture elements, changing one element, will in some cases, force other elements to change also.This

is the change impact, that we intend to identify and measure in this work.

Keywords

Enterprise Architecture, Evaluation, Multi-Criteria Analysis, Weighting Methods, Metric Selection,

Change impact.

iii

Resumo

Actualmente as organizacoes sao um sistema complexo, composto por diversos tipos de elemen-

tos, que trabalham em conjunto para atingir um objectivo comum. Dada a natureza das organizacoes,

estas sofrem mudancas, em diversas fases do seu ciclo de vida, com vista a tornarem-se mais com-

petitivas. Uma vez que estas sao sistemas complexos, decidir que mudancas realizar, nao e um

problema com uma solucao trivial. Alem do mais, podem existir varios cenarios exclusivos entre si,

para escolher numa determinada situacao de mudanca. A metodologia proposta, pretende avaliar

estes cenarios atraves da arquitectura empresarial, com o objectivo de facilitar a escolha do cenario

que melhor cumpre uma serie de criterios identificados. Esta metodologia baseia-se na analise mul-

ticriterio, e incorpora o processo Goal Question Metric (GQM), para se garantir o alinhamento entre

as metricas seleccionadas e os objectivos do projecto. Como metodo de pesagem e utilizada a abor-

dagem SWING, que permite a partir dos resultados parciais das metricas, computar um resultado

global de cada cenario. E proposta uma nova dimensao de analise que tem por objectivo, diferenciar

os cenarios com base na quantidade de impacto que produzem na arquitectura empresarial. Este

impacto existe, devido as dependencias entre os elementos da AE, o que leva a que quando um

objecto e alterado, essa alteracao se propague a outros objectos associados. Um objectivo deste

trabalho e conseguir identificar e quantificar este impacto sistemico da mudanca.

Palavras Chave

Arquitecturas Empresariais, Avaliacao, Cenarios, Metricas, Impacto Sistemico, Analise Multicriterio.

v

Conteudo

1 Introducao 1

1.1 Contexto do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5 Organizacao do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Trabalho Relacionado 9

2.1 Arquitecturas Empresariais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1 Arquitectura organizacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.2 Arquitectura de Negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.3 Arquitectura de Sistemas de Informacao . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.4 Arquitectura Informacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.5 Arquitectura Aplicacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.6 Arquitectura Tecnologica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Frameworks de Arquitectura Empresarial . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 TOGAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.2 ZACHMAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.3 Framework CEO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.4 Archimate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.5 Analise Crıtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Metricas na Avaliacao de Arquitecturas Empresariais . . . . . . . . . . . . . . . . . . . . 17

2.4 Seleccao de Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5 Analise Multicriterio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.5.1 Elementos estruturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.5.2 Processo de analise multicriterio . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.5.3 Analise Crıtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.6 Goal Question Metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.6.1 GQM+Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.6.2 Analise Crıtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.7 Pesagem de Criterios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

vii

2.7.1 Analise Crıtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3 Impacto Sistemico 31

3.1 Impacto da Mudanca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2 Analise de Ligacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3 Metricas de Impacto Sistemico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 Solucao Proposta 43

4.1 Solucao Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1.1 Definicao do ambito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.2 Escolha de Metricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1.3 Representacao dos Cenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.1.4 Aplicacao das Metricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.1.5 Comparacao de cenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.1.6 Decisao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5 Ferramentas Aplicacionais Desenvolvidas 51

5.1 Algoritmo para aplicacao das regras de impacto. . . . . . . . . . . . . . . . . . . . . . . 52

5.1.1 Exemplo de Utilizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.1.2 Calculo Automatico de Metricas . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1.3 Exemplo de utilizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.2 Aplicacao para apresentacao dos resultados . . . . . . . . . . . . . . . . . . . . . . . . 54

6 Casos Praticos 57

6.1 Validacao das Regras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.1.1 Ambito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.1.2 Aplicacao das regras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.1.3 Medicao do impacto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.1.4 Conclusoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.2 Caso Pratico 2: Projecto CRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.2.1 Ambito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.2.2 Objectivos da Mudanca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67


6.2.4 Representacao de Cenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.2.5 Aplicacao de Metricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.2.6 Metricas de Impacto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.2.7 Comparacao de Cenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.2.8 Decisao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.2.9 Conclusoes caso pratico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

viii

7 Conclusoes e Trabalho Futuro 75

7.1 Conclusoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.1.1 Analise Multicriterio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76


7.1.3 Pesagem de Criterios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7.1.4 Analise de Impacto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7.1.5 Limitacoes e Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Bibliografia 79

Anexo A A-1

A.1 Representacao dos cenarios Caso CRM . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2

A.1.1 Cenario As Is . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2

A.1.2 Cenario To Be Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3

A.1.3 Cenario To Be Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4

A.2 Metricas do Caso CRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5

A.2.0.A Taxa de cobertura de requisitos funcionais . . . . . . . . . . . . . . . . A-5

A.2.0.B Taxa de cobertura de requisitos funcionais . . . . . . . . . . . . . . . . A-5

A.2.0.C Alinhamento entre Aplicacoes e Processos de Negocio . . . . . . . . . A-5

A.2.0.D Numero de layouts distintos . . . . . . . . . . . . . . . . . . . . . . . . A-6

A.2.0.E Tempo de implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . A-6

A.2.0.F Cumprimento da politica de seguranca do banco. . . . . . . . . . . . . A-7

A.3 Diagrama BPMN, da metodologia de avaliacao proposta . . . . . . . . . . . . . . . . . . A-8

ix

Lista de Figuras

1.1 Exemplo do Contexto da Avaliacao a realizar. . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Mapeamento entre a abordagem Design Research e as Fases de desenvolvimento da

Dissertacao) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Sub-Arquitecturas da arquitectura empresarial, adaptado de [1]. . . . . . . . . . . . . . 10

2.2 Processo de criacao de cenarios de negocio [2]. . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Framework de Zachman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Exemplo de relacao derivada, entre os elementos CRM e cliente [3]. . . . . . . . . . . . 16

2.5 Mapeamento entre fases do metodo ADM(TOGAF) e os domınios da arquitectura em

Archimate [3]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.6 Mapeamento dos domınios da AE nas dimensoes Archimate [3]. . . . . . . . . . . . . . 17

2.7 Passos do processo de gestao estrategica retirado de [4] . . . . . . . . . . . . . . . . . 20

2.8 Ligacao entre as 4 dimensoes estrategicas. . . . . . . . . . . . . . . . . . . . . . . . . 21

2.9 Mapa de conceitos na abordagem GQM retirado de [5] . . . . . . . . . . . . . . . . . . 25

2.10 Passos da metodologia GQM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1 Exemplo de ligacao Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33



3.4 Exemplo de ligacao Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34



3.7 Exemplo de ligacao Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35



3.10 Exemplo de ligacao Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36


3.12 Relacao entre Create e Extend em aplicacoes. . . . . . . . . . . . . . . . . . . . . . . . 37


3.14 Exemplo de ligacao Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38



xi

4.1 Passos da Avaliacao Proposta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2 1o Passo - Definicao do ambito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.3 2oPasso - Escolha de Metricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.4 Exemplo de simplificacao de uma arvore GQM. . . . . . . . . . . . . . . . . . . . . . . . 47

4.5 Exemplo de simplificacao de uma arvore GQM. . . . . . . . . . . . . . . . . . . . . . . . 47

4.6 3oPasso - Representacao dos Cenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.7 4oPasso - Aplicacao das Metricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.8 5oPasso - Comparacao de cenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.9 6oPasso - Decisao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.1 Codigo de cores utilizado para assinalar objectos impactados. . . . . . . . . . . . . . . 52

5.2 Interface da ferramenta de modelacao ARIS. . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3 Interface do script de aplicacao das metricas de impacto. . . . . . . . . . . . . . . . . . 54

5.4 Output do script de computacao das metricas. . . . . . . . . . . . . . . . . . . . . . . . 54

5.5 Interface da aplicacao para exibicao dos resultados. . . . . . . . . . . . . . . . . . . . . 55

6.1 Vista geral do ambito do projecto, o Processo de recuperacao de dıvida e o de gestao

de contencioso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.2 Vista detalhada do processo de gestao de dıvida. . . . . . . . . . . . . . . . . . . . . . 59

6.3 Vista detalhada do processo de gestao de contencioso. . . . . . . . . . . . . . . . . . . 60

6.4 Visao detalhada do processo de gestao de dıvida no cenario To Be 1, com aplicacao

das regras de impacto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.5 Visao detalhada do processo gestao de contencioso no cenario To Be 1, apos a

aplicacao das regras de impacto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.6 Visao detalhada do processo recuperacao de dıvida no cenario To Be 2, com aplicacao

das regras de impacto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.7 Visao detalhada do processo recuperacao de dıvida contenciosa no cenario To Be 2,

com aplicacao das regras de impacto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.8 Problema de decisao de impacto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.9 Diferentes solucoes, para resolver ambiguidade. . . . . . . . . . . . . . . . . . . . . . . 66

6.10 Strategic Map da organizacao, para iniciativa proposta. . . . . . . . . . . . . . . . . . . 68

6.11 Arvore GQM, para iniciativa proposta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.12 Distribuicao do peso total para cada metrica. . . . . . . . . . . . . . . . . . . . . . . . . 72

6.13 Pontuacao global de cada cenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.14 Pontuacao de cada cenario por metrica. . . . . . . . . . . . . . . . . . . . . . . . . . . 73

A.1 Modelo archimate do cenario As Is do caso CRM. . . . . . . . . . . . . . . . . . . . . . A-2

A.2 Modelo archimate do cenario To Be Local do caso CRM. . . . . . . . . . . . . . . . . . A-3

A.3 Modelo archimate do cenario To Be Cloud do caso CRM. . . . . . . . . . . . . . . . . . A-4

A.4 Modelo BPMN da solucao proposta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8

xii

Lista de Tabelas

2.1 Perspectivas e Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1 Metricas de impacto propostas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.1 Resultados das Metricas de impacto Aplicadas . . . . . . . . . . . . . . . . . . . . . . . 64

6.2 Resultados das metricas para os varios cenarios. . . . . . . . . . . . . . . . . . . . . . . 70

6.3 Resultados das metricas de impacto para os varios cenarios. . . . . . . . . . . . . . . . 71

6.4 Pesos atribuıdos aos objectivos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

xiii

1Introducao

Contents1.1 Contexto do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Organizacao do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1

1.1 Contexto do Problema

Cada vez mais as organizacoes estao dependentes dos seus sistemas de informacao de forma a

realizarem a sua actividade. Estes mesmos sistemas de informacao estao cada vez mais complexos

e directamente relacionados com o sucesso das organizacoes [1].

Como tal, para gerir as organizacoes e especialmente os sistemas de informacao e essencial

realizar analises que nos permitam conhecer o estado destes elementos em relacao a uma serie de

criterios. Em situacoes de mudanca, a necessidade de saber como estes sistemas e a organizacao

que os envolve irao reagir a uma determinada mudanca, e ainda mais importante.

Isto envolve saber que sistemas serao impactados pela mudanca e quais as qualidades dos

mesmos que podem sofrer com a mudanca.

Esta informacao torna-se ainda mais valiosa, quando estamos perante cenarios em que o nıvel

de incerteza e elevado ou a profundidade da mudanca maior. Sao exemplos disso:

• Mudancas aos processos de negocio;

• Fusoes entre entidades empresariais;

• Reestruturacao das aplicacoes;

• Adicao de novas funcionalidades;

• Substituicao da solucao core.

Quando confrontadas com estas situacoes, as organizacoes muitas vezes tem de escolher en-

tre diferentes cenarios possıveis de evolucao, os quais poderao levar a diferentes impactos na

organizacao, os seus goals e estrategia. A imagem 1.1 ilustra o contexto em que e feita a avaliacao

das mudancas apresentadas.

Os cenarios neste contexto, correspondem a historias, que englobam modelos, assuncoes, analises

e accoes ou projectos, bem como a forma como estes se relacionam e conduzem a possıveis estados

futuros do sistema ou organizacao em questao [6].

Figure 1.1: Exemplo do Contexto da Avaliacao a realizar.

2

Na presenca de tais situacoes em que existem diferentes cenarios possıveis, seria bastante util

para uma equipa de AE, possuir uma ferramenta que permitisse, de forma estruturada e procedimen-

tal, avaliar os varios cenarios possıveis bem como saber qual a profundidade das mudancas,ou seja

que elementos da arquitectura seriam afectados em cada cenario. Estabelecendo uma pontuacao,

ainda que relativa, entre os varios cenarios possıveis de evolucao.

De forma a que, o cenario mais vantajoso seja escolhido, atendendo aos goals da organizacao e

as qualidades que se pretendem optimizar.

Actualmente, a avaliacao baseada em cenarios conforme descrita anteriormente, encontra-se

ainda na fase inicial de desenvolvimento, uma vez que as ferramentas de AE existentes so agora

comecam a dar os primeiros passos no desenvolvimento de solucoes focadas nesse aspecto [6].

1.2 Problema

E nesta lacuna da avaliacao de cenarios que se insere o problema desta investigacao, de forma

geral o problema pode ser visto como:

Perante uma situacao de mudanca da arquitectura empresarial, como avaliar num determinado

momento no tempo, diferentes cenarios de evolucao para essa arquitectura empresarial, conseguindo

dessa forma saber qual o comportamento de cada cenario face a um conjunto de metricas. Este prob-

lema envolve avaliar todo o ambito da Arquitectura Empresarial, o qual e composto pelas diferentes

sub-arquitecturas descritas na seccao 2.1. E por isso um problema bastante vasto que pode ser

dividido nos seguintes sub-problemas:

• Que metricas usar para avaliar os cenarios ?

No campo do software e sistemas de informacao, existe um vasto trabalho ja realizado [7] [8],

apesar do seu foco cobrir apenas parte da arquitectura empresarial, este constitui um ponto de

partida importante.

• Qual o peso atribuıdo a cada metrica na avaliacao ?

Diferentes metricas, podem ter diferentes importancias dependendo dos objectivos e pontos de

vista presentes no projecto, como tal e importante incluir na avaliacao uma forma de ter em

conta esta variacao de pesos entre metricas (Seccao 2.7), de forma a aumentar a qualidade da

avaliacao efectuada.

• Como aplicar as metricas seleccionadas ?

A aplicacao de metricas envolve ter acesso a diferentes informacoes sobre a arquitectura e

sobre os cenarios em questao, sendo importante a capacidade de representar, os elementos

da arquitectura necessarios para a correcta aplicacao de metricas.

• Como avaliar o impacto que cada cenario produz na Arquitectura As Is ?

3

Pretende-se incorporar nesta analise, uma dimensao de avaliacao dos cenarios, que e o im-

pacto que produzem nos elementos da arquitectura actual. Para isso e necessario conseguir

estimar esse impacto, e quantifica-lo de forma a poder ser utilizado na analise proposta.

• Comparacao de Cenarios

Apos a aplicacao das metricas, e necessario estabelecer preferencias, entre os diferentes

cenarios possıveis, de forma a saber qual e o melhor de acordo com os objectivos tracados

e a sua pontuacao ao nıvel das diferentes metricas. Dentro da comparacao de cenarios alem

das metricas podera ser util conseguir comparar os cenarios em relacao aos nıveis de impacto

que tem na arquitectura, ou seja por exemplo, que cenario provoca uma maior mudanca na

arquitectura empresarial.

1.3 Objectivos

Os objectivos que se pretendem alcancar com este trabalho passam por desenvolver uma frame-

work no campo da avaliacao de cenarios que no final permita responder as questoes colocadas

anteriormente.

De forma a responder a estas questoes serao analisadas varias metodologias e outros trabalhos,

que cobrem os aspectos a desenvolver neste trabalho, de forma a conseguir reutilizar esses trabalhos

e enquadrar a sua aplicacao nos diferentes problemas encontrados.

• Avaliar os diferentes domınios da AE de forma a conhecer o estado de um cenario face a

um conjunto de qualidade, permitindo estabelecer um nıvel de preferencia entre os diferentes

cenarios, com o objectivo de seleccionar aquele que melhor preenche as qualidade pretendi-

das.

• Suportar aplicacionalmente esta avaliacao, propondo uma ou varias ferramentas que suportem

o processo de avaliacao e automatizem sempre que possıvel componentes desta avaliacao.

• Conseguir mostrar que elementos da AE sao afectados num determinado cenario, de forma a

ser possıvel diferenciar os cenarios em relacao ao seu impacto na estrutura da AE, utilizando

para isso, trabalho ja realizado na area das dependencias entre elementos da arquitectura

empresarial (Seccao 3.1), de forma a compreender as ligacoes existentes entre elementos da

arquitectura.

• A nıvel da escolha de metricas, e necessario definir uma abordagem para a seleccao de

metricas no ambito mais geral da arquitectura empresarial. Ao mesmo tempo deve garantir-se

que as mesmas estao alinhadas com os objectivos propostos. Ou seja, as metricas escolhidas

devem conseguir avaliar a concretizacao dos objectivos nos diferentes cenarios.

Sera necessario analisar metodologias, no campo do levantamento de metricas em contex-

tos mais gerais como a abordagem GQM (Seccao 2.6) e outros trabalhos com ambitos mais

focados em subpartes da arquitectura empresarial (Seccao 2.1).

4

• Analisar e escolher um metodo de atribuir pesos as metricas, baseado nos objectivos do pro-

jecto. E de esperar que diferentes metricas possuam diferentes importancias contribuindo com

um determinado peso para a avaliacao global de cada cenario.

Partindo de trabalhos na area do levantamento de preferencias, cujo objectivo e definir dentro

de um conjunto de criterios (as metricas) a importancia de cada um face aos restantes (Seccao

2.7).

1.4 Metodologia

O metodo de investigacao utilizado neste trabalho e o design research, uma vez que o objectivo

deste trabalho e a formulaca de um modelo de avaliacao, que sera posteriormente testado utilizando

observacoes reais.

As principais caracterısticas do design research sao, estar estruturado como um processo de

procura contınua, que comeca com a criacao de um design, um artefacto ou teoria, para o qual se

pretende demonstrar utilidade ou aplicabilidade no contexto real.

Isto pode ser traduzido em duas perguntas gerais que sao [9]:

• Qual a utilidade do novo artefacto ?

• Como e provada essa utilidade ?

O mapeamento desta metodologia para as etapas de trabalho desta dissertacao encontra-se

representado na seguinte imagem:

Figure 1.2: Mapeamento entre a abordagem Design Research e as Fases de desenvolvimento da Dissertacao)

1. Problema:

Nesta fase e identificado um problema, a sua origem pode ter diversas fontes, como algum

avanco cientıfico, um desenvolvimento a nıvel de uma industria, ou ate a aplicacao de alguma

descoberta. O output deste passo e a proposta, na qual e descrito o tema a que investigacao

sera dedicada. No caso desta tese, isto corresponde a identificacao do problema presente na

(Seccao 1.2), e a analise do estado da arte (Capıtulo 2).

2. Sugestao:

5

E essencialmente um passo criativo, onde e definida uma visao da funcionalidade que se pre-

tende obter quando o artefacto final estiver concluıdo, sendo analisadas as solucoes ja exis-

tentes para o problema, ou partes dele, de forma a perceber como podem ser ligados diferentes

trabalhos para formar uma possıvel solucao do problema. Esta etapa pode ser relacionada com

o capıtulo da solucao proposta, presente neste documento (Seccao 4.1), onde e proposta uma

abordagem para resolver os problemas (Seccao 1.2), ainda que o nıvel de detalhe nao permita

desde logo a formalizacao e aplicacao da sugestao.

3. Desenvolvimento:

O design proposto e implementado nesta fase, o conceito de desenvolvimento varia consoante

o tipo de artefacto que se quer produzir, podendo ir desde a validacao matematica no caso

de um algoritmo, implementacao do software, no caso de uma ferramenta. No caso deste tra-

balho, cujo contexto e o de desenvolver uma metodologia, corresponde a formalizar a mesma,

descrever que fases compoem a mesma, que metodos sao utilizados em cada passo e quais

os seus inputs e outputs. A formalizacao da abordagem, permite que seja reproduzida e a sua

aplicacao semelhante em cada caso. Esta fase corresponde ao trabalho realizado nos capıtulos

3, 4 e 5.

4. Avaliacao:

Uma vez construıdo, e necessario testar o artefacto desenvolvido contra os criterios inicial-

mente definidos, de forma a saber que criterios sao preenchidos com sucesso pela solucao

apresentada e quais os que apresentam um desvio. Desta analise deve ser possıvel formular

hipoteses que expliquem os desvios face ao esperado, podendo estes ser alvo de correccoes

ou indicarem futuros topicos de investigacao. A avaliacao da solucao, sera feita utilizando um

projecto real, uma empresa na area da banca que no passado levou a cabo um processo

de restruturacao, no qual foram consideradas varias solucoes para diferentes problemas, as

quais foram avaliadas sem recurso a uma metodologia de avaliacao estruturada e baseada

em cenarios. De forma a testar a aplicabilidade desta metodologia, foram utilizados casos de

estudo, apresentados no capıtulo 6.

5. Conclusao:

E a fase final do processo de design research, onde os resultados obtidos pela realizacao do

processo sao formalizados, revistos e sao prestadas satisfacoes quanto aos desvios detectados

na avaliacao, ou seja, sao mostradas as hipoteses levantadas para a sua correccao. Igualmente

sao apresentados os conhecimentos adquiridos ao longo do processo, classificados de acordo

com o seu nıvel de maturidade, se estao perfeitamente definidos e fechados ou se ainda ap-

resentam inconsistencias. Por ultimo, sao enunciadas possıveis hipoteses de pesquisa futura

com base nos topicos em aberto do trabalho realizado, isto e feito na conclusao (Capıtulo 7)

Esta etapa pode ser vista como o trabalho de escrita da dissertacao, onde e descrito todo o

trabalho realizado tendo em conta os pontos anteriormente enumerados.

6

1.5 Organizacao do Documento

Este trabalho encontra-se dividido em 6 capıtulos. No primeiro, a Introducao capıtulo 1, comeca-

se por contextualizar o problema abordado, apresentando o seu contexto e objectivos a alcancar com

este trabalho.

Em seguida e identificado o estado da arte capıtulo 2 em temas relacionados com o trabalho, de

forma a ser caracterizado o contexto em que este trabalho se ira inserir.

Depois e definida a solucao proposta capıtulos 4 e 5, de forma a compreender os diferentes ele-

mentos que a compoem, os principais passos, inputs e outputs do processo proposto. Esta solucao

e validada atraves de casos praticos apresentados em capıtulo 6.

Por ultimo fecha-se o documento com uma conclusao capıtulo 7.1, onde e feito um balanco de

todo o trabalho realizado, principais dificuldades e trabalho futuro.

7

2Trabalho Relacionado

Contents2.1 Arquitecturas Empresariais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Frameworks de Arquitectura Empresarial . . . . . . . . . . . . . . . . . . . . . . . 122.3 Metricas na Avaliacao de Arquitecturas Empresariais . . . . . . . . . . . . . . . . 172.4 Seleccao de Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5 Analise Multicriterio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.6 Goal Question Metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.7 Pesagem de Criterios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

9

Ao longo desta seccao e feito o levantamento do estado da arte, para o contexto do problema

de avaliacao de cenarios de uma arquitectura empresarial. Pretende-se com este levantamento

conhecer o estado em que se encontra o trabalho realizado neste campo, conhecer as lacunas

existentes de forma a que o trabalho realizado possa dar o maior contributo possıvel, dentro do

contexto escolhido.

2.1 Arquitecturas Empresariais

O conceito de arquitectura encontra-se definido na norma ISO/IEC 42010:2007 como:

“The fundamental organization of a system, embodied in its components, their rela-

tionships to each other and the environment, and the principles governing its design and

evolution.”

Ou seja, a arquitectura nao foca somente os aspectos estaticos do sistema representado, mas

tambem a forma como estes evoluem. Isto aplicado a uma arquitectura empresarial, significa que

esta representa, nao so os aspectos fundamentais da estrutura da organizacao, mas tambem as suas

relacoes com o ambiente, como os parceiros, os clientes ou os fornecedores. Alem dos factores que

determinam o seu desenho e evolucao [10].

E o nıvel de arquitectura mais geral que permite obter uma imagem geral e compreensıvel da

organizacao, da forma como as sub-arquitecturas que a definem se interligam e se encontram al-

inhadas. A hierarquizacao das sub-arquitecturas segue normalmente o princıpio “IT follows busi-

ness”, sendo que o ponto de partida sao os objectivos de negocio de onde se derivam os processos

necessarios para os atingir, e a infra-estrutura a nıvel de sistemas de informacao necessaria para

suportar esses processos [11] [10].

As sub-arquitecturas que compoem a arquitectura empresarial estao representadas em seguida

conforme descrito em [1] [10]:

Figure 2.1: Sub-Arquitecturas da arquitectura empresarial, adaptado de [1].

10

2.1.1 Arquitectura organizacional

Lida com os aspectos organizacionais da organizacao, que nao estao ligados aos processos de

negocio, usados para gerar valor. O principal conceito neste contexto e o recurso. Sao exemplos

disso as polıticas organizacionais, as unidades da organizacao como departamentos, os recursos

humanos ou a cultura organizacional.

A sua importancia esta na representacao de competencias, permitindo a procura e gestao dos

actores com determinadas capacidades de forma a que estes sejam alocados de uma forma mais

eficiente nas diferentes actividades [12].

2.1.2 Arquitectura de Negocio

Neste nıvel estao representadas as estrategias, bem como os processos de negocio, responsaveis

por gerar valor para o cliente. Estes processos de negocio devem encontrar-se alinhados com os SI

(sistemas de Informacao) que os suportam. Sendo que os processos de negocio fornecem os drivers

de negocio que motivam o desenvolvimento dos SI, pois de acordo com os princıpios de alinhamento

[13], os SI nao sao completamente aproveitados senao se encontrarem devidamente alinhados com

as necessidades do negocio, e da organizacao.

2.1.3 Arquitectura de Sistemas de Informacao

A arquitectura dos sistemas de informacao tem por objectivo representar a estrutura de compo-

nentes presentes nos sistemas de informacao, bem como as relacoes e princıpios que regem as suas

interaccoes. Neste nıvel de arquitectura, o detalhe deve ser elevado, de forma a permitir identificar

os diversos componentes quer a nıvel aplicacional ou tecnologico [1].

A arquitectura de Sistemas de informacao, devido a possuir uma maior granularidade e englobar

domınios bem distintos, quer a nıvel da representacao quer a nıvel das relacoes possıveis entre

conceitos, encontra-se dividida nas seguintes sub-arquitecturas [1].

2.1.4 Arquitectura Informacional

O objectivo desta arquitectura e definir os principais tipos de dados e fontes de dados necessarios

para suportar o negocio. Esta arquitectura deve permitir aos stakeholders compreender que dados

estao envolvidos nos diferentes processos, representa-los de forma completa e consistente e sobre-

tudo estavel. Nao e do ambito desta arquitectura o desenho especifico da base de dados a imple-

mentar quer a nıvel logico quer a nıvel fısico, mas sim a identificacao das entidades informacionais

manipuladas nos diferentes processos [2].

2.1.5 Arquitectura Aplicacional

11

Na arquitectura Aplicacional, estao definidos os principais artefactos aplicacionais da empresa,

cujo objectivo e suportar os processos de negocio da organizacao. O objectivo desta representacao

e definir que objectos aplicacionais sao relevantes para o funcionamento da empresa. Como tal as

aplicaccoes nao sao descritas como sistemas computacionais, mas sim na sua vertente de capaci-

dades logicas, ou seja que dados permitem manipular e quais as suas principais funcoes [1][2].

2.1.6 Arquitectura Tecnologica

A funcao da arquitectura Tecnologica e mapear para componentes tecnologicas, ou seja hardware

ou software, as aplicacoes definidas na arquitectura aplicacional. Define a realizacao fısica de uma

solucao arquitectural, estando fortemente ligada a tematica da implementacao [2] .

Esta possui uma serie de vistas e de conceitos, uma vez que existem varias caracterısticas que

se podem analisar neste contexto, como a seguranca, as comunicacoes e elementos de hardware.

2.2 Frameworks de Arquitectura Empresarial

A definicao formal de uma arquitectura empresarial, que descreva os objectivos da organizacao,

os processos que esta desenvolve, a forma como estes utilizam os sistemas de informacao, traz

diversos benefıcios para a organizacao [10] [11]:

• Alinhamento: garantir que a realidade da organizacao corresponde aquilo que era o plano, e

que todos os elementos da organizacao trabalham no mesmo sentido;

• Integracao: verificar que as regras de negocio sao consistentes, ao longo da organizacao;

• Facilitar a mudanca: tornando possıvel prever alteracoes ao desempenho da organizacao con-

soante as alteracoes propostas.

Existem diferentes frameworks que exploram diferentes aspectos da representacao das arquitec-

turas empresariais, dependendo do seu foco, estas podem ser vistas como metodologias, ontologias

ou linguagens de representacao.

2.2.1 TOGAF

Trata-se de uma framework focada no aspecto de desenvolvimento de uma arquitectura empre-

sarial, desenvolvida pelo The Open Group. Nao possui notacoes nem linguagem proprias. Nesta

framework a arquitectura possui duas definicoes consoante o contexto [2]:

1. Pode ser vista como a descricao de um sistema, ou seja, um plano detalhado que permita a

implementacao do sistema.

2. Uma estrutura de componentes, as suas interligacoes, e princıpios que descrevam o seu design

e evolucao ao longo do tempo.

12

Permite lidar com as seguintes arquitecturas:

• Arquitectura de negocio: Referente a estrategia de negocio, os processos de negocio chave,

bem como a sua governacao e organizacao (Seccao 2.1.2;

• Arquitectura de dados: trata a estrutura dos dados da organizacao, quer em termos logicos

quer em termos fısicos;

• Arquitectura de Aplicacoes: fornece um esquema para cada aplicacao bem como as interaccoes

entre aplicacoes e as relacoes de suporte entre aplicacoes e processos de negocio (Seccao

2.1.5);

• Arquitectura tecnologica: descreve o hardware necessario para implementar o software que

suporta o negocio, os seus dados, redes e comunicacoes (Seccao 2.1.6);

A framework TOGAF, aborda o conceito de cenario de negocio. Segundo esta, e uma descricao

detalhada de um problema a nıvel de negocio, que permite ver os diferentes requisitos desse prob-

lema e coloca-los em contexto.

O uso de cenarios de negocio traz beneficios claros para a organizacao, estes sao:

• Ajuda a clarificar o problema, bem como a relevancia da solucao para a organizacao;

• Permite ainda facilitar a comunicacao quer entre os stakeholders das diferentes areas, bem

como os fornecedores da solucao.

Este conceito dos cenarios de negocio e explorado, em maior detalhe, sendo inclusive proposto

um processo para a criacao de cenarios de negocio, bem como a sua analise 2.2.

Figure 2.2: Processo de criacao de cenarios de negocio [2].

De acordo com [2] e possıvel construir cenarios de negocio atraves de sucessivas iteracoes de

um ciclo composto por 3 fases:

13

• Gathering: e a fase em que a informacao necessaria para elaborar os cenarios e recolhida,

nao e imposto nenhum formato para recolha de informacao especifico, fica ao criterio de quem

aplica o processo.

• Analyze: A fase em que se analisa a informacao levantada anteriormente, e se utiliza a mesma

para construir modelos e descricoes arquitecturais que possam ser compreendidas pelos papeis

envolvidos na analise.

• Review : Por ultimo deve ser feita uma partilha dos resultados da analise, de forma a garantir

que existe um entendimento comum, sobre o cenario em causa, por parte de todos os interve-

nientes.

Estes cenarios de negocio, sao distintos dos que se pretendem avaliar, na metodologia proposta

4.1. Enquanto os cenarios de negocio, representam diferentes problemas, os cenarios de arquitec-

tura empresarial, sao possıveis solucoes para um determinado cenario de negocio. Desta forma

podemos ter para um cenario de negocio, varios cenarios de optimizacao cada um com uma solucao

para o problema apresentado.

2.2.2 ZACHMAN

Trata a categorizacao e organizacao das diferentes representacoes da arquitectura, de forma a

poderem ser relacionadas. Neste aspecto e mais uma ontologia do que propriamente uma metodolo-

gia, uma vez que nao define a forma como a representacao dos artefactos deve ser feita, nem o pro-

cesso de os gerar [14]. Os artefactos podem ir desde diagramas, relatorios, planos ou descricoes,

fica ao criterio de quem usa a framework escolher o melhor formato. Permite escolher as vistas ou

artefactos a desenvolver para responder a uma determinada preocupacao (concern) das diferentes

camadas de negocio (stakeholders). A correspondencia entre preocupacoes e camadas de negocio

e feita por meio de uma tabela bi-dimensional[15]:

Figure 2.3: Framework de Zachman.

Esta tabela1 permite mostrar em ordem a duas dimensoes, o ambito da AE (linhas) e para cada1http://www.tefg.com/pdf/EFG-Zachman-Enterprise-Framework2-An-Overview.pdf

14

ambito, diferentes aspectos da descricao arquitectural (colunas). Cada intercepcao entre linha e

coluna, corresponde a uma serie de artefactos que podem ser usados para descrever a arquitectura

empresarial de acordo com o enquandramento em causa.

2.2.3 Framework CEO

Esta framework [16], tem como ambito a modelacao no contexto mais geral das arquitecturas

empresariais, bem como mostrar que processos estao ligados aos objectivos, cobrindo dessa forma

todas as sub-arquitecturas descritas na (Seccao 2.1).

O metamodelo da framework, que dispoe de elementos para representar as diferentes camadas

da AE e o seguinte:

A CEO assenta sobre a linguagem UML, disponibilizando uma serie de vistas sobre a AE :

• Vistas estaticas, sao vistas em que a dimensao tempo nao varia. Estas englobam vistas

inter-arquitecturas onde e visıvel a relacao entre elementos das diferentes camadas.

• Dinamicas , sao vistas onde e contemplado o tempo enquanto dimensao, sao exemplos destas

vistas, diagramas de sequencia ou de colaboracao.

• Tematicas, servem para ilustrar um determinado problema ou representar um ponto de vista

sobre a arquitectura.

Existem metricas definidas em [17], que podem ser aplicadas em modelos criados usando FCEO.

Estas vao desde metricas relacionadas com o nıvel de seguranca nos SI, ate nıveis de alinhamento

entre camadas como o numero de aplicacoes que manipulam a mesma entidade informacional.

No contexto deste trabalho, a framework FCEO e de destacar pela capacidade de representar

toda a AE, inclusive a ligacao entre os objectivos e os processos de negocio que os suportam. O

conjunto de metricas ja definido, nesta framework, podera contribuir para o trabalho de escolha de

metricas, de acordo com a dimensao arquitectural que se pretende analisar.

2.2.4 Archimate

Esta framework tem como foco a representacao da ligacao existente entre conceitos, dos difer-

entes domınios da arquitectura e a forma como estes estao associados. Nao restringe o uso de

nenhuma linguagem para representacao dos domınios [3] [11].

Permite tornar visıveis, ligacoes entre elementos de diferentes domınios que podem nao ser

obvias, isto pode ajudar a compreender quais as dependencias entre elementos das diferentes

camadas [18]. Neste contexto e importante o conceito de ”relacao derivada” definido pelo Archi-

mate, segundo o qual se ha um caminho de ligacoes entre dois elementos, entao existe uma ligacao

derivada entre estes que os liga directamente.

A figura seguinte ilustra este tipo de ligacao entre os elementos CRM e cliente, tornando clara

uma ligacao que poderia nao ser detectada de outra forma.

15

Figure 2.4: Exemplo de relacao derivada, entre os elementos CRM e cliente [3].

De acordo com esta abordagem a arquitectura encontra-se dividida em 3 camadas: Negocio,

Aplicacao e Tecnologia. Isto e semelhante a divisao da arquitectura presente no TOGAF, apesar do

ambito deste ultimo ser mais abrangente, e possıvel fazer uma ponte entre as duas abordagens na

medida em que alguns viewpoints do TOGAF podem ser representados com recurso a Archimate.

Esta relacao e ilustrada na seguinte figura [2].

Figure 2.5: Mapeamento entre fases do metodo ADM(TOGAF) e os domınios da arquitectura em Archimate [3].

Alem da divisao em 3 camadas, cada uma destas pode ser dividida em 3 outras componentes,

estrutura passiva, comportamento e estrutura activa.

As entidades do domınio activo, podem ser por exemplo, indivıduos (clientes ou empregados,

ou grupos destes (departamentos) e sao estes actores que desenvolvem o comportamento, que

actua sobre as entidades do domınio passivo, que correspondem aos conceitos sobre os quais um

determinado negocio opera[3].

Em seguida ilustra-se a forma como as diferentes dimensoes se relacionam com os varios domınios

da AE tratados em Archimate.

16

Figure 2.6: Mapeamento dos domınios da AE nas dimensoes Archimate [3].

2.2.5 Analise Crıtica

Neste capıtulo foram analisadas diferentes frameworks, que abordam o problema da representacao

da arquitectura empresarial sob diferentes perspectivas. E por isso importante identificar as diferencas

entre as mesmas, de forma a analisar o seu mapeamento para o contexto deste trabalho.

Na framework TOGAF, o conceito de cenario da arquitectura, ja e contemplado no entanto, o

processo de levantamento e analise dos cenarios nao e utilizado para a comparacao directa entre

cenarios, com o objectivo de escolher o melhor cenario, que e o objectivo deste trabalho. Sao contudo

enunciadas neste processo, caracterısticas dos cenarios e do processo para a seu levantamento que

serao um contributo importante para o trabalho proposto. Na framework de Zachman, o foco e a

organizacao dos artefactos de arquitectura empresarial disponıveis, criados com recurso a outras

abordagens, uma vez que na framework de Zachman nao e especificada nenhuma linguagem de

representacao. A framework TOGAF por outro lado, foca-se no processo de desenvolvimento usado

para realizar os artefactos arquitecturais. Definindo os passos necessarios para controlar e levar a

cabo esse processo.

As frameworks Archimate e FCEO, por outro lado, sao focadas na criacao de modelos arquitec-

turais que representem a arquitectura empresarial. O seu ambito e a vertente mais abrangente da

arquitectura empresarial, sendo que a FCEO oferece maior detalhe relativamente aos tipos de ele-

mentos disponıveis para efectuar a representacao, o Archimate e mais simples neste aspecto. Por

outro lado o Archimate encontra-se mais divulgado do que a FCEO, o que dado o contexto empre-

sarial em que o trabalho se desenvolve, corresponde a uma mais valia.

E visıvel que a tematica da avaliacao de cenarios ainda e pouco explorada, a nıvel das diferentes

frameworks, o que deixa espaco para a elaboracao de um trabalho de investigacao como aquele que

aqui se apresenta, que procura contribuir para esta lacuna das ferramentas existentes.

2.3 Metricas na Avaliacao de Arquitecturas Empresariais

A avaliacao das arquitecturas empresariais, e de sistemas de informacao ainda se encontra em

desenvolvimento e num estado de maturidade inferior ao da avaliacao de sistemas de software, para

os quais ja existe um conjunto de qualidades padronizado ISO 9126 [19] [20]. Como tal ja foram

17

levados a cabo esforcos para transportar para o domınio dos sistemas de informacao as qualidades

usadas para avaliar os sistemas de software [1].

Nestes trabalhos sao definidas metricas para avaliar o estado da arquitectura relativamente a um

conjunto de qualidades.

De uma forma geral, uma metrica e a quantificacao de um determinado atributo, de forma a

suportar uma tomada de decisao. Segundo [21], uma metrica e a atribuicao de um valor quantificavel

a um atributo, que depois e comparado com o esperado. No campo da escolha e definicao de

metricas ja existe um longo trabalho realizado, existindo um conjunto de princıpios a respeitar quando

se definem metricas [1]:

• Princıpio 1: Assegurar a objectividade das metricas, atraves da sua clara, inequıvoca e formal

definicao;

• Princıpio 2: As metricas devem ser independentes da dimensao (a nao ser que o objecto da

metrica seja a medicao da dimensao), adimensionais ou expressas num sistema coerente;

• Princıpio 3: As metricas devem ser aplicaveis em fases iniciais do projecto, de forma a detectar

precocemente eventuais problemas e levar a sua correccao;

• Princıpio 4: As metricas devem ser aplicadas a particoes dos sistemas em consideracao, facili-

tando a sua analise e a tarefa de avaliacao;

• Princıpio 5: A quantificacao das metricas deve ser obtida de forma automatica para agilizar o

processo e reduzir os potenciais erros;

• Princıpio 6: As metricas devem ser independentes do formalismo usado, nao estando depen-

dentes de metodos, ou abordagens de analise;

• Princıpio 7: As metricas devem representar diferentes facetas do desenho, o aspecto analisado

numa metrica nao se deve sobrepor ao de outra;

• Princıpio 8: As metricas devem ter poder discriminante, ou seja deve ser possıvel colocar todos

os valores possıveis numa escala.

Estes princıpios, constituem um importante ponto de referencia na definicao de metricas, alem

destes em seguida apresenta-se um conjunto de erros comuns, observados no processo de definicao

de metricas, de forma a serem levados em conta e evitados quando se executa um processo de

levantamento de metricas, como o que e realizado neste trabalho:

• Nao medir a realidade correcta, ou seja medir algo que nao acrescenta valor ao que ja se sabe,

ou medir algo de forma incompleta ignorando dados importantes [22];

• Ser tendencioso na escolha de metricas, ou seja medir apenas aquilo que a partida tera um

bom resultado [23];

18

• Deixar o ambito da organizacao e os seus interesses interferirem na medicao de performance

[23];

• Partir do princıpio que se conhece o que se quer medir [23];

• Escolher o ponto de vista errado para realizar a medicao. O ponto de vista sob o qual o resul-

tado da metrica e analisado deve ser, o de quem tem percepcao sobre a qualidade medida. Por

exemplo medir do ponto de vista da organizacao em vez do ponto de vista do cliente [22] [23];

• Nao levar em conta o impacto que as metricas provocam no comportamento humano. Quando

se define uma metrica, no caso desta se aplicar a pessoas, deve-se ter sempre em conta que

a sua aplicacao, ira ter impacto no comportamento das mesmas. Ou seja uma vez posta em

pratica, os comportamentos que maximizam o valor da mesma serao de certa forma incentiva-

dos enquanto os comportamentos com impacto negativo na metrica inibidos, isto e valido nao

so no comportamento de pessoas individuais como no contexto de uma organizacao [24] [23]

[22];

• Evitar metricas cujos dados necessarios para efectuar o seu calculo, sao difıceis de reunir e o

seu custo de recolha e elevado [22];

Tendo em conta os erros e princıpios identificados anteriormente, e possıvel levar a cabo um

levantamento de metricas com maior qualidade, conduzindo a metricas de maior qualidade. De

forma a obter metricas existem diversas metodologias, cujo foco pode ser tanto procedimental como

estrutural. Uma abordagem estrutural a definicao de metricas, trata a definicao de uma tipologia para

a definicao e gestao de metricas. No caso de uma abordagem procedimental, sao definidos passos

para a obtencao de metricas a partir da estrategia [24].

2.4 Seleccao de Objectivos

Um problema, quando se procura fazer uma avaliacao, seja a uma arquitectura empresarial, seja

em qualquer outro ambito, e a definicao de objectivos de forma a guiar a avaliacao.

Os objectivos caracterizam o que se pretende atingir, como tal todo o processo de avaliacao

deve levar esses mesmos objectivos em conta, de forma a que a avaliacao seja sempre focada nos

mesmos. So desta forma a avaliacao pode constituir uma ferramenta valiosa, para determinar o

estado actual e o seu desvio, face ao goal (estado futuro) pretendido.

Os goals sao descricoes de futuros estados ou resultados que se esperam alcancar, sao o fim e

nao o meio. Os objectivos por outro lado, tratam do meio que se utiliza para alcancar esse mesmo

goal.

Como se podem entao seleccionar bons objectivos, que permitam escolher por sua vez boas

metricas ?

De acordo com o processo de gestao estrategica [4] [25], os objectivos da organizacao devem

ser derivados da visao e missao da organizacao. Ou seja, definem de uma forma mais concreta o

19

que esta descrito na visao, tornando possıvel monitorizar a organizacao, em relacao aos objectivos

tracados.

Os passos do processo de gestao estrategica mostram-se em seguida:

Figure 2.7: Passos do processo de gestao estrategica retirado de [4]

No caso deste trabalho, em que o objecto a avaliar e uma organizacao, atraves da sua arquitectura

empresarial, os objectivos que serao avaliados para conhecer o desempenho da organizacao, devem

ser aqueles definidos a partir da estrategia definida para a organizacao.

Uma abordagem que procura fazer esta ligacao entre a estrategia, os objectivos e goals e o mapa

estrategico, em ingles strategy map, que se apresenta em seguida. Esta abordagem proposta por

[26], pretende organizar todos os objectivos da organizacao em 4 grandes perspectivas, onde se po-

dem integrar os diferentes objectivos possıveis. Esses domınios, sao como ilustra a seguinte figura,

o domınio Financeiro, o domınio do Cliente, dos Processos Internos e por ultimo a aprendizagem e

crescimento. Cada um dividido em 4 dimensoes: Os objectivos, as medidas, os alvos e as iniciativas.

Neste modelo e mostrada ainda a relacao de causa efeito que existe entre os determinados

objectivos, atraves da ligacao entre estes.

20

Figure 2.8: Ligacao entre as 4 dimensoes estrategicas.

Estas quatro dimensoes permitem alinhar todos os objectivos de uma organizacao, perante a

estrategia pretendida:

• Financeira: Neste campo os objectivos ligados ao lucro terao maior destaque (lucros, despe-

sas, retorno, ganhos e perdas) no entanto existem outros que podem ser considerados, por

exemplo a gestao do risco. Conhecer o estado em relacao a estes objectivos e essencial para

possuir uma visao clara do ambiente financeiro.

• Cliente - Se os clientes nao estiverem satisfeitos com os servicos disponibilizados, eventual-

mente poderao deixar de comprar os servicos ou produtos disponibilizados. Logo possuir ob-

jectivos e indicadores de performance que permitam conhecer o estado da organizacao neste

campo, e essencial para garantir que o cliente esta satisfeito ou que se conseguem novos

clientes.

• Processos de Negocio Internos: Os objectivos deste ponto, permitem aos gestores conhecer

a situacao da organizacao, relativamente aos seus processos de negocio, quer os orientados

ao cliente quer os de suporte ( funcoes de negocio ). Estes ultimos sao muitas vezes repetitivos,

21

o que os torna mais simples de avaliar do que os processos de negocio, que muitas vezes sao

unicos e logo mais difıceis de medir.

• Aprendizagem e Crescimento: A infraestrutura de uma organizacao, e o que lhe permite op-

erar com eficacia, e gerar o maximo valor possıvel para o cliente, bem como permitir inovacoes.

Os objectivos desta area, estao geralmente associados ao investimento ou financiamento de

determinadas estruturas, os quais devem provocar o maior ganho possıvel na capacidade da in-

fraestrutura suportar os processo existentes, e permitir o crescimento e inovacao. Alem da infra-

estrutura, uma organizacao e constituıda igualmente pelas pessoas, assim nesta dimensao sao

considerados tambem os objectivos relativos ao pessoal e sua aprendizagem.

Cada uma das perspectivas deve ser detalhada nas seguintes dimensoes:

• Objectivos sao as consequencias esperadas para a iniciativa;

• Medida As dimensoes atraves das quais se pretendem avaliar o sucesso dos diferentes objec-

tivos;

• Alvo O estado que se pretende alcancar com a iniciativa proposta;

• Iniciativa A mudanca que se pretende levar a cabo, ou seja o conjunto de actividades a de-

senvolver.

No ambito deste trabalho, a avaliacao de arquitecturas empresariais, os objectivos presentes

nas perspectivas de processos de negocio internos e de aprendizagem e crescimento, sao aqueles

que melhor se enquadram para uma avaliacao atraves da arquitectura empresarial. Os conceitos

envolvidos nos objectivos destas perspectivas, sao aqueles que se encontram igualmente mapeados

para os elementos presentes na arquitectura empresarial, permitindo assim a sua avaliacao atraves

da aplicacao de metricas dos diferentes domınios da AE.

Em seguida apresentam-se exemplos de objectivos genericos de cada uma das perspectivas:

Perspectiva Objectivos GenericosFinanceira Retorno do capital, valor economico acrescen-

tado, crescimento de vendas, reducao dos cus-tos, aumento de producao.

Cliente Satisfacao do cliente, quota de mercado,aquisicao e retencao de clientes, rentabilidadedo cliente.

Processo de Negocio Interno Actividades duplicadas, alinhamento dos pro-cessos, capacidade dos processos, automacaode processos, disponibilizacao de novosservicos e melhoramentos a servicos exis-tentes.

Aprendizagem e Crescimento Retencao de empregados, treino, capacidadese utilizacao das competencias. A nıvelda infra-estrutura medidas de disponibili-dade, capacidade de suportar o crescimentoda organizacao, implementacao e suporte denovos servicos.

Table 2.1: Perspectivas e Objectivos

22

2.5 Analise Multicriterio

Avaliacao multicriterio e um modelo para realizar avaliacao, que se baseia na analise de varios

criterios que permitem definir varias opcoes e pesar qual a importancia dada pelos stakeholders a

satisfacao de cada criterio em cada um dos cenarios tracados.

Este tipo de analise oferece multiplas vantagens [27]:

• Envolve directamente os stakeholders, de forma a obter as suas preferencias e como estes as

classificam (valor que lhes atribuem). Estes valores permitem saber quais os interesses dos

stakeholders e atribuir-lhes prioridades. O seu processo e interactivo, sendo necessario debate

entre os stakeholders para que compreendam os outros pontos de vista;

• E uma analise multidisciplinar, ou seja leva em conta dados de diferentes areas, o que permite

capturar a complexidade de uma situacao real;

• Permite considerar um vasto leque de criterios e ”pesa-los” na sua analise.

2.5.1 Elementos estruturais

Ha varios metodos de analise multicriterio, mas todos partilham uma estrutura comum, composta

pelos elementos [8] [27]:

• O criterio - representa um aspecto para determinar a escolha, geralmente corresponde ao

ponto de vista de um stakeholder ;

• As alternativas: pensar em cenarios alternativos viaveis (que respeitem os criterios), isto e

particularmente importante em problemas de natureza estrategica;

• Decisores: Aqueles que sao responsaveis pela tomada de decisao final no problema. Devem

ser capazes de compreender os criterios na tomada de decisao;

• Incerteza: O conhecimento que se pode ter de todos os factores e condicionado, uma vez que

nao se controla todo o ambiente. De forma a lidar com esta incerteza devem ser construıdos

varios cenarios que tenham em conta a variacao desses aspectos;

• Ambiente: Sao todos os parametros que definem o contexto da decisao. Podem ser factores

economicos, fiscais, polıticos, ambientais. Influenciam directamente a solucao, sendo que esta

pode diferir consoante o ambiente.

2.5.2 Processo de analise multicriterio

O procedimento para efectuar uma analise multicriterio e o seguinte[27]:

1. Identificacao do problema: Onde se define o ambito e contexto do problema. Analisar o

ambiente e definir um contexto do problema comum a todos os stakeholders. Isto e conseguido

reunindo todos os stakeholders de forma a que partilhem as suas ideias e visoes do problema.

23

2. Estruturacao do problema: Deve ser a formalizacao do problema, em que ficam definidos os

aspectos a ser analisados, os criterios, as incertezas conhecidas bem como os varios pontos

de vista sobre o problema.

3. Modelacao das preferencias: Captura das preferencias dos stakeholders durante o processo

de discussao. Isto pode ser feito usando metodos de aprendizagem. As preferencias podem

ser vistas em duas dimensoes:

(a) Intra-criterio - as preferencias possuem valores relativos que sao associados a diferentes

nıveis de performance dentro de um criterio;

(b) Inter-criterio - foca-se nas preferencias entre cada um dos criterios, o peso que o stake-

holder da a cada criterio, tendo como resultado a ordenacao dos criterios de acordo com

essa mesma preferencia.

4. Pesagem de Criterios:

Numa analise multicriterio, pode acontecer que nem todos os criterios possuam o mesmo peso

na decisao, e necessario entao utilizar metodos de pesagem de criterios. Na seccao 2.7, sao

apresentados varios metodos de pesagem bem como as suas principais caracterısticas;

5. Agregacao e analise Nesta fase combinam-se as classificacoes das alternativas, de forma a

chegar a solucao final que leva em conta todos os criterios anteriormente levantados. Alcancada

a solucao, pode acontecer uma reconsideracao por parte de algum stakeholder forcando a

realizacao de uma nova estruturacao do problema. E possıvel retroceder para uma fase ante-

rior neste processo caso seja detectada alguma ambiguidade nos valores obtidos, ou ocorra

uma mudanca de preferencia por parte de algum stakeholder ;

6. Negociacao e consenso Depois de cada um dos stakeholders expressar a sua preferencia

face a todos os cenarios, podem ainda existir conflitos entre os interesses dos diferentes stake-

holders. A forma de resolver os mesmos e reunindo novamente as partes interessadas e

com base na informacao levantada nas fases anteriores do processo, chegar a um consenso,

que permita alcancar o cenario que melhor cumpre com os objectivos gerais e satisfaz as

aspiracoes dos stakeholders envolvidos.


Analise Multicriterio revela-se uma ferramenta valiosa, racionalizando o processo que e a tomada

de decisao, simplificando uma situacao complexa, facilitando a comunicacao e compreensao do prob-

lema por parte dos grupos interessados. E um metodo de analise cuja aplicabilidade perante os mais

diversos domınios ja foi provada [27], como tal constitui um valioso ponto de partida, na criacao de

uma metodologia de avaliacao.

24

2.6 Goal Question Metric

E uma abordagem para a definicao de metricas de avaliacao, focada em projectos de software

que parte dos objectivos do sistema a desenvolver para chegar as metricas que permitem medir o

grau de sucesso com que o mesmo e atingido. Foi desenvolvida inicialmente para encontrar de-

feitos em projectos de software desenvolvidos pela NASA. [5] Trata-se portanto de uma abordagem

procedimental e Top-Down, uma vez que a abordagem inversa, Bottom-up pode ser extremamente

difıcil devido a enorme quantidade de metricas que e possıvel aplicar, nao sendo claro o contexto em

que eram observadas, como tal utilizam-se os objectivos para definir o contexto do que se pretende

avaliar.

Atraves desta abordagem obtemos um modelo de medida com 3 nıveis [5]:

• Goal Conceptual: O goal e definido com um objectivo em vista, o qual pode ser um produto,

processo ou recurso;

• Operacional: Descrever a forma como o goal pode ser atingido, as caracterısticas que o objec-

tivo deve ter para satisfazer o goal pretendido;

• Quantitativo: Conjunto de dados que permitem responder de forma quantitativa as perguntas.

Podem ser objectivas (apenas dependem do objecto Ex: Numero de versoes) ou subjectivas

(dependem igualmente do viewpoint atraves do qual o objecto e visto Ex: nıvel de satisfacao

de utilizadores).

Figure 2.9: Mapa de conceitos na abordagem GQM retirado de [5]

Metodologia GQM

A abordagem GQM, enquadra-se nas metodologias de avaliacao procedimentais. O seu processo

consiste em 6 passos. As primeiras tres fases, tem como ambito a escolha de metricas, garantindo

que estas metricas estao alinhadas com os objectivos, garantindo assim a sua utilidade. Os passos

seguintes, descrevem um processo de aplicacao para as metricas previamente escolhidas de forma

que possam contribuir como ferramentas de apoio a decisao.

Os diferentes passos que compoem o processo encontram-se descritos em seguida:

25

Figure 2.10: Passos da metodologia GQM

1. Estabelecer objectivos, estes podem ser divididos em 2 tipos: os objectivos de negocio e os

objectivos de medicao. Os objectivos que se encontram no topo da arvore GQM sao os ob-

jectivos de medicao, estes por definicao sao conceptuais, tornando-se apenas quantificaveis

quando ligados as questoes.

Estes goals devem conter a seguinte informacao:

• Objecto: O produto, processo ou sistema em estudo;

• Proposito: A motivacao do objecto, o porque;

• Foco: A qualidade do objecto em estudo que se pretende medir;

• Ponto de Vista: A perspectiva sob a qual a qualidade e percepcionada;

• Ambiente: Contexto em que e realizada a analise, o ambito da medicao (por exemplo um

projecto ou um departamento).

2. Gerar as questoes. Neste passo os objectivos devem ser detalhados e refinados, permitindo

passar do nıvel conceptual para um nıvel operacional. Estas questoes devem definir qual a

informacao necessaria para se poder aferir se o objectivo e atingido ou nao. As questoes

elaboradas devem permitir descrever os diferentes pontos de vista sobre o problema, ajudado

todos os stakeholders a ter uma visao comum do problema.

3. Especificar as metricas. O objectivo deste passo, e conseguir reunir a informacao que permitira

responder as questoes feitas anteriormente, passando do nıvel qualitativo das questoes para

o quantitativo das metricas. Este passo deve ser feito com consulta dos stakeholders com o

objectivo de minimizar as ambiguidades.

4. Preparar a recolha de dados Uma vez definidas as metricas, e necessario analisar que dados

sao necessarios para suportar essas metricas e garantir que os dados terao significado de

acordo com o ponto de vista da metrica. Este plano pode ser realizado atraves de um Plano de

Medicao.

26

5. Recolher os dados, Validar e Analisar os dados para a tomada de decisao. Esta fase segue-se

necessariamente ao planeamento da recolha dos dados, e aqui que serao validados os da-

dos recolhidos de forma a serem preparados para a analise. Isto envolve guardar os dados

de forma a que seja possıvel utiliza-los em diferentes processos de analise. Neste passo e

necessario alguma forma de feedback, de forma que os resultados da medicao sejam encam-

inhados para o stakeholder apropriado permitindo que os objectivos de medicao possam ser

revistos e ajustados caso necessario.

6. Analisar os dados de forma a conseguir atingir os objectivos e aprendizagem. Este ultimo

passo, consiste em realizar uma pos-analise ao processo de forma a sistematizar o trabalho

realizado, retirando licoes para o futuro. Este conhecimento resultante da aplicacao da abor-

dagem GQM, podera ser reutilizado sobre a forma de polıtica ou melhor pratica, de forma a

auxiliar futuros processos de avaliacao.

2.6.1 GQM+Strategy

Apesar de a abordagem GQM ter sido inicialmente pensada para o domınio do software, e

possıvel mapear os seus conceitos para domınios de mais alto nıvel como, estrategias e objectivos

de negocio, criando uma ligacao entre estes e a aplicacao de metricas a um nıvel mais baixo como

o de software ou mesmo infra-estrutura [28].

Esta abordagem mais geral pode ser usada em domınios nao relacionados com o software ou

ate sistemas de informacao conforme e demonstrado em [29], onde a abordagem GQM+Strategy foi

aplicada com sucesso a avaliacao do programa de treino do exercito Italiano.


A metodologia apresentada neste capıtulo, trata a obtencao e estruturacao de metricas, permite li-

dar com domınios alem do software, caracterıstica que o destaca na avaliacao dos diversos domınios

da AE, uma vez que esta compreende elementos que vao desde software, infra-estruturas a papeis

ou processos de negocio, existindo por isso uma enorme variedade de metricas possıveis para cada

domınio.

2.7 Pesagem de Criterios

Os processos de pesagem de criterios, tratam o problema da elicitacao de preferencias por parte

de humanos, ou seja saber quais sao os factores que numa escolha possuem maior importancia.

Atraves da atribuicao de um valor, o peso, associado a cada um dos elementos parciais de pontuacao,

e possıvel no final agregar todas as pontuacoes parciais num unico valor global.

Desta forma diferentes pesos garantem que diferentes resultados parciais, contribuem em graus

diferentes para a pontuacao global. Tipicamente um criterio com maior peso ira contribuir mais para

o resultado final, face a um com menor peso.

27

• Tradeoff - Consegue expor as indecisoes dos stakeholders, atraves da revisao dos criterios e

cenarios, aos pares (2 cenarios face a 2 criterios). Uma alternativa tem a melhor performance

num criterio e a pior no outro, e e pedido aos stakeholders que escolham entre os cenarios.

A sua escolha tornara visıvel qual e o criterio mais importante, sendo o processo repetido ate

todos os criterios terem sido pesados entre si.

• Swing - Constroem-se cenarios extremos hipoteticos P(pior) e M(melhor), e em seguida os

stakeholders decidem que criterios querem mover primeiro de P para M, indicando qual a pre-

ferencia entre os criterios. Os criterios vao tendo preferencias cada vez menores a medida

que vao passando de P para M. Os ultimos a transitar de um estado para outro serao aqueles

com menor peso. Depois deste passo ha que quantificar o peso que cada um dos criterios

tem relativamente aos restantes. Para isto o criterio com maior preferencia (o primeiro a mudar

de P para M), e classificado com um peso de 100, e os restantes a medida que sao mudados

de P para M, classificados com pesos sucessivamente menores, sempre inferiores a 100, que

reflectem a sua importancia relativamente ao criterio de referencia.

• Interval Swing - Este processo e uma variante do metodo Swing anteriormente apresentado,

sendo a unica diferenca a possibilidade dos pesos para os criterios face ao de referencia

poderem ser dados por intervalos de valores em vez de um unico valor. Atraves dos intervalos

ganhamos a capacidade de incorporar incertezas dos stakeholders no processo de pesagem.

Desta forma o resultado final nao sera um unico valor de peso para cada atributo, mas sim

um espaco de solucoes possıveis. Dependendo desse espaco de solucao podera acontecer

que diferentes possibilidades de pesagem, levem a diferentes pontuacoes dos cenarios. Isto

significa que com determinados valores de peso um cenario pode ser superior aos restantes

e o mesmo nao ser valido com outra pesagem possıvel. Para reduzir estes problemas sera

necessario analisar o espaco da solucao para encontrar relacoes de dominancia entre alterna-

tivas ou efectuar repesagens para reduzir de forma progressiva a incerteza na pesagem.

• Resistencia a mudanca - Nesta abordagem, para cada criterio, consideram-se dois nıveis de

performance, o melhor e o pior. Assume-se igualmente que todos os criterios sao desejaveis na

solucao. Os stakeholders devem entao, comparar pares de criterios, em que decidem se estao

dispostos a colocar um deles no melhor estado a custa do outro. A importancia relativa de cada

criterio e obtida com base no numero de vezes que cada criterio foi resistente a mudanca, ou

seja nao foi diminuıda a sua qualidade perante outro criterio.

• Macbeth - Este tipo de pesagem emprega componentes da abordagem Swing e Trade-off,

estabelece nıveis de Bom, Mau e Neutro para cada criterio. Para cada criterio devem ser esta-

belecidos os diferentes nıveis que compoem a escala e estabelecer as fronteiras de Bom, Mau

ou Neutro. Todos os cenarios sao analisados perante todos os criterios e classificados den-

tro da escala anteriormente definida. Disponibiliza testes para aferir a coerencia do processo.

Alem disso este metodo e suportado por uma ferramenta de software, a M-Macbeth [30].

28

• Holıstica - Os stakeholders limitam-se a hierarquizar as diferentes alternativas, de acordo com

o conjunto total das preferencias, sem se preocuparem com criterios particulares, os pesos de

cada criterio serao extraıdos dos dados atraves de analises estatısticas.

Dos metodos de pesagem de criterios analisados, o Macbeth ja provou ser aplicavel dentro do

contexto dos sistemas de informacao em [8], e tem como vantagem ser suportada por uma fer-

ramenta que permite formalizar todo o processo de pesagem. Alem de permitir aos stakeholders

efectuar a pesagem sem utilizar uma quantificacao numerica das suas preferencias. No entanto

este metodo tem uma elevada complexidade, quando comparado por exemplo com o metodo de

Resistencia a mudanca ou Swing. Dado que no contexto da tese, a pesagem sera realizada por

stakeholders apoiados por peritos, assim e possıvel reduzir a incerteza associada ao processo, o

que permite aplicar um processo de pesagem mais directo e baseado em pesos numericos como

a Swing ou tradeoff. Optou-se por utilizar a abordagem Swing, uma vez que a sua variante por

intervalos, alarga a sua aplicabilidade, inclusive em casos de maior incerteza.


A avaliacao de arquitecturas empresariais ainda se encontra em investigacao, faltando-lhe um

conjunto de atributos de qualidade semelhante ao ISO 9126 no campo do software. Desta forma,

encontra-se em aberto a definicao de um corpo de qualidades e metricas para o ambito da arquitec-

tura empresarial.

Neste trabalho, e proposto escolher as metricas a aplicar para avaliar as diferentes arquitec-

turas, a partir de objectivos de negocio. Uma vez que estes objectivos sao aqueles que guiam a

organizacao que se pretende avaliar. Esta abordagem e complementar a avaliacao de arquitecturas

atraves de qualidades, uma vez que uma metrica alem de estar associada a medicao de determina-

dos objectivo, esta igualmente associada a algum atributo de qualidade.

No contexto deste trabalho, uma abordagem procedimental como o GQM 2.6 e a que merece

maior destaque, pois pretende-se rastrear as metricas aplicadas na avaliacao a objectivos estrategicos,

de forma a conseguir medir o grau de sucesso com que estes sao concretizados.

29

3Impacto Sistemico

Contents3.1 Impacto da Mudanca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.2 Analise de Ligacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3 Metricas de Impacto Sistemico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

31

3.1 Impacto da Mudanca

Uma arquitectura empresarial conforme e descrito na seccao 2.1, e uma descricao da estru-

tura empresarial, que e feita com recurso a elementos que representam conceitos presentes na

organizacao real. Uma vez que este elementos se encontram ligados, de forma a poderem operar

em conjunto e concretizarem os objectivos tracados para a organizacao, e importante conhecer qual

o impacto na arquitectura global, devido a alteracao de algum ou alguns dos seus elementos [18].

Esta capacidade de identificar o possıvel efeito de propagacao do impacto atraves da arquitectura

empresarial seria util na analise baseada em cenarios, de forma a poder ser usada como metrica

de avaliacao para os diferentes cenarios. Isto permitiria diferenciar os varios cenarios quanto a

profundidade das mudancas que propoem, a qual esta geralmente associada a um maior esforco de

implementacao.

Em [18], e usada a linguagem Archimate ja introduzida anteriormente 2.2.4, como ponto de par-

tida para a concretizacao de uma framework que utilizando a semantica das ligacoes existentes entre

os elementos da arquitectura empresarial, propoe estruturar a forma como o impacto de mudar um

determinado elemento na arquitectura afecta os restantes.

Nesta abordagem a propagacao de impacto nao implica simplesmente a ligacao entre dois el-

ementos, mas tem em conta igualmente as caracterısticas da ligacao e o tipo de objectos arqui-

tecturais ligados, uma vez que apenas por dois objectos estarem ligados nao existe uma relacao

causa efeito com a propagacao de impacto, sendo esta a principal falha de uma analise puramente

sintactica. Encontram-se definidas heurısticas em 3.2 para as principais ligacoes presentes no Archi-

mate, para situacoes em que um objecto e eliminado (Delete), Modificado (Modify ) ou seja alter-

ado com perda de caracterısticas, ou estendido (Extend) com novas capacidades. Usando estas

heurısticas e possıvel avaliar se de facto existe uma propagacao de impacto numa determinada

relacao ou nao [18].

Uma das contribuicoes deste trabalho e a construcao, de um modelo para compreender a propagacao

de impacto na arquitectura empresarial. Esta capacidade poder ser incluıda na metodologia a de-

senvolver, atraves de uma metrica que quando aplicada aos cenarios os classifique relativamente ao

grau de impacto que cada um efectua a arquitectura.

3.2 Analise de Ligacoes

Conforme ja foi apresentado em 3.1, encontram-se definidas em [18], heurısticas que permitem

determinar a propagacao de impacto, em algumas situacoes de “Extensao”, “Modificacao” ou “Eliminacao”.

A estas tres situacoes e adicionada uma quarta, a “Criacao”, de um novo objecto na arquitectura em-

presarial. Esta situacao e como um caso particular de “Extensao”, em que nao existe objecto inicial

para preservar. Sendo que nesta situacao, devido a nao existir nenhum objecto inicial do qual derivar,

todas a conexoes feitas a este novo elemento sao inteiramente novas, o que por essa razao podera

levar a alteracoes nos objectos a ele associados.

Apresenta-se em seguida para as principais relacoes Archimate, as situacoes que podem originar

32

a propagacao de impacto entre elementos. Tanto as descritas em [18], como a nova situacao de

Create.

• Access

A relacao Access, modela o acesso de elementos comportamentais a objectos de dados. A

relacao de acesso pode representar a criacao do objecto de dados, a escrita ou leitura do

mesmo [3].

Para exemplificar a propagacao de impacto, atraves da relacao access, apresenta-se em seguida

um exemplo, em que o objecto comportamental “A”, um componente aplicacional, acede a um

objecto de dados “B”.

Figure 3.1: Exemplo de ligacao Access

Cenario 1, alteracao feita no elemento “A”:


– Delete: Altera os dados que sao acedidos, removendo-os, e como tal existe propagacao

de impacto, uma vez que nao podem ser acedidos;

– Modify : Pode existir, uma vez que pode resultar numa nova maneira, nao suportada de

acesso aos dados;

– Extend : Pode existir , uma vez que pode resultar numa nova maneira, nao suportada de

acesso aos dados;

– Create: Existe impacto, se os dados “B” nao suportarem o formato de acesso usada por

“A”.

Cenario 2, alteracao feita em “B”:


33

– Delete: Nao provoca directamente, no entanto a aplicacao ja nao pode aceder aos dados;

– Modify : Pode existir impacto, uma vez que podem ser retirados elementos da sua estru-

tura, o que exige uma modificacao na forma de acesso aos dados;

– Extend : Nao existe, pois os dados conservam a estrutura original, apenas sao adicionados

novos elementos;

– Create: Existe impacto, se a aplicacao “A” nao suportar a estrutura de dados presente em

“B”;

• Realization

A relacao Realization liga uma entidade logica com uma entidade concreta que a realiza. Uma

forma de ver esta ligacao e uma relacao entre “o que” a entidade logica e “como”, a entidade

concreta. Esta relacao pode representar por exemplo que um servico e realizado por um pro-

cesso de negocio, ou que um objecto de dados e representado por um objecto de negocio.

Figure 3.4: Exemplo de ligacao Realization

Cenario 1, alteracao com origem em “A”:


– Delete: Acontece propagacao de impacto pois, o objecto de negocio e apenas uma

representacao logica do Data Object, logo nao faz sentido existir sem o ultimo;

– Modify : Se existirem modificacoes, a estrutura do objecto muda e assim a sua representacao

tambem;

– Extend : Nao porque a estrutura do objecto logico e preservada;

– Create: Existe propagacao de impacto, uma vez que um novo objecto possui uma nova

representacao, que podera nao corresponder ao objecto “A”.

Cenario 2, alteracao realizada em “B”:


34

– Delete: Nao produz efeitos, uma vez que o objecto A e uma simples representacao de B;

– Modify : Pode existir propagacao de impacto para “B”;

– Extend : Pode existir propagacao de impacto para “B”;

– Create: Existe propagacao de impacto, uma vez que uma nova representacao, podera nao

ser suportada pela estrutura de dados presente em “B”.

• Assignment

Figure 3.7: Exemplo de ligacao Assignment

A relacao Assignment, liga uma unidade de comportamento “A” com um elemento activo “B”.

Se alterarmos “B” em princıpio nao existira impacto em “A”, excepto no caso em que nenhum

comportamento seja capaz de desempenhar “A”, ou seja se “B” for eliminado ou modificado,

a situacao devera ser sinalizada, de forma a garantir que “A”, continua a ser suportado. Por

outro lado alteracoes a “A” podem ter impacto em “B”, por exemplo se “A” for eliminado e “B”

nao estiver atribuıdo a mais nenhum elemento comportamental. Numa situacao de extensao

ou modificacao de “A”, “B” podera ser impactado, devendo ser revistas as capacidades disponi-

bilizadas por “B” e as requeridas por “A”.

Cenario 1, mudanca com origem em “A”:


– Delete: Nao existe impacto directo, no papel “B”, no maximo “B” pode ficar sem qualquer

uso na arquitectura;

– Modify : Nao existe, uma vez que a versao modificada de “A” requer menos competencias

do que as inicialmente associadas;

– Extend : Pode existir, se forem necessarias novas competencias, que nao presentes em

“B”;

– Create: Pode existir pela mesma razao que no caso Extend.

Cenario 2, origem da mudanca em “B” :

35


– Delete: Existe impacto, se a “A” nao estiverem atribuıdas as competencias necessarias;

– Modify : Existe se forem retiradas de “B”, competencias requeridas por “A”;

– Extend : Nao existe, pois “B” mantem todas as competencias anteriores;

– Create: Nao tera impacto em “A”, uma vez que se este processo ja possuıa todas as

competencias necessarias, adicionar um novo elemento “B”, nao ira alterar essa situacao.

• Uses

Figure 3.10: Exemplo de ligacao Uses

A ligacao Uses, significa que um determinado elemento “B” “usa”, os servicos ou capacidades

disponibilizados por um outro elemento “A”. Se “A” for eliminado ou modificado, existira impacto

em “B”, uma vez que os servicos utilizados por “B” sao total ou parcialmente eliminados, por

outro lado em caso de extensao, nao existira impacto para “A” uma vez que todos os servicos

antigos se mantem. Se as alteracoes ocorrerem em “B”, e estivermos perante uma extensao ou

modificacao, existira impacto em “A” uma vez que podera ser necessario alterar as interfaces

disponibilizadas. Ja o caso de eliminacao de “B”, nao tem impacto directo em “A”, a menos que

mais nenhum elemento use os seus servicos, sendo que nesse caso deixa de fazer sentido

manter este elemento.

Cenario 1, mudanca com origem em “A”:


– Delete: O processo de negocio sera afectado pois nao podera usar as funcionalidades

disponibilizadas pela aplicacao;

– Modify : O processo de negocio sera afectado pois nao poderao deixar de existir algumas

das funcionalidades presentes na aplicacao;

36

– Extend : Nao ha propagacao de impacto, pois a aplicacao mantem todas as funcionali-

dades anteriores e apenas lhe sao adicionadas novas. (Isto pressupoe uma visao modu-

lar da aplicacao, dependendo do nıvel de detalhe utilizado, uma vez que com um detalhe

maior, uma situacao de extend podera ser vista como o create, uma vez que se tornam

visıveis os componentes da aplicacao. Esta limitacao e ilustrada na figura 3.12;

– Create: Existe propagacao de impacto, uma vez que o processo “B”, devera ser modifi-

cado para integrar o uso da nova aplicacao “A”.

Figure 3.12: Relacao entre Create e Extend em aplicacoes.

Cenario 2, origem da mudanca em “B” :


– Delete: Nao existe impacto directo, no entanto se os servicos de “A”, nao forem usados

por mais nenhum processo, podem tornar-se desnecessarios;

– Modify : Nao existe impacto, pois o processo e simplificado, como tal no limite deixa de

utilizar alguma funcionalidade da aplicacao “A”.

– Extend : Existe se for alterada a forma de aceder aos servicos de “A”;

– Create: Existe impacto, uma vez que os servicos de “A” poderao necessitar de alteracoes

de forma a serem usados pelo novo processo “B”.

• Triggers

A relacao Triggers, descreve uma relacao temporal ou causal entre processos. Por exemplo

entre dois processos “A” e “B”, significa que o processo “A” activa o processo “B”, depois de

terminar. Este relacionamento e diferente da relacao flow [3], pois nao envolve a transmissao

de dados entre os processos.

Isto significa que os processos sao independentes, logo a unica alteracao que podera originar

propagacao de impacto e, eliminar um processo que seja o unico trigger de um outro processo.

37

Figure 3.14: Exemplo de ligacao Triggers

Cenario 1, Mudanca com origem em “A”:


– Delete: Acontece propagacao de impacto pois, o elemento “B”, ja nao pode ser accionado

pelo trigger originado em “A”;

– Modify : Pode ocorrer impacto, se a actividade que desencadeia o trigger para “B” for

eliminada;

– Extend : Nao existe propagacao de impacto;

– Create: Nao existe propagacao de impacto.

Cenario 2, mudanca com origem em “B”:


– Delete, Modify, Extend, Create: Alteracoes em “B” nao produzem qualquer impacto em “A”

atraves da relacao trigger, uma vez que a relacao trigger e direccional, e o objecto que e

accionado “B”, nao envia qualquer interaccao no sentido inverso da relacao, ou seja para

o objecto “A”.

De forma a conseguir quantificar este impacto, e traduzi-lo numa metrica, foram analisados os tra-

balhos [1] e [24] . Em [1], sao definidas alguma metricas de dimensao, com o objectivo de comparar

a dimensao e complexidade relativa das arquitecturas, tendo como indicador o numero de objectos

presentes na arquitectura e que sao instancias de um determinado tipo de elemento.

Partindo destes trabalhos foram elaboradas algumas metricas de dimensao 3.3, de forma a saber

que arquitectura possui maior numero de alteracoes, por comparacao com o cenario actual. Estas

38

metricas apesar da sua simplicidade, que ignora a complexidade e dimensao de cada elemento, e as-

sumindo que todos contribuem igualmente para o resultado global do impacto sistemico. Fornecem

uma visao, ainda que simplista sobre o impacto relativo de cada cenario 3.3.

3.3 Metricas de Impacto Sistemico

Atraves das heurısticas definidas em [18] e 3.2, pretende-se saber num cenario To Be, onde e

efectuada uma alteracao num determinado elemento, saber que outros objectos da arquitectura irao

sofrer algum tipo de impacto. Esta propagacao de impacto existe, devido as dependencias entre

elementos da arquitectura, ou seja, as ligacoes que existem entre eles.

Estando na posse de um modelo, com os objectos impactados devidamente identificados, seria

vantajoso conseguir quantificar atraves de uma metrica o grau de impacto presente em cada cenario.

De forma a ser possıvel comparar diferentes cenarios, em ordem a esta dimensao de impacto.

As metricas conforme apresentadas em [1] e [31], podem ser vistas como uma forma de quan-

tificar certos aspectos de qualidade, relativos a sistemas de informacao. O objectivo do uso de

metricas e conseguir avaliar quantitativamente uma determinada dimensao, avaliando-a e colocando

o seu resultado numa escala de medida [24]. Neste caso a realidade a medir, e o esforco necessario

para implementar um determinado cenario To Be face ao As Is actual.

O que se propoe e estimar esse esforco contabilizando o impacto (alteracoes) propagado entre

elementos num determinado cenario, ou seja o numero objectos impactados. Para isso propoem-se

uma serie de metricas que permitem quantificar o grau de impacto ocorrido, em diferentes tipos de

elementos na arquitectura, com o objectivo de diferenciar e comparar os cenarios por meio dessas

mesmas metricas.

No domınio do software, um esforco semelhante ja foi realizado no passado atraves do uso das

metricas de software, Lines of Code(LOC) [32] e Function Points(FP) [31]. A primeira, procura avaliar

a complexidade de um determinado artefacto de software, contando o numero de linhas de codigo, e

usando esse numero como um indicador do esforco necessario para o desenvolvimento e complexi-

dade relativa, desse mesmo artefacto.

Existem varios factores que podem interferir com a validade dos resultados obtidos por esta

metrica, sao estes:

• A diferenca entre linguagens;

• Geracao automatica de codigo;

• Falta de uma definicao standard de linha de codigo

• Apenas estima a fase de desenvolvimento de software, ou seja o esforco total e maior do que

aquele associado apenas a escrita do codigo.

39

Apesar destas limitacoes, se utilizada correctamente, ou seja comparando artefactos de software

desenvolvidos sob as mesmas circunstancias e possıvel distinguir o esforco associado a cada um

deles atraves desta metrica.

Por outro lado a metrica Function Points Analysis, surge como uma tentativa de reduzir alguns

dos problemas identificados na metrica LOC. Esta baseia-se, nao em medir o software pela sua

dimensao, mas sim pela presenca de certas estruturas como, acesso a bases de dados, interfaces

com o utilizador, ficheiros de entrada ou de saıda. Cada qual com um factor de compensacao de

complexidade associado.

Assim alem de contabilizar os elementos, cada um tem associado uma medida de complexidade,

que ajuda a tornar a analise mais realista. No caso deste trabalho, onde o domınio de aplicacao

das metricas e a arquitectura empresarial, existe uma grande variedade de objectos representados.

Estes vao desde processos de negocio, papeis, actores, elementos de infra-estrutura e sistemas de

informacao, assim e difıcil encontrar e definir estruturas dentro de cada um deles que nos permitam

contabilizar a sua complexidade individual. Alem de que os possıveis casos de aplicacao da arqui-

tectura empresarial podem ser tao vastos e distintos que dificultam a comparacao entre arquitecturas

de diferentes ambitos.

Assim e importante que quando se pretende comparar modelos de arquitectura empresarial, estes

sejam realizados com o mesmo nıvel de detalhe e considerando as mesmas dimensoes da arquitec-

tura. Caso contrario o resultado obtido pelas metricas sera condicionado, originando resultados que

nao permitem a comparacao dos cenarios.

Uma forma de obter esta medida de esforco necessario para mudar um dado elemento, e consul-

tar peritos dentro do domınio da organizacao. Estes por sua vez podem atribuir a cada elemento da

AE um valor de esforco, que e compensado na analise.

40

Table 3.1: Metricas de impacto propostas.

Factor Processos de Negocio ImpactadosEsta metrica pode ser usada para quantificar a quantidade de impacto ocorrida nacamada de negocio. A pontuacao e mais elevada quanto menos processos foremimpactados, ou seja, marcados com um dos tipos de impacto descritos na seccao3.2. Por exemplo uma arquitectura em que todos processos fossem alterados, rece-beria uma pontuacao de 0, segundo esta metrica.

Formula de Computacao 1 −∑n

0 Processos de Negocio Impactados∑n0 Processos de Negocio

Factor Sistemas Aplicacionais ImpactadosEsta metrica pode ser usada para quantificar o impacto ocorrido na camada aplica-cional da arquitectura. Relaciona o numero de aplicacoes alteradas com o numerototal de aplicacoes presentes na arquitectura. Uma arquitectura sem impacto a estenıvel receberia uma pontuacao de 1, que e menor com o aumento do numero dealteracoes, chegando a 0 para uma arquitectura em que todas as aplicacoes saoimpactadas.


0 Aplicacoes Impactadas∑n0 Aplicacoes

Factor Elementos de Infra-Estrutura ImpactadosAtraves desta metrica e possıvel saber qual e o estado da arquitectura analisada,relativamente ao impacto sofrido ao nıvel de infraestrutura. As pontuacoes nestametrica a semelhanca das anteriores variam entre 0 e 1, consoante o grau de im-pacto ocorrido.


0 Processos de Negocio Impactados∑n0 Processos de Negocio

Factor Papeis ImpactadosCom esta metrica e possıvel conhecer, que impacto causa determinado cenario, aarquitectura empresarial, ao nıvel dos papeis existentes.


0 Papeis Impactados∑n0 Papeis

A diferenca entre estas metricas e as presentes em [1], e o facto de em vez de quantificarem a

dimensao total da arquitectura em respeito a algum tipo de elemento, quantificam sim a percentagem

de elementos de um determinado tipo alterados face ao cenario As Is. O principio por tras destas

metricas, e que quanto maior for o numero de elementos alterados, maior sera o impacto causado na

arquitectura, pressupondo que todos os elementos implicam um igual esforco ao serem alterados.

As metricas apresentadas, correspondem apenas a algumas metricas possıveis e sao meramente

ilustrativas, para os domınios analisados nos casos praticos a que a metodologia foi aplicada. E

portanto possıvel, construir outras metricas de avaliacao de impacto, de acordo com as necessidades

41

de analise requeridas, tendo sempre presentes as linhas orientadoras para definicao de metricas

descritas em [1].

42

4Solucao Proposta

Contents4.1 Solucao Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

43

4.1 Solucao Proposta

Neste capıtulo, e mostrada a solucao proposta, de forma a estruturar o trabalho relacionado 3.1

e usa-lo como ponto de partida para alcancar os objectivos propostos 1.3.

De acordo com o processo de design research para guiar este trabalho, esta fase corresponde a

apresentacao da sugestao e seu desenvolvimento. Sendo esta a solucao a validar em 6.1 e 6.2.

Ja existem metodologias para realizar avaliacoes em diversos domınios, a analise multicriterio

analisada na seccao 2.5.3, e uma destas metodologias. Destaca-se pois possui uma grande versa-

tilidade, conseguindo lidar com diversos domınios distintos. Os passos desta metodologia possuem,

caracterısticas que se pretendem para esta avaliacao, como a elicitacao de criterios, a sua pesagem,

e conseguir integrar o input de stakeholders no processo de analise e formalizar todo o processo. A

metodologia ATAM por seu lado tambem sugere um processo de avaliacao, mas mais orientado para

o domınio do software, apesar de poder ser adaptado para o ambito dos sistemas de informacao

como em [8].

Partindo dos passos que compoem estas metodologias, predende-se estende-los ou reutiliza-los

no ambito mais geral da arquitectura empresarial. Uma avaliacao da arquitectura, de software ou

outros sistemas, conforme descrito em [1] ou [8], tem sempre como objectivo conhecer o estado de

determinado objecto representado pela arquitectura, em relacao a uma serie de criterios ou quali-

dades. E este trabalho tambem se baseia na utilizacao de criterios ou metricas para avaliar esse

estado. Essas metricas sao obtidas com base nos objectivos tracados para a mudanca, por meio do

processo GQM 2.6.

Alem do uso de GQM para derivar as metricas a aplicar, outros aspectos diferenciadores na

metodologia proposta, em relacao as apresentadas em [1] e [8], sao o objecto da avaliacao ser o

ambito mais vasto da arquitectura empresarial 2.1 e o contexto em que sera aplicada. Tratando este

trabalho, a avaliacao de cenarios de evolucao de uma AE, a aplicacao da metodologia, pressupoe

uma situacao, em que exista uma arquitectura As Is e varios cenarios possıveis To Be.

O objectivo sera comparar esses cenarios com base em varios criterios, para saber qual o mais

vantajoso. Estes criterios correspondem a metricas, derivadas a partir dos objectivos tracados para

a mudanca 2.4. Alem disto e introduzida uma dimensao de esforco, associado a transicao de um

estado As Is para um estado To Be, sendo esta dimensao um criterio de escolha entre cenarios, que

permitira aferir se os benefıcios de implementar um determinado cenario superam o esforco asso-

ciado, a implementacao da alteracao proposta. Este aspecto, relativo a mudanca de objectos entre

cenarios podera ser quantificada, atraves das metricas propostas anteriormente em 3.3.

A aplicacao desta metodologia, seria preferencialmente realizada, numa fase anterior a concretizacao

44

da mudanca, ou seja, antes de um dos possıveis cenarios To Be estar implementado. No entanto

nada impede a sua aplicacao a uma situacao passada, num exercıcio puramente teorico.

Os passos propostos para a realizacao da avaliacao a arquitectura empresarial, estao detalhados

num diagrama BPMN em anexo A.3, e sao os seguintes:

Figure 4.1: Passos da Avaliacao Proposta.

4.1.1 Definicao do ambito

Figure 4.2: 1o Passo - Definicao do ambito

Nesta fase inicial, deve decidir-se qual sera o ambito da avaliacao, ou seja, entre outros aspectos,

que domınios da AE se pretendem avaliar e quais os objectivos da mudanca proposta. Isto per-

mite diminuir o numero de elementos da AE a considerar, baixando os custos do levantamento da

informacao [24], bem como auxiliar na escolha de metricas, facilitando a aplicacao das mesmas em

fases posteriores.

Caso a definicao do ambito nao seja correctamente feita, podemos estar a ignorar elementos da

AE que iriam afectar a pontuacao de metricas, por exemplo a nıvel do impacto de mudanca.

Igualmente os objectivos gerais da mudanca devem ser definidos nesta primeira fase, estes de-

vem estar alinhados com os objectivos de negocio 2.4. De forma a que as metricas mais tarde

derivadas dos objectivos de mudanca, sejam adequadas e permitam quantificar o melhor possıvel

esses mesmos objectivos.

Que cenarios estao a ser avaliados, ou seja quais sao as opcoes a ser consideradas e se alguma

delas ja se encontra implementada. Isto e, saber se a analise se esta a realizar antes de ser con-

cretizada a mudanca ou apos a sua implementacao.

Alem de tudo isto, e ainda necessario determinar quem serao os stakeholders do processo, estes

serao aqueles que ao longo das diferentes etapas do processo terao de fornecer feedback, de forma

a que as suas preferencias sejam levadas em conta.

Nesta metodologia partimos do princıpio que os objectivos da mudanca ja se encontram definidos,

uma boa forma de garantir que os objectivos estao alinhados com a estrategia de negocio e usar um

45

strategic map acompanhado de balanced scorecard, ambos amplamente divulgados e utilizados, nas

mais diversas organizacoes [25].

No final desta fase devera ser possıvel responder as seguintes questoes:

• Quais sao os objectivos da mudanca ?

• Qual e o ambito da analise (que dominios arquitecturais) ?

• Quem sao os stakeholders (os decisores) ?

• Que cenarios existem ?

• Quando e realizada a analise ? Antes ou depois da implementacao de algum cenario?

4.1.2 Escolha de Metricas

Figure 4.3: 2oPasso - Escolha de Metricas

Para realizar a escolha das metricas nesta metodologia, sao utilizados os objectivos como ponto

de partida, para os quais sao seleccionadas metricas atraves da abordagem GQM (Seccao 2.6) mais

concretamente na sua extensao GQM + Strategie, devido a sua flexibilidade em lidar com diferentes

domınios, como aqueles que compoem a arquitectura empresarial (Seccao 2.1).

A aplicacao de GQM nao elimina, a necessidade de ter presentes as boas praticas na definicao

de metricas enunciadas em [24]. Sendo que para todas as metricas seleccionadas devem ser vali-

dadas as qualidades apresentadas em 2.4

Atraves da aplicacao desta metodologia, sera obtida uma arvore de metricas, como aquela

ilustrada em 2.6, nesta estrutura e possıvel ver que objectivos estao relacionados, atraves das

questoes ou metricas que sao partilhadas entre si.

No enquadramento da metodologia proposta, e sugerido que aquando da criacao dessa arvore de

metricas, cada questao derive apenas uma metrica. Diferentes objectivos podem continuar a apontar

para a mesma questao, no entanto cada questao devera possuir apenas uma relacao unaria com

cada uma das suas metricas. Isto ira facilitar o processo de pesagem, uma forma de conseguir esta

estrutura quando uma questao liga varias metricas, e simplificar essa questao em outras questoes

que ligam a cada uma das metricas individualmente. Ver a figura 4.4.

46

Figure 4.4: Exemplo de simplificacao de uma arvore GQM.

Outro caso e quando varias questoes partilham a mesma metrica, isto pode indicar que as

questoes sao bastante semelhantes. Neste caso as questoes devem ser modificadas de forma a

que exista apenas uma questao que derive a metrica anteriormente partilhada, figura 4.5.

Figure 4.5: Exemplo de simplificacao de uma arvore GQM.

4.1.3 Representacao dos Cenarios

Figure 4.6: 3oPasso - Representacao dos Cenarios

Nesta fase da avaliacao sao modelados os diferentes cenarios. A sua representacao e real-

izada apos a definicao do ambito, uma vez que e necessario saber que domınios e elementos

sera necessario representar. Uma vez que estes elementos serao aqueles a que se irao aplicar

as metricas seleccionadas, bem como as heurısticas de impacto 3.2 que permitem realizar a analise

47

de impacto. Esta representacao deve portanto, tornar visıveis as ligacoes entre os elementos que se

pretendem avaliar.

No caso concreto deste trabalho em que foram definidas regras para calcular a propagacao de

impacto, com base na semantica das ligacoes Archimate 2.2.4, os cenarios serao modelados com

esta framework. No entanto poder-se-ia estender este trabalho a outras frameworks de modelacao,

mas para isso teriam de ser criadas e validadas novas regras de propagacao de impacto, como

aquelas descritas em 3.2.

Outro aspecto importante e o ambito da framework escolhida, o qual deve ser capaz de cobrir

todos os domınios da arquitectura empresarial, no limite toda a AE, ou caso contrario estaremos a

limitar os domınios que e possivel avaliar.

No final desta etapa, deve ser possivel responder as seguintes questoes:

• Que metricas serao aplicadas ?

• Que elementos e domınios serao avaliados ?

• Quais a arquitectura empresarial de cada cenario ?

4.1.4 Aplicacao das Metricas

Figure 4.7: 4oPasso - Aplicacao das Metricas

Para cada cenario devem ser aplicadas as metricas escolhidas, de forma a obter a pontuacao de

cada um dos cenarios, face a cada uma das metricas. A forma como uma metrica e calculada ira

variar consoante o tipo de metrica. Podemos por exemplo estar perante uma metrica de dimensao,

em que o resultado e obtido por via de uma operacao matematica.

Devem ser evitadas metricas de natureza subjectiva, ou seja baseadas somente no input de

stakeholders. Deve optar-se por metricas computadas atraves de uma formula objectiva, e que

nao recorra a inputs de stakeholders. Desta forma garante-se uma maior validade e qualidade dos

resultados da analise.

Alem das metricas, devera ser levado a cabo a analise de impacto em cada um dos cenarios To

Be. Isto corresponde a para cada um dos cenario, partir dos objectos alterados e atraves das regras

definidas 3.2, identificar que outros elementos da AE poderao ser alterados. Depois de aplicadas

as regras, devera ser contabilizado esse mesmo impacto atraves das metricas desenvolvidas para o

efeito 3.3.

No final deste passo o facilitador, ou seja quem aplica a metodologia, deve estar na posse dos

resultados de cada cenario em cada uma das metricas escolhidas.

48

De forma a evitar que a unidade em que cada metrica e calculada, influencie a pontuacao da

mesma relativamente as restantes, aconselha-se a que o valor das metricas escolhidas seja normal-

izado [1]. Uma forma de conseguir isto, e garantir que a escala de valores esta contida no intervalo

[0;1].

4.1.5 Comparacao de cenarios

Figure 4.8: 5oPasso - Comparacao de cenarios

Depois de avaliados individualmente, ha que fazer uma analise comparativa de forma a saber,

no geral, qual dos cenarios oferece o melhor compromisso no conjunto completo das metricas. Isto

corresponde a colocar os cenarios numa escala de preferencia que permitira saber qual e o mais

atractivo.

Para fazer isto, tem necessariamente de se agregar os resultados parciais de cada metrica em

cada cenario, de forma a computar a pontuacao global dos cenarios. Uma vez que nem todos os

resultados parciais contribuem de igual forma para o resultado global, ou seja cada resultado tem um

determinado peso associado, que indica a sua importancia relativamente aos restantes no resultado

global. Para conseguir calcular um resultado global, levando em conta o peso relativo das diferentes

metricas, face as preferencias dos stakeholders.

Para garantir o formalismo e rigor, deste processo de pesagem, existem varias abordagens bas-

tante difundidas e devidamente validadas. Alguns deste metodos encontram-se descritos em 2.7.

Neste trabalho e de destacar o metodo SWING, devido a sua simplicidade, capacidade de lidar com

um grande numero de criterios sem com isso aumentar o esforco ou complexidade associados a

realizacao da pesagem.

Independentemente do metodo escolhido, sera sempre exigido input por parte dos stakeholders,

uma vez que estes processos tratam isso mesmo, a elicitacao das preferencias dos stakeholders.

De forma a conseguir pesar as metricas seleccionadas, a opcao mais obvia seria, pedir aos stake-

holders que descrevessem as suas preferencias em ordem a estas mesmas metricas. Mas uma vez

que podem existir inumeros stakeholders e metricas num projecto, e as trocas de informacao com

estes podem ser dispendiosas, seria vantajoso minimizar este trafego de informacao, bem como o

esforco exigido aos stakeholders.

Uma forma de conseguir isto seria pedir aos stakeholders que em vez de pesarem metricas, pe-

49

sem sim os objectivos do projecto. Estes sao em menor numero, alem de mais facilmente compreen-

didos pelos stakeholders, diminuindo a necessidade de input por parte dos stakeholders, ficando a

cargo do facilitador o calculo do peso de cada metrica com base no peso atribuıdo aos objectivos.

Este calculo pode ser alcancado com recurso a um modelo aditivo.

Com a realizacao deste passo, estao reunidas as condicoes para tomar uma decisao quanto a

qual sera o melhor cenario a implementar, uma vez que todos os cenarios estao avaliados e tanto a

sua pontuacao global como parcial sao conhecidas.

4.1.6 Decisao

Figure 4.9: 6oPasso - Decisao

Apos todo este processo e necessario escolher qual dos cenarios sera implementado, esta es-

colha no final, cabera sempre aos responsaveis pelo projecto e stakeholders (os decisores na analise

multicriterio). Uma vez confrontados com a opcao proposta pela metodologia e atendendo que neste

tipo de problemas se consideram diversos pontos de vista sobre o problema, em que o sucesso de

um determinado criterio se pode traduzir no insucesso perante outro, pode acontecer uma mudanca

de posicao por algum decisor, forcando uma repesagem dos criterios envolvidos.

Nesta fase pode ainda realizar-se uma analise de sensibilidade, atraves da qual se consegue

averiguar qual a relacao entre as pontuacoes numa determinada metrica e a pontuacao global.

50

5Ferramentas Aplicacionais

Desenvolvidas

Contents5.1 Algoritmo para aplicacao das regras de impacto. . . . . . . . . . . . . . . . . . . . 525.2 Aplicacao para apresentacao dos resultados . . . . . . . . . . . . . . . . . . . . . 54

51

Um dos objectivos para este trabalho e o suporte da metodologia por uma ferramenta de arqui-

tectura empresarial que permita, nao so guiar a sua aplicacao, mas igualmente facilitar a realizacao

automatica de alguns dos passos. Com isto pretende-se reduzir os erros causados pela manipulacao

dos modelos e dados por humanos.

Para conseguir isto em primeiro lugar e necessario uma representacao formal dos cenarios,

atraves de uma ferramenta de modelacao. No entanto alem da representacao era igualmente um

aspecto a desenvolver a capacidade de analisar os modelos de forma suportada, como por exemplo

para a aplicacao das regras de impacto 3.2.

Uma ferramenta que permite construir modelos e manipular os mesmos via scripts em javascript

e o software ARIS Architect da software AG. Sendo que esta preenche os requisitos enunciados, foi

escolhida como ponto de partida para suportar a metodologia proposta.

5.1 Algoritmo para aplicacao das regras de impacto.

Um dos aspectos desenvolvidos neste trabalho foi a implementacao de um algoritmo, para aplicar

de forma automatica e transparente para o utilizador o conjunto de regras de propagacao de impacto

definido em 3.2. Pretendia-se que a ferramenta representasse a aplicacao das regras de impacto,

marcando os objectos alterados com uma legenda e segundo um codigo de cores apresentado em

seguida, figura 5.1.

Figure 5.1: Codigo de cores utilizado para assinalar objectos impactados.

5.1.1 Exemplo de Utilizacao

Em seguida e mostrado um exemplo de como os scripts desenvolvidos permitem realizar de forma

automatica a aplicacao e representacao das regras definidas. Numa primeira fase cabe ao utilizador

modelar os cenarios pretendidos, atraves da interface de design na ferramenta, figura 5.2.

52

Figure 5.2: Interface da ferramenta de modelacao ARIS.

Estando os cenarios modelados, deve ser escolhido o tipo de mudanca que sera introduzida nos

objectos (Create/Delete/Extend/Modify), atraves do novo atributo criado (Change Type) presente em

cada um dos objectos Archimate.

Uma vez determinado o tipo de mudancas a efectuar, e necessario aplicar o script ao modelo.

O qual uma vez aplicado ira produzir como output, uma versao revista do modelo em que todos os

objectos estao legendados, com o tipo de impacto sofrido, e assinalados de acordo com o codigo de

cores representado em 5.1.

A implementacao deste algoritmo, permite uma aplicacao das regras transparente para o uti-

lizador, ao mesmo tempo que elimina a possibilidade de cometer erros caso a aplicacao das regras

fosse feita manualmente e facilita a manipulacao de modelos mais complexos onde a aplicacao man-

ual seria difıcil.

5.1.2 Calculo Automatico de Metricas

Alem do algoritmo de aplicacao das regras, tambem o calculo das metricas foi implementado

aplicacionalmente, atraves de scripts para a ferramenta de modelacao ARIS Architect. As metricas

calculadas, sao aquelas apresentadas em 3.2, e que dizem respeito a contabilizacao do impacto

ocorrido no cenario modelado. A automatizacao das metricas, e um dos princıpios para a definicao de

boas metricas, apresentados em [1] , Foi com este princıpio em vista que se efectuou a formalizacao

das metricas propostas, atraves deste script.

5.1.3 Exemplo de utilizacao

Para efectuar o calculo das metricas de impacto sobre um modelo, e necessario em primeiro lugar

aplicar sobre esse modelo, o script das regras de impacto. Estando o modelo devidamente marcado,

como o que se apresenta na imagem 5.3.

53

Partindo deste modelo pode-se aplicar o script de calculo das metricas, que atraves da informacao

de impacto contida no modelo, ira produzir um ficheiro de Excel onde esta contida a pontuacao de

cada cenario relativamente as metricas de impacto escolhidas.

Figure 5.3: Interface do script de aplicacao das metricas de impacto.

A execucao do script, ira produzir um documento de Excel, semelhante aquele mostrado na figura

5.4, e que podera ser utilizado em outra ferramenta ou analise como fonte de resultados de metricas.

Figure 5.4: Output do script de computacao das metricas.

No caso deste trabalho toda a informacao obtida pela aplicacao das metricas, foi utilizada para

alimentar uma outra aplicacao. Esta aplicacao, desenvolvida dentro da ferramenta Aris Mashzone,

tem como objectivo servir de camada de apresentacao dos dados.

5.2 Aplicacao para apresentacao dos resultados

Um outro objectivo, de suportar aplicacionalmente a metodologia de avaliacao, e conseguir mostrar

os dados obtidos da avaliacao e comunica-los a quem possui o poder de decisao sobre os mesmos.

De forma a ser possıvel apresentar esses resultados, tornando-os uteis para a tomada de decisoes,

54

foi construıdo um dashboard dentro da ferramenta Aris Mashzone com o objectivo de exibir os resul-

tados produzidos.

Figure 5.5: Interface da aplicacao para exibicao dos resultados.

Na figura 5.5, e possivel ver o ecra dos resultados no qual sao visıveis 3 graficos. Em primeiro

lugar (superior esquerdo), um grafico de barras onde e mostrada a pontuacao global de cada cenario

face aos restantes, bem como a contribuicao de cada metrica nessa pontuacao. No segundo grafico

(superior direito), o objectivo e mostrar para cada metrica de que forma os cenarios pontuam, ou

seja qual e o resultado de cada cenario em cada metrica individualmente. Atraves deste grafico e

possıvel, saber qual e o grafico que melhor pontua numa determinada metrica. Por ultimo, em baixo

e mostrado um grafico em tarte (pie chart) que reflecte a distribuicao de pesos entre as metricas, ou

seja, do peso total considerado, e que percentagem deste, esta presente em cada metrica.

55

6Casos Praticos

Contents6.1 Validacao das Regras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.2 Caso Pratico 2: Projecto CRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

57

De acordo com a metodologia design research seguida neste trabalho [33], o artefacto proposto,

neste caso a metodologia de avaliacao, deve ser testado para que fique provada a sua utilidade e

aplicabilidade.

Para tal, foram utilizados dois casos praticos, cada um com o objectivo de validar um aspecto

diferente do trabalho realizado. Em primeiro lugar e necessario garantir que as regras propostas para

descrever e prever a propagacao de impacto entre elementos da AE (Seccao 3.1), estao correctas e

a sua aplicacao gera resultados credıveis. E este o objectivo do caso pratico 1 6.1.

O segundo caso 6.2, e usado para validar o ambito mais vasto da metodologia, para tal escolheu-

se um projecto realizado no passado, do qual existem todos os dados necessarios para efectuar a

aplicacao da metodologia proposta, e compara-la com a abordagem nao metodologica utilizada para

avaliar o projecto originalmente.

6.1 Caso Pratico Validacao de Regras de Impacto

Com este caso pratico, pretende demonstrar-se a capacidade das regras de impacto apresen-

tadas em 3.2, fazerem previsoes quanto ao impacto de efectuar alteracoes a arquitectura empre-

sarial em casos de (criar/ estender/ modificar/ eliminar) um determinado elemento. Atraves da sua

aplicacao a modelos Archimate que representam os diferentes cenarios As Is e To Be da arquitectura,

iremos obter novos modelos onde estarao assinalados os elementos nos quais se preve um impacto

potencial. Comparando as previsoes efectuadas, com os dados reais de que objectos sofreram efec-

tivamente alteracoes, poderemos testar a aplicabilidade destas regras e se de facto as previsoes

efectuadas correspondem a realidade.

Para conseguir aferir os pontos anteriores, serao aplicadas as regras a uma arquitectura As Is,

para uma situacao concreta de evolucao de uma arquitectura. Os modelos To Be produzidos pelas

regras de propagacao de impacto sistemico, serao depois comparados, com a arquitectura que foi

efectivamente obtida pela realizacao da mudanca. Comparando esta arquitectura com as previsoes

e possıvel saber em que pontos a previsao das regras de impacto foi correcta, e onde falhou.

6.1.1 Ambito

Neste caso pratico foi analisado um banco, mais concretamente, a informatizacao de um pro-

cesso de recuperacao de dıvida, que actualmente (cenario As Is) e feito praticamente sem recurso

a ferramentas de suporte (apenas folhas de calculo Excel). Na imagem 6.1 mostra-se uma visao

de alto nıvel do ambito de recuperacao da dıvida. Este processo de recuperacao e realizado com o

intuito de cobrar junto do cliente, a dıvida de forma a regularizar a situacao. Caso falhe, entra em

accao um processo de gestao de contencioso, entrando num novo ciclo de cobranca. O conjunto

destes 2 processos e o ambito deste caso pratico.

58

Figure 6.1: Vista geral do ambito do projecto, o Processo de recuperacao de dıvida e o de gestao de con-tencioso.

Figure 6.2: Vista detalhada do processo de gestao de dıvida.

59

Figure 6.3: Vista detalhada do processo de gestao de contencioso.

6.1.2 Aplicacao das regras

Encontrando-se a arquitectura no estado As Is, pretende-se desenvolver 1 de 2 possıveis projec-

tos, que conduzem a diferentes estados To Be. Sendo que o objectivo e, implementar uma camada

aplicacional que suporte devidamente as actividades desenvolvidas no processo. No cenario (To

Be 1), pretende-se desenvolver uma aplicacao desenvolvida por medida para suportar apenas o

processo de gestao de dıvida, sendo que a gestao de contencioso mantera a sua aplicacao propria.

De acordo com os dados deste projecto, para a sua concretizacao foi necessario:

• A nıvel organizacional: Dar formacao apenas a equipa responsavel pela gestao do processo

de recuperacao e nao a outras equipas como por exemplo a do processo de recuperacao

contenciosa. Isto acontece pois a equipa de recuperacao sera a unica a interagir com a nova

ferramenta, logo e tambem a unica que necessita de ver as suas competencias alargadas de

forma a operar esta solucao.

• Ao nıvel aplicacional: Tratando-se de uma aplicacao desenvolvida a medida, nao foram efec-

tuadas alteracoes a outras aplicacoes, simplesmente adaptou-se a nova aplicacao de forma

a utilizar as interfaces existentes para interagir com as aplicacoes actuais. Assim pode ser

necessario carregar ficheiros de uma aplicacao para outra, de forma a conseguir utilizar dados

produzidos numa outra aplicacao.

• Ao nıvel informacional: A nova aplicacao (desenvolvida a medida), possui entidades informa-

cionais mais ricas que as existentes anteriormente, ou seja com mais informacao que as ante-

riormente existentes. Mas de forma a manter a compatibilidade com as aplicacoes existentes,

foram mantidas todas as entidades informacionais antigas.

60

Em seguida e mostrado o resultado de aplicar as regras definidas em 3.2 ao cenario To Be 1, no

qual e criada uma nova aplicacao Suporte a gestao de dıvida (a verde claro, caso create), que ira

suportar o processo de recuperacao de dıvida.

Figure 6.4: Visao detalhada do processo de gestao de dıvida no cenario To Be 1, com aplicacao das regras deimpacto.

Figure 6.5: Visao detalhada do processo gestao de contencioso no cenario To Be 1, apos a aplicacao dasregras de impacto.

Este diagrama indica que, se este cenario for implementado serao impactados os elementos da

arquitectura empresarial assinalados a vermelho - delete e verde claro - create, assim analisando

cada um dos nıveis detalhadamente podemos verificar que:

• A nıvel organizacional: Sera necessario estender varios papeis, todos eles pertencentes a

equipa de recuperacao de dıvida. Estender os papeis assinalados, corresponde a alargar as

suas competencias atraves de formacao e capacitacao para operar as novas solucoes. Neste

61

caso as regras de impacto permitiram prever exactamente este efeito, sugerindo que papeis

sao candidatos a realizar formacoes, devido a sua interaccao directa com a nova aplicacao.

• Ao nıvel aplicacional: Segundo o modelo obtido, nenhuma aplicacao existente sofreu qual-

quer tipo de impacto. Isto aconteceu, uma vez que a nova aplicacao foi construıda de forma

a nao criar novas interaccoes com as aplicacoes existentes e como tal nao ocorrem novas

colaboracoes entre aplicacoes que pudessem originar propagacao de impacto entre aplicacoes.

• Ao nıvel informacional: Os objectos informacionais relativos a informacao de cliente, informacao

sobre dıvida e lista de eventos de dıvida foram marcados como casos de extensao, uma vez que

sendo acedidos por uma nova aplicacao podera ser necessario a adicao de nova informacao a

essa mesma entidade. No caso deste projecto, optou-se por construir a aplicacao de tal forma

que nao fosse necessario efectuar essas alteracoes, na estrutura informacional. E apesar da

nova aplicacao utilizar um modelo interno mais rico para a informacao, os formatos antigos

foram conservados para permitir a comunicacao com as outras aplicacoes ja existentes, sem

que mais alteracoes fossem necessarias. Neste ponto as regras fazem uma previsao mais

conservadora, prevendo uma possıvel alteracao a estrutura dos elementos informacionais, que

afinal nao ocorreu.

No cenario (To Be 2), pretende-se desenvolver uma nova aplicacao para suportar nao so o pro-

cesso de recuperacao de dıvida, mas igualmente o processo de recuperacao de dıvida contenciosa.

Substituindo a aplicacao que actualmente suporta o processo de gestao de contencioso.

De acordo com os dados deste projecto, a sua concretizacao levou as seguintes mudancas:

• A nıvel organizacional: Neste caso a formacao teria de ser alargada a membros da equipa de

gestao contenciosa, e nao apenas a membros da equipa de recuperacao de dıvida.

• A nıvel aplicacional: Com a introducao da nova aplicacao, a aplicacao de gestao do processo

de contencioso foi descontinuada, nao existindo alteracoes em outros sistemas aplicacionais.

• A nıvel informacional: As entidades informacionais foram alargadas para lidarem com os con-

ceitos presentes no processo de recuperacao de dıvida contenciosa.

Em seguida e mostrado o resultado de aplicar as regras de impacto ao cenario To Be 2.

62

Figure 6.6: Visao detalhada do processo recuperacao de dıvida no cenario To Be 2, com aplicacao das regrasde impacto.

Figure 6.7: Visao detalhada do processo recuperacao de dıvida contenciosa no cenario To Be 2, com aplicacaodas regras de impacto.

Este diagrama indica que, se este cenario for implementado serao impactados os elementos da

arquitectura empresarial assinalados a vermelho - extend, a verde claro - create. Assim analisando

cada um dos nıveis detalhadamente podemos verificar que:

• A nıvel organizacional: Mais uma vez foram indicados varios papeis como candidatos a ex-

tensao, desta vez nao apenas os da equipa de recuperacao mas igualmente alguns papeis da

equipa de recuperacao contenciosa. Uma vez que foi associada as actividades deste processo

uma nova aplicacao. Como tal de acordo com as regras e de esperar que seja necessario dar

formacao aos actores que desempenham os papeis assinalados.

• Ao nıvel aplicacional: O impacto a este nıvel, para o processo de recuperacao, que actual-

63

mente nao e suportado aplicacionalmente, e exactamente o mesmo que no cenario To Be 1.

No caso do processo de recuperacao contenciosa, o impacto sistemico previsto e diferente,

daquele obtido no cenario To Be 1. Isto acontece, pois a aplicacao que suporta actualmente as

actividades do processo e impactada. Uma vez que o processo de negocio que actualmente

suporta e estendido pela adicao de uma nova aplicacao (create) da gestao de dıvida. Nao e

possıvel saber qual sera o impacto concreto neste componente atraves da simples analises

das regras. Na realidade existiu impacto, uma vez que a aplicacao de gestao do processo de

contencioso foi descontinuada, no entanto atraves das regras nao e claro qual sera o tipo de

impacto ocorrido.

• Ao nıvel informacional: A semelhanca do que aconteceu no cenario To Be 1, as entidades infor-

macionais relacionadas com os processos de negocio afectados pela adicao da nova aplicacao

sao marcadas para extensao. Desta vez pretende-se estender as entidades, de forma a li-

darem com os conceitos associados a fase contenciosa do processo, como tal a previsao esta

de acordo com o esperado, sendo que as entidades existentes vem o seu conteudo alargado.

6.1.3 Medicao do impacto

Alem de se pretender, reconhecer que elementos da arquitectura sao alterados, utilizando as re-

gras apresentadas em 3.2, e tambem um objectivo deste trabalho testar as metricas que permitem

contabilizar esse impacto apresentadas em 3.3, de forma a que diferentes cenarios sejam compara-

dos com base na extensao do impacto, ocorrida em cada um.

Neste caso pratico, o impacto maior como sera de esperar, ocorre no cenario 2, uma vez que sao

realizadas maiores mudancas a arquitectura empresarial. Partindo dos pressupostos em 3.1.

A tabela 6.1 mostra a pontuacao de cada cenario relativamente a cada uma das metricas pro-

postas em 3.3.

Table 6.1: Resultados das Metricas de impacto Aplicadas

Metrica Cenario Pontuacao

Factor de Aplicacoes alteradasAs Is 1To Be 1 0,875To Be 2 0,625

Factor de Processos de negocio alteradosAs Is 1To Be 1 0,8705To Be 2 0,4705

Factor Entidades informacionais alteradasAs Is 1To Be 1 0,625To Be 2 0

64

Os resultados da tabela confirmam o esperado, o cenario As Is ao qual nao e feita nenhuma

alteracao, nao produz qualquer impacto nos diferentes elementos da arquitectura empresarial, ob-

tendo a pontuacao mais elevada (1). Por outro lado nos casos To Be 1 e To Be 2, onde sao adiciona-

dos elementos a arquitectura original, que produzem propagacao de impacto em varios elementos da

arquitectura empresarial, a pontuacao e inferior. Sendo o impacto mais extenso no caso do cenario 2,

este facto e evidenciado pelas metricas aplicadas, uma vez que o cenario To Be 2 e classificado com

uma pontuacao menor que o To Be 1. O que indica a existencia de um maior impacto na estrutura

original.

6.1.4 Conclusoes

Atraves da realizacao deste caso pratico, foi mostrada a aplicabilidade das regras, na previsao de

possıvel propagacao de impacto entre elementos da arquitectura empresarial. No entanto a aplicacao

de regras proposta, contem ainda algumas limitacoes. Sao as mais significativas, a dificuldade em

decidir que tipo de impacto ocorre quando existem varias mudancas em simultaneo que se intercep-

tam.

Outra limitacao, relacionada igualmente com a capacidade de avaliar o tipo de impacto propa-

gado, relaciona-se com casos em que o impacto propagado atravessa varias camadas arquitec-

turais. Tornando-se mais difıcil indicar o tipo de impacto ocorrido uma vez que a cada transicao entre

camadas, a distancia ao objecto que e fonte do impacto aumenta e como tal o nıvel de incerteza

aumenta.

Uma possıvel abordagem e, em situacoes de incerteza escolher a opcao que provoca um maior

impacto. Desta forma fica coberto o pior cenario possıvel e sabemos que o impacto real sera menor

ou igual aquele calculado pelas regras. No modelo 6.8 mostra-se um exemplo de uma situacao em

que 2 situacoes de impacto colidem. Por um lado a criacao da Aplicacao 1, ira originar a necessidade

de realizar extend ao processo de negocio, por outro a Eliminacao da Aplicacao 2 ira resultar numa

perda de funcionalidade no processo representado.

Figure 6.8: Problema de decisao de impacto.

Neste caso optar-se-ia pela marcacao do processo como um caso de extend, pois a adicao de

65

funcionalidades sera mais dispendiosa, e sera aquela que causa maior propagacao de impacto a

outras camadas. Facto ilustrado no modelo 6.9 em que o papel associado ao processo e igualmente

alterado.

Figure 6.9: Diferentes solucoes, para resolver ambiguidade.

A nıvel das metricas, estas permitiram diferenciar os cenarios relativamente a quantidade de

mudanca ocorrida em cada um destes. Tendo como principal limitacao, ja apresentada em 3.3, a

igual importancia de todos os elementos para a pontuacao de impacto, ou seja todos os objectos

requerem o mesmo esforco para serem alterados. Assim um cenario com 2 elementos modificados,

tera sempre pior pontuacao que, um cenario apenas com uma modificacao.

Uma forma de minimizar este efeito seria recorrer a peritos que classificassem cada elemento al-

terado, com um valor de esforco de mudanca, crescente de acordo com o nıvel de esforco associado,

a introduzir alteracoes nesse mesmo elemento.

66

6.2 Caso Pratico 2: Projecto CRM

Atraves desde caso pratico, pretende-se demonstrar a aplicacao da metodologia de avaliacao

proposta em 4.1. Propoe-se esta metodologia como meio de conduzir uma avaliacao a arquitectura

empresarial, com o objectivo de avaliar e escolher o cenario que melhor cumpre, o conjunto de

objectivos definidos para o problema.

Neste caso pratico a metodologia sera aplicada a uma situacao de escolha de cenarios, con-

cretizada no passado. Assim a validacao sera feita aplicando a metodologia proposta a essa situacao,

comparando os resultados obtidos com aqueles produzidos por a avaliacao de cenarios realizada in-

formalmente.

6.2.1 Ambito

Neste caso e apresentado um projecto, onde se pretende introduzir um sistema CRM num Banco.

Neste projecto foram ponderadas duas hipoteses para a implementacao deste sistema, a primeira

envolve uma solucao local, a qual necessita de uma infra-estrutura propria dentro do banco. Estando

as aplicacoes e servicos de CRM instalados sobre esta infraestrutura. Por outro lado existe a hipotese

de optar por uma solucao baseada em cloud computing na qual todas as funcionalidades seriam

acedidas via web, sem necessidade de implementar uma infra-estrutura dedicada. O objectivo da

analise sera, identificar os objectivos tracados para esta mudanca, definir metricas alinhadas com os

mesmos e em seguida, avaliar cada uma destas hipoteses e escolher aquela que melhor cumpre as

metricas escolhidas.

6.2.2 Objectivos da Mudanca

Em seguida apresenta-se o strategic map da organizacao elaborado para este projecto, com os

principais objectivos da organizacao. Conforme foi descrito na seccao 2.4, esta metodologia utiliza

objectivos estrategicos para em seguida derivar metricas que os permitam medir. No contexto deste

caso, a motivacao para a realizacao deste projecto, e desenvolver uma relacao mais proxima com o

cliente, atraves de um maior conhecimento do seu perfil enquanto cliente. Isto ira permitir direccionar

as campanhas de marketing, para um publico alvo mais especıfico, conquistando novos clientes,

conseguindo assim alargar o numero de clientes e com isto a receita obtida.

Na figura 6.10, e mostrado o strategyc map, da organizacao para este projecto, no qual e possıvel

ver os objectivos para a iniciativa de implementacao de um sistema de CRM, bem como a forma como

estes se associam entre si.

67

Figure 6.10: Strategic Map da organizacao, para iniciativa proposta.


Neste capıtulo encontram-se detalhadas as metricas seleccionadas atraves da abordagem GQM,

para avaliar o projecto de implementacao de um sistema de CRM na entidade bancaria em analise.

Todas as metricas possuem: ID, Nome, Tipo de Metrica, Objectivo, Formula de computacao e a es-

cala usada. As metricas utilizadas encontram-se descritas integralmente em A.2

O fundamento por tras das metricas escolhidas, e o seu alinhamento com os objectivos da

organizacao e do projecto. Para conseguir efectuar esta escolha, foi pedido aos stakeholders do

projecto que formulassem questoes com as quais fosse possivel alinhar metricas, conforme descrito

anteriormente em 2.6. A elaboracao destas questoes apesar de contar com alguma subjectividade,

atraves da metodologia GQM, e possıvel reduzir a mesma, tornando a escolha de metricas mais

formal e suportada.

68

Figure 6.11: Arvore GQM, para iniciativa proposta.

Neste caso pratico, atendendo ao objectivo de minimizar o impacto causado na estrutura organi-

zacional, foram selecionadas duas metricas de impacto, ja apresentadas em 3.3: a Metrica 5, Factor

processos de negocio impactados e Metrica 6, Factor de elementos tecnologicos impactados. Foram

escolhidas estas metricas pois e nestes domınios que se pretende analisar as diferencas de im-

pacto entre projectos, particularmente no tecnologico, uma vez que estas solucoes se baseiam em

paradigmas tecnologicos diferentes.

Devido a natureza da analise, e possıvel que algumas metricas nao sejam directamente analisaveis

atraves da arquitectura, podendo em alguns casos depender directamente da preferencia dos stake-

holders em certos aspectos. Um exemplo seria num determinado projecto, algum stakeholder definir

como metrica a experiencia passada com o fornecedor da solucao. Este tipo de metricas apesar

de poderem ser enquadradas na analise, sao desencorajadas, pois aumentam a subjectividade na

analise.

6.2.4 Representacao de Cenarios

Apresentam-se agora modelados formalmente atraves de diagramas Archimate, os diferentes

cenarios envolvidos no projecto. Uma vez que o ambito deste projecto e mais vasto que o apre-

sentado no caso utilizado para validar as metricas de impacto 6.1, o detalhe sobre os processos

de negocio do banco bem como os papeis associados as actividades e menor. Por outro lado e

mostrada a infra-estrutura do banco, uma vez que neste caso se pretende avaliar o impacto de cada

projecto na infra-estrutura da organizacao. A figura A.1.1 e um modelo de alto nıvel da arquitectura

empresarial do banco, com os principais processo de negocio, aplicacoes de suporte ao negocio e

infra-estrutura onde se encontram dispostas as aplicacoes.

No anexo A, e possıvel ter uma visao detalhada das varias areas de negocio identificadas nesta

organizacao, com os seus processos de negocio, equipas e aplicacoes associadas, representadas

mais uma vez por via de diagramas Archimate. No modelo Archimate apresentado em A.1.2, encontra-

69

se modelado o primeiro cenario que mostra a arquitectura empresarial To Be, caso seja implemen-

tado o projecto de CRM local. A implementacao de um sistema deste tipo, ira exigir a implementacao

de uma nova infra-estrutura para suportar as novas aplicacoes de CRM, as quais irao estar associ-

adas a processos de negocio relativos a gestao de clientes e dos seus dados.

No modelo Archimate apresentado em A.1.3, encontra-se modelado o segundo cenario, no qual

e mostrada a arquitectura empresarial To Be, caso seja implementado o projecto de CRM cloud. A

implementacao deste sistema nao requer qualquer infra-estrutura nova do lado do banco, sendo que

a mesma se encontra implementada no espaco do provedor do servico. Desta forma para aceder

aos servicos sera necessario possuir uma ligacao a web, pois so dessa forma estarao acessıveis os

mesmos.

6.2.5 Aplicacao de Metricas

A aplicacao das metricas descritas anteriormente, aos 2 cenarios identificados, produz os seguintes

resultados:

Table 6.2: Resultados das metricas para os varios cenarios.

Cenario Metrica ResultadoCRM local Req Fun 1CRM local Map Competencies 1CRM local Neg app 1CRM local Num layouts 0,75CRM local Impact negocio 0,833333CRM local Impact Tecnologico 0,8CRM local Time to Market 0,75CRM local Pol Seg 1

CRM Cloud Req Fun 0,75CRM Cloud Map Competencies 0,25CRM Cloud Neg app 0,75CRM Cloud Num layouts 0,5CRM Cloud Impact negocio 0,833333CRM Cloud Impact Tecnologico 1CRM Cloud Time to Market 1CRM Cloud Pol Seg 0,6

6.2.6 Metricas de Impacto

Para este caso pretendeu-se analisar o impacto causado a nıvel de processos de negocio, ou seja

quais serao afectados pela adicao do novo sistema CRM. Alem dos processos de negocio tambem o

impacto causado a infra-estrutura do banco sera uma metrica a considerar, uma vez que os cenarios

apresentados diferem bastante neste aspecto.

70

Table 6.3: Resultados das metricas de impacto para os varios cenarios.

Metrica Cenario Pontuacao

Factor de Processos de negocio alteradosAs Is 1To Be 1 0,833333To Be 2 0,833333

Factor Elementos de infra-estrutura alteradosAs Is 1To Be 1 0,8To Be 2 1

De acordo com as metricas de impacto, o impacto a nıvel de negocio pouco difere, isto faz sentido

uma vez que ambas as solucoes pretendem implementar e disponibilizar os mesmos servicos, como

tal e de esperar que os processos de negocio impactados sejam os mesmos. A nıvel de impacto

na camada tecnologica, a solucao cloud produziu o menor impacto, uma vez que a infra-estrutura

necessaria, pertence ao lado do fornecedor do servico, bastando apenas possuir um browser do

lado do cliente para aceder aos servicos disponibilizados. No caso da solucao local, e necessario

realizar alteracoes a infra-estrutura, introduzindo novas maquinas para suportar alguns dos servicos

introduzidos, o que necessariamente corresponde a um impacto maior face a solucao cloud.

6.2.7 Comparacao de Cenarios

Uma vez na posse dos resultados dos cenarios nas diferentes metricas, e necessario ponderar

essa pontuacao com os pesos definidos para cada metrica. Seguindo a abordagem SWING de-

scrita em 2.7, foi pedido aos stakeholders que pesassem os diferentes objectivos identificados para

o projecto. Da aplicacao desta metodologia resultaram os seguintes pesos:

Table 6.4: Pesos atribuıdos aos objectivos.

Nome WeightAumentar a qualidade dos Servicos (+funcionalidade + eficiencia) 100Garantir a capacitacao dos colaboradores no suporte ao relacionamento comos Clientes

40

Aumentar a eficiencia operacional 30Minimizar a proliferacao de solucoes aplicacionais com layout distintos 40Minimizar impacto nas restantes areas de negocio 10Minimizar o tempo de implementacao da solucao 10Partilhar a Informacao do cliente entre areas de negocio 30Garantir o cumprimento da politica de seguranca 20

A distribuicao de pesos pelas diferentes metricas, apos a aplicacao do modelo aditivo e a que se

segue:

71

Figure 6.12: Distribuicao do peso total para cada metrica.

Efectuado o calculo da pontuacao global com pesagem, obtem-se as seguintes classificacoes

dos cenarios:

Figure 6.13: Pontuacao global de cada cenario.

Pontuacao de cada cenario em cada uma das metricas escolhidas:

72

Figure 6.14: Pontuacao de cada cenario por metrica.

De acordo com os resultados exibidos nas figuras 6.13 e 6.14, e o cenario CRM local, que melhor

pontua na globalidade. No entanto e interessante analisar os resultados parciais obtidos, por exemplo

a nıvel de time to market e respeito pelas polıticas de seguranca do banco. A solucao cloud, e

a que necessita de um menor tempo para estar implementada, faz sentido, uma vez que a infra-

estrutura necessaria esta do lado do fornecedor, por outro lado o facto da infra-estrutura pertencer

ao fornecedor, faz com que este cenario nao cumpra totalmente a polıtica de seguranca do banco,

pontuado pior nesse aspecto.

Uma metrica na qual os cenarios pontuaram de forma bastante diferente, foi a metrica relativa a

reutilizacao de competencias ja existentes no banco. Uma vez que ja existe uma extensa formacao

para operar e manter a solucao local proposta, comparativamente a solucao proposta no cenario

cloud, que iria exigir formar os actores presentes na organizacao.

6.2.8 Decisao

Esta fase, uma vez que se esta a analisar um projecto passado, nao pode ser realizada, mas

como e descrito em 4.1 seria a etapa final em que os resultados sao comunicados aos stakeholders

e estes aceitariam a solucao proposta pela metodologia ou em alternativa, poderiam realizar uma

analise de sensibilidade para testar a influencia dos pesos nos resultados da analise.

6.2.9 Conclusoes caso pratico

Atraves da realizacao deste caso pratico, foi possıvel testar a aplicabilidade da metodologia pro-

posta em 4.1, num contexto real, cujo ambito e aquele que se pretende para a aplicacao da metodolo-

gia. Onde existiam varios cenarios a avaliar, e eram varios os criterios a considerar no problema. Este

caso permitiu igualmente utilizar novamente as regras de impacto, ja validadas em 6.1.

73

7Conclusoes e Trabalho Futuro

Contents7.1 Conclusoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

75

7.1 Conclusoes

Durante este trabalho foram focados diversos aspectos relativos ao tema da analise de cenarios

de uma arquitectura empresarial. Neste capıtulo sao apresentadas as principais conclusoes, limitacoes

e trabalho futuro. As conclusoes foram estruturadas e separadas de acordo com o topico analisado.

O ambito mais geral do trabalho, e a construcao de uma metodologia que permita de forma

sistematica e estruturada, guiar uma analise a arquitectura empresarial em que o objectivo e escolher

um entre varios cenarios. Existe necessidade de um tal metodo uma vez que e um campo de estudo

ainda em aberto, o que leva a que a maioria das analises deste tipo seja feita de forma empırica,

faltando uma abordagem metodologica, objectiva e justificavel de realizar esse trabalho.

7.1.1 Analise Multicriterio

O problema de avaliacao proposto, pode ser visto como um caso de avaliacao multicriterio [27],

no qual os criterios correspondem as metricas a aplicar a cada cenario, e os cenarios da arquitectura

empresarial, as opcoes presentes na analise multicriterio. Este genero de analise ja amplamente

estudado e testado, constituiu um importante ponto de partida para a construcao da metodologia de

avaliacao apresentada, sendo um tipo de analise bastante geral e aplicavel a inumeras situacoes.

Serviu como indicador de quais os elementos a desenvolver, para implementacao da analise pre-

tendida.


Um dos aspectos mais importantes desenvolvidos neste trabalho, foi a escolha de metricas.

Quando se realiza uma analise multicriterio, e necessario seleccionar criterios, que permitirao, quando

aplicados aos cenarios, conhecer o seu estado, em relacao a determinadas qualidades. Ja existem

varios trabalhos, sobre como deve ser feita a construcao de metricas [24] [1], nos quais sao de-

scritos os elementos e caracterısticas que garantem uma boa metrica, e importante garantir que uma

metrica apesar de respeitar todos os princıpios e estar correctamente formulada, e util e consegue

realmente medir aquilo que se pretende.

No caso deste trabalho nao era o objectivo propor um conjunto de metricas para avaliar difer-

entes cenarios, mas sim construir uma metodologia, para que no contexto da analise proposto, fosse

possıvel escolher as metricas a aplicar. Esta escolha deve possuir uma logica clara, de forma a ser

possıvel justificar a escolha dessas mesmas metricas.

Desta forma, foram analisadas metodologias procedimentais e estruturais para a definicao de

metricas, sendo neste ponto de destacar a abordagem GQM, que permitiu ligar as metricas escolhi-

das, a objectivos de mais alto nıvel garantindo o alinhamento entre ambos. Apesar desta abordagem

ser realizada com base em questoes formuladas por stakeholders, permite reduzir a subjectividade

76

e fundamentar a escolha das metricas, atraves de um processo estruturado com regras a respeitar

no processo de formulacao das questoes e metricas. Esta associacao entre metricas e objectivos

adiciona uma nova dimensao face ao que foi feito noutros trabalhos, nos quais estas se encontram

associadas apenas a qualidades.

Para que seja possıvel realizar este passo na avaliacao e essencial em primeiro lugar, que os

objectivos da organizacao no contexto da mudanca estejam definidos, conforme o trabalho analisado

em 2.4, uma forma de efectuar esta definicao e atraves de um balanced scorecard, na qual se podem

associar os objectivos a iniciativas, como por exemplo os projectos que pretendemos avaliar.

Utilizando os objectivos para a mudanca, como ponto de partida e possıvel garantir que as

metricas se encontram alinhadas com a mudanca a avaliar, e que uma vez aplicadas irao auxiliar

na avaliacao do problema.

7.1.3 Pesagem de Criterios

Outro elemento crucial da analise multicriterio que foi necessario explorar foi a pesagem de

criterios 2.7. No contexto do metodo de avaliacao desenvolvido, existem sempre varias metricas

que apenas em conjunto permitem avaliar os cenarios, sob diferentes pontos de vista. Das opcoes

analisadas, aquela que foi utilizada nos casos praticos foi o metodo SWING, devido a sua simpli-

cidade, e capacidade de incorporar incertezas dos utilizadores, atraves de intervalos de pesagem.

Nao era um objectivo deste trabalho comparar os metodos de pesagem existentes, podendo quem

aplica a metodologia, escolher o metodo que melhor se adapta as suas necessidades, e introduzi-lo

na metodologia.

7.1.4 Analise de Impacto

Um dos objectivos tracados para este trabalho foi, o desenvolvimento de um processo que partindo

de um cenario da AE, conseguir saber que impacto provoca a implementacao desse cenario nos

diferentes elementos da AE. Este aspecto do trabalho foi concretizado, utilizando como base a lin-

guagem de modelacao Archimate, e as ligacoes que esta define entre os elementos. Para isso foram

analisadas as ligacoes Archimate e definidas regras que estabelecem as situacoes em que existe

propagacao de impacto.

Estas regras inicialmente propostas em [18], de forma mais simplificada, foram validadas atraves

de um caso pratico e implementadas formalmente atraves de uma ferramenta de arquitectura empre-

sarial. As limitacoes neste aspecto prendem-se com obrigacao de usar a linguagem Archimate, uma

vez que as regras foram definidas para esta linguagem e para que o seu uso fosse possıvel numa

outra Framework de modelacao, seria necessario construir um conjunto de regras novo adequado as

ligacoes e elementos da linguagem.

Foram tambem propostas algumas metricas de dimensao, ainda que simplificadas de forma a

incluir o impacto na arquitectura como elemento da analise proposta. As quais foram possıveis de

77

validar atraves dos casos praticos realizados.

7.1.5 Limitacoes e Trabalho Futuro

A investigacao realizada neste trabalho deixa ainda, pontos em aberto dentro do seu ambito, os

quais podem constituir possıveis investigacoes futuras.

E de salientar como possıvel trabalho futuro, a nıvel das regras de impacto, conseguir alargar es-

tas regras a outras linguagens de modelacao, bem como elaborar e validar metricas mais complexas.

Uma vez que as metricas apresentadas pressupoem, por exemplo que todos os elementos da arqui-

tectura exigem o mesmo esforco para serem alterados, uma melhoria as mesmas poderia passar

por distinguir o peso com que cada objecto da arquitectura contribui para o calculo do impacto geral

do cenario. Alem disto seria interessante relacionar estas metricas com as qualidades existentes,

identificadas em outros trabalhos [8] [1].

Ao nıvel da escolha de metricas e seu alinhamento, com objectivos, a criacao de uma biblioteca

de metricas, na qual as metricas se encontrassem agrupadas por objectivos ou tipos de objectivos,

poderia acrescentar valor a este trabalho. Isto seria algo semelhante ao que existe para o domınio

do software, com um conjunto de qualidades e de metricas que permitem avaliar essas qualidades.

Quanto as ferramentas desenvolvidas, para realizar automaticamente e de forma a facilitar a

aplicacao da metodologia, estas foram implementadas em varias solucoes ja existentes, o que di-

ficulta a sua integracao, exigindo a transicao entre ferramentas. Uma forma de alargar e melhorar

esta investigacao seria construir uma solucao integrada, para gerir todo o processo de avaliacao dos

cenarios. Esta solucao teria de juntar todas as componentes da analise proposta, desde o levanta-

mento de metricas, a representacao dos cenarios, definicao de pesos e avaliacao dos cenarios. Por

exemplo a ferramenta Macbeth [30], foca-se na pesagem e classificacao dos cenarios, faltando uma

componente que permita formalizar esses cenarios, atraves de uma framework de modelacao por

exemplo.

Como forma adicional de validacao e divulgacao deste trabalho, foi produzido um artigo cientıfico

com o tıtulo “Using Multi-criteria Analysis to Evaluate Enterprise Architecture Scenarios”. publicado

na conferencia ICEIS 2012 [34].

78

Bibliografia

[1] A. Vasconcelos, “Arquitecturas dos sistemas de informacao: Representacao e avaliacao,” Ph.D.

dissertation, Instituto Superior Tecnico, 2007.

[2] The Open Group: TOGAFTMVersion 9. Van Haren Publishing, 2009.

[3] T. O. Group, ArchiMate 1.0 Specification, ser. Van Haren Series. Van Haren Publishing, 2009.

[Online]. Available: http://books.google.com/books?id=zK5v3ukz8TkC

[4] S. I. A. J. G. J. Thompson, A.Arthur, Crafting & Executing Strategy: The Quest for Competitive

Advantage: Concepts and Cases. McGraw-Hill Companies,Inc., 2007. [Online]. Available:

http://books.google.pt/books?id=Z0l3cgAACAAJ

[5] V. R. Basili, G. Caldiera, and H. D. Rombach, “The goal question metric approach,” in Encyclo-

pedia of Software Engineering. Wiley, 1994.

[6] T. D. Henry Peyret, “The forrester wave: Enterprise architecture management suites,” Forrester,

Tech. Rep., 2011.

[7] A. Vasconcelos, “Arquitectura de sistemas de informacao no contexto do negocio,” Master’s

thesis, Instituto Superior Tecnico, 2001.

[8] P. G. F. F. da Costa, “Simplexis - avaliacao do impacto das medidas simplex na arquitectura dos

sistemas de informacao,” Master’s thesis, Instituto Superior Tecnico, 2010.

[9] A. Hevner, S. March, J. Park, and S. Ram, “Design science in information systems research,”

Management information systems quarterly, vol. 28, no. 1, pp. 75–106, 2004.

[10] R. Winter and R. Fischer, “Essential layers, artifacts, and dependencies,” Journal of Enterprise

Architecture, vol. 3, no. 2, pp. 7–19, 2007.

[11] M. Lankhorst, Enterprise Architecture at Work: Modelling, Communication and Analysis, 2nd ed.

Berlin: Springer, 2009.

[12] A. Caetano and J. Tribolet, “Modeling organizational actors and business processes,” in

Proceedings of the 2006 ACM symposium on Applied computing, ser. SAC ’06. New York,

NY, USA: ACM, 2006, pp. 1565–1566. [Online]. Available: http://doi.acm.org/10.1145/1141277.

1141640

79

http://books.google.com/books?id=zK5v3ukz8TkC

http://books.google.pt/books?id=Z0l3cgAACAAJ

http://doi.acm.org/10.1145/1141277.1141640

http://doi.acm.org/10.1145/1141277.1141640

[13] C. M. Pereira and P. Sousa, “Enterprise architecture: business and IT alignment,” in SAC ’05:

Proceedings of the 2005 ACM symposium on Applied computing. New York, NY, USA: ACM,

2005, pp. 1344–1345. [Online]. Available: http://dx.doi.org/10.1145/1066677.1066980

[14] J. Zachman, “A framework for information systems architecture,” IBM Syst. J., vol. 26, pp.

276–292, September 1987. [Online]. Available: http://dx.doi.org/10.1147/sj.263.0276

[15] J. A. Zachman, “A framework for information systems architecture,” IBM Systems Journal, vol. 38,

no. 2/3, pp. 454–470, 1999.

[16] A. Vasconcelos, P. Sousa, and J. Tribolet, “Information system architecture metrics: an enter-

prise engineering evaluation approach,” The Electronic Journal Information Systems Evaluation,

vol. 10, no. 1, pp. 91–122, 2007.

[17] A. F. Vasconcelos, “Ceo framework information system architecture evaluation metrics,” Instituto

Superior Tecnico, Tech. Rep., 2007.

[18] F. S. de Boer, M. M. Bonsangue, L. Groenewegen, A. Stam, S. Stevens, and L. W. N. van der

Torre, “Change impact analysis of enterprise architectures,” in IRI, 2005, pp. 177–181.

[19] ISO/IEC, ISO/IEC 9126. Software engineering – Product quality. ISO/IEC, 2001.

[20] C. Kaner, S. Member, and W. P. Bond, “Software engineering metrics: What do they measure

and how do we know?” in In METRICS 2004. IEEE CS. Press, 2004.

[21] K. D., “A structured method for generating, evaluating and using metrics.”

[22] J. R. Hauser and G. M. Katz, “Metrics: you are what you measure!” European

Management Journal, vol. 16, no. 5, pp. 517–528, 1998. [Online]. Available: http:

//linkinghub.elsevier.com/retrieve/pii/S0263237398000292

[23] M. Hammer, “The 7 deadly sins of performance measurement and how to avoid them,”

MIT Sloan Management Review, vol. 48, no. 3, pp. 19–28, 2007. [Online]. Available:

http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=24841214&site=ehost-live

[24] C. Blackburn and R. Valerdi, “Navigating the metrics landscape: An introductory literature guide

to metric selection, implementation, decision making,” Administrative Science Quarterly, no.

April, pp. 1–16, 2009.

[25] R. S. Kaplan and D. P. Norton, “Mastering the management system.” Harvard Business Review,

vol. 86, no. 1, pp. 62–77, 136, 2008.

[26] Kaplan, “Linking the balanced scorecard to strategy,” California Management Review, vol. 39,

no. 1, pp. 53–80+.

[27] A. P. JS Dodgson, M Spackman, “Multi-criteria analysis: a manual,” Department for Communities

and Local Government, Tech. Rep., 2009.

80

http://dx.doi.org/10.1145/1066677.1066980

http://dx.doi.org/10.1147/sj.263.0276

http://linkinghub.elsevier.com/retrieve/pii/S0263237398000292

http://linkinghub.elsevier.com/retrieve/pii/S0263237398000292

http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=24841214&site=ehost-live

[28] V. Basili, J. Heidrich, M. Lindvall, J. Munch, M. Regardie, and A. Trendowicz, “Gqm+ strategies

– aligning business strategies with software measurement,” First International Symposium on

Empirical Software Engineering and Measurement ESEM 2007, pp. 488–490, 2007. [Online].

Available: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4343788

[29] S. A. Sarcia’, “Is gqm+strategies really applicable as is to non-software development domains?”

in Proceedings of the 2010 ACM-IEEE International Symposium on Empirical Software

Engineering and Measurement, ser. ESEM ’10. New York, NY, USA: ACM, 2010, pp.

45:1–45:4. [Online]. Available: http://doi.acm.org/10.1145/1852786.1852844

[30] J.-C. V. Carlos A. Bana e Costa, “Applications of the macbeth approach in the framework of an

additive aggregation model,” JOURNAL OF MULTI-CRITERIA DECISION ANALYSIS, 1997.

[31] C. Jones, Applied software measurement: assuring productivity and quality. McGraw-Hill, 1991.

[32] T. Khoshgoftaar and J. Munson, “The lines of code metric as a predictor of program faults: A

critical analysis,” in Proceedings of the Computer Software and Applications Conference, 1990,

pp. 408–413.

[33] V. Vaishnavi and W. Kuechler, “Design science research in information systems,” 2004. [Online].

Available: http://desrist.org/desrist

[34] F. Cansado, A. Vasconcelos, and G. Santos, “Using multi-criteria analysis to evaluate enterprise

architecture scenarios,” in ICEIS (3), 2012, pp. 232–237.

[35] J. Van Bon, A. de Jong, and A. Kolthof, Foundations of IT Service Management Based

on ITIL, ser. ITSM Library. Van Haren Publishing, 2007, no. v. 3. [Online]. Available:

http://books.google.pt/books?id=PKNFiXLk5bIC

81

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4343788

http://doi.acm.org/10.1145/1852786.1852844

http://desrist.org/desrist

http://books.google.pt/books?id=PKNFiXLk5bIC

A

A-1

A.1 Representacao dos cenarios Caso CRM

A.1.1 Cenario As Is

Figure A.1: Modelo archimate do cenario As Is do caso CRM.

A-2

A.1.2 Cenario To Be Local

Figure A.2: Modelo archimate do cenario To Be Local do caso CRM.

A-3

A.1.3 Cenario To Be Cloud

Figure A.3: Modelo archimate do cenario To Be Cloud do caso CRM.

A-4

A.2 Metricas do Caso CRM

A.2.0.A Taxa de cobertura de requisitos funcionais

• ID: M1

• Racional/Objectivo: Uma solucao e tanto melhor e completa quantos mais requisitos fun-

cionais preencher, atraves desta metrica pretende-se saber qual taxa de cobertura dos req-

uisitos funcionais de uma determinada opcao. Assim torna-se possıvel comparar diferentes

solucoes atraves de um valor que expressa a percentagem de requisitos funcionais cumpridos.

• Formula de Computacao: (No de Requisitos funcionais realizados pela solucao)/(No de Req-

uisitos funcionais)

• Gama de Valores: [0;1] : Uma solucao que cumpra com todos os requisitos funcionais pre-

tendidos ira obter uma pontuacao de 1, se o numero de requisitos cumpridos for menor que

o de pretendidos, a pontuacao sera menor que 1 ate 0 para uma solucao que nao cumpra

qualquer requisito funcional.

A.2.0.B Taxa de cobertura de requisitos funcionais

• ID: M2

• Racional/Objectivo:Conhecer quao alinhadas estao as competencias necessarias para op-

erar uma determinada solucao, com as competencias actualmente disponıveis na organizacao,

pode ser um indicador de quais sao as lacunas presentes na organizacao a nıvel de com-

petencias. Quanto maior for o numero de competencias que e necessario desenvolver, para op-

erar uma determinada solucao maior sera o esforco necessario para as adicionar a organizacao.

Atraves desta metrica e possıvel saber quao capaz esta a organizacao para implementar um

determinado projecto com as suas competencias actuais.


uisitos funcionais)

• Gama de Valores: [0;1] Uma solucao para a qual a organizacao, possua todas as com-

petencias necessarias para a sua correcta operacao ira obter uma pontuacao de 1. Se por outro

lado for necessario introduzir novas competencias na organizacao a pontuacao ira diminuir,

sendo de 0 para uma organizacao sem nenhuma competencia adequada a solucao propostas.

A.2.0.C Alinhamento entre Aplicacoes e Processos de Negocio

• ID: M3

• Racional/Objectivo:As aplicacoes implementadas na organizacao, devem suportar adequada-

mente os processo de negocio. Ou seja devem minimizar situacoes como, introduzir varias

vezes a mesma informacao em diversas aplicacoes ou ser forcado a utilizar varias aplicacoes

A-5

numa mesma tarefa. Estas situacoes indicam um fraco alinhamento entre o negocio e as

aplicacoes utilizadas. Com esta metrica pretendemos saber quao bem suportados estao os

processos de negocio da organizacao pelo landscape aplicacional implementado.


uisitos funcionais)

• Gama de Valores: [0;1] Se todos os processos forem suportados por uma aplicacao, entao

esta metrica tera como valor 1, se por outro lado existirem processos de negocio sem qualquer

suporte aplicacional, a classificacao ira diminuir, podendo ser 0 no caso de uma arquitectura

em que todos os processos sao manuais (sem suporte aplicacional).

A.2.0.D Numero de layouts distintos

ID: M4

Racional/Objectivo:Quanto menos for o numero de layouts distintos presentes nas aplicacoes,

mais facil e para o utilizador interagir com o sistema. Isto leva a um menor numero de transicoes

entre aplicacoes para realizar uma tarefa, agilizando e tornando mais rapida a sua realizacao. Esta

metrica tem por objectivo contabilizar o numero de layouts diferentes presentes na solucao compar-

ativamente ao numero de aplicacoes, de forma a conhecer qual o nıvel de integracao existente entre

as aplicacoes apresentadas.

Formula de Computacao: (No de Requisitos funcionais realizados pela solucao)/(No de Requi-

sitos funcionais)

Gama de Valores:[0,1[]] Uma solucao em que cada aplicacao possua um layout distinto, sera

classificada com 0 pontos nesta metrica, a medida que o nıvel de integracao aumenta, e as diferentes

aplicacoes partilham layouts, a pontuacao aumenta ate ao limite de 1.

A.2.0.E Tempo de implementacao

• ID: M7

• Racional/Objectivo:O tempo que uma determinada solucao demora ate estar operacional,

pode ter grande impacto no sucesso da sua implementacao, e inclusive ser um factor deci-

sivo na escolha da solucao a implementar.

• Gama de Valores: [0;1] Os valores de tempo de implementacao podem variar dentro do inter-

valo de [0,+00[] ] , de forma a conseguir que esta metrica seja mapeada para o intervalo [0,1],

sera necessario normalizar os valores, colocando o cenario que demora menos tempo a ser

implementado com a pontuacao de 1, e os restantes cenarios com pontuacoes menores mas

que conservem a diferenca relativa entre solucoes.

A-6

A.2.0.F Cumprimento da politica de seguranca do banco.

• ID: M8

• Racional/Objectivo:De acordo com os conjuntos de boas praticas, como por exemplo o ITIL

[35] no caso das boas praticas para a gestao dos servicos informaticos numa organizacao, deve

estar implementada e formalizada uma politica de seguranca dentro da organizacao. Atraves

desta metrica, pretende-se avaliar o cumprimento da politica de seguranca em cada uma das

solucoes, de forma a saber qual ou quais solucoes melhor cumprem a politica de seguranca

definida. Numa entidade como um banco que se usa no exemplo, uma politica de seguranca

e composta por inumeras categorias que definem procedimentos e condicoes que se tem de

verificar de forma a que a actividade do banco possa ser desenvolvida. Numa politica de

seguranca podem constar por exemplo, obrigacoes a nıvel dos utilizadores, Informacao gerida

pelo sistema, permissoes de acesso, gestao de incidentes e normas para fornecimento de

servicos por terceiros. Uma vez que a politica de seguranca de uma entidade como um banco

e bastante extensa, em seguida enumeramos alguns dos itens que iremos considerar para

avaliar as solucoes propostas:

1. As redes e infra-estruturas onde se encontram implementadas as aplicacoes e dados do

banco, devem estar isoladas da rede publica e de outros servicos de terceiros.

2. Devem efectuar-se backups diarios de toda a informacao e sistemas, bem como guardar

seguramente esses mesmos backups.

3. Firewalls e sistemas de antivırus devem estar actualizados de acordo com a especificacao

do fornecedor do mesmo.

4. Devem estar implementados mecanismos de deteccao de intrusos, e registo de ocorrencias.

5. Os dados trocados atraves de redes ou dispositivos moveis, devem encontrar-se encripta-

dos.

• Gama de Valores: [0;1] Num cenario em que sejam respeitadas todas as polıticas de seguranca,

a pontuacao atribuıda sera de 1, caso alguns dos itens de seguranca nao sejam cumpridos, a

pontuacao ira diminuir, chegando a 0 caso nao seja garantido nenhum dos itens de seguranca

descritos.

A-7

A.3 Diagrama BPMN, da metodologia de avaliacao proposta

Figure A.4: Modelo BPMN da solucao proposta.

A-8

Avaliaçao de Cen˜ arios de Optimizaç´ ao de uma ... · Avaliaçao de Cen˜ arios de...

Documents

Transcript of Avaliaçao de Cen˜ arios de Optimizaç´ ao de uma ... · Avaliaçao de Cen˜ arios de...