Ase

Arquitectura Sistemas Empresariais
(ASE)
Prof. Acácio Carmona

acacio.carmona@vodafone.com
1ª Sessão: Apresentação
 Objectivos
 Competências
 Organização e metodologia de
trabalho
 Métodos de avaliação.
 Bibliografia, comunicação e apoio aos
alunos.
 Programa
 Arquitecturas de Sistemas
Empresariais - Introdução
Objectivos
 Obter o conhecimento necessário à elaboração de Arquitectura de
Sistemas de Informação Empresariais.
 Obtenção da compreensão e domínio das tecnologias, das
componentes aplicativos, das metodologias de desenvolvimento e
conhecimento necessário à elaboração de arquitecturas de
sistemas de informação.
 Caracterizar os aspectos essenciais das Arquitecturas de
Sistemas Empresariais e sua interligação com a Gestão
Estratégica das Empresas.
 Compreender, desenhar e avaliar arquitecturas de sistemas de
software, tendo em vista a sua aplicação aos vários níveis e
domínios, tanto a nível macro como a nível micro.
 Abordar os princípios e técnicas para análise, gestão e
planeamento de Portfólios Aplicacionais de Empresas.
Competências
 Após a aprovação em ASE - Arquitectura de Sistemas de
Informação Empresariais os alunos deverão ter as seguintes
competências:
 Compreender, desenhar e avaliar arquitecturas de sistemas de
software, tanto ao nível macro como micro;
 Familiarização com os conceitos fundamentais de arquitectura de
software e sua interligação com a Gestão Estratégica das
Empresas.
 Domínio dos princípios e técnicas para análise, gestão e
planeamento de Portfólios Aplicacionais de Empresas.
 Compreender a importância da arquitectura empresarial na
standardização de tarefas, funções, sistemas, infraestruturas e
dados nos principais processos de negócio.
Organização da disciplina
 Aulas Teóricas
◦ De acordo com o Horário do Curso.
 Trabalhos
◦ Relatório(s) de análise de caso(s) de estudo.
◦ 1 Trabalho de Grupo e uma apresentação em
aula.
 Dúvidas e outros esclarecimentos
◦ Através de e-mail.
◦ Após as aulas : A combinar
 Repositório da Informação
◦ http://moodle.ulusofona.pt
Avaliação
 A avaliação é composta por :
◦ Frequência (50% da nota final)
◦ Trabalhos Práticos (40 % da nota final)
 Relatório de análise de Caso de estudo individual. (15 %)
 Trabalho de Grupo (45 %)
 Apresentação em aula (40 %).
◦ Participação na Disciplina (10% da nota final)
◦ Trabalhos entregues fora do prazo não serão
considerados
◦ Aluno obtém aprovação na disciplina desde que tenha:
◦ Média Final igual ou superior a 10 valores e
 Nota igual ou superior a 8 valores na Frequência
 Nota igual ou superior a 8 valores na Parte Prática (média
dos trabalhos).
Bibliografia (Principal)
 McGovern, James: Ambler, Scott W.; Stevens, Michael E.;
Linn, James; Sharan, Vikas; Jo, Elias K.; A Practical Guide
to Enterprise Architecture, Pearson – Prentice Hall, 2007
 Laudon, Keneth C.; “Management Information Systems:
Managing the Digital Firm, 11 ed. Global Edition, Pearson
– Prentice Hall, 2009
 Steven H. Spewak, “Enterprise Architecture Planning:
Developing a Blueprint for Data, Applications and
Technology”, John Willey & Sons, 1992.
 Jeanne W. Ross, Peter Weill, David C. Robertson;
Enterprise Architecture As Strategy; Harvard Business
School Press; 2006
 Acetatos, Casos e artigos diversos a distribuir ao longo de
semestre, acessíveis em: http://moodle.ulusofona.pt
Linn, James; Sharan, Vikas; Jo, Elias K.; A Practical Guide
to Enterprise Architecture, Pearson – Prentice Hall, 2007
Managing the Digital Firm, 11 ed. Global Edition, Pearson
– Prentice Hall, 2009
Technology”, John Willey & Sons, 1992.
 Jeanne W. Ross, Peter Weill, David C. Robertson;
Enterprise Architecture As Strategy; Harvard Business
School Press; 2006
 Acetatos, Casos e artigos diversos a distribuir ao longo de
semestre, acessíveis em: http://moodle.ulusofona.pt
Linn, James; Sharan, Vikas; Jo, Elias K.; A Practical Guide to
Enterprise Architecture, Pearson – Prentice Hall, 2007 (Prefácio;
Capítulos 1 ; 2; 5 e 6.)
Managing the Digital Firm, 11 ed. Global Edition, Pearson –
Prentice Hall, 2009 (Capítulos 1; 2, 3 e 9)
Technology”, John Willey & Sons, 1992 (Capítulos 1; 2; 3; 6; 8; 9
e 10).
 Jeanne W. Ross, Peter Weill, David C. Robertson; Enterprise
Architecture As Strategy; Harvard Business School Press;
2006 (Capítulos 1; 2; 3; 4 e 7).
Bibliografia (Secundária)
 Martin Van Den Berg, Marlies Van Steenbergen; Building
an Enterprise Architecture Practice; Springer, Sogeti; July
2006, Netherlands
 Shaw, Mary; Garlan, David, “Software Architecture:
Perspectives on an Emerging Discipline”, Prentice Hall,
1996.
 Bernard H. Boar, “Constructing Blueprints Enterprise IT
Architectures”, John Willey & Sons, 1998.
 Bass, Len; Clements, Paul; Kazman, Rick, “Software
Architecture in Practice” Addison-Wesley, 2003.
 Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides,
John, “Design Patterns –Elements of Reusable Object-
Oriented Software”, 1995.
 Data Warehouse - From Architecture to Implementation,
Barry Devlin, Addison-Wesley 1997.
Programa
1. Introdução à temática das Arquitecturas
de Sistemas de Informação Empresariais
2. Fundamentos da Arquitectura de Empresa
3. Enquadramento dos sistemas de informação
no Negócio Global actual. Sistemas de
Informação, Estratégia e Organização.
4. Tipos de Arquitecturas
5. Framework de Zachman
6. Gestão Estratégica. Análise SWOT. Modelos
BCG e de Porter
7. Análise, Gestão e Planeamento de Portfólio
Aplicacional
8. Apresentações e Discussão de Casos de
Estudo.
Questionário
 Arquitectura da Empresa é desenvolver
aplicações utilizando J2EE, .Net, ou
tecnologias semelhantes ?
Falso
 Arquitectura da Empresa é organizar os
dados da empresa para facilitar a
integração ?
Falso
 Arquitectura da Empresa é uma forma de

desenhar sistemas de TI ?
Falso
Mitos & Realidade
 Mito:
◦ É uma forma de desenhar sistemas de TI
◦ É uma forma de organizar Dados
◦ É uma metodologia de desenvolvimento de
aplicações Java (J2EE! & Java certified
enterprise architect)
 Realidade:
◦ É a arquitectura da “Empresa”
◦ Envolve documentação global e a gestão de
todos os aspectos da empresa
◦ É uma questão de negócio, não apenas uma
questão de TI
◦ Não tem nada a ver com Java!
O Que é “Arquitectura Empresarial…”?
Arquitectura
+
Negócio
Arquitectura
q Sistemas Empresariais
p
(ASE)

Programa
1. Introdução
ç à temática das Arquitecturas
q de
Sistemas de Informação Empresariais
3
6
6. Gestão Estratégica.
Estratégica Análise SWOT
SWOT. Modelos
BCG e de Porter
A li
Aplicacional
i l
Estudo.
2ª Sessão: Fundamentos
2
 Arquitectura da Empresa
 C
Compreender a Arquitectura
 O q
que é um Arquitecto
q Empresarial?
p
 Diferentes tipos de arquitectos de TI
Como é que um edifício construído?
 Cliente / utilizador final tem uma necessidade
 Cliente discute com o Arquitecto as suas
necessidades e gostos pessoais
 O arquitecto
q “desenha” o edifício,, tendo em conta:
◦ Requisitos explícitos do cliente
◦ Requisitos explícitos dos reguladores (regras municipais etc.)
◦ Requisitos implícitos da localização do lote
lote, ambiente
ambiente, etc
etc.
◦ Requisitos implícitos que o edifício tem de ter bom aspecto e
que possa ser realizável na prática.
 O engenheiro de estruturas desenha a estrutura da
casa
◦ Cumpre com o desenho do arquitecto
◦ Pode ser construído com as tecnologias existentes
◦ Será suficientemente robusto para o uso pretendido
 O designer de interiores modela o ambiente
◦ Superfície exterior
◦ Cores interiores
◦ Móveis, candeeiros etc.
A Salientar
 Todas as questões anteriores são
igualmente importantes
 Múltiplos papeis podem ser
desempenhados pela mesma pessoa
 As competências necessárias para cada
papel são distintas
 Um edifício irá falhar se lhe faltar qualquer
um dos aspectos mencionados
A Torre de Pisa
Winchester House
 Desenho estrutural robusto
 Lindamente decorada
 A ê i d
Ausência de desenho
d h funcional
f i l
Resultado
 Status de lenda
como
monumento da
não-
ã
funcionalidade
Museu do Louvre
 Desenho altamente funcional
 Estruturalmente robusta
 B l
Bela
Resultado
 Considerada
uma “obra de
arte”
Ciclo de Desenvolvimento de Sistemas TI
 Cliente identifica a necessidade
 Arquitecto cria o desenho funcional
 Engenheiro cria a estrutura do sistema
◦ Engenheiro de software desenha a aplicação
◦ Engenheiro de redes desenha a infra-estrutura
infra estrutura
 Designer de User Interface concebe as
questões estéticas
 Programadores constroem o sistema
Papel de um Arquitecto
 Assegura que o sistema
A i t cumpre as
necessidades funcionais
 Asseg ra q
Assegura que
e o sistema c
cumpre
mpre as
necessidades não funcionais implícitas
 Assegura que o sistema cumpre com os
standards
◦ Standards Legais / Regulatórios
◦ Standards de Indústria
◦ Standards da empresa
 Assegurar que o sistema é “realizável”
Tipos de Arquitectos
 Business Architect
 Application / Solutions Architect
 Information / Data Architect
 Infrastructure Architect
 Enterprise Architect
Business Architect
 Assegura que os
A
processos de negócio e as
g
estratégias p
podem apoiar
p
as business functions
 Preocupação primária são
os business
b i processes &
organizações
 Este papel pode ter
apenas um interesse
periférico nas TI
 Um business architect
pode focalizar-se apenas
num processo de cada
vez.
Application / Solutions Architect
 Responsável
R á l pelal
compreensão das business
functions e p
pela sua
tradução em sistemas
possíveis de implementar.
 P
Preocupadod
essencialmente com cada
um dos sistemas e com o
seu interface com os
outros sistemas
 Nã se preocupa
Não
realmente com a visão
global de toda a Empresa.
Data / Information Architect
 Responsável
R á l por garantir
ti
que os dados são
g
organizados de forma
adequada e que suportam
as diversas soluções.
 A sua área
á d
de
responsabilidade pode
estender-se
estender se ao longo de
diversos sistemas de forma
a garantir que estes podem
trabalhar em conjunto
conjunto.
Infrastructure Architect
 Preocupado
P d com a infra-
i f
estrutura física de IT da
p
Empresa
 Papel relacionado com
aspectos como a
capacidade
id d d dos recursos,
a capacidade da rede,
server clustering,
administração e segurança
 O foco pode ser
d
departamental l ou alargado
l d
a toda a empresa
Enterprise Architect
 Papell associado
P i d à big
bi picture;
i t
Responsável pelo framework
g
global
 Garante que o trabalho de todos
os arquitectos constitui um todo
coerente
t e que estes
t trabalham
t b lh
de forma sincronizada
 Garante que os resultados estão
alinhados com a orientação do
negócio
 Estabelece direcção estratégica,
gere riscos, define normas e
mantém a comunicação através
de toda a organização.
O que faz um Enterprise Architect?
 Cria portfolio: estado corrente & futuro de:
◦ Objectivos & Estratégias
◦ L
Localizações
li õ
◦ Organizações
◦ Funções & Processos
◦ Recursos Físicos & Conhecimento
 Cria normas & processos para:
◦ Documentar o portfolio
◦ Manter o portfolio actualizado
◦ Realiza uma análise de gaps e uma avaliação da
solução
◦ Criar soluções
Funções do Enterprise Architect
Qualificações de Enterprise Architect
 Comunicação  Domínio do Conhecimento
◦ Learn ◦ Understand
◦ Listen ◦ Spot trends
◦ Understand ◦ Translate
◦ Critique ◦ Model
◦ Translate ◦ Process Knowledge
◦ Champion ◦ Analysis
◦ Envision  Conhecimento da
◦ Educate
Tecnologia
◦ Technology Environment
◦ Mediate
◦ Spot trends
◦ Police/ Enforce
◦ Methodologies
◦ Document
◦ T l
Tools
◦ Present
◦ Design solutions
 Será uma surpresa que Bill
p
Gates se apresente como
“Arquitecto”da Microsoft ?
Arquitectura
p
(ASE)

Programa
1. Introdução
q de
3
6
SWOT. Modelos
BCG e de Porter
A li
Aplicacional
i l
Estudo.
3ª Sessão
3 Sessão:: Fundamentos
 D fi i ã d
Definição de A
Arquitectura
it t E
Empresarial
i l
 Modelo de Arquitectura Empresarial
 Necessidade e aplicação …
Numa sua empresa …
 Os empregados trabalham cada vez mais
árduamente, mas sem resultados.
 Tem os melhores colaboradores, investe de
forma cuidadosa e tem a estratégia
correcta.
 Observa atentamente o mercado, ouve os
seus clientes, reage às iniciativas da sua
concorrência, faz tudo de acordo com as
boas práticas mas não consegue a
liderança.
Enquanto outras empresas …
 Crescem e obtêm lucros …

 … o que fazem de forma diferente?
 Têm melhores infra-estruturas,, têm
tecnologia sincronizada com os seus
processos e assim executamde forma
eficiente e fiável as suas operaçoes
nucleares.
Alertas …
 Diferentes áreas da empresa dão respostas
diferentes para a mesma pergunta de clientes
 Ser compatível com um novo regulamento ou fazer
novo reporting exige um esforço um esforço enorme
da gestão e investimentos significativos
 O negógio da empresa não tem agilidade – qualquer
nova iniciativa estratégica é como começar do zero
 O IT é de forma consistente um ponto de
estrangulamento.
estrangulamento
 Há diferentes processos de negócio efectuando a
mesma actividade transversalmente a toda a
empresa, cada um com um sistema distinto
Alertas …
 A informação necessária para lançar um produto
chave ou tomar decisões de clientes não está
disponível
 Uma parte significativa do trabalho diário dos
colaboradores é obter dados de um conjunto de
sistemas, processá-los e registá-los em outros
sistemas.
sistemas
 A Gestão de topo preocupa-se com a discussão de
pontos de agenda do IT
 Não se sabe se a nossa empresa retira um valor
justo do IT.
Definição “Oficial”
 A Arquitectura de Empresa (EA) é a

organização lógica
ó para os
processos de negócio e a
infraestrutura de IT
IT, reflectindo os
requisitos de integração e
standardização do modelo
opracional da Empresa.
Arquitectura Empresarial
 A arquitectura
it t d Empresa
da E f
fornece uma
visão a longo prazo dos processos,
sistemas e tecnologias para que os
projectos individuais possam construir
capacidades e não apenas satisfazer
necessidades imediatas.
 A verdadeira AE deve lidar com TODA a

Empresa;
 AE deve criar/melhorar as soluções com um
reduzido ou sem um envolvimento das TI
Enterprise Architecture
 Define
D fi as necessidades
id d d de uma
empresa para tarefas standardizadas,
papéis sistemas,
papéis, sistemas infra
infra-estrutura
estrutura e
dados nos principais processos de
negócio.
negócio
 Portanto, ajuda uma empresa a articular

Portanto
a forma de como competir numa
economia digital e orienta as decisões
diárias dos gestores a concretizar as
suas visões de sucesso.
ARQUITECTURA É…
 Metodologias & Frameworks
 Gestão de Meta-dados
 Governance & Standards
 Serviços & Recursos
 Pl
Planeamentot de
d IT
IT, Gestão
G tã
de Projectos e de
Portfólio
 Modelação
 etc…
Definição de Arquitectura de SI / TI
 Arquitectura
q é o conjunto
j de artefactos de desenho,, ou
representações descritivas que são relevantes para a
descrição de um objecto de forma que possa ser produzido
q
de acordo com os requisitos (qualidade)
(q ) bem como mantido
ao longo do seu tempo útil de vida (mudança).
 [Arquitectura da Empresa] é o conjunto de representações

descritivas ( modelos) que são relevantes para a descrição
de uma empresa de forma que possa ser produzida de
acordo com os requisitos de gestão (qualidade) e mantida
ao longo do seu tempo útil de vida (mudança).
 Arquitectura da Empresa ou dos SI / TI?
 AMBAS : A arquitectura de entidades e processos vistas

quer na perspectiva do negócio, quer na perspectiva dos
sistemas
i e Tecnologias
T l i informação.
i f ã
Definição de Arquitectura Empresarial
 Arquitectura
Arq itect ra da Empresa é o
esquema (Blueprint) que define o
relacionamento
l i t entre
t os elementos
l t
de tecnologias de informação numa
organização
i ã
 “The enterprise architecture blueprint is
meant to provide sufficient detail to allow the
idea to become a reality when put in the
hands of skilled professionals, must as a
house blueprint does.”
 Uma Arquitectura de Sistemas e tecnologias de
informação é um conjunto logicamente
consistente de pprincípios
p e de componentes,
p ,
nomeadamente Arquitectura de dados, Arquitectura
de aplicações e Arquitectura tecnológica.
 D i d dos
Derivada d requisitos
i it dod negócio
ó i
 Guia a engenharia nas infra-estruturas de sistemas e
tecnologias
g de informação
ç
 É entendida e suportada pela gestão de topo
 Planeamento da Arquitectura da Empresa é o
processo de definição de Arquitecturas par o uso
de informação no suporte do negócio e o plano de
implementação dessas Arquitecturas. Uma
Arquitectura sem plano de implementação acaba
na gaveta.
 A Arquitectura Empresarial identifica os
componentes principais de uma organização e
p
como essas componentes no sistema “nervoso”
da organização funcionam em conjunto para
atingir os objectivos de negócio definidos.
 As componentes
A t incluem
i l pessoal,
l processos ded
negócio, tecnologia, informação financeira e
outros recursos.
 Como é possível ter uma estratégia de CRM viável se não
sabemos onde residem os dados dos nossos clientes?
 Como são equacionados os gastos em tecnologia para
permitir o atingimento dos nossos objectivos estratégicos?
 A nosso organização tem um modelo de processos
operacional?
 Uma boa Arquitectura Empresarial deve responder:
 Às necessidades de negócio e de informação da
organização.
organização
 Nivelar a relação de sinergias entre o Retorno de
Investimento (ROI) e Custo total da posse (TCO).
 A capacidade para suportar a migração do estado corrente
(as-is).
 A capacidade
id d para suportar
t fá
fácilmente
il t a migração
i ã para o
estado futuro desejado.
 Formas de suporte os objectivos de negócio de redução de
custos, melhoria dos serviços operacionais e aumento de
lucros.
 Se uma Arquitectura Empresarial não endereçar os
temas seguintes será mais prejudicial que útil:
 Os dados estão separados da lógica (Funções de Negócio).
 Os princípios de modularidade são observados assegurando que
cada componente na arquitectura empresarial executa apenas uma
ou duas tarefas discretas.
 As funções estão separadas em tarefas diferenciadas que são
genéricas e bem delimitadas
 A arquitectura está auto-documentada. De contrário algo está
errado!
d !
 Todos os dados e artefactos gerados por uma organização são
geridos e mantidos pela mesma organização.
 A arquitectura
it t é exequível
í l técnicamente
té i t e pode
d ser iimplementada
l t d
a um custo e período de tempo razoáveis.
 A arquitectura pode ser “traceable” desde o requisito de negócio
até à implementação tecnológica
tecnológica.
 A Arquitectura Lógica está separada da arquitectura Física.
Arquitectura
p
(ASE)

Programa
1. Introdução
q de
3
6
SWOT. Modelos
BCG e de Porter
A li
Aplicacional
i l
Estudo.
4ª Sessão
4 Sessão:: Fundamentos
 Modelo de Arquitectura Empresarial
 Aplicação da Arquitectura da Empresa
 Implementação
p ç da Arquitectura
q da
Empresa
 Ferramentas de Arquitectura
q
Empresarial
Modelo de Arquitectura Empresarial
 “Meta-Architecture”
 Concentração centrada nas decisões de alto-nível que
influenciam a estrutura do sistema
sistema. A selecção e
compromissos são efectuados aqui.
 “Architecture”
 Definição da estrutura, relações, vistas, pressupostos e
criação de regras para o sistema.
 “G id li
“Guidelines”
”
 Criação de modelos, manuais, modelos e utilização do
desenho de padrões para o sistema.
sistema Neste nível são
utilizados os frameworks e standards. É fornecida
orientação aos engenheiros para que a integridade seja
mantida é feita aqui
aqui.
 “Software Architecture”
 A Arquitectura de Software de um sistema ou programa é a
estrutura ou estruturas do sistema, que inclui as
componentes do software, propriedades visíveis
externamente desses componentes e as relações entre
elas. “Software Archtecture in Practice, Len Bass, Paul Clements and Rick Kazman,
Addison-Wesley
Addison Wesley, 1997.
1997 ”
 A Arquitectura é o conjunto de decisões importantes acerca da
organização dos sistemas de software, selecção dos elementos
estruturais constituintes e seus interfaces
interfaces, em conjunto com o seu
cumprimento das especificações. “The UML Modeling language user Guide,
Booch, Jacobsen, Rumbaugh, Addison-Wesley, 1999.”
 A Arquitectura de Software é um conjunto de conceitos e decisões
de desenho acerca da estrutura e textura do software que devem
ser feitas antes da engenharia para permitir uma satisfação
efectiva dos requisitos funcionais e outros relevantes da
arquitectura. “Software Archtecture for Product Families: Principles and Practice,
Mehdi Jazayeri, Alexander Ran, Frank van der Linden, Addison-Wesley, 2000.”
 “Systems
y Architecture”
 Alinhada com os objectivos de negócio da organização.
 Processo e disciplina para produzir sistemas de informação
eficientes e eficazes, tem típicamente os seguintes níveis
 Business
 Information
 Operational
 Organizational
g
 Architectural
 Infastructural
 Legacy Application
 Client/Server Architecture
 Thi Cli t A
Thin-Client Architecture
hit t
 3 Tier Architecture
Aplicação
da Arquitectura da Empresa
Quando utilizamos uma AE?
 As E
A Empresas usam-nas todos
t d os
dias!
 Gestão da mudança
◦ Planeamento Estratégico
◦ Análise de Requisitos
◦ Estimativa de Custo & Calendário
◦ Satisfação dos Regulamentos &
Certificação
◦ Relatório de Planeamento alargado das
Empresas
◦ Partilha do Conhecimento
Como utilizar uma AE documentada?
 Operações do Dia a Dia & Gestão
 Criação de uma Gestão da Estratégia de
Evolução
◦ Alteração de processos
◦ Alteração do Sistema & Tecnologia
 Planeamento Táctico
◦ Requisito de validação para os projectos
◦ Seguimento dos processos, sistema, e tecnologia
◦ Análise & Gestão do Risco
 Monitorização
M it i ã do
d respeito
it pelos
l
Regulamentos & Reporting
 Fusões & Aquisições: avaliação do parceiro à
luz dos objectivos definidos para a aquisição
Quem pode beneficiar disso?
 Proprietários: para a compreensão do
funcionamento de toda a Empresap
 Business leaders: para definir
ç
orientações
 Planeadores: para a estratégia &
planeamento táctico
 Gestores: para gestão dos riscos,
custos prioridades e fitas do tempo
custos,
 Implementadores: para avaliação de
alternativas e atingir objectivos
Implementação
da Arquitectura de Empresa
Porque necessitamos de uma Arquitectura
Empresarial
p ((AE)?
)
 Razões de ordem Legal / Regulamentar
◦ Nos EUA
EUA, de acordo com o Clinger
Clinger-Cohen
Cohen act
act,
todos os projectos do Gov. federal necessitam
de uma Arquitectura Empresarial.
◦ AE pode ajudar a satisfazer os requisitos de
certificação.
◦ I tit i õ financeiras
Instituições fi i podem
d utilizar
tili AE para
a gestão do risco operacional.
 Planeamento da Estratégia de IT
 Gestão da mudança na Empresa
 Análise / mitigação do risco operacional
Porque necessitamos de uma Arquitectura
Empresarial
p ((AE)?
)
 Crescimento da Empresa
 Optimização
p ç Processos
 Nova Linha de negócio
 Mudança de actividade
 Optimização de tecnologias
 Obtenção de certificações (Qualidade,
Ambiente, SOX, etc.)
 Criação
ç de uma nova empresa
p
 Optimização de custos (Tecnologias,
Aplicações,
p ç , Operacionais,
p , …))
 Internacionalização
 Aquisição ou fusão empresas
Quando necessitamos de uma AE?
 Em todos os momentos
 Quanto mais cedo melhor
 Em alternativa:
a te at a
◦ “Tentativa e Erro…”
◦ “Destr ir e Constr
“Destruir Construir
ir de no
novo
o …””
O Processo de Enterprise Architecture
 Documentara base de trabalho: “the
the as
as-is
is
state”
◦ Oqque temos: Recursos Físicos,, Intelectuais e
Dados
◦ Como fazemos as coisas: Funções & Processos
◦ Onde: localização física e lógica associada com os
processos
◦ Quem: Papéis,
Papéis organizações & pessoas
associadas com os processos
 Perceber a razão para a mudança: drivers,
estratégias & fitas do tempo.
 Design do estado Futuro
 Identificar gaps & criar uma estratégia de
migração
Ferramentas de Enterprise Architecture
 Knowledge Collection
◦ Bases de Dados, Word, Groupware
 Portfolio de recursos de conhecimento
◦ Popkin, Troux etc.
 Ferramentas de Modelação de Processos
◦ Powerdesigner, IDS-Scheer Aris, Visio, Ultimus, etc.
 Ferramentas de Análise & Traceability
y
◦ Excel, Popkin, minitab etc.
 Ferramentas de Comunicação
◦ E-mail, Websites, Powerpoint etc.
Quem deve ser envolvido na definição?
 Gestores / executantes Seniores,

tanto na área de IT como negócio
 Responsáveis pelo planeamento
estratégico
 Especialistas da melhoria dos
processos
 Gestores da área Tecnológica
Arquitectura
p
(ASE)

Empresariais
4. M d l d
Modelos de A
Arquitecturas
it t
6
SWOT. Modelos
BCG e de Porter
7. Análise,, Gestão e Planeamento de Portfólio
Aplicacional
Estudo.
5ª Sessão:
Sessão: Fundamentos da Arquitectura
de Empresa
 Arquitectura de Quê?
 O que se Diz
Di sobre
b aAArquitectura
i d
da E
Empresa
 O Porquê da Arquitectura da Empresa.
 Perspectiva Histórica.
 Actividades de desenvolvimento de SI
Arquitectura de Quê ?
O que se Diz sobre a Arquitectura
 Fad
F d surfing
fi é andar
d
na crista da última
onda da gestão.
gestão
Saindo a tempo de
apanhar a onda
seguinte, uma tarefa
absorvente p para os
gestores, lucrativa
para os consultores
e desastrosa para as
empresas.
 Flexibilidade crescente e redução dos
tempos de chegada ao mercado não vão
acontecer por acidente, através da
aquisição de mais tecnologia, de mais um
pacote ou da implementação de mais uma
aplicação. Isto só vai acontecer devido a
um investimento intelectual responsável.
 Neste caso, um investimento no

desenvolvimento e manutenção da
Arquitectura da Empresa, para fornecer
informação
ç de qqualidade, p
para produzir,
p
de facto uma empresa de qualidade.
 Com o crescente
C t ttamanhoh e complexidade
l id d na
implementação de S.I., é necessário usar
algum
g construtor lógico
g (arquitectura)
( q )ppara
definir e controlar as interfaces e a
integração de todas as componentes do
sistema.
sistema
 Descentralização sem estrutura é o caos.
Portanto para evitar a desintegração do
Portanto,
negócio, o conceito de arquitectura de
sistemas de informação está a tornar-se já
não numa opção mas uma necessidade para
estabelecer alguma ordem e controlo nos
investimentos em recursos de sistemas de
informação.
 Ela fornece
El f uma taxonomia
t i para
relacionar conceitos que descrevem o
mundo real com conceitos q que descrevem
os sistemas de informação e a sua
implementação.
 A única forma que uma organização tem
para gerir informação estratégica, é
implementar Sistemas de Informação
Informação,
interoperáveis e estabelecer uma
verdadeira ppartilha de dados e através da
utilização de uma Arquitectura de
Informação da Empresa
 Perda de Infra-estrutura:
Oqque falta quando
q
soluções isoladas
deixam de ser
suficientes
fi i para
concretizar as tarefas.
Resumo
 Possibilidade de obter informação
estratégica, sistemas de informação
integrados e partilha de dados.
 Diminuição do time to market, encurtando
o tempo
t necessário
á i para reflectir
fl ti nos Sist
Si t
Inf as mudanças operadas ou desejadas
g
nos negócios.
 Integração das áreas funcionais e dos
recursos da empresa, através da
integração dos sistemas de informação
informação.
 Coordenação dos vários projectos de
sistemas e tecnologias de informação e
dos vários intervenientes nesses
projectos.
O Porquê da Arquitectura
 Produtos de engenharia
complexos;
Olhemos para  P d t construídos
Produtos t íd
peça a peça,
outros produtos … componente a
componente, e que,
quando tudo se junta,
voam ;
“voam”;
 Produtos que persistem
décadas após décadas,
num ambiente
extremamente
dinâmico, com
alterações no mercado
e nas tecnologias.
Perspectiva Histórica
Perspectiva Histórica
Actividades de Desenvolvimento de SI
U ifi
Unificação
ã
 O Backlog de sistemas multi-departamento aumentou.
 Os custos de manutenção aumentaram
 Os problemas de redundância de dados continuaram
 Os problemas de integração de dados pioraram
 As promessas de reutilização não se verificaram.
 As necessidade dos negócios continuaram a não
serem respondidas a tempo
 O potencial das novas tecnologias não era totalmente
explorado.
 Sistemas distribuídos: descentralização sem estrutura é o caos
 Sistemas de Gestão de Base de dados: em vez de duplicação de
p ç de base de dados.
ficheiros, duplicação
 Dicionário de Dados : Impossível de implementar sem algum tipo
de autoridade central
p ç dos custos
Decomposição
p ç dos custos
Decomposição
Engenharia de Requisitos
Engenharia de Requisitos
 A manutenção consume recursos
elevadíssimos (67% total).
 Investe-se muito pouco na definição de

requisitos (2% total)
total). Como
consequência quase metade dos custos
de manutenção (45% total) devem
devem-se
se a
alterações de requisitos.
 Quanto mais tarde se descobrem os
defeitos mais caro é corrigi-los.
(ASE)

Empresariais
4. Modelos de Arquitecturas
Aplicacional
BCG e de Porter
Estudo.
6ª Sessão: Enquadramento dos sistemas de
informação no Negócio Global actual.
Sistemas de Informação, Estratégia e
Organização.
Management Information Systems
Chapter 1 Information Systems in Global Business Today
O papel dos Sistemas de Informação no Negócio actualmente
• Como os sistemas de informação estão a

transformar o negócio
• Incremento da utilização de tecnologia sem fios, Sites
Web
• Shifts in media and advertising
• Novas leis comunitárias e and accounting laws
• Globalization opportunities
• Internet has drastically reduced costs of operating on
global scale
• Presents both challenges and opportunities
Information Systems in Global Business Today
The Role of Information Systems in Business Today
 Growing interdependence between ability to use

information technology and ability to implement
corporate strategies and achieve corporate goals
 Business firms invest heavily in information

systems to achieve six strategic business
objectives:
◦ Operational excellence
◦ New products, services, and business models
◦ Customer and supplier intimacy
◦ Improved decision making
◦ Competitive advantage
◦ Survival
INTERDEPENDENCE BETWEEN ORGANIZATIONS AND
INFORMATION SYSTEMS
 There is a growing interdependence between a firm’s information

systems and its business capabilities. Changes in strategy, rules,
and business processes increasingly require changes in
hardware, software, databases, and telecommunications. Often,
what the organization would like to do depends on what its
systems will permit it to do.
Perspectives on Information Systems
 Information system: Three

activities produce information
organizations need
◦ Input: Captures raw data from
organization or external environment
◦ Processing: Converts raw data into
meaningful form
◦ Output: Transfers processed
information to people or activities that
use it
Perspectives on Information Systems
 Information system:
◦ Set of interrelated components
◦ Collect, process, store, and distribute
information
◦ Support decision making, coordination, and
control
 Information vs. data
◦ Data are streams of raw facts
◦ Information is data shaped into meaningful
form
FUNCTIONS OF AN INFORMATION SYSTEM
 Feedback:
◦ Output returned to appropriate members of
organization to help evaluate or correct input
stage
 Computer/Computer program vs.
information system
◦ Computers and software are technical
foundation and tools, similar to the material
and tools used to build a house
FUNCTIONS OF AN INFORMATION SYSTEM
 An information system contains information about an organization and its

surrounding environment. Three basic activities—input, processing, and
output—produce the information organizations need. Feedback is output
returned to appropriate people or activities in the organization to evaluate
and refine the input. Environmental actors, such as customers, suppliers,
competitors, stockholders, and regulatory agencies, interact with the
organization and its information systems.
Levels in a Firm
Business organizations are hierarchies consisting of three principal

levels: senior management, middle management, and operational
management. Information systems serve each of these levels.
Scientists and knowledge workers often work with middle management.
TYPES OF INFORMATION SYSTEMS
KIND OF SYSTEM GROUPS SERVED
STRATEGIC LEVEL SENIOR
MANAGERS
MANAGEMENT LEVEL MIDDLE

MANAGERS
KNOWLEDGE LEVEL KNOWLEDGE &

DATA WORKERS
OPERATIONAL OPERATIONAL
LEVEL MANAGERS
SALES & MANUFACTURING FINANCE ACCOUNTING HUMAN

MARKETING RESOURCES
MAJOR TYPES OF SYSTEMS
 EXECUTIVE SUPPORT SYSTEMS (ESS)
 DECISION SUPPORT SYSTEMS (DSS)
 MANAGEMENT INFORMATION SYSTEMS (MIS)
 KNOWLEDGE WORK SYSTEMS (KWS)
 OFFICE AUTOMATION SYSTEMS (OAS)
 TRANSACTION PROCESSING
SYSTEMS (TPS)
*
Global E-Business: How Businesses Use Information Systems
Types of Business Information Systems
 Transaction processing systems

◦ Perform and record daily routine transactions
necessary to conduct business
 Examples: sales order entry, payroll, shipping
◦ Allow managers to monitor status of operations
and relations with external environment
◦ Serve operational levels
◦ Serve predefined, structured goals and decision
making
 Decision support systems

◦ Serve middle management
◦ Support nonroutine decision making
 Example: What is impact on production schedule if
December sales doubled?
◦ Often use external information as well from TPS
and MIS
◦ Model driven DSS
 Voyage-estimating systems
◦ Data driven DSS
 Intrawest’s marketing analysis systems
 Executive support systems

◦ Support senior management
◦ Address nonroutine decisions requiring judgment,
evaluation, and insight
◦ Incorporate data about external events (e.g. new
tax laws or competitors) as well as summarized
information from internal MIS and DSS
◦ Example: ESS that provides minute-to-minute view
of firm’s financial performance as measured by
working capital, accounts receivable, accounts
payable, cash flow, and inventory
Systems That Span the Enterprise
• Knowledge management systems

• Support processes for acquiring, creating, storing,
distributing, applying, integrating knowledge
• Collect internal knowledge and link to external
knowledge
• Include enterprise-wide systems for:
• Managing documents, graphics and other digital
knowledge objects
• Directories of employees with expertise
BUSINESS PROCESSES AND INFORMATION
SYSTEMS
 Examples of functional business

processes
◦ Manufacturing and production
 Assembling the product
◦ Sales and marketing
 Identifying customers
◦ Finance and accounting
 Creating financial statements
◦ Human resources
 Hiring employees
THE ORDER FULFILLMENT PROCESS
 Fulfilling a customer order involves a complex set of

steps that requires the close coordination of the
sales, accounting, and manufacturing functions.
TYPES OF BUSINESS INFORMATION
SYSTEMS
 Management information systems

◦ Serve middle management
◦ Provide reports on firm’s current
performance, based on data from TPS
◦ Provide answers to routine questions with
predefined procedure for answering them
◦ Typically have little analytic capability
TPS DATA FOR MIS APPLICATIONS
 In the system illustrated by this diagram, three TPS

supply summarized transaction data to the MIS
reporting system at the end of the time period.
Managers gain access to the organizational data
through the MIS, which provides them with the
appropriate reports.
TYPES OF SYSTEMS IN THE ENTERPRISE
• Enterprise applications
• Span functional areas
• Execute business processes across firm
• Include all levels of management
• Four major applications:
• Enterprise systems
• Supply chain management systems
• Customer relationship management systems
• Knowledge management systems
TYPES OF SYSTEMS IN THE ENTERPRISE
• Enterprise systems
• Collects data from different firm functions and stores
data in single central data repository
• Resolves problem of fragmented, redundant data
sets and systems
• Enable:
• Coordination of daily activities
• Efficient response to customer orders
(production, inventory)
• Provide valuable information for improving
management decision making
 Enterprise Systems (ERP)
 Supply Chain Management Systems (SCM) &
Logistics
 Customer Relationship Management Systems (CRM)
 Knowledge Management Systems & Office
Automation
 DW/ BI Data Warehouse / Business Intelligence
 Billing & Interconnection
SYSTEMS
• Supply chain management systems

• Manage firm’s relationships with suppliers
• Share information about
• Orders, production, inventory levels, delivery
of products and services
• Goal: Right amount of products to destination
with least amount of time and lowest cost
SUPPLY-CHAIN MANAGEMENT
Customer orders, shipping notifications, optimized shipping

plans, and other supply chain information flow among Haworth’s
Warehouse Management System (WMS), Transportation
Management System (TMS), and its back-end corporate systems.
SUPPLY-CHAIN MANAGEMENT
ORDER PLANNING &

CUSTOMERS PROCESSING FORECASTING SUPPLIERS
PROCUREMENT
ACCOUNTING INTRANET
PRODUCTION
LOGISTICS
SHIPPING INVENTORY DISTRIBUTORS
SERVICES
SYSTEMS
• Customer relationship management systems:

• Provide information to coordinate all of the
business processes that deal with customers in
sales, marketing, and service to optimize revenue,
customer satisfaction, and customer retention.
• Integrate firm’s customer-related processes and

consolidate customer information from multiple
communication channels
TYPES OF BUSINESS INFORMATION SYSTEMS
Salesforce.com Executive Team Dashboard
Some of the capabilities of salesforce.com, a market-leading provider of

on-demand customer relationship management (CRM) software. CRM
systems integrate information from sales, marketing, and customer
service.
INTERRELATIONSHIPS AMONG SYSTEMS
ESS
MIS DSS
KWS
TPS
OAS
INFO SYSTEMS, LEVELS, DECISIONS
ORGANIZATIONAL LEVEL
TYPE OF
DECISION OPERATIONAL KNOWLEDGE MANAGEMENT STRATEGIC
STRUCTURED ACCOUNTS
RECEIVABLE
ELECTRONIC PRODUCTION
SCHEDULING COST OVERRUNS
TPS
OAS MIS
SEMI- BUDGET
STRUCTURED PREPARATION
PROJECT
SCHEDULING DSS
FACILITY
LOCATION
KWS ESS
UNSTRUCTURED PRODUCT DESIGN NEW PRODUCTS
NEW MARKETS
Organization of the Information Systems Function
There are alternative ways of organizing the information systems

function within the business: within each functional area (A), as a
separate department under central control (B), or represented in each
division of a large multidivisional company but under centralized
control (C).
B: A separate department under central control

C: Represented in each division of a large multidivisional company but

under centralized control
CRM SYSTEMS ARCHITECTURE CM Resource
Sales Management
Management
Channel
Sales Force Automation Shop System Management CM Resource
System System Management
System
Contact Channel Management CM Reporting

System
Document
IVR WEB SIP SMS MMS E-Mail FAX IM Mobile SLA and Quality
Voice Handling
Management
System
Contact Channels Management System SLA and
Quality
Management
Campaigns System Customer Management System

Customer Contact
One-to-one Product Contract Order Customer Management Risk and Credit
Relationship Catalog Management Capture Incentive Management
One-to-one
System
Management Field Service
Management
Risk and Credit
Managementt
Customer BPM & Integration System

Process Integration Order Fulfillment Business Process Management
Loyalty Trouble Knowledge Management

Campaign Planning System Fraud Management
Management Management
System
System System Knowledge
Document
Campaign Loyalty Fraud Trouble Management Management
Management Program Management Management System System
Management
IVR Arquitecture
SS#7
REDE M o dem B ank
TELEFÓNICA
PBX
RDIS Linhas
Analógicas
ou Digitais Link
CTI
TCP/IP
IVR IVR
SERVER SERVER
TCP/IP
Telefone
Interaction CTI Sever

Middleware
Database
Telefone
Aplicação CTI /
Aplicação
Firewall/Secure Network Arquitecture
Internal
Network
Internet Ultra-
Internet Secure Server
APPL 1
Windows Request Request

Windows
Windows
NT Servers Request
NT Servers
NT Web
Servers APPL 2
"Safe"
DMZ
Middleware
Server
Application
Web
Server
Appl
Server
Application
Gateway GLOBAL DB
Request Appl
Server Server
Web Servers Appl

Server
LDAP
Internet DB
7ª Sessão: Sistemas de Informação, e
Normas (Melhores Práticas).
Modelos de Arquitecturas
SI e Normas (Melhores Práticas)
Governação
ISO 17799 –
CobiT –
Procedimentos
Alinhamento com
de segurança
missão e
e riscos da TI
estratégias da
Clientes empresa (vertical)
< Custos
< Riscos
> Resultados
Utilizadores (Internos)
Depto. TI
Gestão de Serviços
ITIL – Alinhamento Information Technology Infrastructure Library
organizacional Promover a gestão com foco no cliente e na qualidade
(Processos de dos serviços de tecnologia da informação. Standard “de
Negócios) facto ” Gestão de Serviços de TI (Processos). 39
ITIL – Information Technology Infrastructure
Library
• Conjunto de melhores práticas, que tem como
objectivo o de definir as regras de utilização
responsável e eficiente dos recursos de
Tecnologias de Informação e tem vindo a
assumir nos últimos anos um grande
protagonismo, na medida em que a utilização
dos sistemas, tecnologias de informação e
comunicação é cada vez mais um suporte
crítico das organizações.
Library
A ITIL assenta essencialmente na gestão de
serviços de TI, cujos objectivos são:
• Alinhar os serviços de TI com as necessidades
actuais e futuras das organizações e dos seus
clientes e fornecedores;
• Melhorar a qualidade dos serviços de TI
fornecidos;
• Reduzir, a longo prazo, o custo inerente à
Disponibilização de Serviços de TI.
• Garantir a continuidade e disponibilidade de
serviços.
Library
Muitas organizações, públicas e privadas,
contribuem com o seu conhecimento e experiência,
de uma ou outra forma para o desenvolvimento dos
processos ITIL que tem evoluído e sofrendo
actualizações constantes, primeiro pelo dono do
processo, Office of Government Commerce (OGC)
e ultimamente e na maior parte pelo IT Service
Management Fórum (itSMF ). itSMF é um fórum
público presente em muitos países com o objectivo
principal de divulgar, recolher e publicar a melhores
práticas para gestão de Sistemas de Informação e
torná-las de domínio público.
Library
Library
Service Support
• Configuration Managment
• *Service Desk
• Incident Managment
• Problem Managment
• Change Managment
• Release Managment
*Não se trata de um processo mas de uma função

Library
Service Delivery
• Capacity Managment
• Service Level Managment
• Availability Managment
• Financial Managment for IT Services
• IT Service Continuity Managment
Library – V 3.0
Library V3.0
Framework ITIL
• Compreende 5 publicações directamente
relacionadas com os estágios do ciclo de
vida de um serviço, são elas :
• Service Strategy
• Service Design
• Service Transition
• Service Operation
• Continual Service Improvment
Library
Referências
• Foundations of IT Service Management based
on ITIL – publicação da ITSMF
• ITIL Essentials for IT Service Management -EXIN
• www.itil.co.uk
• www.itil.org
• www.itsmf.com
• www.itilcommunity.com
• http://www.ogc.gov.uk/
O NOVO FOCO
A Internet
Fornecedores e Outros Parceiros da Empresa Fronteira da
Empresa
Administração da Cadeia de Suprimentos
Compras, Distribuição, e Logística
Extranets
Fabricação
Engenharia & Contabilidade
e
Pesquisa e Finanças
Produção
Intranets
Gerenciamento da Relação com o Cliente
Marketing Vendas Atendimento ao Cliente
Extranets
Consumidores e Clientes da Empresa
O DESAFIO DOS S.I.
1. Alinhamento Estratégico
2. Modelo de Negócios
3. Carteira de Aplicações
4. Arquitectura Informação
5. TCO e ROI
Resumo
Empresariais
4. Modelos de Arquitecturas.
Aplicacional
BCG e de Porter
Estudo.
8ª Sessão: Enterprise Framework Architectures
1. Enterprise, segment, and solution
architecture - different business
perspectives by varying the level of
detail and addressing related but
distinct concerns.
1. E.A. – Identificação de bens comuns ou partilhados (estratégias,
processos de negócio, investimentos, dados, sistemas ou
tecnologias). Orientado pela estratégia;
2. Segment A. – Define vias simples para áreas de missão crítica,
serviços de negócio ou da empresa. Orientado pela gestão de
negócio, entrega produtos que melhoram a entrega de serviços.
3. Solution A. – Define os Bens (aplicações ou componentes
utilizados para automatizar e melhorar as funções de negócio
individuais). Projecto Simples – implementa uma solução de
negócio parcial ou totalmente.
4. Solution architecture - Relacionada com segment architecture e
enterprise architecture através de definições e restrições.
1. Zachman Framework – A “framework architecture” mais amplamente
utilizada, baseada no trabalho de John Zachman (IBM - 1980s).
2. EAP e FEAF – Derivaram do framework de Zachman – Primitivas e
Dados.
3. DODAF – Framework Architecture do Departamento Defesa EUA
4. UML – Define muitos “Visual Artifacts”
5. “The Open Group Architecture Framework (TOGAF) - Fornece um
método compreensivo para desenhar, planear, implementar e gerir
uma arquitectura de Informação da Empresa.
6. IAF - Integrated Architecture Framework, from Capgemini company
7. MODAF - The UK Ministry of Defence Architecture Framework
8. RM-ODP -- The Reference Model of Open Distributed Processing (ITU-
T Rec. X.901-X.904 | ISO/IEC 10746) defines an enterprise
architecture framework for structuring the specifications of open
distributed systems.
Enterprise Framework Architecture
1. Foundational Research
2. Zachman Framework - The most widely used architecture framework,
based on the work of John Zachman at IBM in the 1980s.
3. PRISM Architecture Framework - First EA ("Partnership for Research in
Information Systems Management").
4. Commercial frameworks
5. TOGAF - The Open Group Architecture Framework, which also defines
a method.
6. IAF - Integrated Architecture Framework, from Capgemini company
7. Defense industry frameworks
8. DODAF - the US Department of Defense Architecture Framework
9. MODAF - The UK Ministry of Defence Architecture Framework
10. AGATE - The France DGA Architecture Framework
11. Government frameworks
12. Government Enterprise Architecture, or GEA - Common framework
legislated for use by departments of the Queensland Government.
13. Federal Enterprise Architecture, or FEA - produced by the Office of
Management and Budget for use within the U.S. Government.
14. International standard frameworks
15. RM-ODP -- The Reference Model of Open Distributed Processing (ITU-
T Rec. X.901-X.904 | ISO/IEC 10746) defines an enterprise
architecture framework for structuring the specifications of open
distributed systems.
Os 5 Erros mais Comuns
 Confundir uma lista de produtos, diagramas

e normas com uma arquitectura
 Não derivar a arquitectura dos requisitos
do negócio
 Não ter uma visão do negócio e do papel
das STI com a gestão de topo
 Não adoptar uma abordagem holística e
sistemática no desenvolvimento da
arquitectura
 Tratar a arquitectura como um evento que
ocorre uma vez e não com algo orgânico e
evolutivo.
Sumário
 O que é uma Arquitectura Empresarial
◦ Compreensão das envolventes de uma Arquitectura
◦ Quais são os diferentes tipos de “arquitectos”de IT
◦ O que é um “Arquitecto de Empresa”
 Aplicação de uma Arquitectura de Empresa
◦ Quando é que a utilizamos?
◦ Quem a utiliza?
 Execução de uma Arquitectura de Empresa
◦ Porque é que necessitamos dela?
◦ Quando é que precisamos dela?
◦ Quando é que a iremos utilizar?
◦ Quem deverá ser envolvido neste esforço?
◦ Competências & ferramentas para um “Arquitecto de
Empresa”
(ASE)

1. Introdução à temática das Arquitecturas de
BCG e de Porter
Aplicacional
Estudo.
O Framework de Zachman
 Fundamentos da Arquitectura de
Empresa
 Framework de Zachman
 Desenho da Arquitectura de Empresa
 Arquitectura da Empresa: Obstáculos,
Benefícios Interacções
 Recursos
9ª Sessão: Framework de Zachman
 Motivação.
 Regras.
 Organização.
 Valor do Modelo.
 Produtos complexos
requerem o
desenvolvimento de
muitos e diferentes
planos, plantas, modelos,
esquemas, documentos,
componentes e envolvem
muitas disciplinas com
diferentes pontos de vista.
 Esquema genérico de classificação de
artefactos de desenho, isto é,
representações descritivas, de
qualquer objecto complexo.
 Proposto em 1987:
 A Framework for Information System
Architecture, IBM Systems Journal,
VOL 26 nº3, 1987
 Estendido em 1992:
 Extending and formalizing the
framework for Information System
Architecture, IBM Systems Journal,
VOL 31 nº3, 1992
John Zachman
Motivação
Em 1987, John Zachman, escreveu: “Para evitar que o
negócio se desintegre, o conceito de uma arquitectura dos
sistemas de informação está a tornar-se menos uma opção
e mais uma necessidade. ” Daí em diante, o framework do
Enterprise Architecture de Zachman evoluiu.
Tornou-se o modelo em torno do qual muitas das principais
organizações estão a ver e a comunicar a sua
infraestrutura da informação empresarial. Fornece um
blueprint, ou arquitectura, para a organização actual e
futura da infraestrutura da informação.
O Enterprise Architecture de Zachman representou naquele
tempo um modelo novo para a ver e comunicar as
infraestruturas de informação. Em vez de olhar o processo
como uma série das etapas, organizou-o em torno dos
pontos da vista (perspectivas) desempenhados pelos
vários actores.
Motivação
 Existem várias representações arquitectónicas,
uma para cada actor envolvido no processo.
 Cada arquitectura tem uma natureza diferente,
independentemente do nível de detalhe.
 O mesmo produto pode ser descrito de diferentes
formas, com diferentes propósitos, o que resulta
em vários tipos de representações.
Motivação
 As disciplinas antigas (Arquitectura, Produção)
acumularam um considerável corpo de
conhecimento sobre os produtos, através de uma
gestão disciplinada das suas definições ou
artefactos de desenho.
 Este conhecimento permitiu a sofisticação dos
produtos e a acomodação de elevados ritmos de
mudança.
 Por analogia, para acomodar a sofisticação e a
mudança, as empresas, devem ter uma gestão
disciplinada das definições da empresa e dos
Sistemas de Informação.
Os artefactos organizam-se numa matriz de perspectivas e aspectos

 Proposto no âmbito
dos Sistemas e
Tecnologias de
Informação, embora
fosse claro desde o
início o seu maior
abrangimento.
 Resultou de
analogias com as
disciplinas
tradicionais como a
Arquitectura e a
Produção.
 Cada Linha é uma
VA Enterprise DATA FUNCTION NETWORK PEOPLE TIME MOTIVATION Based on work by
Architecture What How Where Who When Why John A. Zachman
perspectiva. SCOPE Things Im portant
to the Business
Processes
Performed
Business
locations
Important
Organiz ations
Ev ents Signific ant
to the Business
Business Goals
and Strategy
SCOPE
(CONTEXTUAL) (CONTEXTUAL)
Representa a Planner Entity = Class of Function = Class of Node = Major People = Major Time = Major Ends/Means = Planner
Business Thing Business Process Business Locations Organiz ations Business Event Major Business Goals
perspectiva do ENTERPRISE
MODEL
(CONCEPTUAL)
Semantic Model Business Process
Model
Business Logistic s
System
Work Flow Model Master Schedule Business Plan ENTERPRISE
MODEL
(CONCEPTUAL)
sistema do ponto de Owner Ent = Business Entity Proc = Business Process Node = Business Location People = Organization Unit Time = Business Event
Rel = Business Relationship I/O = Business Resources Link = Business Linkage Work = Work Product Cycle = Business Cycle
End = Business Objectiv e
Means = Business Strategy
Owner
SYSTEM MODEL Logical Data Application Distributed System Human Interface Processing Business Rule SYSTEM MODEL
Model Architecture Architecture Architecture Structure Model
vista de um dado (LOGICAL) (LOGICAL)
Designer Ent = Data Entity Proc = Application Function Node = IS Function People = Role Time = System Event End = Structural Assertion Designer
actor TECHNOLOGY
Rel = Data Relationship
Physical Data
Model
I/O = User Views
System
Design
Link = Line Characteristic s Work = Deliv erable
Technology
Architecture
Presentation
Architecture
Cycle = Processing Cycle Means = Action Assertion
Control
Structure
Rule
Design
TECHNOLOGY
MODEL MODEL
(PHYSICAL) (PHYSICAL)
 Cada Coluna é uma Builder Ent = Segment/Table

Rel = Pointer/Key
Proc = Computer Function Node = Hardware/Softw are People = User
I/O = Data Elements /Sets Link = Line Specifications Work = Screen Format
Time = Ex ecute End = Condition
Cycle = Component Cycle Means = Action
Builder
DETAILED Data Program Netw ork Security Timing Rule DETAILED
dimensão. Descreve REPRESENTATIONS Definition

(OUT-OF-CONTEXT)
Architecture Architecture Definition Design REPRESENTATIONS
(OUT-OF-CONTEXT)
Sub-Contractor Ent = Field Proc = Language Statement Node = Addresses People = Identity Time = Interrupt End = Sub-Condition Sub-Contractor
um determinado FUNCTIONING
Rel = Address
Data
I/O = Control Block
Function
Link = Protocols
Netw ork
Work = Job
Organiz ation
Cycle = Machine Cycle
Schedule
Means = Step
Strategy FUNCTIONING
ENTERPRISE ENTERPRISE
aspecto do sistema. Ent = Proc = Node = People = Time = End =

Rel = I/O = Link = Work = Cycle = Means =
DATA FUNCTION NETWORK PEOPLE TIME MOTIVATION
 Cada Célula What How Where Who When Why
descreve um aspecto
do sistema na
perspectiva de
determinado actor.
VA Enterprise DATA FUNCTION NETWORK PEOPLE TIME MOTIVATION Based on work by
Architecture What How Where Who When Why John A. Zachman
SCOPE Things Im portant Processes Business Important Ev ents Signific ant Business Goals SCOPE
(CONTEXTUAL) to the Business Performed locations Organiz ations to the Business and Strategy (CONTEXTUAL)
Planner Entity = Class of Function = Class of Node = Major People = Major Time = Major Ends/Means = Planner
Business Thing Business Process Business Locations Organiz ations Business Event Major Business Goals
ENTERPRISE Semantic Model Business Process Business Logistic s Work Flow Model Master Schedule Business Plan ENTERPRISE
MODEL Model System MODEL
(CONCEPTUAL) (CONCEPTUAL)
Owner Ent = Business Entity Proc = Business Process Node = Business Location People = Organization Unit Time = Business Event End = Business Objectiv e Owner
Rel = Business Relationship I/O = Business Resources Link = Business Linkage Work = Work Product Cycle = Business Cycle Means = Business Strategy
SYSTEM MODEL Logical Data Application Distributed System Human Interface Processing Business Rule SYSTEM MODEL
(LOGICAL) Model Architecture Architecture Architecture Structure Model (LOGICAL)
Designer Ent = Data Entity Proc = Application Function Node = IS Function People = Role Time = System Event End = Structural Assertion Designer
Rel = Data Relationship I/O = User Views Link = Line Characteristic s Work = Deliv erable Cycle = Processing Cycle Means = Action Assertion
TECHNOLOGY Physical Data System Technology Presentation Control Rule TECHNOLOGY
MODEL Model Design Architecture Architecture Structure Design MODEL
(PHYSICAL) (PHYSICAL)
Builder Ent = Segment/Table Proc = Computer Function Node = Hardware/Softw are People = User Time = Ex ecute End = Condition Builder
Rel = Pointer/Key I/O = Data Elements /Sets Link = Line Specifications Work = Screen Format Cycle = Component Cycle Means = Action
DETAILED Data Program Netw ork Security Timing Rule DETAILED
REPRESENTATIONS Definition Architecture Architecture Definition Design REPRESENTATIONS
(OUT-OF-CONTEXT) (OUT-OF-CONTEXT)
Sub-Contractor Ent = Field Proc = Language Statement Node = Addresses People = Identity Time = Interrupt End = Sub-Condition Sub-Contractor
Rel = Address I/O = Control Block Link = Protocols Work = Job Cycle = Machine Cycle Means = Step
FUNCTIONING Data Function Netw ork Organiz ation Schedule Strategy FUNCTIONING
ENTERPRISE ENTERPRISE
Ent = Proc = Node = People = Time = End =

Rel = I/O = Link = Work = Cycle = Means =
DATA FUNCTION NETWORK PEOPLE TIME MOTIVATION
What How Where Who When Why
Regras da Framework de Zachman
 Regra 1:
As colunas não têm ordem Modelo Básico = Entidades e Relações
 Regra 2: Entidade Relação Entidade
Cada coluna tem um modelo

básico simples
 Regra 3:
Modelo básico de cada What How Where Who When Why
coluna é único Contextual Contextual
Conceptual Conceptual
 Regra 4:
Logical Logical
Cada linha representa uma
vista distinta Physical Physical
 Regra 5: As Built As Built
Cada célula é única Functioning Functioning

 Regra 6:
Combinação das células em uma
linha forma uma descrição
completa dessa vista
Regras do Framework
 Todas as dimensões são igualmente importantes. A

sua ordem nas colunas não tem significado.
 Cada dimensão tem um modelo básico.
 Cada perspectiva tem um modelo básico.
 Cada meia-entidade aparece somente numa célula.
 Todas as dimensões são necessárias para a
representação completa de uma dada perspectiva.
 O Framework é recursivo relativamente a
versões e decomposição.
Framework de Zachman
 Linha 1 – Âmbito / Planeador
Requisitos Externos e Drivers
Modelação das Funções de Negócio
 Linha 2 – Modelo da Empresa / Dono
Modelos de Processos de Negócio
 Linha 3 – Modelo do Sistema / Projectista
Modelos Lógicos
Definição de Requisitos
 Linha 4 – Modelo de Tecnologia/Construtor

Modelos Físicos What How Where Who When Why
Definição e Desenvolvimento de 1 Contextual Contextual
Soluções
Linha 5 – Fora-contexto 2

/Subcontratado 3 Logical Logical
Fora-Contexto
4 Physical Physical
Implementação
 Linha 6 – Produto / 5 As Built As Built
Utilizador 6 Functioning Functioning
Produto What How Where Who When Why
Avaliação
Framework de Zachman – Linha 1
Âmbito/Vista de Planeador
Motivação/Why
Requisitos Externos

Missão,visão, metas, e medidas de 
performance relacionados com cada e Drivers
função
 Função/How  Modelação de
Funções negócio de alto nível, lista
processos de negócio
funções de Negócio
 Dados/What
Drivers importantes para o negócio,
classes dados alto nível
relacionados com cada função
 Pessoas/Who 1 Contextual Contextual

Unidades organizacionais,
“Stakeholders” relacionados com cada Conceptual Conceptual
função
Logical Logical
 Rede/Where
Localização das actividades Physical Physical
relacionadas com cada função As Built As Built
 Tempo/When Functioning Functioning

Principais eventos e ciclos
relacionados com cada função What How Where Who When Why
Framework de Zachman Linha 2
Enterprise Model/Owner’s View
 Motivação/Why  Modelos Processo
Objectivos, estratégias, tácticas, políticas, Negócio
procedimentos e standards para cada
processo  Alocação de Funções
 Função/How Negócio
Modelo de Processos de Negócio
 Eliminação de
 Dados/What
Modelo Entidades Dados de sobreposição e
Negócio
ambiguidade de funções
 Pessoas/Who What How Where Who When Why
Organograma, Lista de Papéis e
responsabilidades em cada processo
Contextual Contextual
 Rede/Where 2 Conceptual Conceptual
Modelo da rede do negócio, Logical Logical

localizações relacionados com cada
processo Physical Physical
 Tempo/When As Built As Built

Eventos para cada processo e sequência
de integração e melhorias do processo Functioning Functioning

System Model/Designer’s View
 Motivação/Why
Estratégias do sistema, políticas,
standards e procedimentos associados  Modelos Lógicos
com uma regra do modelo de negócio.
 Gestão Projecto
 Função/How
Representação Lógica de Sistemas  Definição Requisitos
Informação e suas relações
 Dados/What
Modelos lógicos de dados e relações.
 Pessoas/Who
Representação lógica de privilégios de What How Where Who When Why
acesso restringidos por papéis e Contextual Contextual

responsabilidades
 Rede/Where
Representação lógica da arquitectura 3
Logical Logical
distribuída de sistemas para as várias Physical Physical

localizações
As Built As Built
 Tempo/When
Eventos lógicos e suas respostas Functioning Functioning
iniciadas restringidas por eventos What How Where Who When Why
de negócio e suas respostas

Technology Model/Builder’s View
 Motivação/Why
Estratégias tecnológicas, regras negócio  Modelos Físicos
restringidas pelos standards de sistemas
Informação.  Gestão Tecnológica
Função/How

Especificações de aplicações que  Definição e
operam em plataformas particulares de
tecnologia
desenvolvimento
 Dados/What
Tipos de requisitos lógicos de Sistemas de
Gestão de Bases de Dados (SGBDS)
restringidos por modelos lógicos de dados What How Where Who When Why
 Pessoas/Who Contextual Contextual
Especificação de privilégios de
acesso a plataformas e tecnologias
específicas Logical Logical
 Rede/Where
Especificação de dispositivos de rede e 4 Physical Physical
suas relações no interior das fronteiras físicas As Built As Built

Especificação de alertas para responder a
events de sistema em plataformas e
tecnologias específicos
As Built/Integrator’s View
 Motivação/Why
Regras de negócio restringidas por
standards tecnológicos de sistemas de  Fora-contexto
informação
 Função/How  Gestão
Programas codificados para operar
em plataformas específicas de
Configurações
tecnologia  Implementação
 Dados/What
Definições de dados restringidas
por modelos de dados físicos
Pessoas/Who

Privilégios de acesso codificados
Contextual Contextual
para controlar acessos a plataformas Conceptual Conceptual

e tecnologias específicas
Rede/Where
Logical Logical

Dispositivos de rede configurados Physical Physical
para conformidade com

especificações de nós 5 As Built As Built

Definições de tempo codificados para
sequenciar actividades em plataformas What How Where Who When Why
e tecnologias específicas
Functioning Enterprise/User’s View
 Motivação/Why
Características Operativas de tecnologias  Funcionamento da
específicas restringidas pelos standards
Empresa
 Função/How
Instruções de funcionamento  Gestão de
do computador
Operações
 Dados/What
Valores de dados armazenados  Avaliação
em bases de dados actuais
 Pessoas/Who What How Where Who When Why
Pessoal VA e stakeholders chave Contextual Contextual
trabalhando nos seus papéis e

responsabilidades Conceptual Conceptual
Logical Logical
 Rede/Where
Envio e recepção de mensagens Physical Physical
Integrated Integrated
 Tempo/When
Definições de operações temporais 6 Functioning Functioning
para sequência de actividades What How Where Who When Why

Portal do Framework Zachman
 Em todas as estruturas complexas,
existem 6 perspectivas abstractas
 Em cada perspectiva existem 6 aspectos fundamentais
O Valor do Framework
 Simples : Fácil de entender,
não técnico, puramente lógico
 Abrangente : Aborda a
empresa e os seus S.I’s no
seu todo. Qualquer questão
pode ser posicionada no
Framework
 Linguagem : Ajuda a pensar
e comunicar conceitos
complexos
 Resolução de problemas :
Permite isolar variáveis sem
perder a noção da contexto.
 Neutral : Independentemente
de ferramentas e métodos.
 Suporta Arquitectura
 Suporta o alinhamento
Negócio - Sistemas de
Informação
 Acomoda vários
actores (stakeholders)
10ª Sessão: Framework de Zachman
 Desenho Arquitectura.
 Fases Projecto.
 Ferramentas Modelação.
Desenho da Arquitectura da Empresa
 Fases do Projecto
Iniciação Nível 1 : Início
Planning Initiation Level 1: Getting Started
Tecnologias e
Modelo de
Sistemas Actuais Nível 2 . Situação Actual
Negócio
Current Sy stems & Level 2: Where We Are Today
Business Modeling
Technology
Arquitectura de Arquitectura de Arquitectura

Nível 3 : Situação Futura
Dados Aplicações Tecnológica
Data Architecture Application Architecture Technology Architecture Level 3 : Future Vision
Plano de Implementação / Plano de Migração Nível 4 : Como Chegar Lá

Implementusiation / Migration Plans Level 4 : How to get There
Fase %
Modelo Preliminar do Negocio 7%

Levantamento da Empresa 23%
Tecnologias e sistemas correntes 15%
Arquitectura de dados 15%
Arquitectura de aplicações 15%
Arquitectura Tecnológica 10%
Plano de Implementação 15%
Plano de Arquitectura da Empresa
Iniciação Nível 1 : Início

Planning Initiation Level 1: Getting Started
Tecnologias e
Modelo de
Sistemas Actuais Nível 2 . Situação Actual
Negócio
Current Sy stems & Level 2: Where We Are Today
Business Modeling
Technology

Nível 3 : Situação Futura
Data Architecture Application Architecture Technology Architecture Level 3 : Future Vision
Plano de Implementação / Plano de Migração Nível 4 : Como Chegar Lá

Implementusiation / Migration Plans Level 4 : How to get There
Plano de Arquitectura da Empresa
Níveis 1 e 2 – Início e Situação actual
◦ Início: Planeamento da
equipa, Âmbito, Objectivos,
Visão, Metodologia e
Ferramentas, Apresentações
e Plano de Trabalho
◦ Modelo de Negócio:
Estrutura da Organização,
Modelo de negócio,
Iniciação
Planning Initiation
Processos de Negócio e
informação de suporte
Tecnologias e ◦ Sumário estratégico
Modelo de
Negócio
Sistemas Actuais Operacional: Definição dos
Current Sy stems &
Business Modeling
Technology
principais business drivers.
◦ Tecnologia e Sistemas
Arquitectura de Arquitectura de Arquitectura Actuais: Situação actual de
Data Architecture Application Architecture Technology Architecture
aplicações e plataformas
tecnológicas.
Plano de Implementação / Plano de Migração
Implementusiation / Migration Plans
Plano de Arquitectura da Empresa Nível 3 –
Situação futura a atingir
◦ Arquitectura de
Dados: Principais
dados do negócio.
◦ Arquitectura de
Aplicações: Principais
Iniciação aplicações necessárias
Planning Initiation para a gestão dos dados
e suporte do negócio.
Modelo de
Tecnologias e
Sistemas Actuais
◦ Arquitectura de
Negócio
Current Sy stems & Tecnologias:
Business Modeling
Technology Plataformas
tecnológicas para
Arquitectura de Arquitectura de Arquitectura suporte das aplicações
Dados Aplicações Tecnológica e caminho de migração.
Data Architecture Application Architecture Technology Architecture

Plano de Arquitectura da Empresa Nível 4 –
Como chegar lá
◦ Plano de
implementação:
Sequência de
implementação das
aplicações.
◦ Conclusão: Relatório e
apresentação final.
◦ Transição para a
Iniciação
Planning Initiation
implementação:
Medidas e iniciativas
organizacionais
Tecnologias e
Modelo de
Sistemas Actuais
insdispensáveis para a
Negócio
Business Modeling
Current Sy stems & realização da
Technology arquitectura. Melhorias
para a organização,
politicas, standards,
Data Architecture Application Architecture Technology Architecture procedimentos e planos
de projecto detalhados.
A Necessidade da Arquitectura Empresarial
Common Processes
Communication
Infrastructure
Alinhamento entre
Governance
Integration
Enterprise Architecture
Negócio e
Requisitos de IT Process
Information
System
Elementos da Arquitectura Empresarial
 Metodologias e Frameworks
 Gestão de Metadata
 Governance e Standards
 Serviços de Consultadoria
 Planeamento de IT
 Gestão de Projecto e de Portfólio
 Modelação
 Etc…
Existem hoje já ferramentas efectivas de

modelação para viabilizar uma A.E.
uma delas é o PowerDesigner 15.0
Os Pilares da Arquitectura Empresarial
Frameworks
◦ Zachman
◦ TOGAF Enterprise Architecture
◦ FEAF
Implementation Models
◦ DoDAF
Architecture Models
Primitive Models
Methodology
Frameworks
Metodologias
◦ Waterfall
◦ Iterative
Modelos Primitivos
◦ Elementos
Modelos de Arquitectura
Process
◦ High-level composites
Information
Modelos de
Implementação System
◦ Low-level composites
Porquê utilizar Frameworks ?
Obter activos principais independentes uns dos
outros
◦ Ser capaz de perceber primeiro um processo
independentemente dos dados ou aplicações
Reduz/Identifica Redundância
◦ Como elementos são categorizados de forma
independente, a duplicação de esforço torna-
se fácilmente aparente
Gerir a complexidade através da normalização
◦ Desagregando sistemas/organizações
complexas nos seus elementos individuais
podemos obter uma percepção comum
Ferramentas de Modelação: Frameworks e
Metodologias – Blocos Constituintes
Objectivo:
◦ Oferecer uma estrutura de artefactos para assegurar
introspection, completeness, and longevidade.
Frameworks :
◦ Outline os artefactos, a estrutura e contexto para
construir software durante o SDLC – (Software
development Life Cycle).
Metodologias :
◦ Outline como utilizar e aplicar as frameworks na
organização para completar o SDLC e produzir
sistemas de software fiáveis, nos prazos e eficazes.
Metodologias descrevem os papéis e como eles se
relacionam para entregar os artefactos outlined
num framework.
Ferramentas de modelação: Tornando um
Framework Realidade
Transformação
◦ Mover-se de um nível abstracção para o nível seguinte
mais detalhado.
◦ No PowerDesigner é efectuado através das funções de
Generate ou Export.
Integração
◦ Juntar as diferentes perspectivas do mesmo nível de
abstracção.
◦ No PowerDesigner é efectuado através das funções the
Export, Traceability Link, ou Extended Dependency
functions
Afinidade
◦ Qualquer intersecção entre quaisquer duas perspectivas
em qualquer nível de abstracção
◦ No PowerDesigner é efectuado através da Dependency
Matrix
Ferramentas de modelação: Como abordar
a AE
Ferver o tanque … não o oceano
◦ Começar com um único domínio ou unidade de
negócios
Top-Down
◦ Iniciar com um elevado nível de abstracção
◦ Terminar com implementação
Middle-Out
◦ Em concerto…
• Elevado nível de abstracção
• Reverse Engineer dos bens correntes
◦ Ligá-los entre si
Bottom Up
◦ Construído através do tratamento dos metadados
correntes.
Ferramentas de modelação: Utilizando um
framework para a AE
Ferver o tanque …não a Oceano
◦ Começar com um único domínio ou unidade de
negócios
Construir fatias de cada ‘Tanque’
◦ À medida que cada fatia está concluída – ligá-los
entre si
Não é necessária a utilização de todas as células
◦ Cada organização deve determinar o que pensa ser
necessário para descrever de forma efectiva a sua
empresa.
A AE é uma Caminhada com Paragens Frequentes
–
Não um Destino
 “Gartner EA Activity Map,” identifica e descreve algumas das
actividades que devem ser coordenadas e integradas. As linhas
orientadoras do plano de trabalhos incluem o desenvolvimento de
procedimentos que incluem esta coordenação e integração.
What’s New in PowerDesigner v15
EA Function Benefit
Models Formally capture all meta data relevant to
traditional EA analysis
Impact Analysis Diagram Easy visualization of impact and lineage

dependencies associated with given set of design
objects.
EA Frameworks Highly customizable support for homemade or

industry standard EA frameworks
Repository Web Viewer Share EA meta data with all stakeholders

independent of technical abilities
Import Visio Capture business level meta data for incorporation

into the complete EA
O que é uma Arquitectura bem sucedida?
 A arquitectura foi terminada
 O plano está a ser concretizado.
 A arquitectura é usada para guiar os novos
desenvolvimentos
 A arquitectura é mantida
 O resultado da arquitectura (derivable) é
accionável em toda a função de sistemas de
informação.
 Os gestores seniores e de linha percebem
como é que a arquitectura suporta o negócio
 As decisões técnicas da arquitectura estão
claramente ligadas aos requisitos de alto
nível do negócio.
(ASE)

3. Enquadramento dos sistemas de
Organização.
6. Gestão Estratégica. Análise SWOT.
Modelos BCG e de Porter
7. Análise, Gestão e Planeamento de
Portfólio Aplicacional
Estudo.
11ª Sessão: Gestão Estratégica
 Gestão de SI
 Estratégias de Gestão.
 Gestão Estratégica.
 Análise SWOT.
Gestão Estratégica - Portfólios Aplicacionais
 A importância de um modelo de gestão
 Conceito de Gestão Estratégica
 Análise Estratégica
 Forças, Fraquezas e Ameaças (Análise SWOT)
 Matriz de Boston
 Cinco Forças Concorrentes (Porter)
 Cadeia de Valor (Porter)
 Alinhamento estratégico Negócio – IT – Modelo de
Venkatraman
 Modelos de Maturidade na gstão de Sistemas de
Informação - Nolan
 Importância Estratégica dos SI – matriz de McFarlan
 Estratégias de gestão de SI (Parson)
 Modelo de gestão de Sistemas de Informação
Quando falta uma estratégia de gestão
de SI
 Perda de controlo das SI/TI
 os utilizadores competem para obter serviço
 Os investimentos não suportam o negócio
 aumento desenfreado de $$
 Os sistemas não estão
integrados
 Não há uma noção de
prioridades
 Falta informação de gestão
 Incapacidade para afectar correctamente os
recursos
 Conflitos latentes entre utilizadores e
informáticos
Sistemas de informação: O cimento
entre o negócio e a tecnologia
Processos de negócio Negócio

Procura de SI
Sistemas de informação SI
Oferta integrada com TI
Tecnologias de informação TI
Gerir os sistemas de informação
(Earl e Sampler)
 Reconhecer o desequilíbrio
 o negócio não está satisfeito
 problemas tecnológicos de gestão
 Enquadrar a oferta
 definir objectivos
 arquitectura tecnológica e de informação (com
prioridades)
 Enquadrar a procura
 visão do negócio
 processo de gestão da procura
 planeamento de acordo com o valor das propostas
 Manter o equilíbrio
 governance
Alinhamento estratégico negócio/SI
 Dado um portfólio de aplicações (futuras)
…
 Como regular a procura de SI?
◦ Planeamento
 Como gerir a oferta de SI/TI?
◦ modelo de gestão
 Como actuar de acordo com a

maturidade da organização?
◦ (ou como amadurecê-la)
Estratégias de gestão dos SI
 Modelo de gestão, precisa-se.
alta direcção
utilizadores profissionais de
sistemas de informação
Conceito de Gestão Estratégica
 O QUE É UMA ESTRATÉGIA?
Uma estratégia é uma proposta de curso de acção,
elaborada antecipadamente, de forma exploratória
mas sustentada, para atingir um fim preciso. Para que
exista uma estratégia é necessário que exista um
objectivo bem identificado que confira
intencionalidade a essa estratégia.
 DOIS TIPOS ESTRATÉGIA

 Estratégias intencionadas – as que os decisores
concebem e procuram seguir.
 Estratégias realizadas – as que se materializam na
prática, em função das oportunidades e restrições que
entretanto surgiram.
O CARÁCTER EMERGENTE DAS ESTRATÉGIAS:
ESTRATÉGIAS INTENCIONADAS E
ESTRATÉGIAS REALIZADAS?
 Componentes das estratégias intencionadas
◦ Finalidades
◦ Políticas e
◦ Planos.
As finalidades estruturam-se hierárquicamente em :
◦ Visão – o que a organização aspira a ser no futuro.
◦ Missão – materialização da visão numa declaração
da missão (mission statement) que exprime a razão
de ser da organização.
◦ Objectivos – finalidades concretas a satisfazer para
atingir o que ficou especificado na declaração de
missão; estruturam-se por sua vez em sucessivos
níveis hierárquicos, cada vez mais restritos.
As políticas expressam as regras gerais que balizam as
acções da organização.
 Asseguraremos os custos mais baixos do mercado.
 Teremos o melhor serviço a clientes do mercado.
 Os nossos serviços cobrirão todo o país.
Os planos exprimem como é que as acções da

organização se estruturam para atingir as diversas
finalidades.
Modelo
 Planeamento estratégico (Strategic Planning). Processo
destinado a :
◦ Determinar e rever as grandes finalidades da organização,
◦ Escolher os recursos a utilizar para as atingir e
◦ Definir políticas para a obtenção e gestão desses recursos.
 Controlo de Gestão (Management Control). Processo

que garante que as acções a realizar concorrem para
atingir os objectivos fixados.
 Controlo Operacional (Operations Control). Processo

que garante a execução das tarefas correspondentes às
actividades da organização e controla em pormenor a
sua boa execução.
Pirâmide das Actividades de Gestão
de uma Organização
ESCOLAS DA GESTÃO ESTRATÉGICA
 ESTRATÉGIAS PRESCRITIVAS :
◦ A estratégia como processo de concepção (SWOT)
◦ A estratégia como processo formal (Ackoff)
◦ A estratégia como processo analítico (Porter).
 ESTRATÉGIAS DESCRITIVAS :
◦ A estratégia como processo visionário (liderança, visão)
◦ A estratégia como processo mental (escolas cognitivas)
◦ A estratégia como processo emergente (aprendizagem)
◦ A estratégia como processo de negociação (Pettigrew)
◦ A estratégia como processo cultural (cognição colectiva)
◦ A estratégia como processo ambiental (contingência)
 ESTRATÉGIAS COMBINADAS :
◦ A estratégia como processo de transformação (Minzerg).
FORÇAS, FRAQUEZAS, OPORTUNIDADES E AMEAÇAS
 Análise SWOT :
 Análise SWOT :
 Competências Chave :
O Quadrante 1 é a posição mais desejável. A empresa encara várias
oportunidades e com forças internas complementares para executar essas
oportunidades. Esta situação suporta estratégias orientadas para o
crescimento para explorar ou capitalizar. As empresas Microsoft e American
Online seguem esta estratégia de desenvolvimento intensivo.
A situação menos favorável é o quadrante 4. A empresa enfrenta muitas
ameaças no meio em que se insere e está numa posição de fraqueza. Esta
situação exige estratégias que reduzam ou redireccionem envolvimento em
produtos ou mercados objecto da análise SWOT. Muitas companhias em
situação insolvente podem ser incluídas neste segmento.
Uma firma no quadrante 2 com forças chave enfrentará um ambiente
desfavorável. As estratégias aqui são utilizar as forças correntes para construir
oportunidades de longo prazo em melhores mercados para o produto.
Empresas de transportes tais como a Companhia Greyhound bus quando
enfrentam ameaças de longa duração tais como aumento da concorrência dos
caminhos de ferro e companhias de aviação e os custos adicionais originados
de serviços não dedicados aos passageiros tais como fretes e serviços
financeiros.
Uma firma no quadrante 3 encontra oportunidades impressionantes e
favoráveis de mercado mas é constrangida pelas fraquezas internas. A
estratégia para esta firma é focar-se na eliminação de fraquezas internas,
assim essas oportunidades podem ser seguidas de forma mais efectiva.
Algumas firmas embarked em estratégias de aquisição para ultrapassar as
fraquezas.
Análise da Situação – Método SWOT
 É um acrónimo para forças e debilidades na empresa e oportunidades e

ameaças que a empresa enfrenta do exterior.
 É um conjunto de técnicas simples e básicas onde os gestores obtêm
uma rápida visão geral da situação estratégica da empresa.
 É baseada na noção de que uma estratégia eficaz deriva de um bom
equilíbrio entre as competências internas da empresa (Forças e
Debilidades) e a sua situação externa (Oportunidades e Ameaças).
 A análise SWOT fornece um meio excelente através do qual os gestores

podem analizar as posições actuais das suas firmas.
 Contudo não detalha de que forma as empresas devem tentar identificar
as forças internas e fraquezas.
 Uma análise funcional onde departamentos como o marketing, sistemas
de informação financeira e operações são examinadas minuciosamente
para determinar as tendências passadas das vendas, custos, lucro e
produtividade.
 Estes resultados são comparados com os standards das indústrias.
 Este método reduz a análise da cadeia de valor - dividindo a empresa
em conjuntos de actividades distintas que acrescentam valor.
Weaknesses
1. Limitation of deficiencies in
Opportunities
resources, skills, or capabilities that
impedes the firm's effective
1. Major favorable situations
performance.
2. Change in competitive or regulatory
2. Poor facilities, management skills
circumstances
and financial resources
3. Technological changes and
3. Weak marketing skills and poor
improved buyer/supplier relationship
brand image
4. Concentration of sales in a few
products or to a few customers.
Strengths
Threats
1. Strength in resources ,skills or
1.Major unfavorable situations in a
other advantages relative to
firm's environment representing
competitors
impediments to the firm's desired
2. Strong financial resources
position
3. Powerful brand image and market
2. The entrance of new competitors
leadership
3. Slow market growth
4. Strong buyer-supplier relationship
4. Technological changes and new
5. Ability to raise long and short term
revised regulations
capital
S = Strengths
W = Weaknesses
O = Opportunities
T = Threats
The SWOT Matrix Explained
All the best management models have four quadrants, and the SWOT matrix
is no exception. You use each of the four quadrants in turn to analyze where
you are now, where you want to be, and then make an action plan to get
there.
A empresa AMT comercializa computadores, actuando num mercado de
dimensão média nos Estados Unidos. Mais tarde foi atingida a sua posição
de negócio sólida, devido ao aumento da concorrência de armazéns de maior
dimensão oferecendo produtos de marcas nacionais locais. Apresenta-se a
análise SWOT efectuada e incluída no seu plano de marketing.
Análise SWOT para a AMT:

12ª Sessão: Gestão Estratégica
 Ciclo de Vida de um produto (Matriz BCG).
 Modelo forças competitivas.
 Cadeia de valor.
Modelo BCG
Matriz BCG(Boston Consulting Group)
 Representa o posicionamento do estado no ciclo de vida de cada
produto oferecido pela empresa.
 Modelo utilizado para análise de portfólio de produtos ou de
unidades de negócio baseado no conceito de ciclo de vida do
produto.
 Para garantir a criação de valor a longo prazo, a empresa deve ter
um portfolio de produtos que contenha tanto mercadorias com
altas taxas de crescimento no mercado (que precisam de
investimentos) e mercadorias com baixo crescimento (que geram
receita).
 A matriz tem duas dimensões: crescimento do produto no
mercado e participação relativa do produto no mercado (que é a
participação da empresa em relação à participação de seu maior
concorrente). Quanto maior a participação de mercado de um
produto ou quanto mais rápido o mercado de um produto cresce,
melhor para a empresa.
Matriz BCG
Ciclo de Vida
Matriz BCG
Matriz BCG
Matriz BCG
Matriz BCG
Matriz BCG
Exemplo Via Verde
Modelos das Forças Competitivas (M. Porter)
Michael Porter defende que uma empresa, para
melhor competir num determinado mercado, deve
decidir a sua estratégia - liderança pelo custo,
diferenciação ou foco - com base no conhecimento
da estrutura da indústria em que a empresa compete
bem como na perfeita identificação dos clientes - alvo.
Porter aponta cinco factores de competitividade
determinantes da estrutura de uma indústria e da
forma como essa estrutura evolui.
São as "cinco forças competitivas": a rivalidade entre

empresas concorrentes, a ameaça de novas
entradas, o poder negocial dos fornecedores, o
poder negocial dos clientes e a ameaça do
aparecimento de produtos ou serviços substitutos.
AS CINCO FORÇAS CONCORRENTES (Porter)
Cadeia de Valor (M. Porter)
CADEIA DE VALOR EXTERNA OU SISTEMA DE VALOR
CADEIA DE VALOR INTERNA
Cadeia de Valor
(ASE)

3. Enquadramento dos sistemas de
Organização.
6. Gestão Estratégica. Análise SWOT.
Modelos BCG e de Porter
7. Análise, Gestão e Planeamento de
Portfólio Aplicacional
Estudo.
13ª Sessão: Análise, Gestão e
Planeamento de Portfólio Aplicacional
 Alinhamento estratégico Negócio - IT – Modelo
de Venkatraman
 Importância Estratégica dos SI – Matriz Mc
Farlan.
Modelo de Venkatraman
 Alinhamento estratégico Negócio - IT
Benefícios de investimentos em Sistemas de
Informação vs nível de mudança para as realizar.
Exploração Localizada
Utilização de SI/TI para automatizar

determinados processos de negócio e
satisfazer as necessidades particulares
de gestão baseado primordialmente
numa aproximação funcional aos
investimentos em SI/TI.
Os benefícios são limitados mas a

alteração ao negócio ou organização
para obter os benefícios são mínimas.
Integração Interna
Envolve a reorganização interna e a
criação de novos papeis e interacção. A
capacidade para definir e implementar as
alterações está inteiramente dentro da
própria empresa.
Redesenho de Processos de Negócio

Envolve o realinhamento das actividades
de negócio para melhorar as relações
com os clientes e fornecedores e
portanto melhorar a performance do
negócio.
Redesenho Relações de Negócio
Envolve a reconsideração de como a

informação é partilhada e utilizada pela
organização e parceiros de negócio.
 Requer novos sistemas de controle de

gestão para monitorizar a performance
destas novas relações.
Redefinição do Alcance do Negócio
Envolve a realização de que baseado nos
níveis anteriormente referidos a
organização pode estender o seu mercado
ou racionalizar as suas actividades para
crescer ou ser mais rentável como parte
da reestruturação da indústria.
Como é óbvio, depende não só na

extensão e qualidade dos seus sistemas
de informação mas também e sobretudo
na visão da gestão para observar novas
oportunidades que podem derivar dos
seus recursos de informação.
Portfólio de Aplicações
Define a procura de SI
risco futuro +
estratégicos exploratórios
Importância
estratégica
dos sistemas
planeados
operacionais suporte
risco actual -
+ -
Importância estratégica
dos sistemas actuais
risco de negócio risco financeiro
Matriz de McFarlan
(Importância Estratégica dos SI)
Aplicações Exploratórias
 Ideias, oportunidades
Aplicação de tecnologia ao negócio
 Não perder tempo
 Tentar provar o potencial estratégico (ou seja $$)
 Tanto em vantagen(s) competitiva(s)
 Como em factores críticos de sucesso
 É como a investigação/inovação
Experimentação controlada
 O resultado não é um sistema em si, mas
conhecimento
 Saber se dá origem a um sistema estratégico ou
operacional
 ou seja, o que fazer a seguir
Aplicações Estratégicas
 Dirigidas aos objectivos e factores
críticos de sucesso
◦ preencher necessidades do mercado
◦ pressão competitiva
 A rapidez é fundamental
◦ Janela de oportunidade, inovação contínua
◦ Moving target: suster a vantagem
 ex: criar continuamente barreiras à entrada
 Perceber como acrescentar valor de forma
diferenciada
◦ Há normalmente uma associação a uma parte do
negócio com grande intensidade de informação
 A ligação ao negócio supera a necessidade de
excelência tecnológica
Aplicações Operacionais
 Fazem o negócio funcionar
 Superam desvantagens competitivas
 Aumentam a performance do negócio
Traduz-se em resultados
 Devem ser integradas
 Para evitar duplicação e inconsistências
de informação
 Com qualidade
 Prioridade à eficácia (integração, rapidez, consistência)
 O investimento tem de ser ponderado
Retorno ligado à eficácia
Utilização eficiente de recursos
 Inovação Defensiva
Aplicações de Suporte
 São as aplicações que temos de ter

Podem ser iguais às dos competidores
 lembrar “do what you do best, outsource the rest”
 São um custo
Deve ser controlado (minimizado)
 olhar para o longo prazo
 Objectivo: eficiência
Funções de suporte ao negócio
 “overhead” mínimo
 Questão:
A ausência representa um risco substancial para
o negócio?
 se não então é de suporte
Matriz de McFarlan
(Importância Estratégica dos SI – VIA VERDE)
14ª Sessão: Análise, Gestão e
Planeamento de Portfólio Aplicacional
 Modelos de Maturidade na Gestão de
Sistemas de Informação - Nolan.
 Estratégias de gestão de SI (Parson)
… ou como adequar a oferta de TI
Modelo de Nolan
maturidade
Importância
estratégica
dos sistemas
planeados
controlo Iniciação
e contágio
-
+ -
Grau de Maturidade (segundo Nolan)
 Os Modelos de Maturidade na Gestão de Sistemas de Informação
 Críticas:
◦ É improvável que o orçamento e a tecnologia sejam os principais
indicadores ou factores de crescimento da maturidade;
◦ É improvável que a despesa em SI siga uma curva em ´S´;
◦ É improvável que uma qualquer organização esteja inteiramente no
mesmo estádio de maturidade relativamente a todos os factores de SI
avaliados;
◦ É improvável que partes diferentes de uma organização estejam no
mesmo estádio de maturidade dentro do mesmo factor;
◦ É improvável que todas as organizações se iniciem no primeiro
estádio;
◦ É improvável que a sequência em direcção à maturidade não tenha
por vezes retrocessos, principalmente nos estádios mais avançados
(e.g., devido a uma mudança de pessoal ou de atitude de gestão);
◦ E é também improvável que não possa saltar estádios (e.g., pela
aquisição de empresas mais maduras)
◦ É insuficiente a atenção dada a aspectos ambientais, sociais,
organizacionais e de gestão;
◦ É baseado em suposições simplistas e associações subjectivas;
 A maturidade é relativa a uma dada
tecnologia
 uma empresa pode ter várias
 A maturidade também é relativa às
diferentes áreas de negócio
 A matriz mais completa tem 6 estágios de
maturidade
 e 3 eixos de análise
 Cada eixo de análise sugere a estratégia
a aplicar
 A organização funciona de forma
diferente em cada estágio
 burocracia, cultura organizacional.
Grau de Maturidade
 1. Iniciação
 os SI são introduzidos para poupar $
 ganhos de eficiência
 preocupação operacional e automatização
 não há visão de longo prazo
 a informática pertence ao dep. financeiro
 pouco interesse dos gestores
 2. Expansão ou contágio
 florescimento inesperado
 sem controlo nem planeamento
 a responsabilidade é delegada nos tecnocratas
 preocupação com a tecnologia
Grau de Maturidade
 3. Formalização
 motivado pelos gastos exacerbados em TI
 é executado através de uma centralização
 e diminuição do número de pessoas dedicadas aos SI
 formalização do planeamento, desenho e
orçamento
 preocupação em poupar dinheiro
 e não em ganhar dinheiro
 burocratização e especialização de funções
 é o estádio das metodologias e do
planeamento formal
 e do característico atraso no desenvolvimento de SI
(o que sugere ser o estádio mais comum)
Grau de Maturidade
 4. Integração (primeiro passo para a
maturidade)
 diminuição dos níveis de controlo
 para encorajar a inovação
 o dep. de informação reorganiza-se para se
aproximar do utilizador e do negócio
 5. Administração de dados (segundo
passo)
 o mais importante é a informação para o negócio
 acesso a informação inter-departamental
 existência da “base de dados” consolidada
 6. Maturidade
 planeamento e gestão estratégica inseridos no do
próprio negócio
Modelo de gestão dos SI
 Encontrar o portfólio de aplicações a gerir
 Para cada grupo do portfólio:
1. quem é responsável e quem participa na procura
de SI
2. como submeter a oferta de SI/TI à procura
3. os mecanismos de coordenação e controlo
alta direcção
utilizadores profissionais de SI
Modelo de Parson
Planeamento Crista da Onda

Centralizado Postura Mercado
Importância
estratégica Monopólio,
Postura de
Recurso
dos sistemas Mercado,
Escasso ou
planeados Postura de
Recurso escasso
ou monopólio
- Mercado
+ -
Estratégias de gestão de SI
ou como adequar a oferta de TI
 Como gerir as oportunidades de

utilização da tecnologia?
 Integrar a oferta de TI na gestão de SI
Estratégias de Parson:
 planeamento centralizado estratégicos
 “na crista da onda” exploratórios
 postura de mercado suporte
 monopólio suporte
operacionais
 recurso escasso suporte

operacionais
 mal necessário
Estratégias de Parson
estratégicos
1. Planeamento Centralizado
 Envolvimento coordenado dos gestores do
negócio
 liderança com coordenação centralizada (daí o
nome)
 O significado estratégico dos Sistemas de
Informação tem de estar bem percebido
 Postura proactiva do utilizador para explorar
convenientemente o potencial dos SI
 Prestação de serviços, em sintonia com o
utilizador final, para preencher os objectivos do
negócio
 ATENÇÃO: planeamento centralizado é diferente
de controlo centralizado ou centralização
suporte
operacionais
2. Monopólio
 Quando a informação é um activo
 Controlo centralizado do departamento de
informação
 o utilizador pede de serviços a um só fornecedor
 para standardizar e integrar as soluções com custos
controlados
 o utilizador aceita (ou é obrigado a aceitar) o controlo
 o departamento de SI tem de prever a procura
 As prioridades têm de ser definidas pela alta
direcção
 porque o óptimo global não é a soma dos óptimos locais
 Postura reactiva do departamento de SI
 A centralização pode trazer grandes economias
de escala
3. Postura de mercado suporte
 Crença quase cega no mecanismo de mercado

 Utilizadores totalmente responsáveis pelos
resultados
 altamente motivados: eficácia
 os utilizadores sabem negociar a aquisição do serviço (de
SI)
 custará alguma duplicação
 Pode criar barreiras à integração
 Os SI terão de ser auditáveis financeiramente
 Não é bom para tempos de recessão:
 tem problemas de integração por causa da duplicação
 os sistemas abertos podem complicar as coisas
4. Recurso escasso suporte
operacionais
 Controlo apertado de todos os gastos em SI

 Utilizadores e departamento de SI motivados ao
controlo
 Os utilizadores justificam investimentos
(custo/benefício)
 o departamento de SI é um centro de despesa
 Comunidade de utilizadores passiva
 Tenta forçar o ganho de 80% dos benefícios
com apenas 20% dos custos
5. Na Crista da onda exploratórios
 Crença na inovação tecnológica e no seu

impacto nos resultados
 cuidado com a utopia tecnocrática
 Postura de experimentação
 O utilizador também é inovador na forma de
fazer negócio
 Observatório tecnológico obrigatório
 Grandes investimentos em investigação e
desenvolvimento
6. Mal necessário
 Situação felizmente menos vulgar

 A informática é utilizada apenas em último
recurso
 O utilizadores são completamente passivos
 Normalmente provém de grandes falhas
comunicação
 falta de confiança
 grandes falhanços no passado
 Há problemas quando se aplicam tácticas de

gestão erradas
◦ ex: outsourcing total para esquecer problemas
 Se há sempre uma multiplicidade de
sistemas com características diversas
◦ Nomeadamente de impacto estratégico, ……então
também há formas de gerir apropriadas
 Deve haver uma conjugação de várias

tácticas de gestão
( VIA VERDE)
risco futuro +
Estratégicos Exploratórios
Planeamento Na Crista da Onda
Importância Centralizado Identificador OBUI
Sistema central
estratégica
dos sistemas Operacionais Suporte
planeados Monopólio Recurso Escasso
Identificador DSRC Office
Sistemas RFID
Postura mercado
Recurso Escasso Adobe Acrobat Pro
mySAP Business
risco actual - Suite
+ -
risco de negócio risco financeiro

Posicionamento do Mercado
Economia e Informação
Gestão Estratégica
Planeamento Estratégico
Diferentes Ambientes Sl/TI
Exemplo
Planeamento e Portfólio Aplicacional
Grandes Empresas
Processos de Planeamento
Análise do Portfólio Aplicacional
 Num determinado instante a nossa

carteira será composta por três tipos
diferentes de investimentos:
◦ Sistemas existentes
◦ Desenvolvimento em curso e planeado de
sistemas
◦ Desenvolvimentos potenciais
Gerir o Portfólio de forma diferenciada
Dar prioridade ao que é importante!
 1. SI operacionais: a maioria das aplicações
 criar uma burocracia simples para garantir
qualidade
(maturidade média)
 2. SI estratégicos: garantir o futuro
 acautelar todas as opções: estratégia empresarial
(maturidade alta)
 3. SI de suporte: gastar o menos possível
 em dinheiro (ex: outsourcing) e em tempo
 4. SI exploratórios
 investir e dar autonomia a quem experimenta o
negócio
Portfólio Aplicacional e Estratégia
Segmentos Portfólio
Organizações Complexas
Estratégicas Genéricas
Modelo de gestão
 Definir o Portfólio de aplicações
◦ de acordo com a estratégia de negócio
 Definir o estilo eclético de gestão
◦ por grupos de aplicações
 de acordo com a sua importância estratégica
 Definir a organização
◦ os papéis, responsabilidades e critérios
Definir sistema de decisão e
comunicação
=> através de uma composição dos
diversos modelos
(comparar com o modelo do Value Center
de Venkatraman)

Ase

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ase

Transféré par

Droits d'auteur :

Formats disponibles

Arquitectura Sistemas Empresariais

Prof. Acácio Carmona

 Arquitectura da Empresa é uma forma de

Prof. Acácio Carmona

Prof. Acácio Carmona

 Crescem e obtêm lucros …

 A Arquitectura de Empresa (EA) é a

 A verdadeira AE deve lidar com TODA a

 Portanto, ajuda uma empresa a articular

 [Arquitectura da Empresa] é o conjunto de representações

 Arquitectura da Empresa ou dos SI / TI?

 AMBAS : A arquitectura de entidades e processos vistas

Prof. Acácio Carmona

 Gestores / executantes Seniores,

Prof. Acácio Carmona

 Neste caso, um investimento no

 Investe-se muito pouco na definição de

Prof. Acácio Carmona

O papel dos Sistemas de Informação no Negócio actualmente

• Como os sistemas de informação estão a

 Growing interdependence between ability to use

 Business firms invest heavily in information

 There is a growing interdependence between a firm’s information

 Information system: Three

 An information system contains information about an organization and its

Business organizations are hierarchies consisting of three principal

MANAGEMENT LEVEL MIDDLE

KNOWLEDGE LEVEL KNOWLEDGE &

SALES & MANUFACTURING FINANCE ACCOUNTING HUMAN

Types of Business Information Systems

 Transaction processing systems

Types of Business Information Systems

 Decision support systems

 Executive support systems

• Knowledge management systems

 Examples of functional business

 Fulfilling a customer order involves a complex set of

 Management information systems

 In the system illustrated by this diagram, three TPS

• Supply chain management systems

Customer orders, shipping notifications, optimized shipping

ORDER PLANNING &

• Customer relationship management systems:

• Integrate firm’s customer-related processes and

Some of the capabilities of salesforce.com, a market-leading provider of

There are alternative ways of organizing the information systems

B: A separate department under central control

C: Represented in each division of a large multidivisional company but

Contact Channel Management CM Reporting

Campaigns System Customer Management System

Customer BPM & Integration System

Loyalty Trouble Knowledge Management

Interaction CTI Sever

Windows Request Request

Web Servers Appl

*Não se trata de um processo mas de uma função

 Confundir uma lista de produtos, diagramas

Prof. Acácio Carmona

Os artefactos organizam-se numa matriz de perspectivas e aspectos

 Cada Coluna é uma Builder Ent = Segment/Table

DETAILED Data Program Netw ork Security Timing Rule DETAILED

dimensão. Descreve REPRESENTATIONS Definition

aspecto do sistema. Ent = Proc = Node = People = Time = End =