Arquitetura Corporativa em

Enterprise Architecture

SOA on your terms and our expertise Marcelo Sávio
Senior IT Architect
Agradecimentos ao Núcleo de Prática e Pesquisa IBM Software Group
em Tecnologia da UNIRIO (NP2TEC), pela cessão http://www.linkedin.com/in/msavio
de uso de parte do material didático do seu curso http://msavio.myplaxo.com/
de extensão em Arquitetura de TI.
© 2006 IBM Corporation
2010

Enterprise Architecture (EA)
=
Arquitetura Corporativa
=
Arquitetura Empresarial

≠ ≠

2

Objetivos da apresentação

Ao final dessa apresentação eu espero que você possa saber um pouco mais sobre:

– O que é Arquitetura Corporativa;
– Os desafios na implantação de uma Arquitetura Corporativa;
– A importância do uso de um framework de Arquitetura;
– O papel de uma ferramenta de apoio à Arquitetura;

3

Cenário atual em muitas organizações

Principais Problemas com a Tecnologia da Informação
– Pouca eficácia nas soluções de TI para o negócio;
– Falta de flexibilidade e alto custo para adaptação dos sistemas às mudanças;
– Baixa qualidade das informações
• Redundâncias, inconsistências, falta de semântica explícita e consensual;
– Múltiplas tecnologias para manter, gerenciar e evoluir;
– Necessidade constantes de soluções de curto prazo;
– Necessidade de contínua adaptação às mudanças tecnológicas e de negócio;

4

Por que isso acontece?

– Distância entre o planejamento do negócio e os desenvolvimentos da TI;
– Falta de visão da estratégia de longo prazo;
– Mercado de tecnologias muito volátil e, ao mesmo tempo, ágil para atendimento
das exigências de curto prazo do negócio;
– Ausência de modelos conceituais de representação do domínio (do negócio);
– Fraca integração de aplicações e dados;
– Baixo nível de padronização de tecnologia.

5

Soluções desenvolvidas de forma independente e sem uma perspectiva corporativa, no
longo prazo, implicam em grande esforço de integração, falta de suporte aos requisitos
funcionais ou não-funcionais, dificuldade de gerência e operação e um maior custo.

Arquitetura de Solução

6

Como resolver esses problemas?
“Conhecendo” a organização
– Objetivos e metas, processos, conceitos e dados, sistemas e componentes, infra-estrutura;

Promovendo alinhamento entre a TI e os processos de negócio;

Integrando e otimizando aplicações, informações e tecnologias;

Definindo melhores práticas para TI;

Definindo e organizando:
– Modelos,

– Métodos,

– e ferramentas para suporte ao desenvolvimento de TI;

Estabelecendo padrões;

Gerindo os repositórios de informações;

Prospectando novas soluções no mercado.

7

O que é Enterprise Architecture ?
(Arquitetura Corporativa ou Arquitetura Empresarial)

“The enterprise architecture is the organizing logic for business
processes and IT infrastructure, reflecting the integration and
standardisation requirements of the company’s operating model

The Enterprise architecture provides a long term view of a company’s
processes, systems and technologies so that individual projects can
build capabilities – not just fulfil immediate needs”

Fonte: Ross et al, “Enterprise Architecture as Strategy”, 2006
(Harvard Business Press)

2008
(versão traduzida)

8

A Definition

Enterprise Architecture is explicitly describing an organization
through a set of independent, non-redundant artifacts,
defining how these artifacts interrelate with each other, and
developing a set of prioritized, aligned initiatives and
roadmaps to understand the organization, communicate this
understanding to stakeholders, and move the organization
forward to its desired state.

9

Arquitetura Corporativa é formada por quatro domínios que encapsulam e asseguram a efetividade
para entregar soluções que suportem a estratégia do negócio.

• Arquitetura de Negócio - Definição dos processos de negócio e suas características funcionais e
operacionais, que são a base para estabelecer a estratégia das aplicações que suportam os processos;
• Arquitetura de Informação (ou dados)- São os dados e seus relacionamentos com objetivo de
alimentar as estratégias de negócio e otimizar as decisões. Também serve como base para o desenho e
entrega das aplicações;
• Arquitetura de Aplicação (ou sistemas)- Identifica quais aplicações são necessárias para suportar o
negócio e conduz o desenho, construção (ou aquisição) e integração dessas aplicações;
• Arquitetura de Infra-estrutura (ou tecnologia) - cobre todo o suporte dos elementos de operação de TI
que devem ser operados no dia-a-dia, com ferramentas, processo de monitoração e gerenciamento.


Arquitetura de Negócio

Arquitetura de Arquitetura de
Informação Aplicação

Arquitetura de Infra-estrutura

10


É uma composição de Arquiteturas...



Arquitetura de Arquitetura de Arquitetura de
Sistemas de Informação Sistemas
Informação (ou dados) (ou aplicação)

Arquitetura de
Tecnologia de Arquitetura de Infra-estrutura
Informação (TI) (ou tecnologia)

11

Posicionamento da Arquitetura Corporativa

Oportunidades Estratégia de Negócios Estratégia de TI Novas
de Negócios Tecnologias

ARQUITETURA CORPORATIVA Governança
Visão
Arquitetura de Negócio Arquitetura de TI
Princípios
Processos Informações Standards
Classes de Informação Aplicações
Organização Guidelines
Localidades Infra-estrutura
Métricas
Framework

AMBIENTE DE NEGÓCIOS E DE TI

12

Posicionamento da Arquitetura Corporativa
A Arquitetura Corporativa de uma organização fornece o “plano” para se alinhar
tecnologia e negócios através de alguns elementos/componentes.
Oportunidades Alternativas
de Negócios Tecnológicas
Abrangência corporativa

Estratégia de
Estratégia de TI
Negócios

Estratégia Arquitetura Corporativa
Arquitetura Corporativa “O Planejamento da Cidade”

Arquitetura
Arquitetura de TI
de Negócio
Processos Informações
Informação Aplicações
Pessoas Infra-Estrutura
Planejamento
Localidades

Plano de Transição
Foco dos projetos

Ambiente Operacional da Empresa Arquitetura dos sistemas
Desenho, e Infra-estrutura de TI Aspectos Funcionais
implementação Aspectos Operacionais
e Prestação
de “O projeto da infra-estrutura de cada um
Soluções de TI
Serviços
dos edifícios”

13

Arquitetura em Silos vs. Arquitetura Corporativa

Arquitetura em Silos Arquitetura Corporativa

• Várias Arquiteturas; • Uma única Arquitetura;

• Diferentes soluções/tecnologias; • Padronização;

• Falta de padronização; • Viabiliza a Integração;

• Dificuldade de integração; • Ganhos de sinergia (reúso, etc.)

• Duplicidade de esforços; • Visão única da empresa;

• Falta de visão única da empresa; • Endereça problemas de negócio da corporação

• Cada “arquitetura” endereça problemas de negócio • Centralização do poder decisório.
da área ou departamento;

• Redução da complexidade na gestão;
• Distribuição do poder decisório.

• Maior complexidade na gestão

14

Uma composição de Arquiteturas...



(ou dados) (ou sistemas)

(ou tecnologia)

15




(ou tecnologia)

16


Arquitetura de Negócio Arquitetura de
Informação
Arquitetura de
Aplicação


Domínio das áreas de negócio

Trata dos processos do negócio (suportam as estratégias da
organização e as de cada área)

“O coração de uma boa arquitetura de negócios é a definição dos
processos de negócio com suas características funcionais e
operacionais, se tornando a base para manusear a aplicação das
estratégias de negócio”
Forrester

17


Arquitetura de Negócio Arquitetura de Arquitetura de
Organização e Estratégia do negócio

Vasta coletânea de pensamentos com os propósitos, metas, estruturas
e planos da organização;

Múltiplas formas possíveis
– principal objetivo é contextualizar o desenho dos processos de negócio;

Tecnicamente, não faz parte da Arquitetura Corporativa de TI, mas é
crítico o suficiente para que o desenho de arquitetura garanta o que
está sendo levado em consideração como parte dos processos de TI.

18


Arquitetura de Negócio Arquitetura de Arquitetura de
Arquitetura de processos de negócio

Define os principais processos da empresa
– ex.: Desenvolvimento de produtos, vendas, distribuição, ...

Detalha processos específicos e reflete parâmetros operacionais
– ex.: Volumes de transações, regras, operação centralizada ou distribuída, ...

Primeiro ponto de contato entre o negócio e a arquitetura de TI;

Apresenta a visão do negócio que será detalhada o suficiente para que
sejam definidos os planos e estratégias para a construção dos
Sistemas de Informação.

19


Modelo de Negócio Arquitetura de
Informação
Arquitetura de
Aplicação


Conceitos do negócio

Onde?
Localização Quem?
Quando? Como? Papel
Evento
Departamento

Processo Atividade

O quê?
Produto Sistema
Meta
Por quê?
Obstáculo Objetivo Documento

20

Exemplo de workproduct: Empresa de Seguros

Estrutura Organizacional Funções de negócios designadas
aos departamentos

21


Funções de negócio, fluxos de informação e recursos financeiros

22

Montando a Arquitetura Corporativa

Organização e estratégia de negócio

Arquitetura de Processos de Negócio
Arq. Infor.

Arq. Apl.
Arquitetura de Infra

23




(ou tecnologia)

24

Desafios na Gestão da Informação

+60% dos CEOs: Precisam realizar um trabalho Apenas 1/3 dos CFOs acham que a
melhor para capturar e entender rapidamente as informação é fácil de usar, objetiva, de custo
informações de forma a viabilizar as decisões de e nível de integração razoáveis
negócios;

30-50% do tempo de
85% da projeto de aplicações
informação é Clientes é gasto em gerência
não-estruturada Tráfego de Empregados de cópias.
dados.
Parceiros
Produtos Organização 42% das
30% do tempo Finanças
das pessoas é transações ainda
gasto buscando são “em papel”
informação Conteúdo
relevante. emails Bases Web
40% do orcamento
Mídia de TI é gasto em
Relatórios integração.
Documentos
Em organizações da ordem de 1B de Fontes: IBM & Industry Studies, Forrester
dólares, na média existem
48 sistemas financeiros distintos e 79% das organizações têm mais de 2
2.7 sistemas ERP repositórios. 25% têm mais de 15

25


Arquitetura de Informação Arquitetura de
Informação
Arquitetura de
Aplicação


No domínio da Gerência de Dados;
Orienta e organiza toda a informação que trafega em uma organização
– Descreve a sua estrutura conceitual, lógica e física;
– Viabiliza conhecimento da organização sobre seus dados, facilita acesso e
trata aspectos de eficiência;
Visão dos Dados -> Informação -> Conhecimento
– Operacionalizar e otimizar as estratégias e decisões de negócio;
Base para o desenho e implantação dos Sistemas de Informação.

26


Arquitetura de Informação Arquitetura de
Informação
Arquitetura de
Aplicação
Arquitetura de Dados

Dados, Metadados, Modelos
– Princípios e Políticas
• quem é o responsável pela informação, pelo uso e gerenciamento
• Estratégias de uso dos dados

– Semântica (conceitual)

– Estruturas de armazenamento (lógico)

– Eficiência no acesso (físico)

Objetivos
– Facilitar o acesso à informação
• abstração
• transformações entre os modelos, rastreabilidade
– Fornecer subsídios para
• mapear a arquitetura de sistemas
• definir a arquitetura futura
– Orientar a arquitetura tecnológica
• bases de dados, serviços de gerência de dados, modelagem física

27

Arquitetura de Informação

Modelo de Informação

28


Arquitetura da Informação Arquitetura de Arquitetura de
Serviços de Dados Informação Aplicação


Serviços para acesso às informações
– Informação-como-um-Serviço (information-as-a-service – IaaS)
Camada que encapsula as necessidades de dados das aplicações
– transparência
Altamente reutilizável
Implementação diversa
– Remete à abordagem SOA

29


Arquitetura de dados
Serviços de Dados
Arq. Infor.

Arq. Apl.

30




(ou tecnologia)

31


Arquitetura de Aplicação Arquitetura de
Informação
Arquitetura de
Aplicação


Muitas vezes dispersa entre as múltiplas gerências de TI

Compreende o mapeamento e planejamento adequado de todos os componentes de
sistemas
– para suportar o negócio e as atividades de uma organização

– Para manipular as informações que trafegam na organização

Contempla
– identificação de quais aplicações são necessárias para suportar o negócio

– desenho, construção (ou aquisição) e integração de aplicações

Composta por
– Arquitetura de Software (desenvolvimento das aplicações);

– Arquitetura de Integração;

– Arquitetura de Serviços.

32


Informação
Arquitetura de
Aplicação
Arquitetura de Software

Contempla
– Documentação das aplicações

• Análise, projeto, construção

– Informação trafegada entre as aplicações;

– Processos suportados pelas aplicações;

Objetivo é promover o desenvolvimento de aplicações
– de fácil integração;

– consistentes com os requisitos identificados;

– que manipulem dados conhecidos;

– adequadas às características do ambiente operacional

• Restrições e requisitos não funcionais;

33


Informação
Arquitetura de
Aplicação

Arquitetura de Integração
– Visão única (corporativa) da integração de aplicações
• Baseada no reúso e da distribuição de funcionalidades por um barramento lógico de integração;
• Middleware de integração entre as aplicações;
– relacionamentos entre os diversos componentes implementados
• serviços, APIs, conectores, interfaces e protocolos de comunicação disponíveis e padronizados

Arquitetura de Serviços
– Serviços como paradigma de construção das aplicações
• Encapsulamento de detalhes de funcionamento e acesso às informações
• Interoperabilidade
– Cria uma camada que encapsula componentes da aplicação
• Registro e repositório de serviços, Barramento de Serviços (ESB)
– Aderente à abordagem SOA

34

Arquitetura de Aplicação
Principais aplicações e
seus relacionamentos

35

Arquitetura de Aplicação

Uso de aplicações pelo processo de negócio.

36


Serviços de Dados
Arq. Infor.

Arq. Apl.
Arquitetura de software

Arquitetura de serviços
Arquitetura de integração


37




(ou tecnologia)

38

Arquitetura de Tecnologia Arquitetura de Negócio

Arquitetura de Infra-estrutura Arquitetura de
Informação
Arquitetura de
Aplicação


Também conhecida como arquitetura de tecnologia (ou tecnológica)
– Muito próxima do operacional e produção da organização

Abrange todos os elementos para suportar TI que devem ser operados
no dia a dia, bem como software e processos para gerenciá-los
– hardware, storage, rede, ambientes de desenvolvimento, plataformas de
gerência de dados,...

– Recursos que representam uma significativa parte dos ativos da organização

Influencia diretamente a implementação dos Sistemas de Informação

39


Informação
Arquitetura de
Aplicação


Arquitetura Técnica
– infra-estrutura de hardware e software para as aplicações e dados empresariais

• Plataformas de e-mail, compartilhamento de arquivos, especificação dos equipamentos
• Plataformas de SGBD, servidores, protocolos de rede, ambiente de data warehousing

Arquitetura de Operações
– ferramentas e e processos necessários para construir, monitorar, gerenciar e medir todos os aspectos de tecnologia, aplicações e
ativos de dados da empresa

Arquitetura de Segurança
– proteger a informação corporativa e os processos de negócio da organização

• Políticas de privacidade das informações, políticas para detecção e tratamento de invasões e ataques, avaliação
de incidentes de segurança
– Aspectos de segurança de vários itens de TI

• Especificação de sistemas de firewall, políticas de acesso a aplicações e arquivos, perfis de acesso às bases de
dados, proteção contra vírus e espionagem eletrônica, políticas de recuperação após desastre,
– Tem ganhado cada vez mais projeção

• Lei Sarbanes Oxley, ...

40

Arquitetura de Tecnologia Arquitetura de Negócio

Informação
Arquitetura de
Aplicação


Derivações da arquitetura técnica e de operações
– Bancos de Dados
• Padrões e procedimentos sobre os dados
• Modelagem física das bases de dados

– Plataformas
• padrões e processos de infra-estrutura
• Estratificação de itens de infra-estrutura

– hardware, sistemas operacionais, mídias de armazenamento (storage), monitoração
de infra-estrutura e softwares básicos
• Relacionamento com os diversos fornecedores

– Redes
• Padrões, especificações e infra-estrutura para interconectar os elementos da arquitetura técnica
• Alto grau de especialização dos recursos

41


Deployment of the main applications onto the infrastructure

42


Serviços de Dados
Arq. Infor.

Arq. Apl.
Arquitetura de Software

Arquitetura de serviços
Arquitetura de integração
Arquitetura Técnica
Arquitetura de Operações

Arquitetura de Segurança

43

Visões semelhantes (4 domínios)

Giga

Forrester

44

Visão dos quatro domínios da EA

Arquitetura Arquitetura Arquitetura Arquitetura
de Negócios de Sistemas de Informação de Infra-estrutura
Visão, Princípios
Modelos de Modelo funcional Modelo de Framework
Conceitual Governança
negócios & das aplicações dados Tecnológico Padrões
Alinhamento (Arquitetura de
(Estratégia) (Processos, Ativitidades, referência, Patterns)
(Acesso aos dados &
Guidelines de Critérios de seleção
(Arquitetura de referência)
Eventos, estrutura, Info, armazenamento Análise de gaps
papéis, Localidades)
Plano de Transição

Estrutura Projeto de Rede
Design Projetos de BD
Funcional Organizacional
específico da Escolha de Plataforma
aplicação Projeto de Storage
(Design) Processos de Data Warehouse
Negócios (Arquietura de Projeto Segurança
Referência escolhida

------------------------------------------------------ etc.

Aplicação Implementação
Armazenamento
Operacional Instalações
ou Produto e gerenciamento Operação
(Físico) de dados Desempenho
Instalação & Escalabilidade
Localidades Instalação de
Operação Bancos de Dados Consolidação
Gerenciamento

Como uma arquitetura corporativa funciona?

Modelagem da arquitetura atual;

Definição de uma arquitetura futura;

Manutenção das arquiteturas em decorrência dos novos desenvolvimentos;

Definição e implantação de políticas e padrões;
Processos
E mais..
de
– Prospecção de novas tecnologias;
Arquitetura
– Participação em comitês;

– Avaliação da qualidade de TI;

– Acompanhamento e medições de atividades;

– Etc.

Negócios Informações Aplicações Infra-estrutura

46

Implantando uma área de
arquitetura

47

Desafios para Implantação da Área de Arquitetura de TI

Mudança cultural na organização;
Identificação de perfis e competências;
Implantação da área;
Total alinhamento com o negócio;
Processos de Arquitetura alinhados com os processos de
desenvolvimento;
“Comprovar” ROI.

48

O desafio da
mudança cultural
Que problemas podemos enfrentar?
– “O novo em geral não é confortável” ;

– Resistência a novos processos;

– Dificuldade do ser humano com exposições e avaliações de seu trabalho;

– Falta de maturidade;

– Falta de competência;

– Preferência pelo reconhecimento individual;

– Dificuldade de trabalho em grupo;

– Utilização de práticas pessoais “que já dão certo”;

– “Sindrome de Gabriela”

– etc...

49

O desafio da mudança cultural

O que fazer para melhorar?
– Treinamento;

– Disseminação das práticas;

– Reconhecimento de melhorias (ex: prêmios);

– Revezamento de equipes (participação temporária na Arquitetura);

– Estabelecimento de processos participativos para definição de padrões;

– Demonstração constante dos resultados obtidos por quem utiliza os processos e padrões
estabelecidos;

– Estabelecimento de programas de integração de equipes (trabalho conjunto com o RH).

50

A Implantação de uma área de Arquitetura

Estabelecimento do Grupo / Área;

Definição da estratégia de implantação;

Definição dos processos;

Estabelecimento de parceria com o processo de desenvolvimento;

Definição e aquisição/construção de ferramentas;

Institucionalização dos processos;

Aquisição de infra-estrutura de hardware para suporte, divulgação e
uso dos processos e ferramentas.

51

Níveis de maturidade de EA

52

A implementação de uma Arquitetura Corporativa abrange
usualmente diversas iniciativas:

Desafios usuais :
Formalizar a falta de skills
Analisar a
Desenvolver o função falta de metodologia
Estratégia
skill dos “Arquiteto”
de Negócios
Arquitetos de TI
Plano de
capacitação
Compreender
a Arquitetura
dos Negócios
Integrar às
operações
Criar a da empresa
estrutura e os
Desafios usuais:
Definir a processos de
Aquisições ou fusões Arquitetura Governança
Preocupações de qualidade
Mudanças radical de tecnologia
Outsourcing

Desenvolver
Desafios usuais : plano de
Construir o comunicação
Dificuldades de implementação Construir a repositório
Benefícios não identificados Arquitetura da
(Identificação, Arquitetura
Seleção e
Transição) Desafios usuais :
Arquitetura Transição Padrões e procedimentos não
Capacitação Governança estabelecidos ou não conhecidos

53

O escopo de atuação do time de arquitetura envolve um ciclo de atividades
relacionados a estratégia, definição da arquitetura, liderança, governança e
comunicação:

Estratégia – Contribui para a estratégia, no mínimo, para
assegurar que a estratégia foi compreendida para atuar.
Definição da Arquitetura – Articula o desenvolvimento do
modelo futuro, compreende o modelo atual, identifica os gaps
e planeja o roadmap para fechar esses gaps;
Liderança – Coordena o esforço de implantação da
arquitetura corporativa e agrega e desenvolve os skills
necessários para integração de negócio e TI;
Governança – Assegura a adoção dos princípios de
arquitetura definidos para as disciplinas e estabelece um
processo de decisão sobre a utilização de novos
componentes;
Comunicação - Articula a visão futura e mostra como essa
visão se adere ao modelo proposto, retornando feedbacks
sobre os progressos alcançados e problemas enfrentados.

54

Importante: Parceria com processo de desenvolvimento

ARQUITETURA ARQUITETURA
DE APLICAÇÃO DE INFORMAÇÃO

Teste de Sistema

Pós-Implantação
Teste Integrado
ARQUITETURA

Teste Unitário
DE NEGÓCIO

Inicialização

Construção

Implantação
Definição

Design

UAT
Desenvolvimento Usr Produção

ARQUITETURA DE TECNOLOGIA

55

Governança – Abordagem balanceada

Alvo
Baseado nos
Requisitos

Não-Estruturada Estruturada Demais
•Não há espaço para criatividade
•Liberdade para tudo e todos
•Burorática e lenta
•Processos não repetitíveis Governança •Muitas métricas
•Não há métricas
•Balanceada •Excesso de políticas /procedimentos
•Não há documentação
•Processos Repetitíveis •Geralmente ignorada / minada
•Depende de ‘heróis’
•Mensurável
•Documentada e utilizada
•Continuamente melhorada

56

Arquitetura Corporativa é mais do que apenas uma coleção de componentes e seus
relacionamentos – é uma abordagem para governança da execução da construção
de soluções
na
do ?“
n ta
ve
mo corre “Nossa Arquite
os o tura alvo
o s n reçã continua válida?
am di Governança
tinu
n
”Co Arquitetura
Corporativa
Transição ”Estamos conduzindo
os projetos da forma
como desejamos?“
”Estas são as
orientações para a
”Esses são os
Arquitetura dos
projetos que
projetos“
serão feitos”

Forma “normal” de Outline da Macro Micro Ciclo de Implemen-
Solução Planejamento Planejamento Construção tação
priorização e
planejamento dos
projetos Outline da Macro Micro Ciclo de Implemen-
Solução Planejamento Planejamento Construção tação

Outline da Macro Micro Ciclo de Implemen-
Solução Planejamento Planejamento Construção tação Projetos

57

Recomendações gerais para uma área de arquitetura

Criar processos de arquitetura ágeis
– documentos de padrões com flexibilidade;
Prover acesso a uma base de conhecimento de arquitetura;
Envolver profissionais de arquitetura mais cedo nos desenvolvimentos
de projetos;
Divulgar os processos e competências da arquitetura;

58

Papéis e Responsabilidades
Ao construir um processo de Arquitetura, é essencial considerar que:
A comunidade de “arquitetos” é sempre maior
que a área encarregada de gerenciar a
Arquitetura; Usuários de Negócio
Um processo de arquitetura transcende as
Áreas Afetadas
atividades realizadas por uma área de
arquitetura; Multiplicadores
de Arquitetura
Um processo de arquitetura tem maior
potencial de benefícios se for parte de uma Grupo de
iniciativa ou esforço corporativo. Isto significa Arquitetura
atribuir e distribuir responsabilidades sobre as
funções de arquitetura, não apenas fora da Grupo de
área de Arquitetura, mas principalmente fora Revisão da
Arquitetura
de TI.

59

Por onde começar?

Tentar não “reinventar a roda”:
– Estudar Modelos de Governança e Práticas;
– Identificar workproducts baseado em Frameworks existentes;
– Identificar ferramentas de suporte;
• Exemplo: IBM System Architect
http://www-01.ibm.com/software/awdtools/systemarchitect/
Modelar os processos de arquitetura;
Construir modelos;
Institucionalizar os processos;
Estabelecer a governança;

61

O que é um framework de Arquitetura?

62

Há 25 anos ...
Em 1984 John Zachman (IBM) escreveu um
artigo (de uso interno IBM) sobre arquitetura
de sistemas de informação, no qual propôs
um framework;

Zachman foi convidado a publicar o artigo externamente,
o que ocorreu em 1987, no IBM Systems Journal
(disponível na Internet)

Em 1990 se aposentou da IBM e montou sua própria empresa de
consultoria em arquitetura corporativa;

Em 1992 publicou, novamente no IBM
Systems Journal, e em parceria com
John Sowa (também então recém
aposentado da IBM) uma versão
estendida do artigo original, contendo um
nova e definitiva versão do framework.

63

Zachman Enterprise Architecture Framework
O Framework de Zachman é um esquema, como se fosse uma Tabela Periódica dos Elementos, a qual
também é um esquema que classifica os elementos da natureza (em duas dimensões);
Aliás, foi somente após o cientista russo Dmitri Mendeleyev articular esse esquema foi que a Química se
tornou uma ciência de fato com disciplina. Até então a Química era somente Alquimia. Não era previsível
nem repetitível;
Depois que o Framework de Zachman foi publicado, se tornou o esquema de fato para Arquitetura
Corporativas e practicamente transformou a EA em uma discliplina.

SCOPE
(CONTEXTUAL)
DATA

List of Things Important
to the Business
What FUNCTION

List of Processes the
Business Performs
How NETWORK Where

List of Locations in which
the Business Operates
PEOPLE

List of Organizations
Important to the Business
Who TIME When

List of Events Significant
to the Business
MOTIVATION Why

List of Business Goals/Strat

1984
1869 Planner

ENTERPRISE
MODEL
(CONCEPTUAL)

Owner
ENTITY = Class of
Business Thing

e.g. Semantic Model

Ent = Business Entity
Reln = Business Relationship
e.g. Logical Data Model
Function = Class of
Business Process

e.g. Business Process Model

Proc. = Business Process
I/O = Business Resources
e.g. Application Architecture
Node = Major Business
Location

e.g. Business Logistics
System

Node = Business Location
Link = Business Linkage
e.g. Distributed System
People = Major Organizations

e.g. Work Flow Model

People = Organization Unit
Work = Work Product
e.g. Human Interface
Time = Major Business Event

e.g. Master Schedule

Time = Business Event
Cycle = Business Cycle
e.g. Processing Structure
Ends/Means=Major Bus. Goal/
Critical Success Factor

e.g. Business Plan

End = Business Objective
Means = Business Strategy
e.g., Business Rule Model
SYSTEM Architecture Architecture
MODEL
(LOGICAL)

Node = I/S Function
Ent = Data Entity Proc .= Application Function (Processor, Storage, etc) People = Role Time = System Event End = Structural Assertion
Designer Reln = Data Relationship I/O = User Views Link = Line Characteristics Work = Deliverable Cycle = Processing Cycle Means =Action Assertion

TECHNOLOGY e.g. Physical Data Model e.g. System Design e.g. Technology Architecture e.g. Presentation Architecture e.g. Control Structure e.g. Rule Design

MODEL
(PHYSICAL)

Node = Hardware/System
Builder Ent = Segment/T able/etc. Proc.= Computer Function Software People = User Time = Execute End = Condition
Reln = Pointer/Key/etc. I/O = Data Elements/Sets Link = Line Specifications Work = Screen Format Cycle = Component Cycle Means = Action

DETAILED e.g. Data Definition e.g. Program e.g. Network Architecture e.g. Security Architecture e.g. Timing Definition e.g. Rule Specification
REPRESEN-
TATIONS
(OUT-OF-
CONTEXT)

Sub-
Contractor Ent = Field Proc.= Language Stmt Node = Addresses People = Identity Time = Interrupt End = Sub-condition
Reln = Address I/O = Control Block Link = Protocols Work = Job Cycle = Machine Cycle Means = Step

FUNCTIONING
e.g. DATA e.g. FUNCTION e.g. NETWORK e.g. ORGANIZATION e.g. SCHEDULE e.g. STRATEGY
ENTERPRISE

64

Zachman Enterprise Architecture Framework
DATA What FUNCTION How NETWORK Where PEOPLE Who TIME When MOTIVATION Why

SCOPE List of Things Important List of Processes the List of Locations in which List of Organizations List of Events Significant List of Business Goals/Strat
to the Business Business Performs the Business Operates Important to the Business to the Business
(CONTEXTUAL)

Planner ENTITY = Class of Function = Class of Node = Major Business Ends/Means=Major Bus. Goal/
Business Thing Business Process People = Major Organizations Time = Major Business Event Critical Success Factor
Location
e.g. Semantic Model e.g. Business Process Model e.g. Business Logistics e.g. Work Flow Model e.g. Master Schedule e.g. Business Plan
ENTERPRISE System
MODEL
(CONCEPTUAL)

Owner Ent = Business Entity Proc. = Business Process Node = Business Location People = Organization Unit Time = Business Event End = Business Objective
Reln = Business Relationship I/O = Business Resources Link = Business Linkage Work = Work Product Cycle = Business Cycle Means = Business Strategy
e.g. Logical Data Model e.g. Application Architecture e.g. Distributed System e.g. Human Interface e.g. Processing Structure e.g., Business Rule Model
SYSTEM Architecture Architecture
MODEL
(LOGICAL)

Node = I/S Function
Ent = Data Entity Proc .= Application Function (Processor, Storage, etc) People = Role Time = System Event End = Structural Assertion
Designer Reln = Data Relationship I/O = User Views Link = Line Characteristics Work = Deliverable Cycle = Processing Cycle Means =Action Assertion
e.g. Physical Data Model e.g. System Design e.g. Technology Architecture e.g. Presentation Architecture e.g. Control Structure e.g. Rule Design
TECHNOLOGY
MODEL
(PHYSICAL)

Node = Hardware/System
Builder Ent = Segment/Table/etc. Proc.= Computer Function Software People = User Time = Execute End = Condition
Reln = Pointer/Key/etc. I/O = Data Elements/Sets Link = Line Specifications Work = Screen Format Cycle = Component Cycle Means = Action

DETAILED e.g. Data Definition e.g. Program e.g. Network Architecture e.g. Security Architecture e.g. Timing Definition e.g. Rule Specification
REPRESEN-
TATIONS
(OUT-OF-
CONTEXT)

Sub-
Contractor Ent = Field Proc.= Language Stmt Node = Addresses People = Identity Time = Interrupt End = Sub-condition
Reln = Address I/O = Control Block Link = Protocols Work = Job Cycle = Machine Cycle Means = Step

FUNCTIONING
e.g. DATA e.g. FUNCTION e.g. NETWORK e.g. ORGANIZATION e.g. SCHEDULE e.g. STRATEGY
ENTERPRISE

65

Por que Frameworks?

Mo
da elo del
s
do o
de
de od

e
a d cias obj
M

p e t iv
Ma ndân os
du de
re ál ogo es
Cat licaçõ
ap

Po l Ma
í
Seg tica d infr p
a-e a da
ura e str
nça utu

Di
ra

Re

sa
co

ste
ve

r
ry
da rio
s

elo a
do
de oná

M od g ram
de Dia e
ci

s d
sso es
Di

oc
e açõ
Pr lic
ap

66

Vantagens do uso de um Framework

Organizar as iniciativas de uma arquitetura corporativa;

Uniformizar os termos e linguagem
– itens e domínios de arquitetura em toda a empresa;

Concentrar as discussões de arquitetura;

Acelerar o funcionamento e diminuir a complexidade;

Permitir projeções dos itens de um framework de arquitetura em outros
– Apoio de ferramentas;

Integrar soluções, fornecedores e equipes distintas de forma mais harmônica e estruturada
– conforme planejamento;

Facilitar comunicação da visão e dos planos para toda a corporação;

Identificar alinhamento de TI com as diretrizes de negócio.

68

A “ávore genealógica” dos frameworks de arquitetura

69

Refinando alguns conceitos
Frameworks de EA
– O termo “Framework” de EA pode ser muito genérico e às vezes é necessário adjetivá-lo
• Framework de Navegação – Para localização dos artefatos de EA;
• Framework Conceitual – Para definir os meta-conceitos de EA;
• Framework de Modelagem – Para criar os artefatos/visões de EA;

Metodologias de EA
– Spewak’s Enterprise Architecture Planning (EAP)
– Scott Bernard’s EA Cube (EA3)
– TOGAF – Architecture Development Method (ADM)

Padrões de Notação para artefatos de EA
– Entidade/Relacionamento – Modelagem de Dados
– Unified Modeling Language (UML) – Requisitos dos sistemas
– Business Process Modeling Notation (BPMN) – Modelagem de Processos

70
70

Uma sopa de letrinhas...

recomendação de livro:

Assunto de hoje

71

É um consórcio aberto, formado por clientes e fornecedores com o objetivo de:
– Capturar, entender e endereçar requisitos existentes ou emergentes, estabelecer
políticas e compartilhar melhores práticas;
– Facilitar a interoperabilidade, criar consenso, evoluir e integrar especificações e
tecnologias abertas;
– Oferecer serviços para melhorar a eficiência operacional do consórcio;
– Operar um serviço de certificação de alto gabarito para o mercado.
Foi fundado em 1996, através da fusão de duas entidades: X/Open e Open Software
Foundation (OSF);
Trabalha em conjunto com outros consórcios e órgãos de padronização;

Promoção de Eventos

Tecnologias Fórums
Métodos & Certificações
Melhores Práticas
LDAP / CCI MILS Architecture • UNIX
SOA-WG • LDAP
Platform
Jericho & Security • WAP
AQRM Identity Management • S/MIME
• ITAC / ITSC
Motif® DCE
Enterprise Management
Real Time and Embedded Systems • NASPL
(Open DCE) •TOGAF

72

The Open Group Architecture Framework (TOGAF)

TOGAF
– É um framework de EA com foco além da TI;
– “Como as organizações podem, usando sistemas, alcançar objetivos de negócio?”

As quatro áreas principais são endereçadas:
– Negócios (estratégia, organização e processos);
– Aplicações (deployment, interações e relacionamento com processos de negócio);
– Informações (estrutura fisica e lógica dos ativos informacionais de uma organização e os
recursos para gerir esses ativos);
– Tecnologia (infra-estrutura e middleware de suporte).

73

Histórico do TOGAF

• Clientes membros do Open Group demandaram padrões de arquitetura
• Clientes membros selecionaram o TAFIM ponto de partida.
• DoD Information Systems Agency (DISA) doou o TAFIM como base
• TOGAF 1 • TOGAF 7 – Technical Edition
‘93 publicado • TOGAF 8 Enterprise Edition
‘94 ‘95
‘01 • TOGAF 8.1
‘02 ‘03 • TOGAF 8.1.1
‘06
‘07
‘09

TOGAF 9

• Foi publicado o estudo
Lançamento do programa
“The Interoperable Enterprise Business”
de certificação em TOGAF

74

The Open Group Architecture Framework (TOGAF)

– O TOGAF oferece :
• Um método, o ADM (Architectural Development Method),usado projetar,
avaliar e construir a arquitetura para uma organização;
• Um repositório chamado Enterprise Continuum para armazenar a
representação da arquitetura;
• Um conjunto de outras ferramentas úteis no desenvolvimento de
arquiteturas.

76

Visão da estrutura do TOGAF

77

TOGAF: Metodologia ADM

Processo iterativo para
desenvolvimento centrado na
arquitetura (sempre baseada
nos requisitos);
Cada passo no processo
está associado a uma view
que pode ser “capturada”;
Permite reúso de artefatos
de arquitetura;
As fases iniciais focam nas
questões conceituais e mais
gerais; as fases posteriores
movem-se em direção às
especificações e às práticas;

78

TOGAF: Metodologia ADM (Deliverables)

79

TOGAF Content Metamodel

Os 4 dominios

80

TOGAF Enterprise Continuum

81

O papel de uma ferramenta de apoio a EA

“Creating Actionable Architectures”

82

Desafios que impedem a adoção ampla de uma Arquitetura Corporativa

Reportar a EA em
Armazenamento
uma linguagem de Falar a linguagem Inventário/informação
das informações de
estrategistas e dos projetistas de sobre “as is” e “to-be”
EA para reúso
planejadores soluções
Criando a EA
(“Upstream EA”)

Comunicar com os stakeholders Popular a EA com informação
(no contexto deles) de todos os domínios

Desafio de transformar os requisitos de negócio em implementações

Manter as implementações Gerenciar as mudanças
Consumindo a EA
em sincronia com o que está (em escala corporativa)
(“Downstream EA”)
prescrito na EA

Estabilidade Mover-se no
Prover Assegurar a para os passo do
Orientação Governança Programas negócio

84

Características de uma “Actionable EA”
Oferece integração da
ferramenta de EA com
Possui uma linguagem outras, oferece
única de arquitetura, usabilidade e facilidade
mas com diversas na realização de análises
possibilidades de “as-is” / “to-be”
visualização
Criando a EA
(“Upstream EA”)
Facilidades de uso e de
geração de relatórios para Armazenamento simples e
melhorar a comunicação e automatizado de todos os
a tomada de decisões recursos da organização

Integração entre os requisitos de negócio e as implementações

Os serviço de TI são realizados de Governança corporativa, com
forma integrada e de forma a Consumindo a EA gestão de mudanças e medição de
possibilitar o reúso de ativos e práticas melhores práticas
(“Downstream EA”)
Consuming
the EA

Implementa
Trabalha com controle de versão
aplicações, processos e gestão de
e pessoas de forma publicação
integrada

85

The System Architect Approach to Enterprise Architecture

Create an Organizational Blueprint
Understand the current structure of the organization,
it’s business, it’s information

Share the Results
A common resource for Analyze and Optimize
empowering informed
decisions Identify, Create, and Optimize
for continued improvement

Telelogic
System Architect™

What Challenges Are We Facing
Show Impact, Identify Risk, and Intelligently Walk the
Organization Through Change

86
86

IBM Rational System Architect
O System Architect software foi inicialmente criado e desenvolvido pela Popkin Software
em 1988, sob o comando do Prof. Jan Popkin, uma reconhecida autoridade em EA.
O System Architect foi um dos primeiras ferramentas CASE ( Computer-Aided Software
Engineering) para ambiente Windows. A ferramenta evoluiu através dos anos e se
tornou uma das primeiras ferramentas de modelagem para EA.

Telelogic adquiriu a Popkin Software em Março, 2005.
IBM anunciou a aquisição da Telelogic em Junho, 2007 e a transferência total
ocorreu em Novembro, 2008.
Os produtos da Telelogic (System Architect, Focal Point, DOORS, etc.) agora
são parte da brand IBM Rational;
IBM anunciou que System Architect como sua ferramenta padrão para
Enterprise Architecture.
87
87

Um modelo versus um diagrama…

Orientado a diagrama Orientado a modelo
Diagrama de um Modelo de Dados

Um diagrama é uma figura
que se desenha Modelo de Dados/ER

Um diagrama é uma visão dentro de um modelo….

Diagrama de um modelo UML
Ex: Diagrama MS Visio
Modelo UML

88

Usando o SA para capturar e modelar todos os
domínios de uma organização

Application and
Network
Infrastructure
Service Models
Behavior (UML Support)

Network Topologies Matrix Views

Relational
Organizational Charts Application Models
Process Models
Data Modeling

Business Process
Modeling and Analysis

Data Models Goals Objectives Class Diagrams

89
89

Arquitetura Corporativa em

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Arquitetura Corporativa em

Semelhante a Arquitetura Corporativa em (20)

Mais de Marcelo Sávio

Mais de Marcelo Sávio (20)

Arquitetura Corporativa em