Apostila Togaf 9.1-new 5k5v20

Módulo 0 - Introdução TOGAF® 9 Certified - Arquitetura Corporativa Atila Belloquim Gnosis IT Knowledge Solutions V9.1 Edition Copyright © 2009-2011

Slide 1

of 67

All rights reserved Published by The Open Group, 2011

Objetivos • Este curso tem por objetivo capacitar os participantes a: – Compreender os conceitos relacionados à Arquitetura Corporativa – Identificar os processos necessários ao estabelecimento de uma prática de Arquitetura Corporativa na Organização – Conhecer o framework TOGAF 9 de Arquitetura Corporativa – Conhecer a metodologia associada ao framework TOGAF 9 – Realizar os exames necessários à obtenção da certificação profissional TOGAF 9 Certified

Slide 2

Agenda • The Open Group • O Fórum de Arquitetura

• • • • •

Por que arquitetura corporativa Por que um framework TOGAF 9.1 Certificação em TOGAF 9 Resumo

Slide 10

The Open Group • É um fornecedor internacional e um consórcio neutro de tecnologia, ao qual organizações confiam a liderança no desenvolvimento de padrões de TI e cetificação. • Provê a orientação e um ambiente aberto visando proporcionar interoperabilidade e neutralidade de fornecedor. • A filiação é aberta a todas as empresas: pequenas, médias e grandes, em qualquer lugar do mundo.

Slide 11

Agenda • The Open Group • O Fórum de Arquitetura

• • • • •

Por que arquitetura corporativa Por que um framework TOGAF 9.1 Certificação em TOGAF 9 Resumo

Slide 20

Fórum de Arquitetura – Missão • A missão do Fórum de Arquitetura é avançar a visão do The Open Group sobre o Fluxo de Informação sem Fronteiras, para e entre as empresas, • Através de um conjunto de programas que incidem sobre todos os aspectos arquiteturais, incluindo: – Proporcionar ampla e profunda liderança para a comunidade EA – Validando, publicando, fomentando e mantendo as melhores práticas para EA – Desenvolvendo, organizando, pesquisando, publicando através de líderes em EA – Iniciando e gerindo programas e projetos para apoiar estas atividades Slide 21

Partes Interessadas e Valor • Arquitetos de Clientes – Tempo, custo e risco reduzidos • Fornecedores de Ferramentas – Maior mercado, maior participação no mercado • Fornecedores de Solução de TI – Melhor custo-eficiência • Integradores – Melhor custo-eficiência, melhor serviço • Organizações Acadêmicas / Pesquisa – Apoio para a obtenção de financiamento

Slide 22

Agenda • The Open Group • O Fórum de Arquitetura • Por que arquitetura corporativa

• • • •

Por que um framework TOGAF 9.1 Certificação em TOGAF 9 Resumo

Slide 23

O que é uma Corporação? • Um conjunto de organizações que compartilham um conjunto comum de metas – Agência Governamental – Parte de uma corporação – Empresa

• As grandes corporações podem incluir múltiplas empresas • Pode ser uma "empresa estendida", incluindo parceiros, fornecedores e clientes

Slide 24

O Que é uma Arquitetura? • Uma Arquitetura é a organização fundamental de alguma coisa, consubstanciado em: – Seus componentes, – Suas inter-relações e com o ambiente – E os princípios que governam seu design e evolução

Adaptado do padrão ANSI/IEEE 1471-2000

Slide 25

O Que é Arquitetura Corporativa?

[1] MIT Center for Information Systems Research [2] SearchCIO.com Slide 26

Arquitetura Corporativa é: • A lógica de organização para os processos de negócios e infraestrutura de TI refletindo os requisitos de integração e padronização do modelo operacional da empresa. [1] • Um modelo conceitual que define a estrutura e funcionamento de uma organização. A intenção de uma arquitetura corporativa é determinar como uma organização pode mais efetivamente atingir os seus objetivos atuais e futuros. [2]

Tipos de Arquitetura Arquitetura de Negócio

Arquitetura de Aplicação

Serviços

Hardware, software, redes Slide 27

Processos de Negócio, organização, pessoas

Arquitetura de Dados Dados, Informação

Arquitetura de Tecnologia

Por quê Arquitetura Corporativa? • Uma gestão eficaz e a exploração da informação através da TI é a chave para o sucesso do negócio • Boa gestão da informação = vantagem competitiva • Atuais sistemas de TI realmente não atendem às necessidades de negócios – Fragmentados, duplicados – Mal compreendidos – Não responsivos a mudanças

• Investimento em Tecnologia da Informação – Centrada na manutenção do sistema – Desenvolvimentos táticos em vez de um plano estratégico

Slide 28

Por que Arquitetura Corporativa? • Duas principais razões por que você precisa de uma arquitetura corporativa: – Fundamental para a sobrevivência e sucesso do negócio – Permite a inovação gerenciada dentro da empresa

Slide 29

Pressões para se Desenvolver uma Arquitetura Corporativa • Leis e regulamentações – Clinger-Cohen Act (US Information Technology Management Reform Act 1996) – Diretivas da União Europeia sobre a Adjudicação de Contratos Públicos – Sarbanes-Oxley

• • • • •

Extensibilidade das Empresas Operações de TI mais cooperativas Maior divulgação às falhas Aumento no contencioso Requisitos de auditoria

Slide 30

Benefícios de Negócio da Arquitetura Corporativa • Ajuda uma organização a alcançar sua estratégia de negócios • Menor tempo para chegar ao mercado para inovações e novas capacidades • Processos de negócio e informações mais consistentes nas unidades de negócios • Mais confiabilidade e segurança, menor risco

Fonte: “Why Enterprise Architecture Matters?”, White Paper do The Open Groupr, W076

Slide 31

Benefícios de Negócios da Arquitetura Corporativa • • • • •

Uma operação de negócio mais eficiente Uma operação de TI mais eficiente Melhor retorno sobre o investimento existente Redução do risco de investimento futuro Compras mais rápidas, mais simples e mais baratas

Veja também: “Why Enterprise Architecture Matters?”, White Paper do The Open Group, W076

Slide 32

A Importância da Governança • Uma arquitetura corporativa é apenas tão boa quanto o framework de tomada de decisão que se estabelece em torno dele  framework de "governança" • A estrutura de governança depende de – Estrutura de autoridade clara – Os participantes certos

Slide 33

O quê queremos dizer com Governança? • A forma na qual as decisões são tomadas • Quem é responsável (responsible)? • Quem está envolvido? • Quem é responsável (able)?

Slide 34

Agenda • The Open Group • O Fórum de Arquitetura • Por que arquitetura corporativa • Por que um framework

• TOGAF 9.1 • Certificação em TOGAF 9 • Resumo

Slide 35

O que é um Framework? • Definição 3.13: Framework de Arquitetura – Uma estrutura conceitual usada para desenvolver, implementar e manter uma arquitetura corporativa

• Deve descrever um método para projetar um estado alvo da empresa em termos de um conjunto de blocos de construção, e para mostrar como os blocos de construção se encaixam • Deve conter um conjunto de ferramentas e fornecer um vocabulário comum • Ele também deve incluir uma lista de padrões recomendados e produtos compatíveis que podem ser usados ​para implementar os blocos de construção

Slide 36

O Valor de um Framework • Fornece um ponto de partida prático para um Projeto de Arquitetura – – – –

Evita o pânico inicial quando a escala da tarefa torna-se aparente Sistemática - "bom senso codificado" Captura o que outros já descobriram que funciona no mundo real Contém um conjunto de recursos base para a reutilização

Slide 37

Enterprise Architecture Development Method Padrão aberto e neutro Um método geral abrangente

Complementário a, não concorrente a, outros frameworks

Amplamente adotado no mercado Desenvolvido para atender as necessidades da empresa e da indústria Disponível sob uma licença grátis e perpétua Slide 38

de fornecedor, tecnologia e ferramenta Evita reinventar a roda

Alinha TI com o Negócio Baseado em Boas Práticas Possibilidade em participar na evolução do framework

Agenda • • • •

The Open Group O Fórum de Arquitetura Por que arquitetura corporativa Por que um framework

• TOGAF 9.1

• Certificação em TOGAF 9 • Resumo

Slide 39

Desenvolvimento do TOGAF 1994

Requirement

Prova de necessidade

1995

TOGAF Version 1

Prova de conceito

1996

TOGAF Version 2

Prova de aplicação

1997

TOGAF Version 3

Relevância para Arquiteturas Práticas (blocos de construção)

1998

TOGAF Version 4

Continuum da Arquitetura (TOGAF em Contexto)

1999

TOGAF Version 5

Cenários de Negócios (requisitos de arquitetura)

2000

TOGAF Version 6

Visões de Arquitetura (IEEE Std 1471)

Slide 41

Desenvolvimento do TOGAF 2001

TOGAF Versão7

Princípios de Arquitetura; Avaliações de Conformidade

2002

TOGAF Versão 8

Extensão para Arquitetura Corporativa

2003

TOGAF Versão 8.1

Gerenciamento de Requisitos; Governança; Modelos de Maturidade; Framework de Competências

2006

TOGAF Versão 8.1.1

Retificação Técnica 1 Aplicada

2009

TOGAF Versão 9

Reestruturação Evolucionária; Framework de Conteúdo da Arquitetura

2011

TOGAF Versão 9.1

Retificação Técnica 1 Aplicada

Slide 42

Direcionada pelos Membros (Usuários Finais) • Clientes Membros exigem padrões de arquitetura ... • Clientes Membros escolhem o TAFIM como ponto inicial preferido… • DoD Information Systems Agency (DISA) doa o TAFIM como base ‘93

‘94

• O primeiro TOGAF é publicado • TOGAF 7 – Technical Edition ‘96

‘01

• Publicado o primeiro Cenário Interoperável de Negócios Corporativo (The Interoperable Enterprise Business Scenario) Slide 43

‘02 ‘03

‘06

‘09

TOGAF 9 Enterprise Edition ‘11

TOGAF 9.1 TOGAF 8.1.1 TOGAF 8 – Enterprise Edition É lançado o primeiro programa de certificação para TOGAF

O Escopo do TOGAF • O TOGAF enfatiza metas de negócio como condutores de arquitetura e fornece um repositório de boas práticas, incluindo: – – – – – –

O Método de Desenvolvimento de Arquitetura do TOGAF () Orientações & Técnicas do O Framework de Conteúdo da Arquitetura do TOGAF O Continuum Corporativo Modelos de Referência do TOGAF Modelo de Capacidades do TOGAF

Slide 44

Objetivos do TOGAF • Longo Prazo: – Um padrão da indústria, um método de arquitetura corporativa genérico…. – ….utilizável por si próprio ou em conjunto com frameworks que possuam produtos relevantes/específicos para setores em particular. • Vários frameworks possuem “mind share”: – Zachman, Spewak, DoD Framework, FEAF, TEAF, …

• A maioria foca em produtos não em método • TOGAF e…. (não TOGAF ou….)

• Versão 9: – Uma evolução do TOGAF 8.1.1. Maior alinhamento com o negócio. Reestruturação para facilitar o uso. Estrutura geral e método central para arquitetura corporativa que pode ser completado em anos futuros. Slide 45

Componentes do TOGAF 9

Slide 46

O TOGAF 9.1 Parte I - Introdução Prefácio, Sumário Executivo, Conceitos Principais, Definições e Notas do Release.

Parte II – Método de Desenvolvimento de Arquitetura Introdução ao Narrativa das fases do

Parte III – Orientações e Técnicas do Orientações para adaptar o processo do Técnicas para o Desenvolvimento da Arquitetura

Parte IV – Framework de Conteúdo de Arquitetura Metamodelo de Conteúdo de Arquitetura Artefatos Arquiteturais Entregáveis de Arquitetura Blocos de Construção

Parte V – Continuum Corporativo e Ferramentas Continuum Corporativo Particionamento da Arquitetura Repositório de Arquitetura Ferramentas para o Desenvolvimento da Arquitetura

Parte VI – Modelos de Referência do TOGAF Arquitetura de Fundação: Modelo de Referência Técnico Modelo de Referência de Infraestrutura de Informação Integrado

Parte VII – Framework de Capacidades de Arquitetura Comitê de Arquitetura Conformidade de Arquitetura Contratos de Arquitetura Governança de Arquitetura Modelos de Maturidade de Arquitetura Framework de Competências de Arquitetura

Slide 47

Componentes do TOGAF 9 • Método de Desenvolvimento de Arquitetura () – Uma sequência iterativa de os para desenvolver uma arquitetura para toda a empresa

• Orientações e Técnicas do – Orientações e técnicas para dar e à aplicação do

• Framework de Conteúdo da Arquitetura – Um modelo detalhado de produtos de trabalho de arquitetura, incluindo entregáveis, artefatos dentro de entregáveis, e os Blocos de Construção de Arquitetura (BCAs) que os entregáveis representam.

Slide 48

Componentes do TOGAF 9 • O Continuum da Corporação – Um modelo para a estruturação de um repositório virtual e métodos para a classificação de artefatos de arquitetura e de solução

• Modelos de Referência do TOGAF: – O Modelo de Referência Técnica do TOGAF (TRM) – O Modelo de Informação de Infraestrutura Integrado (III-RM).

• O Framework de Capacidade de Arquitetura – Uma definição estruturada das organizações, competências, funções e responsabilidades para estabelecer e operar uma arquitetura corporativa.

Slide 49

Framework de Habilidades Corporativas do TOGAF

Informa a capacidade Garante a realização

Framework de Capacidade de Arquitetura (Parte VII)

Da visão de negócio

Necessidades de negócio alimenta o método Visão e Direcionadores de Negócio

Refina

Método de Desenvolvimento de Arquitetura (Parte II)

Orientações & Técnicas do (Parte III)

Entende

Framework de Conteúdo de Arquitetura (Parte IV)

Define objetivos, KPIs, orçamentos para os papéis de Arquitetura Direciona a necessidade por maturidade nas Capacidades de Arquitetura Entrega novas soluções de Negócio

& Framework de Conteúdo do TOGAF

Continuum Corporativo & Ferramentas (Parte V) Informa o Negócio Do Estado Atual

Slide 50

Modelos de Referência do TOGAF (Parte VI)

Estrutura Modiular Framework de Conteúdo Orientação Estendida Estilos Arquiteturais Detalhamentos adicionais do

Mudanças operacionais Causam atualizações

Continuum Corporativo e Ferramentas do TOGAF

Capacidade de Negócio

– Princípios Básicos Um método iterativo, ao longo de todo o processo, entre as fases e dentro das fases Cada Iteração= novas decisões: Cobertura da Corporação Nível de detalhe Horizonte de tempo Reuso de ativos de Arquitetura: Iterações anteriores do , outros frameworks, modelos sistêmicos, modelos de indústria…

Decisões baseadas em: Competência / recursos disponíveis Valor agregado para a corporação. Slide 51

– Princípios Básicos Cada fase é validada contra, e valida os requisitos atuais do negócio

Slide 52

Fase Preliminar • Esta fase inclui as atividades de preparação e iniciação para criar uma capacidade de Arquitetura – Entender o ambiente de negócio – Compromisso da Alta istração – Acordo sobre o escopo – Estabelecer os princípios – Estabelecer a estrutura de governança – Customização do TOGAF

Slide 53

Fase A Visão da Arquitetura • Inicia uma iteração do processo de arquitetura – Define o escopo, restrições, expectativas – Requerido no início de todos os ciclos de arquitetura • Cria a Visão da Arquitetura • Valida o contexto de negócio • Cria a Declaração de Trabalho de Arquitetura

Slide 54

Fase B Arquitetura de Negócio •

A organização fundamental de um negócio, incorporado em – Seus processos de negócios e pessoas, – Suas relações • Entre si e com o ambiente,

–

•

Slide 55

E os princípios que governam seu design e sua evolução Mostra como a organização atende a seus objetivos de negócio

Arquitetura de Negócio - Conteúdo • Estrutura da organização • Metas e objetivos de negócio • Funções de negócios • Serviços do Negócio • Processos de negócio • Papéis corporativas • Correlação entre organização e funções.

Slide 56

de 67

Arquitetura de Negócio - os 1. Selecionar modelos de referência, pontos de vista e ferramentas 2. Definir a Descrição da Arquitetura de linha de base 3. Definir a Descrição da Arquitetura Alvo 4. Realizar análise da diferença (gap analysis) 5. Definir os componentes candidatos do roap 6. Realizar revisão formal pelas partes interessadas 7. Finalizar a Arquitetura 8. Criar o Documento de Definição de Arquitetura Slide 57

Fase C Arquitetura de Sistemas de Informação • A organização fundamental de um sistema de TI incorporada em • Os principais tipos de informações e aplicações que as processam • A relação entre si e com o ambiente, e os princípios que governam seu design e evolução • Mostra como os sistemas de TI atendem os objetivos de negócio da corporação Continued Slide 58

Dados ou Aplicações primeiro? •

•

•

Slide 59

Geralmente se faz necessário abordar ambos • Nem sempre é o caso, dependendo do escopo do projeto e suas restrições Podem ser desenvolvidos em qualquer ordem, ou em paralelo • A teoria sugere que a Arquitetura de Dados vem primeiro • Considerações de ordem prática dizem que começar com a Arquitetura de Aplicação pode ser mais eficiente Será preciso haver alguma iteração para assegurar a consistência

Fase D Arquitetura de Tecnologia • A organização fundamental de um sistema de TI incorporada em • Sua tecnologia de hardware, software e comunicação • Suas relações entre si e com o ambiente, • e os princípios que governam seu design e evolução

Slide 60

Fase E Oportunidades e Soluções • Realizar o planejamento inicial da implementação • Identificar os principais projetos de implementação • Determinar se uma abordagem incremental é necessária, se assim, definir Arquiteturas de Transição • Decidir a abordagem • Construir v Comprar v Reusar • Terceirizar • Pacotes Comerciais • Código Aberto • Avaliar as prioridades • Identificar as dependências Slide 61

Fase F Plano de Migração • Para os pacotes de trabalho e projetos identificados na Fase E realizar • Análise de Custo/Benefício • Avaliação de Risco

• Finalizar o Plano de Implementação e Migração detalhado

Slide 62

Fase G Governança da Implementação • Fornecer uma supervisão arquitetural para a implementação • Define restrições de arquitetura em projetos de implementação • Governar e gerir um Contrato de Arquitetura • Monitorar o trabalho de implementação visando conformidade • Produzir realização de valor de negócio

Slide 63

Fase H Gerenciamento de Mudanças na Arquitetura • Fornecer monitoramento contínuo e um processo de gerenciamento de mudanças • Garantir que as mudanças na arquitetura são geridas de uma forma coesa e arquitetada • Estabelece e apoia a Arquitetura Corporativa a fornecer flexibilidade para evoluir rapidamente em resposta a mudanças no ambiente tecnológico ou de negócios • Monitora o negócio e o gerenciamento de capacidade. Slide 64

Agenda • • • • •

The Open Group O Fórum de Arquitetura Por que arquitetura corporativa Por que um framework TOGAF 9.1

• Certificação em TOGAF 9

• Resumo

Slide 65

Certificação em TOGAF Nível da Certificação

Propósito

TOGAF 9 Foundation

Fornecer validação de que o candidato tenha adquirido conhecimento dos conceitos básicos e da terminologia do TOGAF 9 e compreende os princípios fundamentais da Arquitetura Corporativa e do TOGAF

TOGAF 9 Certified

Fornecer validação de que, além de conhecimento e compreensão, o candidato é capaz de analisar e aplicar os conhecimentos do TOGAF

Slide 66

Alguns Fatos sobre o TOGAF • Desenvolvido por mais de 300 organizações de todo o mundo envolvidas no seu desenvolvimento – Grande usuários de TI – Fornecedores de TI – Integradores e Sistemas – Acadêmicos • Usado nos maiores projetos de TI no mundo todo – IBM, HP, Sun, Infosys, ….. • Comunidade de experientes praticantes de TOGAF – Mais de 16000 certificados • ado por ferramentas de arquitetura Slide 69

Agenda • • • • • •

The Open Group O Fórum de Arquitetura Por que arquitetura corporativa Por que um framework TOGAF 9.1 Certificação em TOGAF 9

• Resumo

Slide 70

Introdução Gerencial

TOGAF é marca registrada do The Open Group nos Estados Unidos e outros países

Slide 73

of 67

Módulo 2 TOGAF 9 Componentes V9.1 Edition Copyright © 2010-2011

Slide 74

of 26

Todos os direitos reservados Publicado por The Open Group, 2011

TOGAF 9 Componentes

TOGAF é marca registrada do The Open Group nos Estados Unidos e outros países.

Slide 75

of 26

Componentes do TOGAF 9

Slide 77

Parte I - Introdução Prefácio, Preface, Visão global executiva, Principais Conceitos, Definições e Notas da Versão

Parte II – Método de Desenvolvimento da Arquitetura Introdução ao Narrativas das Fases do

Parte III – Orientações e Técnicas do Orientações para Adaptação do Processo do Técnicas para o Desenvolvimento da Arquitetura

Parte IV – Framework de Conteúdo da Arquitetura Metamodelo de Conteúdo Artefatos Arquiteturais Entregáveis da Arquitetura Blocos de Construção

Parte V – Continuum da Corporação e Ferramentas Continuum da Corporação Particionamento da Arquitetura Repositório da Arquitetura Ferramentas para o Desenvolvimento da Arquitetura

Parte VI – Modelos de Referência do TOGAF Arquitetura de Fundação: Modelo de Referência Técnico Modelo de Referência da Infraestrutura Integrada da Informação

Parte VII – Framework de Capacidade da Arquitetura Comitê de Arquitetura Aderência da Arquitetura Contratos da Arquitetura Governança da Arquitetura Modelos de Maturidade da Arquitetura Frameworks de Competências da Arquitetura

Slide 78

O Método de Desenvolvimento da Arquitetura • O núcleo do TOGAF • Uma forma comprovada de desenvolvimento de uma arquitetura • Projetada para atender requisitos de negócio • Um método interativo • Um conjunto de visões de arquitetura para garantir que um conjunto complexo de requisitos são adequadamente atendidos • Cada fase inclui objetivos, abordagem, entradas, os e saídas. Slide 79

Orientações e Técnicas do • Um conjunto de orientações e técnicas para dar e à implementação do • As Orientações ajudam a adaptar o para lidar com diferentes cenários, incluindo diferentes estilos do processo (ex.: o uso de iteração) e também requisitos específicos (ex.: segurança) • As técnicas dão e a tarefas específicas dentro do (ex.: definir princípios, cenários de negócio, análise de diferenças, planejamento da migração, gerenciamento de riscos, etc).

Slide 80

Aplicando Iteração ao

Exemplo de Orientação Slide 81

Aplicando o Através do Panorama da Arquitetura

Exemplo de Orientação Slide 82

Categorias de Partes Interessadas

Exemplo de Técnica Slide 83

Framework de Conteúdo da Arquitetura Fornece um modelo detalhado dos produtos de trabalho arquiteturais, incluindo Entregáveis, Artefatos dentro dos entregáveis, e Blocos de Construção de Arquitetura (BCAs / ABBs - Architecture Building Blocks) que aqueles entregáveis representam • Propicia maior consistência para as saídas do TOGAF • Fornece um checklist abrangente de saídas da arquitetura • Promove melhor integração dos produtos de trabalho • Provê um detalhado padrão aberto de como as arquiteturas deveriam ser descritas • Inclui um metamodelo detalhado

Slide 84

Entregáveis, Artefatos e Blocos de Construção

Slide 85

Metamodelo de Conteúdo Completo com Relacionamentos

Slide 86

de 26

Continuum da Corporação

Slide 87

Repositório da Arquitetura

Slide 88

Modelos de Referência do TOGAF • São fornecidos dois Modelos de Referência – O Modelo de Referência Técnica do TOGAF (TRM) • Uma Arquitetura de Fundação • Um modelo e uma taxionomia de serviços genéricos de plataforma

– O Modelo Integrado de Infraestrutura de Informação (III-RM) • Um modelo para aplicações de negócio e infraestrutura • Direcionado especificamente para dar e à visão do Fluxo de Informação sem fronteiras (Boundaryless Information Flow™)

Slide 89

Modelo de Referência Técnico Alto-Nível

Slide 90

Modelo de Referência Técnica Detalhado

Slide 91

Fluxo de Informação sem Fronteiras (Boundaryless Information Flow™) • Uma marca registrada do The Open Group • O o à informação integrada para apoiar a melhoria de processos de negócios • Uma infraestrutura que fornece fluxo de informações sem fronteiras tem componentes padrões abertos que prestam serviços em uma corporação estendida de um cliente que: – Combinam múltiplas fontes de informações – De forma segura, entregam a informação seja lá quando e onde ela seja necessária, no contexto correto para pessoas ou sistemas que utilizam esta informação.

Slide 92

O Modelo Integrado de Infraestrutura de Informação (III-RM)

Slide 93

Framework de Capacidades

Slide 94

Estabelecendo a Capacidade de Arquitetura como uma Entidade Operacional • •

O Framework de Capacidade da Arquitetura oferece orientações sobre o estabelecimento de uma prática operacional de Arquitetura Corporativa É recomendável que incluam capacidades como: – – – – – – – – – –

Gestão Financeira Gestão de Desempenho Gestão de Serviço Gestão de Risco Gestão de Recursos Gestão de Partes Interessadas e Comunicações Gestão da Qualidade Gestão de Fornecedores Gerenciamento da Configuração Gestão do Ambiente

Slide 95

TOGAF 9 Componentes

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 99

of 26

Módulo 3 Introdução ao Método de Desenvolvimento da Arquitetura V9.1 Edition Copyright © 2009-2011

Slide 100

of 19

All rights reserved Published by The Open Group, 2011

Introdução ao Método de Desenvolvimento de Arquitetura ()

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 101

of 19

O que é o do TOGAF? •

O constitui o núcleo do TOGAF

•

O resultado da contribuição de vários arquitetos

•

Um processo para desenvolver uma Arquitetura Corporativa

•

Integra todos os elementos dentro do TOGAF

•

Projetado para atender necessidades de Negócio e de TI provendo: –

Um conjunto de visões de arquitetura (negócio, dados, aplicação, tecnologia)

–

Um conjunto recomendado de entregáveis

–

Um método para gerenciar requisitos

–

Orientações para ferramentas de desenvolvimento de arquitetura

Slide 103

Método de Desenvolimento de Arquitetura - Processo • O é um processo iterativo: – Ao longo do processo inteiro – Entre fases – Dentro das fases • Para cada iteração, reconsidere: – Escopo – Detalhe – Cronogramas, marcos Slide 104

Método de Desenvolimento de Arquitetura - Processo • Considere ativos de: – Iterações adas – Mercado, de acordo com a disponibilidade, competência, e valor: • Outros Frameworks • Modelos Sistêmicos • Modelos Verticais de Indústria

Slide 105

Relacionamento com outras partes do TOGAF Framework de Capacidade de Arquitetura (Parte VII)

Método de Desenvolvimento de Arquitetura (Parte II) Diretrizes & Técnicas do (Parte III) Framework de Conteúdo de Arquitetura (Parte IV) Continuum da Corporação & Ferramentas (Parte V) Modelos de Referência do TOGAF (Parte VI) Slide 106

Preparar a organização para um projeto de arquitetura de sucesso.

Definir o escopo, as limitações e as expectativas para um projeto de TOGAF; criar a Visão de Arquitetura; validar o contexto do negócio, criar a Declaração de Trabalho de Arquitetura

Phases

Fornecer monitoração contínua e um processo de gerenciamento de mudanças para assegurar que a arquitetura responde às necessidades da empresa

Fornecer supervisão arquitetural para a implementação; garantir que o projeto de implementação está em conformidade com a arquitetura

Analisar os custos, benefícios e riscos; desenvolver o Plano de Implementação e Migração detalhado

Garantir que todas as fases do projeto de TOGAF estão baseadas nos requisitos de negócios e os validam Slide 107

Desenvolver a Arquitetura de Negócio Desenvolver as arquiteturas de linha de base e alvo e analisar as diferenças

Desenvolver a Arquiteturas de Sistemas de Informação Desenvolver as arquiteturas de linha de base e alvo e analisar as diferenças

Desenvolver a Arquitetura Tecnológica Desenvolver as arquiteturas de linha de base e alvo e analisar as diferenças Realizar o planejamento inicial da implementação, identificar os mais importantes projetos de implementação

Exemplo de os na Fase do

Slide 108

Entradas e Saídas do • O TOGAF define um número de entradas e saídas de entregáveis para cada fase – Estas são sugestões, não precisam ser seguidas a risca – Uma saída em uma fase inicial pode ser modificada em uma fase futura – Números de versão são usados para gerenciar as saídas – Uma convenção é usada para ilustrar a evolução dos entregáveis • 0.1 – Um esboços de alto nível de um entregável • 1.0 – Um entregável detalhado e formalmente revisado

Slide 109

Adaptando o • Metodologia Genérica para diferentes: – Geografias – Setores verticais – Tipos de indústrias

• Utilizável com entregáveis de outros frameworks como Zachman, DODAF, … • É comum modificar ou estender o para atender necessidades específicas Slide 110

Governança do • O , seja adaptado ou usado sem alteração, é um processo fundamental para ser gerido e governado • O Comitê de Arquitetura deve estar convencido de que o método está sendo aplicado corretamente • A gestão de todos os artefatos arquiteturais, governança e processos relacionados deve ser apoiada por um ambiente controlado, como um repositório

Slide 111

Repositório de Governança • Dados de Referência • Status de Processos • Informação de Auditoria

Slide 112

Motivos para limitar o Escopo da Atividade de Arquitetura • A autoridade organizacional da equipe produzindo a arquitetura • Os objetivos e preocupações das partes interessadas a serem endereçadas dentro da arquitetura • A disponibilidade de pessoas, finanças e outros recursos

Slide 113

Limitando o Escopo da Atividade de Arquitetura • Existem quatro dimensões em que o escopo pode ser limitado: – Abrangência – Profundidade – Período de Tempo – Domínios de Arquitetura

Slide 114

Integração da Arquitetura

Slide 115

Introdução ao Método de Desenvolvimento de Arquitetura ()

O TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 118

of 19

Módulo 4 O Continuum da Corporação e Ferramentas

V9.1 Edition Copyright © 2009-2011

Slide 119

of 30

All rights reserved Published by The Open Group, 2011

O Continuum da Corporação e Ferramentas

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 120

of 30

Roap Parte I - Introdução Prefácio, Preface, Visão global executiva, Principais Conceitos, Definições e Notas da Versão

Parte II – Método de Desenvolvimento da Arquitetura Introdução ao Narrativas das Fases do

Parte III – Orientações e Técnicas do Orientações para Adaptação do Processo do Técnicas para o Desenvolvimento da Arquitetura

Parte IV – Framework de Conteúdo da Arquitetura Metamodelo de Conteúdo Artefatos Arquiteturais Entregáveis da Arquitetura Blocos de Construção

Parte V – Continuum da Corporação e Ferramentas Continuum da Corporação Particionamento da Arquitetura Repositório da Arquitetura Ferramentas para o Desenvolvimento da Arquitetura

Parte VI – Modelos de Referência do TOGAF Arquitetura de Fundação: Modelo de Referência Técnico Modelo de Referência da Infraestrutura Integrada da Informação

Parte VII – Framework de Capacidade da Arquitetura Comitê de Arquitetura Aderência da Arquitetura Contratos da Arquitetura Governança da Arquitetura Modelos de Maturidade da Arquitetura Frameworks de Competências da Arquitetura

Slide 121

• Parte V, Continuum da Corporação e Ferramentas, Capítulo 39

Definição de‘Continuum’ • Substantivo: uma extensão contínua de algo, em que nenhuma parte é diferente de qualquer outra Fonte: Wiktionary.org

Slide 123

Componentes do TOGAF

Diretrizes e Técnicas do

Slide 124

Framework de Conteúdo de Arquitetura

Modelos de Referência

Continuum da Corporação

Framework de Capacidade De Arquitetura

Visão Geral • Um modelo para estruturar um repositório virtual e métodos para classificar artefatos de arquitetura e solução • Baseado em arquiteturas e soluções: – – – – –

Modelos, padrões, descrições de arquitetura Entregáveis produzidos na iteração atual do Entregáveis produzidos em outras iterações do Ativos da indústria em geral Demonstra como os artefatos evoluem

• A implementação prática do Continuum da Corporação se materializa em um Repositório de Arquitetura Continua… Slide 125

Visão Geral (continuação) • O Continuum da Corporação é uma combinação de dois conceitos complementares: O Continuum da Arquitetura e O Continuum de Soluções • Ele habilita a efetiva utilização de “Produtos de Prateleira” (COTS) • Ele aperfeiçoa a eficiência da engenharia • Ele ajuda a organizar ativos de arquitetura e solução reusáveis • Ele propicia uma linguagem comum: – Dentro da organização – Entre empresas clientes e fornecedores Slide 126

Reuso da Arquitetura • O Continuum da Corporação consiste de todos os ativos da arquitetura: modelos, padrões, descrições de arquitetura, etc. • Ativos externos incluem: – Modelos de referência genéricos (TRM do TOGAF, Zachman, …) – Modelos específicos de TI (ex.: arquitetura de web services) – Modelos específicos de processamento de informações (ex.: comércio eletrônico, gerenciamento de cadeia de suprimentos, …) – Modelos específicos de setores verticais (ex.: TMF, ARTS, POSC…)

• A função de governança da arquitetura decide quais ativos uma organização deve considerar como parte de seu Continuum da Corporação

Slide 127

Continuum da Corporação: Componentes

Slide 128

O Continuum da Corporação

Figura 1

Slide 129

Figure 1

• Arquiteturas variam desde Arquiteturas de Fundação ando por Arquiteturas de Sistemas Comuns e Arquiteturas Setoriais chegando a uma Arquitetura Específica para a Organização • As setas representam a relação bidirecional entre as diferentes arquiteturas – Da esquerda para a direita: atendendo as necessidades da corporação e os requisitos de negócio • As necessidades da corporação e os requisitos de negócio aumentam em detalhes da esquerda para a direita

– Direita para a esquerda: alavancando componentes arquiteturais e blocos de construção Slide 130

Figure 1

• Os elementos arquiteturais mais a esquerda são os mais reutilizáveis. • Requisitos relacionados a elementos faltantes são ados para a esquerda para inclusão. • Corporações podem utilizar os mesmos modelos do Continuum, especializados para negócios específicos. • A Figura 1 mostra as diferentes arquiteturas que podem ser desenvolvidas: – Estes não são etapas fixas em um processo – Arquiteturas diferentes também podem existir. Slide 131

Figure 1

• A Figura 1 não representa um processo formal, mas sim uma progressão ocorrendo em vários diferentes níveis: – Lógico

Físico

– Horizontal (focado em tecnologia de TI)

– Generalização – Taxonomia

Vertical (foco no negócio)

Especialização Especificação de Arquitetura

• Em cada ponto, um arquitetura é projetada em termos de conceitos de projeto e blocos de construção disponíveis. Slide 132

O Continuum de Soluções

Figura 2

Slide 133

Figure 2

• As arquiteturas mais específicas estão a direita: – Soluções de Fundação ajudam a criar soluções de sistemas comuns – Soluções de Sistemas Comuns são usadas para criar soluções setoriais – Soluções Setoriais são usadas para criar soluções específicas para a organização

• Os conceitos mais genéricos estão a esquerda • O espectro completo é importante quando se faz o balanço entre custo e valor. Slide 134

O Continuum de Soluções: • Representa as implementações de arquiteturas em níveis correspondentes do Continuum da Arquitetura. • É um preenchimento da arquitetura com Blocos de Construção de Solução, tanto produtos adquiridos do mercado quanto componentes construídos, que representam uma solução para as necessidades da corporação.

• Forma um Inventário de Soluções ou Biblioteca de Reuso, o qual adiciona significativo valor à tarefa de gerenciar e implementar melhorias ao ambiente de TI. Slide 135

Relacionamentos • O relacionamento entre o Continuum da Arquitetura e o Continuum de Soluções é de orientação, direção, e e. • Ex.: a Arquitetura de Fundação – É uma arquitetura de blocos de construção e padrões correlatos – a todas as Arquiteturas de Sistemas Comuns e, desta forma, o ambiente operacional completo da corporação

• A Arquitetura de Fundação do The Open Group consiste no TRM • O III-RM do The Open Group é um exemplo de Arquitetura de Sistemas Comuns

Slide 136

O Continuum da Corporação

Figura 3: melhor caso para alavancagem da arquitetura e de componentes de solução Slide 137

Usando o Continuum • O do TOGAF descreve o processo de desenvolvimento de uma arquitetura específica para a organização adotando e adaptando arquiteturas e soluções genéricas • O Continuum: – Contém soluções completas e “ainda em desenvolvimento” – É um “framework dentro de um framework” – Inicialmente possui poucos ativos internos – Cresce pela adição de Blocos de Construção reutilizáveis Slide 138

Relacionamentos • O Continuum de Soluções auxilia a compreensão de produtos, sistemas, serviços e soluções • O Continuum da Corporação melhora a produtividade através de alavancagem • O Continuum da Corporação não representa relacionamentos estritamente em cadeia: – arquiteturas corporativas podem possuir componentes de uma Arquitetura de Sistemas Comuns – soluções corporativas podem conter um produto ou serviço Slide 139

A Necessidade de Ferramentas • Ferramentas são necessárias para gerenciar e controlar os artefatos dentro do Continuum Corporativo – Promover o reuso – Habilitar o compartilhamento de informações da arquitetura dentro da organização – Permitir uma manutenção mais fácil da arquitetura – Garantir que uma terminologia comum seja utilizada – Fornecer modelos relevantes a partes interessadas

Slide 140

Ferramentas podem modelar a Arquitetura Corporativa

Slide 141

Questões sobre Padronização de Ferramentas • Uma única ferramenta de “tamanho único” que atende a todos versus múltiplas ferramentas • Pode uma ferramenta só atender a todas as necessidades, todos os níveis de maturidade? • O The Open Group reconhece a complexidade nesta área e está desenvolvendo um programa de Certificação de Ferramentas para o TOGAF 9, para auxiliar na avaliação.

Slide 142

Resumo • Ferramentas são necessárias para gerenciar artefatos dentro do Continuum da Corporação • O TOGAF fornece uma introdução às questões de Padronização de Ferramentas

Slide 145

O Continuum da Corporação & Ferramentas

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 148

of 30

Módulo 5 Repositório de Arquitetura V9.1 Edition Copyright © 2009-2011

Slide 149

of 18

All rights reserved Published by The Open Group, 2011

Repositório de Arquitetura

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 150

of 18

Roap Parte I - Introdução Prefácio, Preface, Visão global executiva, Principais Conceitos, Definições e Notas da Versão

Parte II – Método de Desenvolvimento da Arquitetura Introdução ao Narrativas das Fases do

Parte III – Orientações e Técnicas do Orientações para Adaptação do Processo do Técnicas para o Desenvolvimento da Arquitetura

Parte IV – Framework de Conteúdo da Arquitetura Metamodelo de Conteúdo Artefatos Arquiteturais Entregáveis da Arquitetura Blocos de Construção

Parte V – Continuum da Corporação e Ferramentas Continuum da Corporação Particionamento da Arquitetura Repositório da Arquitetura Ferramentas para o Desenvolvimento da Arquitetura

Parte VI – Modelos de Referência do TOGAF Arquitetura de Fundação: Modelo de Referência Técnico Modelo de Referência da Infraestrutura Integrada da Informação

Parte VII – Framework de Capacidade da Arquitetura Comitê de Arquitetura Aderência da Arquitetura Contratos da Arquitetura Governança da Arquitetura Modelos de Maturidade da Arquitetura Frameworks de Competências da Arquitetura

Slide 151

• Parte V, Continuum da Corporação e Ferramentas, Capítulo 41

Propósito • O gerenciamento e alavancagem efetivo de saídas arquiteturais requer uma taxonomia formal para diferentes tipos de ativos arquiteturais • O TOGAF fornece um framework estrutural para um Repositório de Arquitetura • Esta é uma parte de um Repositório Corporativo mais abrangente

Slide 153

Repositório de Arquitetura Descreve o framework de arquitetura em uso na corporação Contém produtos de trabalho de arquitetura reusáveis Mostra o estado da operação da corporação em pontos do tempo particulares Define critérios de conformidade para trabalho governado pela arquitetura

Captura os resultados da atividade da governança Descreve a organização, papéis, habilidades e responsabilidades da prática de arquitetura Slide 154

Panorama da Arquitetura 1.

2.

3.

Arquiteturas Estratégicas –

mostram um visão resumida de longo prazo de toda a corporação

–

fornecem um framework organizado para atividades operacionais e de mudança e permitem ajuste de direção no nível executivo

Arquiteturas de Segmento –

fornecem um modelo operacional mais detalhado para áreas dentro de uma corporação

–

podem ser usadas no nível de portfólio ou de programa para organizar e alinhar operacionalmente as atividades de mudança de forma mais detalhada

Arquiteturas de Capacidade –

mostram com maior detalhe como a corporação pode ar uma capacidade em particular

–

usadas para fornecer uma visão geral da capacidade atual, capacidade alvo, e incrementos de capacidade, e permitem que pacotes de trabalho individuais sejam agrupados dentro de portfólios e programas gerenciados.

Slide 155

Biblioteca de Referência •

Uma área do repositório destinado a manter boas práticas ou modelos que podem ser usados para construir arquiteturas dentro da corporação

•

O material de referência mantido na Biblioteca de Referência é tipicamente obtido de uma variedade de fontes, incluindo: –

Organizações de padrões

–

Fornecedores de produtos e serviços

–

Fóruns ou comunidades da indústria

–

Modelos definidos corporativamente

–

Boas práticas provenientes de implementações de projetos

Slide 156

Base de Informação de Normas •

Uma área do repositório destinada a manter um conjunto de especificações, com as quais as arquiteturas precisam estar de acordo

•

O estabelecimento de uma Base de Informações de Normas fornece uma base não ambígua para a governança de arquiteturas uma vez que: –

As normas são facilmente adas pelos projetos e desta forma as obrigações do projeto podem ser entendidas e planejadas

–

Normas são declaradas de uma forma clara e não ambígua, de modo que a conformidade pode ser objetivamente verificada

Slide 157

Base de Informação de Normas •

Tipos de Normas – Legais e Regulatórias – Industria – Organizacional

Slide 158

• Ciclo de Vida de Normas – – – –

Em Teste Ativa Em Obsolescência Obsoleta

Classificação de Normas •

•

Normas de Negócio –

Normas para funções de negócio compartilhadas

–

Normas para definição de papel e ator

–

Normas de segurança e governança para a atividade de negócio

Normas de Dados –

Normas para codificação e valores para dados

–

Normas para estruturas e formatos para dados

–

Normas para origem e propriedade de dados

–

Restrições sobre replicação e o

Slide 159

•

Normas de Aplicação: – Normas para aplicações compartilhadas que am funções de negócio específicas – Normas para comunicação e interoperabilidade de aplicações – Normas para ar, apresentação, e estilo

•

Normas Tecnológicas – Normas para produtos de hardware – Normas para produtos de Software – Normas para desenvolvimento de sistemas

O Log de Governança •

Uma área de repositório para armazenar informações compartilhadas relativas à governança em curso de projetos.

•

Manter um repositório compartilhado de informações de governança é importante, pois: – Decisões feitas durante os projetos (como desvios de normas ou a justificativa para uma abordagem de arquitetura particular) são importantes para reter e ar continuamente. – Várias partes interessadas estão preocupadas nos resultados de governança de projetos (ex.: outros projetos, clientes dos projetos, o Comitê de Arquitetura, etc.).

Slide 160

Conteúdo do Log de Governança

Slide 161

Relacionamento com outras partes do TOGAF • O do TOGAF possui lembretes de quando usar os ativos do Repositório de Arquitetura • O Repositório de Arquitetura é um modelo para uma instância física do Continuum da Corporação

Slide 162

Repositório de Arquitetura

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 165

of 18

Módulo 6 Framework de Conteúdo de Arquitetura Edição V9.1 Copyright © 2009-2011

Slide 166

of 19

Todos os direitos reservados Publicado por The Open Group, 2011

Framework de Conteúdo de Arquitetura

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 167

of 19

Part 3 IV: Framework de Conteúdo de Arquitetura Parte I - Introdução Prefácio, Preface, Visão global executiva, Principais Conceitos, Definições e Notas da Versão

Parte II – Método de Desenvolvimento da Arquitetura Introdução ao Narrativas das Fases do

Parte III – Orientações e Técnicas do Orientações para Adaptação do Processo do Técnicas para o Desenvolvimento da Arquitetura

Parte IV – Framework de Conteúdo da Arquitetura Metamodelo de Conteúdo Artefatos Arquiteturais Entregáveis da Arquitetura Blocos de Construção

Parte V – Continuum da Corporação e Ferramentas Continuum da Corporação Particionamento da Arquitetura Repositório da Arquitetura Ferramentas para o Desenvolvimento da Arquitetura

Parte VI – Modelos de Referência do TOGAF Arquitetura de Fundação: Modelo de Referência Técnico Modelo de Referência da Infraestrutura Integrada da Informação

Parte VII – Framework de Capacidade da Arquitetura Comitê de Arquitetura Aderência da Arquitetura Contratos da Arquitetura Governança da Arquitetura Modelos de Maturidade da Arquitetura Frameworks de Competências da Arquitetura

Slide 168

• Novo para o TOGAF 9 • Esta parte descreve – Um metamodelo estruturado para artefatos de arquitetura, – Uso de blocos de construção de arquitetura – Uma visão geral de entregáveis típicos da arquitetura

Introdução • O Framework é uma parte significativa do TOGAF • Ele fornece um modelo detalhado dos produtos do trabalho de arquitetura • Ele ajuda a melhorar a consistência das saídas do TOGAF – Apresenta resultados de uma forma consistente e estruturada – Ajuda a referenciar e classificá-las.

Slide 170

Benefícos do Framework de Conteúdo de Arquitetura • Fornece uma lista abrangente de saídas de arquitetura • Promove uma melhor integração dos produtos de trabalho se adotado em toda a empresa • Fornece um padrão aberto detalhado de como arquiteturas devem ser descritas

Slide 171

Visão Geral • O Framework tem 3 categorias para descrever produtos de trabalho –Entregáveis –Artefatos –Blocos de Construção

Slide 172

Entregáveis, Artefatos e Blocos de Construção • Entregáveis – – – –

Produtos formais Especificados em contrato Gerados a partir de um projeto Um entregável pode conter vários artefatos

• Blocos de Construção – Componentes que podem ser combinados com outros blocos de construção para entregar arquiteturas e soluções

• Artefatos – produtos granulares que descrevem uma arquitetura de um ponto de vista específico – Por exemplo: especificações de casos de uso, requisitos de arquitetura, diagramas de rede, etc. – Classificados como: • Catálogos (listas de coisas) • Matrizes (mostrando o relacionamento entre coisas) • Diagramas (imagens de coisas).

– Artefatos constituem o conteúdo do Repositório de Arquitetura Slide 173

Relacionamento entre Entregáveis, Artefatos e Blocos de Construção

Slide 174

Exemplo – Documento de Definição de Arquitetura

Slide 175

Artefatos de Arquitetura • Artefatos são produtos que são criados ao desenvolver uma arquitetura. • Um artefato é diferente de um entregável, que é uma saída contratada a partir de um projeto. • Normalmente entregáveis podem conter muitos artefatos e cada artefato pode existir em muitos entregáveis.

Slide 176

Metamodelo de Conteúdo O framework é baseado em um metamodelo de conteúdo padrão que define todos os tipos de blocos de construção em uma arquitetura – Mostrando como estes objetos podem ser descritos – Como eles se relacionam entre si

• O modelo de conteúdo consiste de um núcleo e extensões. • Catálogos, matrizes e diagramas são usados para apresentar informações arquiteturais.

Slide 177

Visão Geral do Conteúdo de Arquitetura

Slide 178

Mapeando o Framework e o Há um mapeamento do Framework de Conteúdo de Arquitetura para as fases do TOGAF : • Artefatos de Princípios de Arquitetura, Visão e Requisitos devem capturar o contexto dos modelos de arquitetura, incluindo os princípios gerais de arquitetura, o contexto estratégico e requisitos. • Artefatos de Arquitetura de Negócio capturam modelos de arquitetura das operações de negócio, especificamente fatores que motivam a corporação, como a corporação está estruturada e as suas capacidades funcionais. • Artefatos de Arquitetura de Sistemas de Informação capturam modelos de arquitetura de sistemas de TI, especificamente aplicativos e dados. • Artefatos de Arquitetura Tecnológica capturam ativos de tecnologia adquiridos usados ​para implementar e realizar soluções. • Artefatos de Realização da Arquitetura capturam as transições entre os estados da arquitetura e são usados para ar e governar a implementação. Slide 179

Mapeando o Framework e o

Slide 180

of 19

Framework de Conteúdo e TOGAF • O aborda uma necessidade de negócio através de um processo de visão, definição, planejamento e governança. Cada etapa do tem informações como entradas e saídas. • O framework de conteúdo fornece uma estrutura para o que define as entradas e saídas em detalhes e coloca cada produto dentro do contexto da arquitetura. • Assim, o framework de conteúdo é um companheiro para a . • O descreve o que precisa ser feito para criar uma arquitetura e o framework de conteúdo descreve com o que ele deve se assemelhar no final. Slide 181

Framework de Conteúdo de Arquitetura

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 184

of 19

Módulo7 TOGAF Metamodelo de Conteúdo

Edição V9.1 Copyright © 2009-2011

Slide 185

de 45

Todos os direitos reservados Publicado por The Open Group, 2011

TOGAF Metamodelo de Conteúdo

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 186

de 45

Roap Parte I - Introdução Prefácio, Visão Executiva, Conceitos Básicos, Definições e Notas de Release

Parte II – Método de Desenvolvimento da Arquitetura Introdução ao Fases Nerrativas do

Parte III – Orientações e técnicas do Orientações para adaptar o processo Técnicas para o desenvolvimento de Arquiteturas

Part IV – Framework de Conteúdo de Arquitetura Metamodelo de Conteúdo Artefatos Arquiteturais Entregáveis de arquitetura Blocos de Construção

Parte V – Continuum Corporativo e Ferramentas Continuum Corporativo Particionamento de Arquitetura Repositório de Arquitetura Ferramentas para o desenvolvimento e Arquiteturas

Part VI – Modelos de referência Foundation Architecture: Modelo Técnico de Referência Modelo de Referência de Infrastrutura de Informação Integrada

Part VII –Framework de Capacidade de Arquitetura Comitê de Arquitetura Conformidade de Arquitetura Contratos e Arquitetura Governança de Arquitetura Modelo de maturidade de Arquitetura Framework de Compe”^encias de Arquitetura

Slide 187

• Parte IV, Framework de Conteúdo de Arquitetura, Capítulo 34

O que é um metamodelo? • Um metamodelo é uma definição precisa dos constructos e regras necessárias para a criação de modelos – Fonte www.metamodel.com

• Um modelo que descreve como e com o quê a arquitetura será descrita numa forma estruturada. – TOGAF 9 definições

Slide 189

Por quê um metamodelo?

Slide 190

Benefícios do metamodelo O metamodelo de conteúdo fornece uma série de benefícios: • Formaliza a definição de Arquitetura Corporativa • Formaliza o relacionamento entre objetos • Habilita um mapeamento por ferramenta de arquitetura

Slide 191

Modelagem Formal e Informal • Há escolhas a serem feitas sobre o nível de estrutura e formalidade na definição do conteúdo arquitetura • Em alguns casos linguagem muito formal e específica é necessária para articular e governar de forma precisa e detalhada • Em outros casos, a utilização de disciplina de engenharia formal irá resultar em um conteúdo arquitetura que é: – Inapropriado para a audiência – Difícil de comunicar

Slide 192

Conceitos do Metamodelo de Conteúdo Base • A arquitetura do TOGAF é baseada em – Definição de blocos de construção de arquitetura em catálogos de arquitetura – Especificação das relações entre estes blocos de construção nas matrizes de arquitetura – E apresentação de diagramas de comunicação que mostram de uma forma precisa o que é a arquitetura

• O metamodelo é estruturado em conteúdo Base e Extensão – O Conteúdo Base é projetado para não ser alterado

Slide 193

Conteúdo Base e Extensão • Para dar e a vários cenários o metamodelo foi particionado em conteúdos conhecidos como Base e Extensão • O conteúdo Base fornece um conjunto mínimo de conteúdo de arquitetura para ar a rastreabilidade entre artefatos • O conteúdo Extensão permite uma modelagem mais profunda e específica

Slide 194

O Metamodelo de Conteúdo do TOGAF e suas Extensões

Slide 195

Entidades do Metamodelo Base • Ator: Uma pessoa, organização ou sistema que está fora do escopo do modelo da arquitetura, mas interage com ela. • Componente de Aplicação: Um encapsulamento de funcionalidade de aplicação que está alinhado com a estrutura de implementação. • Serviço de Negócio: Dá e às capacidades de negócio através de uma interface explícita e definida que é explicitamente governado pela organização. • Entidade de Dados: Um encapsulamento de dados que é reconhecido por um especialista de domínio do negócio como um conceito discreto. Entidades de dados podem ser ligadas a aplicações, repositórios e serviços e podem ser estruturadas de acordo com as considerações de implementação. • Função: Fornece recursos de negócio estreitamente alinhados a uma organização, mas não é explicitamente governada pela organização. Slide 196

Entidades do Metamodelo Base (continuação) • Serviço de Sistema de Informação: Os elementos automatizados de um serviço de negócio. Um serviço de sistema de informação pode entregar ou oferecer e completo a um ou mais serviços de negócio. • Unidade Organizacional: uma unidade delimitada de recursos com linhas de reportagem, metas, objetivos e métricas. Unidades Organizacionais podem incluir partes externas e as organizações parceiras de negócios. • Serviço de Plataforma: A capacidade técnica necessária para prover a infraestrutura que dá e à entrega de aplicativos. • Papel: Um ator assume um papel para executar uma tarefa. • Componente de Tecnologia: Um encapsulamento de infraestrutura tecnológico que representa uma classe de produtos de tecnologia ou um produto de tecnologia específico. Slide 197

Principais Entidades e seus Relacionamentos

Slide 198

Necessidades da Partes Interessadas Executive

CxO Programme Management Office

Line Management

Executive

HR

Application Management

Line Management

IT Service Business Management Domain Experts

Infrastructure Management

Functional / Business Process Experts

Data / Voice Communications

Stakeholder Types

Corporate

Slide 199

System

End -

Project

QA / Standards Groups

Product Specialists

Enterprise Security

Technical Specialists

Procurement

O Metamodelo de Conteúdo O metamodelo de conteúdo fornece definições de todos os tipos de blocos de construção que podem existir, mostrando como eles podem ser descritos e relacionados entre si. • Ao criar e gerenciar arquiteturas, é necessário considerar questões tais como serviços de negócios, atores, aplicações, entidades de dados, e tecnologia. • O metamodelo destaca estas questões, mostra seus relacionamentos e identifica artefatos que podem ser usados ​para representá-las de forma consistente. • O metamodelo também pode ser usado para fornecer orientação às organizações que desejem implementar sua arquitetura usando uma ferramenta de arquitetura. Slide 200

Metamodelo de Conteúdo (Simplificado)

Slide 201

Metamodelo de Conteúdo (Detalhado)

Slide 202

Metamodelo de Conteúdo Base

Slide 203

Fase Preliminar • Catálogo de Principios Gerenciamento de Requisitos Fase B, Arquitetura de Negócio • • • • • • • • • • • • •

Fase A, Visão de Arquitetura • Matriz de Mapa de Partes interessadas

• Diagrama Conceitual • Diagrama de Cadeia de Valor da Soluçao

TOGAF 9 Artifacts • Catálogo de Requisitos

Catálogo de Organização/Ator Catálogo de Direcionador/Meta/Objetivo Catálogo de Papéis Catálogo de Serviço de Negócio/Função Catálogo de Localidades Catálogo de Processo/Evento/Controle/Produ to Catálogo de Contrato/Medida Matriz de Interação de Negócio Matriz de Ator//Papel Diagrama de “Footprint” de Negócio Diagrama de Serviço de Negócio/Informação Diagrama de Decomposição Funcional Diagrama de Ciclo de Vida de Produto

Fase E. Oportunidades e Soluções Slide 204 de Contexto de Projeto • Diagrama • Diagrama de Benefícios

Fase C, Arquitetira de Dados

Fase C, Arquitetura de Aplicação

Fase D, Arquitetura Tecnológica

•

•

•

• • • •

Catálogo de Entidade de Dados/ Componente de Dados Matriz de Entidade de Dados/Funções de Negócio Matriz de Aplicação/Dados Diagrama lógico de dados Diarama de Disseminação de Dados

• • • • • •

• •

Catálogo de Portifólio de Aplicação Catálogo de Interface Matriz de Aplicação/Organização Matriz de Papel/Aplicação Matriz de Aplicação/Função Matriz de Interação de Aplicação Diagrama de Comunicação de Aplicação Diagrama de Localização de Aplicação e Usuário Diagrama de caso de Usos de Aplicações

• •

• •

Catálogo de Normas de Tecnologia Catálogo de Portifólio de Tecnologia Matriz de Sistema/Tecnologia Diagrama de Ambientes e Locais Diagrmaa de Decomposição de Plataforma

Princípais Artefatos Do TOGAF 9

of 33

Full Content Metamodel

Slide 205

Full Content Metamodel with Relationships

Slide 206

de 45

Full Content Metamodel Artifacts

Slide 207

de 45

Extensões do Metamodelo

Slide 208

Governance Extension

Slide 209

Extensão de Governança •

Escopo: – –

–

–

•

A habilidade de aplicar medições para objetivos e, em seguida, ligar essas medidas a serviços A capacidade de aplicar contratos à comunicação de serviço ou interações de serviços com os usuários e sistemas externos A capacidade para definir as qualidades reutilizáveis ​de serviço que definem um perfil de nível de serviço que pode ser utilizado em contratos Criação de diagramas adicionais para mostrar a propriedade e gestão de sistemas

Diagramas adicionais a serem criados: – Diagrama de Gerenciabilidade da Corporação

Slide 210

Extensão de Governança • Esta extensão deve ser utilizado nas seguintes situações: – Quando uma organização está considerando mudança em TI que irá resultar em um impacto significativo para os modelos existentes de governança operacionais – Quando uma organização tem requisitos granulares para os níveis de serviço que diferem de serviço para serviço – Quando uma organização está procurando transformar sua prática de governança operacional Slide 211

Extensão de Serviços

Slide 212

Extensão de Serviços • Escopo: – Criação de serviços de SI como uma extensão de um serviço de negócio

• Diagramas adicionais a serem criados: – Diagramas de Casos de Uso de negócio – Diagrama de Decomposição da Organização

Slide 213

Extensão de Serviços •

Esta extensão deve ser usada nas seguintes situações: – Quando o negócio tem uma definição predefinida de seus serviços que não se alinha bem com as necessidades técnicas e arquiteturais – Quando o negócio e TI utilizam uma linguagem diferente para descrever capacidades semelhantes – Onde o serviço de TI está desalinhado com a necessidade de negócio, particularmente em torno das áreas de qualidade de serviço, visibilidade de desempenho, e granularidade de gestão – Onde TI está dando os primeiros os para envolver o negócio em discussões sobre arquitetura de TI

Slide 214

Extensão de Modelagem de Processos

Slide 215

Extensão de Modelagem de Processos •

Escopo: – Criação de eventos como acionadores para processos – Criação de controles que a lógica de negócios e governança leva para a execução do processo – Criação de produtos para representar a saída de um processo – Criação de diagramas de eventos para acompanhar acionadores e mudanças de estado em toda a organização

•

Diagramas adicionais a serem criados: – Diagramas de Fluxo de Processos – Diagramas de Eventos

Slide 216

Extensão de Modelagem de Processos • Esta extensão deve ser usada nas seguintes situações: – Onde a arquitetura deve prestar atenção especial no estado e eventos – Onde a arquitetura deve explicitamente identificar e armazenar as etapas de controle de processo; por exemplo, para ar a conformidade normativa – Onde a arquitetura apresenta fluxos de processo crítico ou complexos

Slide 217

Extensão de Dados

Slide 218

Extensão de Dados •

Escopo: – Criação de componentes de dados lógicos que agrupam as entidades de dados em módulos encapsulados para propósitos de governança, segurança e implantação – Criação de componentes de dados físicos que implementam componentes lógicos de dados; análogo a bases de dados, registros, repositórios, esquemas e outras técnicas de segmentação de dados – Criação de diagramas de ciclo de vida de dados, segurança de dados e de migração de dados para mostrar preocupações sobre dados em mais detalhes

•

Diagramas adicionais a serem criados: – – – –

Slide 219

Diagrama de Segurança de Dados Diagrama de Hierarquia de Classes Diagrama de Migração de Dados Diagrama de Ciclo de Vida de Dados

Extensão de Dados • Esta extensão deve ser usada nas seguintes situações: – Onde a arquitetura apresenta significativa complexidade e risco ao redor do local, encapsulamento e gestão ou o a dados

Slide 220

Extensão de Consolidação de Infraestrutura

Slide 221

Extensão de Consolidação de Infraestrutura •

•

Diagramas adicionais a serem criados: • Diagrama de Realização de Processo/Sistema • Diagrama de Engenharia de Software • Diagrama de Migração de Aplicação • Diagrama de Distribuição de Software • Diagrama de Processamento • Diagrama de Computação em Rede/Hardware • Diagrama de Engenharia de Comunicacões

Slide 222

Escopo: – Criação de uma entidade de localização para documentar a localização de ativos de TI e consumidores externos de serviço – Criação de componentes de aplicação lógicos e físicos para abstrair a capacidade de uma aplicação aplicações reais existentes – Criação de componentes físicos e lógicos de tecnologia para abstrair o tipo de produto separadamente dos produtos de tecnologia existentes – Criação de diagramas adicionais com foco na localização dos ativos, o cumprimento das normas, a estrutura de aplicações, a migração de aplicativos e a configuração de infraestrutura

Extensão de Consolidação de Infraestrutura •

Esta extensão deve ser usada nas seguintes situações: – Onde muitos produtos de tecnologia existem com capacidade duplicada ou sobreposta – Onde muitas aplicações existem com funcionalidade duplicada ou sobreposta – Quando as aplicações estão geograficamente dispersas e a lógica de decisão para determinar a localização de uma aplicação não é bem compreendida – Quando as aplicações vão ser migradas para uma plataforma consolidada – Quando os recursos de aplicações serão migrados para uma aplicação consolidada

Slide 223

Extensão de Motivação

Slide 224

Extensão Motivacional •

O escopo desta extensão é a seguinte: – Criação de uma nova entidade no metamodelo para “Direcionador” que mostrará fatores que genericamente motivarão ou limitarão a organização – Criação de uma nova entidade no metamodelo para “Meta” que mostrará propósito estratégico e a missão de uma organização – Criação de uma nova entidade no metamodelo para “Objetivo” que mostrará resultados de curto a médio prazo que uma organização gostaria de alcançar – Criação de um diagrama de Meta/Objetivo/Serviço mostrando a rastreabilidade de direcionadores, metas e objetivos aos serviços

• Diagramas adicionais a serem criados: – Diagrama de Meta/Objetivo/Serviço Slide 225

Extensão Motivacional • Esta extensão deve ser utilizado nas seguintes situações: – Quando a arquitetura precisa entender a motivação das organizações em mais detalhes do que os princípios normais de negócios ou engajamento e objetivos que são informalmente modelados dentro do metamodelo de conteúdo base – Quando as organizações têm direcionadores e objetivos conflitantes e que o conflito precisa ser compreendido e tratado de forma estruturada – Quando os níveis de serviço são desconhecidos ou pouco claros

Slide 226

TOGAF Metamodelo de Conteúdo

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 229

de 45

Módulo 8 Fase Preliminar

Edição V91 Copyright © 2009-2011

Slide 230

de 37

Todos os direitos reservados Publicado por The Open Group, 2011

Fase Preliminar

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 231

de 37

Fase Preliminar: Objetivos em Detalhe • Determinar a Capacidade de Arquitetura desejada pela

Organização: – Revisar o contexto organizacional para a condução da arquitetura corporativa – Identificar e definir o escopo dos elementos das organizações corporativas afetados pela Capacidade de Arquitetura – Identificar os frameworks estabelecidos, métodos e processos que se cruzam com a Capacidade de Arquitetura – Estabelecer uma meta de Maturidade da Capacidade

Continua… Slide 233

Fase Preliminar: Objetivos em Detalhe • Estabelecer a Capacidade de Arquitetura: – Definir e estabelecer o Modelo Organizacional para a Arquitetura Corporativa – Definir e estabelecer o processo detalhado e recursos para a governança da arquitetura – Selecionar e implementar ferramentas que am a Capacidade da Arquitetura – Definir os princípios de arquitetura

Slide 234

Abordagem • Definir a corporação • Identificar os principais direcionadores e elementos no contexto organizacional • Definir os requisitos para o trabalho de arquitetura • Definir os princípios de arquitetura que irão informar qualquer trabalho de arquitetura • Definir o framework a ser usado • Definir as relações entre frameworks de gerenciamento • Avaliar a maturidade da arquitetura corporativa

Slide 235

Fase Preliminar: Principais Entradas • TOGAF • Outros frameworks de arquitetura • Estratégias de negócios e planos de negócios executivos, estratégia de TI • Princípios de negócios, metas de negócio, e os direcionadores de negócio • Governança e frameworks legais Qualquer existente: • modelo organizacional • framework de arquitetura • princípios de arquitetura • repositório de arquitetura

Slide 236

os 6. Implementar Ferramentas de Arquitetura 5. Adaptar o TOGAF, e outros Frameworks de Arquitetura se houver 4. Identificar os Princípios de Arquitetura

3. Definir & Estabelecer a Equipe de Arquitetura Corporativa 2. Confirmar os frameworks de Governança e de e 1. Definir o escopo das Organizações impactadas na Corporação

Slide 237

1. Definir o escopo das organizações impactadas na Corporação • • • • •

Identificar corporação chave Identificar corporação leve (soft) Identificar corporação estendida Identificar comunidades Identificar a governança envolvida

Slide 238

2. Confirmar os Frameworks de Governança e de e • A saída principal desta fase é um framework para governança de arquitetura • Os modelos de governança e e existentes na organização provavelmente precisarão mudar • Os atuais modelos de governança e e precisam ser avaliados para entender seu conteúdo • Patrocinadores e partes interessadas terão de ser consultados sobre o impacto potencial Como resultado do o 2 pontos de contato da arquitetura e impactos prováveis devem ser entendidos e acordados pelas partes interessadas. Slide 239

3. Definir & Estabelecer a Equipe de Arquitetura Corporativa

• Determinar as capacidades existentes da corporação e do negócio • Conduzir uma avaliação de maturidade de mudança na arquitetura/negócio • Identificar lacunas nas áreas de trabalho atuais • Alocar os papéis e responsabilidades chaves para o gerenciamento e governança da capacidade da arquitetura corporativa • Escrever Solicitações de Mudança para os projetos existentes • Definir o escopo do novo trabalho de arquitetura corporativa • Determinar as limitações no trabalho de arquitetura corporativa • Revisar e acordar com os patrocinadores e executivos • Avaliar requisitos de orçamento Slide 240

4. Identificar os Princípios de

Arquitetura • Os princípios são normas e diretrizes que dizem como uma organização cumpre a sua missão. • Princípios corporativos permitem a tomada de decisões • Princípios de arquitetura se relacionam com o trabalho de arquitetura, e incluem: – Princípios de processos de Arquitetura – Princípios de implementação de Arquitetura

Slide 241

Definindo Princípios de Arquitetura • Por quê – Princípios de arquitetura fornecem um framework para tomada de decisões • Quem – Desenvolvido por Arquitetos Corporativos – Em conjunto com partes interessadas chave • O CIO da Corporação • O Comitê de Arquitetura • Outras partes interessadas chave

Slide 242

Modelo para Princípios do TOGAF Nome • Deve representar a essência da regra, e ser memorável • Não deve mencionar plataformas tecnológicas específicas • Deve evitar palavras ambíguas Descrição • Deve suscintamente e de forma não ambígua comunicar a regra fundamental

Continued… Slide 243

TOGAF Template for Principles Razão de Ser • Deve destacar os benefícios da adesão ao princípio, usando terminologia de negócios • Deve descrever a relação com outros princípios Implicações

• •

Deve destacar os requisitos para o negócio e para a TI para a realização do princípio. Deve indicar o impacto nos negócios e as consequências da adoção do princípio

Slide 244

Um Exemplo de Declaração de Princípios • O seguinte grupo de princípios foi aprovado pelo Comitê de Arquitetura interno Princípios de Negócio: 1. Primazia dos Princípios 2. Maximizar os benefícios para a corporação 3. Conformidade com a Lei 4. Disponibilidade a qualquer hora de qualquer lugar 5. Continuidade de Negócio 6. Cidadania Continua… Slide 245

Um Exemplo de Declaração de Princípios 7. Custódia 8. Des-Customização 9. Experiência do Usuário indolor 10. Autoatendimento 11. Compartilhamento de Informações Princípios de Arquitetura: 1. Des-Habilidade 2. Uma Origem 3. Gerenciamento de Conteúdo Slide 246

Estudo de caso do Open Group: Y082

Exemplo: Primazia dos Princípios Descrição

Princípios se aplicam em toda a corporação e substituem todas as outras considerações quando as decisões são tomadas

Razão de Ser

A única maneira de fornecer um nível reconhecido, consistente e mensurável de operações é se todas as partes da corporação respeitarem os princípios ao tomar decisões

Implicações

Sem esse princípio, considerações de curto prazo, supostas exceções convenientes e inconsistências iriam rapidamente comprometer a gestão da informação. Iniciativas de gestão de informação não serão autorizadas até que sejam examinadas quanto ao cumprimento dos princípios. Um conflito com um princípio será resolvido alterando a iniciativa conflitante, o que pode atrasar ou impedir a iniciativa.

Slide 247

Exemplo: Auto-atendimento Descrição

Clientes devem ser capazes de atenderem a si mesmos.

Razão de Ser

Aplicando este princípio, será melhorada a satisfação do cliente, reduzindo a sobrecarga istrativa e, potencialmente, melhorando a receita.

Implicações

Há uma implicação para melhorar a facilidade de uso e minimizar as necessidades de treinamento; por exemplo, os membros devem ser capazes de atualizar seus dados para contato, etc. e ser capazes de comprar produtos de associação adicionais online.

Slide 248

Cinco Qualidades dos Princípios 1. Inteligível: eles podem ser rapidamente compreendidos. A intenção é clara e inequívoca.

2. Robusto: eles permitem boas decisões sobre arquiteturas e planos, e habilitam a criação de políticas ​e padrões obrigatórios. Um princípio deve ser preciso para apoiar a tomada de decisão consistente em situações complexas. 3. Completo: todos os princípios potencialmente importantes para a gestão de TI estão definidos. Princípios cobrem todas as situações percebidas. Continua… Slide 249

Cinco Qualidades dos Princípios 4. Consistente: a estrita adesão a um princípio pode exigir a interpretação livre de outro. Princípios devem ser expressos de uma forma que permita um equilíbrio das interpretações e não devem ser contraditórios.

5. Estável: Princípios devem ser duradouros, ainda que capazes de acomodar mudança. Um processo de alteração deve ser estabelecido para adicionar, remover ou alterar princípios depois de serem ratificados.

Slide 250

Princípios e Metamodelo • Informações relacionadas aos Princípios podem ser modeladas, se a informação certa for capturada • O metamodelo relaciona Princípios de volta para direcionadores, metas e objetivos específicos

Slide 251

5. Adaptar o TOGAF, e outros Frameworks de Arquitetura se houver • Adaptando o a terminologia: o melhor é usar a terminologia que é entendida em toda a corporação. • Adaptando o processo: o é um processo genérico. A adaptação de processo nos permite remover tarefas que são realizadas em outros lugares, adicionar tarefas específicas de organização e alinhar os processos do com os frameworks de processos externos. • Adaptando o Conteúdo : usando o Framework de Conteúdo de Arquitetura do TOGAF, permite a adoção de frameworks de conteúdo de terceiros e a personalização do framework para dar e aos requisitos específicos da organização Slide 252

Adaptando a Terminologia • Falta de concordância sobre os significados de termos precisos pode causar problemas de comunicação durante o trabalho de Arquitetura. • Definir e acordar uma terminologia padrão • Fornecer um glossário, se for o caso

Slide 253

Adaptação de Processo • Reordenar as fases do • Usar apenas um subconjunto das fases • Completar os Sistemas de Informação ou Arquitetura Tecnológica primeiro

Slide 254

Adaptação do Conteúdo

Slide 255

Slide 256

de 37

6. Implementar Ferramentas de Arquitetura Neste o devemos selecionar ferramentas de arquitetura apropriadas. A implementação das ferramentas pode variar desde uma tarefa trivial até uma atividade de implementação de sistema mais envolvente utilizando o metamodelo de conteúdo do TOGAF

Slide 257

Fase Preliminar: Saídas • Modelo Organizacional para a Arquitetura Corporativa • Framework de Arquitetura adaptado, incluindo os princípios de arquitetura • Repositório de Arquitetura inicial • Reafirmação de princípios, metas e direcionadores de negócios • Requisição para Trabalho de Arquitetura • Framework de Governança de Arquitetura Slide 258

Resumo Fase Preliminar Objetivos

os

Entradas

Saídas

Determinar a capacidade de Arquitetura

Definir o escopo das Organizações impactadas na Corporação

• •

•

desejada pela Organização: •Revisar o contexto organizacional para a condução da arquitetura corporativa •Identificar e definir o escopo dos elementos das organizações corporativas afetados pela Capacidade de Arquitetura •Identificar os frameworks estabelecidos, métodos e processos que se cruzam com a Capacidade de Arquitetura •Estabelecer uma meta de Maturidade da Capacidade Estabelecer a Capacidade de Arquitetura: •Definir e estabelecer o Modelo Organizacional para a Arquitetura Corporativa •Definir e estabelecer o processo detalhado e recursos para a estrutura de governança •Selecionar e implementar ferramentas que am a Capacidade da Arquitetura •Definir os princípios de arquitetura

Slide 260

•

Confirmar os frameworks de Governança e de e

•

Definir & Estabelecer a Equipe de Arquitetura Corporativa

•

Identificar os Princípios de Arquitetura Adaptar o TOGAF, e outros Frameworks de Arquitetura se houver Implementar Ferramentas de Arquitetura

•

•

TOGAF Outros frameworks de arquitetura Estratégias de negócios e planos de negócios executivos, estratégia de TI Princípios de negócios, metas de negócio, e os direcionadores de negócio Governança e frameworks jurídicos Contratos de Parceiria Existentes Modelos de Arquitetura Corporativa Existente

Qualquer existente: • modelo organizacional • estrutura de arquitetura • princípios de arquitetura • repositório de arquitetura • Método de Arquitetura • Conteúdo de Arquitetura • Ferramentas configuradas e implantadas

•

• • •

•

Modelo Organizacional para a arquitetura corporativa Framework de Arquitetura Adaptado, incluindo os princípios de arquitetura Repositório de Arquitetura inicial Reafirmação de princípios de negócios, metas e direcionadores Requisição para Trabalho de Arquitetura Framework de Governança de Arquitetura

Fase Preliminar • Catálogo de Principios Gerenciamento de Requisitos Fase B, Arquitetura de Negócio • • • • • • • • • • • •

• • • • • •

Fase A, Visão de Arquitetura •

Matriz de Mapa de Partes interessadas

• Diagrama Conceitual • Diagrama de Cadeia de Valor da Soluçao

TOGAF 9 Artifacts • Catálogo de Requisitos Fase C, Arquitetira de Dados

Catálogo de Organização/Ator Catálogo de Direcionador/Meta/Objetivo Catálogo de Papéis Catálogo de Serviço de Negócio/Função Catálogo de Localidades Catálogo de Processo/Evento/Controle/Produ to Catálogo de Contrato/Medida Matriz de Interação de Negócio Matriz de Ator//Papel Diagrama de “Footprint” de Negócio Diagrama de Serviço de Negócio/Informação Diagrama de Decomposição Funcional Diagrama de Ciclo de Vida de Produto Diagrama de Meta/Objetivo/Serviço Diagrama de Casos de Uso de Negócio Diagrama de Decomposição da Organização Diagrama de Fluxo de Processo Diagrama Slide 261 de Evento

Fase E. Oportunidades e Soluções

•

• • •

• • • • •

Catálogo de Entidade de Dados/ Componente de Dados Matriz de Entidade de Dados/Funções de Negócio Matriz de Aplicação/Dados Diagrama lógico de dados Diarama de Disseminação de Dados Diagrama de segurança de Dados Diagrama hierárquico de Classes Diagrama de Migração de Dados Diagrama de Ciclo de Vida de Dados

Fase C, Arquitetura de Aplicação

Fase D, Arquitetura Tecnológica

•

•

• • • • • • • • • • • • •

of 33

Catálogo de Portifólio de Aplicação Catálogo de Interface Matriz de Aplicação/Organização Matriz de Papel/Aplicação Matriz de Aplicação/Função Matriz de Interação de Aplicação Diagrama de Comunicação de Aplicação Diagrama de Localização de Aplicação e Usuário Diagrama de caso de Usos de Aplicações Diagrama de gerenciabiliade da Corporação Diagrama de Realização de Processo/Aplicação Diagrama de Engenharia de Software Diagrmaa de Migração de Aplicação Diagrama de Distribuição de Software

•

• • •

• • •

Catálogo de Normas de Tecnologia Catálogo de Portifólio de Tecnologia Matriz de Sistema/Tecnologia Diagrmaa de Ambientes e Locais Diagrmaa de Decomposição de Plataforma Diagrama de Processamento Diagrmaa de Computação em Rede/Hardware Diagrama de Engenhari de Comunicação

Artefatos

P

Catálogos

Catálogo Catálogo de Princípios

Propósito O catálogo de princípios captura princípios dos princípios do negócio e princípios de arquitetura que descrevem quão “bem” uma solução ou arquitetura deve parecer. Princípios são usados para avaliar e acordar uma saída para pontos de decisão de arquitetura. Princípios também são usados como uma ferramenta para ajudar na governança arquitetural de iniciativas de mudança. •Catálogo de Princípios contém as seguintes entidades de metamodelo: * Princípio

Slide 262

Fase Preliminar

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 266

de 37

Módulo 9 Governança da Arquitetura Edição V9.1 Copyright © 2009-2011

Slide 267

de 35

Todos os direitos reservados Publicado por The Open Group, 2011

Governança da Arquitetura

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 268

de 35

Introdução à Governança Governança é a prática pela qual arquiteturas corporativas são gerenciadas e controladas. Isto inclui: • controles sobre a criação e monitoramento de componentes e atividades – garantindo a introdução, implementação e evolução das arquiteturas • assegurar o cumprimento das normas internas e externas e obrigações regulatórias • ando o gerenciamento do supracitado • assegurar a prestação de contas para as partes interessadas internas e externas

Slide 270

Governança e o • A Governança deve ser estabelecida na Fase Preliminar – Usualmente uma adaptação modelos existentes de governança e de e • O Comitê de Arquitetura deve assegurar que o está sendo aplicado corretamente – Aderência ao é fundamental para a governança da Arquitetura • Governança desempenha um papel fundamental nas Fases GeH – As atividades de implementação e depois gerenciamento de mudanças Slide 271

Natureza da Governança • A governança garante que o negócio é conduzido corretamente. • É sobre o uso eficaz e equitativo dos recursos para garantir a sustentabilidade dos objetivos estratégicos.

Continued Slide 272

Natureza da Governança • Princípios básicos da governança corporativa: – Foco nos direitos, papéis e tratamento equitativo dos acionistas – Divulgação e transparência – Prestação de contas do Conselho de istração para os acionistas • Responsabilidades do Conselho: • Rever e orientar a estratégia corporativa • Definir e acompanhar os objetivos de performance alta istração Slide 273

Governança – Princípios Básicos [Governança é] "... o sistema pelo qual as

corporações são dirigidas e controladas. A estrutura de governança corporativa especifica a distribuição de direitos e responsabilidades entre os diferentes participantes [...] e define as regras e procedimentos para a tomada de decisões nas questões corporativas. [...] Fornece também a estrutura através da qual os objetivos da empresa são definidos, e os meios de atingir esses objetivos e monitorar o desempenho "[OCDE (1999)]. Slide 274

Níveis de Governança A hierarquia de domínios de governança inclui: • Governança de Tecnologia • Governança de TI • Governança da Arquitetura Cada domínio pode existir em vários níveis geográficos: • Global • Regional • Locais

Slide 275

Um Framework de Governança de TI COBIT • COBIT é um padrão aberto para o controle de TI. • Ele foi desenvolvido e promovido pelo IT Governance Institute. • COBIT fornece um padrão geralmente aceito para boas práticas de segurança de TI e controle • Há também um conjunto de orientações de gestão para o COBIT, incluindo Modelos de Maturidade, Fatores Críticos de Sucesso, Indicadores Chave de Objetivos e Indicadores Chave de Desempenho. • O framework pode ajudar os gestores a controlar e medir os recursos de TI.

Slide 276

Framework de Governança da Arquitetura do TOGAF • A Fase G do do TOGAF é sobre Governança da Implementação – a realização de arquitetura através de projetos de mudança • A Governança da Arquitetura cobre o gerenciamento e controle de todos os aspectos do desenvolvimento e evolução de arquiteturas corporativas • O Framework de Governança da Arquitetura é genérico e pode ser adaptado a um ambiente de governança existente. Ele ajuda a identificar processos eficazes e estruturas organizacionais, de forma que as responsabilidades de negócio possam ser esclarecidas, comunicadas, e gerenciadas. Slide 277

Estrutura Conceitual

Slide 278

Framework de Governança da Arquitetura – Estrutura Conceitual • Governança da Arquitetura é uma abordagem, uma série de processos, uma orientação cultural e um conjunto de responsabilidades que asseguram a integridade e a efetividade de arquiteturas. • A divisão entre processo, conteúdo, e contexto é fundamental para apoiar uma iniciativa de governança da arquitetura. Ela permite a introdução de material novo de governança, sem afetar os processos e garante flexibilidade do Framework.

Slide 279

Estrutura Conceitual •

O Framework de Governança da Arquitetura é essencial para o Continuum da Corporação, e gerencia todo o conteúdo, tanto para os processos de arquitetura como os de governança da arquitetura.

Slide 280

Estrutura Organizacional

Slide 281

Estrutura Organizacional • Governança é a gestão e controle de arquiteturas. • Para garantir um controle efetivo, é necessário ter as estruturas organizacionais corretas para apoiar todas as atividades de governança. • Uma implementação efetiva requer processos de Governança de TI, estruturas organizacionais e capacidades, incluindo (por exemplo): – – – –

Slide 282

Comitê global de governança Comitê local de governança Autoridades de Design Grupos de trabalho

Benefícios da Governança da Arquitetura • Liga processos, recursos e informações às estratégias e objetivos organizacionais • Integra e institucionaliza boas práticas • Alinha com frameworks da indústria • Permite a organização tirar pleno proveito de seus ativos • Protege os ativos digitais subjacentes da organização • Dá e aos requisitos regulatórios e de melhores práticas • Promove uma gestão de risco visível

Slide 283

Governança de Arquitetura na Prática Fatores chave de sucesso incluem: • Melhores práticas para a submissão, adoção, reutilização, reporte e retirada de políticas, procedimentos, papéis, competências, estruturas organizacionais, e serviços de apoio de arquitetura

• Responsabilidades organizacionais e estruturas para apoiar os processos de governança da arquitetura e requisitos de reporte

Continued Slide 284

Governança da Arquitetura na Prática • Ferramentas e processos para promover a adoção proceduralmente e culturalmente • Gestão de critérios para controle de processos de governança da arquitetura, dispensas, avaliações de conformidade, SLAs e OLAs • Atender aos requisitos internos e externos para a eficácia, eficiência, confidencialidade, integridade, disponibilidade, conformidade e confiabilidade das informações, serviços e processos relacionados com a Governança da Arquitetura

Slide 285

Comitê de Arquitetura • O Comitê supervisiona a implementação da estratégia de governança • O Comitê é composto de partes interessadas representativas responsáveis ​pela revisão e manutenção da arquitetura tipicamente em dois níveis: – Local (especialistas em domínios, responsabilidade de linha) – Global (responsabilidade por toda a organização) • Para cada Comitê, são identificados e articulados: • Capacidades de tomada de decisão e responsabilidades • Limites de competência e autoridade Slide 286

O Valor do Comitê de Arquitetura • O custo é compensado pela prevenção de soluções extraordinárias e desenvolvimentos sem restrições que levam a: – Elevados custos de desenvolvimento, operação e e, devido a inúmeros ambientes de execução, linguagens, interfaces, protocolos ... – Qualidade inferior – Maior risco – Dificuldade em replicar e reutilizar soluções

Slide 287

Responsabilidades do Comitê de Arquitetura • Fornecer a base para todas as decisões no que diz respeito a alterações nas arquiteturas • Garantir a consistência entre as sub-arquiteturas • O estabelecimento de metas para a reutilização de componentes • Garantir a flexibilidade da arquitetura corporativa: – Para atender às necessidades de negócio em mudança – Para alavancar novas tecnologias

• Garantia da Conformidade da Arquitetura • Melhorar o nível de maturidade da arquitetura dentro da organização • Assegurar que a disciplina de desenvolvimento baseado em arquitetura é adotada • Apoiar uma capacidade de escalação visível para decisões fora de alçada

Slide 288

Operações do Comitê de Arquitetura • O TOGAF fornece orientações sobre operações do Comitê • Estas são primariamente focadas nas melhores práticas para condução de reuniões • Por exemplo: – As reuniões devem ser realizadas com agendas claramente definidas – Cada participante participando de uma reunião deve estar totalmente preparado

• O TOGAF fornece uma amostra de esboço de pauta

Slide 289

Contratos de Arquitetura • Acordos comuns entre os parceiros de desenvolvimento e patrocinadores sobre os entregáveis, qualidade e adequação aos propósitos de uma arquitetura

Slide 290

Contratos de Arquitetura • O uso de Contratos de Arquitetura garante: – Monitoramento contínuo para checar a integridade, mudanças, tomadas de decisão, e auditoria de todas as atividades relacionadas com arquitetura – Adesão aos princípios, normas e requisitos das arquiteturas existentes ou em desenvolvimento – Identificação dos riscos – Um conjunto de processos e práticas que asseguram a atribuição de responsabilidade e disciplina com relação ao desenvolvimento e uso de todos os artefatos arquiteturais – Um entendimento formal da organização da governança

Slide 291

Contratos de Arquitetura e o • A Declaração de Trabalho de Arquitetura criada na Fase A • Domínios de Arquitetura (Negócio, Dados, Aplicação e Tecnologia) • Fase G • Projetos de implementação

Slide 292

Conformidade da Arquitetura Dois processos são definidos para garantir a conformidade de projetos com a arquitetura corporativa: 1. Preparar Avaliações de Impacto do Projeto – visões específicas de projetos que ilustram como a Arquitetura Corporativa impacta um projeto 2. Executar uma Avaliação de Conformidade da Arquitetura

Slide 294

Avaliações de Conformidade da Arquitetura • • • •

• •

• • • •

Detectar erros de arquitetura no projeto o mais cedo possível. Garantir a aplicação das melhores práticas de trabalho de arquitetura. Fornecer uma visão geral do cumprimento de normas obrigatórias. Identificar onde as próprias normas podem necessitar de modificações. Identificar os serviços que estão atualmente como específicos da aplicação mas podem ser oferecidas como parte da infraestrutura da corporação. Documentar estratégias para colaboração, compartilhamento de recursos, e outras sinergias entre múltiplas equipes de arquitetura. Levar vantagem dos avanços tecnológicos. Comunicar à gerência o estado da prontidão tecnológica do projeto. Identificar os principais critérios para atividades de compra. Identificar e comunicar lacunas significativas na arquitetura em relação a produtos e provedores de serviço.

Slide 295

Processo de Avaliação de Conformidade de Arquitetura

Slide 296

Estabelecendo uma Capacidade de Arquitetura • O TOGAF fornece orientações para estabelecer uma capacidade de Arquitetura Corporativa usando o – Tratamento como uma prática contínua – Abordar os quatro domínios de Arquitetura • Arquitetura de Negócio: a governança da arquitetura, processos de arquitetura, estrutura organizacional da arquitetura, requisitos de informação de arquitetura, produtos de arquitetura, etc. • Arquitetura de Dados: a estrutura do Continuum da Corporação da organização e Repositório de Arquitetura • Arquitetura de Aplicação: a funcionalidade e/ou serviços de aplicação requeridos para habilitar a prática de arquitetura • Arquitetura Tecnológica: requisitos e implementações de infraestrutura para dar e às aplicações da arquitetura e ao Continuum da Corporação Slide 297

Governança da Arquitetura

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 301

34 34

Módulo 10 Cenários de Negócio Edição V9.1 Copyright © 2009-2011

Slide 302

de 24

Todos os direitos reservados Publicado por The Open Group, 2011

Cenários de Negócio

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 303

de 24

Introdução Principais fatores para o sucesso de qualquer arquitetura corporativa são: • a medida em que está relacionada com os requisitos de negócio, e • o seu apoio para os objetivos de negócios. Cenários de negócio nos ajudam a identificar e entender os requisitos de negócio que o desenvolvimento da arquitetura deve atender.

Slide 305

O Que é um Cenário de Negócio? Un cenário de negócio descreve: • um processo de negócio, aplicação ou conjunto de aplicações que podem ser habilitados pela arquitetura • o ambiente de negócios e tecnologia; • as pessoas e componentes de computação (os "atores") que o executam; • o resultado desejado de uma execução adequada.

Slide 306

Cenários de Negócio • O TOGAF define um método para o desenvolvimento de Cenários de Negócio – Um “método dentro de um método” – Documentado na Parte III, Orientações e Técnicas do

Slide 307

Cenários de Negócio e o Usado de forma proeminente na Fase A (Visão da Arquitetura) e iterativamente na Fase B (Arquitetura de Negócio) Requisitos de Negócio são referidos em todas as fases do

Slide 308

O Que é um Bom Cenário de Negócio? Um bom cenário de negócio: • É representativo de uma significativa necessidade de negócio ou problema • Permite que os fornecedores compreendam o valor de uma solução desenvolvida para um cliente • É “SMART”

Slide 309

SMART • eSpecifico – define o que precisa ser feito no negócio; • Mensurável – possui métricas claras de sucesso; • Acionável – claramente segmenta o problema e fornece a base para a busca de uma solução; • Realístico – define os limites da capacidade tecnológica e restrições de custo; • Vinculados ao Tempo – dá uma compreensão clara de quando uma solução expira

Slide 310

Os Benefícios de Cenários de Negócio Um cenário de negócio deve ser uma descrição completa de um problema de negócio Sem isso: • Há perigo de que os requisitos não estejam completos • O valor do negócio em solucionar o problema será incerto • A relevância das possíveis soluções será pouco clara Um cenário: • pode desempenhar um papel importante no envolvimento das partes interessadas • pode ajudar a estabelecer uma boa comunicação com fornecedores desde o início. Slide 311

Quem Contribui para um Cenário de Negócio • A criação de um cenário de negócio não é apenas de responsabilidade do arquiteto • A gerência de linha de negócio e outras partes interessadas da empresa devem estar envolvidos • Também pode envolver uma empresa fornecedora de TI • Tipicamente o envolvimento da gerência é maior nas primeiras etapas enquanto o comprometimento do arquiteto é maior em fases posteriores

Slide 312

Desenvolvendo um Cenário de Negócio 1 - Identificar, documentar e classificar o problema conduzindo o cenário 2 - Identificar o ambiente técnico e de negócio do cenário e documentá-lo em modelos de cenários 3 - Identificar e documentar os objetivos desejados - os resultados para resolver os problemas com sucesso - utilizando o SMART

1 - problem 2 - environment

3 - objectives

Continued Slide 313

Desenvolvendo um Cenário de Negócio 4 - Identificar os atores humanos e seus lugares no modelo de negócios 5 - Identificar os atores computacionais (elementos de computação), e seus lugares no modelo de tecnologia 6 - Identificar e documentar papéis, responsabilidades e medidas de sucesso por ator 7 - Verifique se há "adequação ao propósito" e refinar se necessário

1 - problem 2 - environment

3 - objectives 4 - human actors 5 - computer actors 6 - roles & responsibilities

7 - refine Slide 314

Entendendo Bem os Cenários de Negócio • Clientes quase sempre sabem o que querem – Mas muitas vezes não é escrito, especialmente a ligação aos negócios – Então nós ajudamos a anotar

• Clientes muitas vezes não sabem o que eles realmente precisam – Então, nós observamos e questionamos para ajudar a descobrir o que é necessário – Nós ajudamos a trazer à superfície regras de negócio essenciais – Focamos também o "o que", não o "como"

• Cenários de Negócio são parte de um processo maior. Eles são uma técnica, não um fim em si mesmos. Slide 315

Conteúdo de um Cenário de Negócio • Modelos de Cenário de negócio devem: – Capturar visões de negócios e de tecnologia graficamente para ajudar a compreensão – Fornecer um ponto de partida para os requisitos, – Relacionar os atores e interações

• Descrições de Cenários de Negócio devem: – Capturar os os críticos entre atores na seqüência correta – Particionar a responsabilidade dos atores – Listar as pré-condições que precisam ser satisfeitas antes da funcionalidade adequada do sistema, e – Fornecer requisitos técnicos para garantir que o serviço possua qualidade aceitável

Slide 316

Modelo para um Cenário de Negócio • Descrição do problema do cenário de negócio • Objetivos detalhados • Visões de ambientes e processos • Atores, seus papéis e responsabilidades • Princípios e Limitações • Requisitos • Próximos os • Glossário de termos e abreviações • Referências Slide 317

Cenários de Negócio

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 325

de 24

Módulo 11 Gerenciamento de Partes Interessadas Edição V9.1 Copyright © 2009-2011

Slide 326

de 19

Todos os direitos reservados Publicado por The Open Group, 2011

Gerenciamento de Partes Interessadas

O TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 327

de 19

Roap Parte I - Introdução Prefácio, Preface, Visão global executiva, Principais Conceitos, Definições e Notas da Versão

Parte II – Método de Desenvolvimento da Arquitetura Introdução ao Narrativas das Fases do

Parte III – Orientações e Técnicas do Orientações para Adaptação do Processo do Técnicas para o Desenvolvimento da Arquitetura

Parte IV – Framework de Conteúdo da Arquitetura Metamodelo de Conteúdo Artefatos Arquiteturais Entregáveis da Arquitetura Blocos de Construção

Parte V – Continuum da Corporação e Ferramentas Continuum da Corporação Particionamento da Arquitetura Repositório da Arquitetura Ferramentas para o Desenvolvimento da Arquitetura

Parte VI – Modelos de Referência do TOGAF Arquitetura de Fundação: Modelo de Referência Técnico Modelo de Referência da Infraestrutura Integrada da Informação

Parte VII – Framework de Capacidade da Arquitetura Comitê de Arquitetura Aderência da Arquitetura Contratos da Arquitetura Governança da Arquitetura Modelos de Maturidade da Arquitetura Frameworks de Competências da Arquitetura

Slide 328

• Parte III, Orientações e Técnicas do , Capítulo 24

Objetivos do Módulo Os objetivos são: • Explicar como aplicar a técnica de gerenciamento de partes interessadas • Entender as etapas de desenvolvimento de um mapa de partes interessadas e como utilizar o mapa • Entender os benefícios para a criação de visões, e relacionando estas às partes interessadas e suas preocupações

Slide 329

Visão Geral • O Gerenciamento de Partes Interessadas é uma disciplina importante que os profissionais de arquitetura podem usar com sucesso para ganhar apoio de outros • Esta técnica deve ser utilizada na Fase A para identificar pessoas chave (key players) e ser atualizada ao longo de cada fase • A saída deste processo faz parte do Plano de Comunicação

Slide 330

Benefícios • Identificar as partes interessadas mais poderosas logo no início e assegurar que a suas considerações sejam usadas para moldar a arquitetura • Conseguir apoio das partes interessadas mais poderosas pode ajudar a alcançar os recursos necessários • A comunicação inicial com as partes interessadas ajuda a garantir que todos compreendem o processo de arquitetura e estão envolvidos nele • Pode ser usado para antecipar prováveis ​reações e desenvolver uma estratégia para enfrentá-las • Pode ser usado para identificar os conflitos ou objetivos conflitantes entre as partes interessadas e desenvolver estratégias para gerenciar

Slide 331

Partes Interessadas Executive

CxO Programme Management Office

Line Management

Executive

HR

Line Management

IT Service Business Management Domain Experts

Partes Interessadas têm papéis chave em, ou preocupações sobre, a arquitetura corporativa. Partes Interessadas podem ser pessoas, equipes, organizações, etc.

Functional / Business Process Experts

Application Management

Infrastructure Management

Data / Voice Communications

Stakeholder Types

Corporate

Slide 332

System

End -

Project

QA / Standards Groups

Product Specialists

Enterprise Security

Technical Specialists

Procurement

Stakeholder Management Executive

Line Management

CxO

TOGAF fornece uma abordagem o a o:

Programme Management Office

o 1: Identificar Partes Interessadas o 2: Classificar Posições das Partes Executive Interessadas o 3: Determinar abordagem do Line gerenciamento de Partes HR Management Interessadas o 4: Adaptar entregáveis para o Functional / IT Service Business Business engajamento Management Domain Process Experts

Application Management

Infrastructure Management

Experts Data / Voice Communications

Stakeholder Types

Corporate

Slide 333

System

End -

Project

QA / Standards Groups

Product Specialists

Enterprise Security

Technical Specialists

Procurement

o 1: Identificar Partes Interessadas • Identificar as principais partes interessadas da arquitetura corporativa. • Olhar para quem é afetado pelo projeto de arquitetura corporativa: – – – – – – – –

Quem ganha e quem perde com essa mudança? Quem controla o gerenciamento de mudanças dos processos? Quem desenha novos sistemas? Quem vai tomar as decisões? Quem adquire sistemas de TI e quem decide o que comprar? Quem controla os recursos? Quem são os especialistas de que o projeto precisa? Quem tem influência?

Slide 334

Categorias de Partes Interessadas

Slide 335

o 2: Classifique a Posição das Partes Interessadas • Classificar e registrar as posições em uma Matriz de Análise das Partes Interessadas Grupo de Partes Interessadas

Parte Interessada

Habilidade de romper a mudança

Entendimento atual

Entendimento requerido

Compromisso atual

Compromisso requerido

e requerido

CIO

John Smith

A

M

A

B

M

A

CFO

Jeff Brown

M

M

M

B

M

M

Slide 336

o 3: Determinar a Abordagem do Gerenciamento de Partes Interessadas • Identifique o poder, a influência e interesse das partes interessadas, de modo a concentrar o engajamento nos indivíduos chave. • Estes podem então ser mapeados em uma matriz de poder / interesse, que é usada para determinar uma estratégia para o engajamento com eles.

Slide 337

o 3: Determinar a Abordagem do Gerenciamento de Partes Interessadas • Desenvolver uma Matriz de Poder/Interesse e colocar os grupos de Partes Interessadas nela

Slide 338

o 4: Adaptar os Entregáveis de Engajamento • Para cada grupo de Partes Interessadas: – Identificar os pontos de vista que o empenho da arquitetura precisa produzir e validar com cada grupo de partes interessadas – Definir pontos de vista, matrizes e visões específicos do modelo de arquitetura corporativa

Slide 339

Exemplo: Mapa de Partes Interessadas Grupo de Partes Interessadas

CLASSE

EXAMPLO DE PAPÉIS

PRINCIPAIS PREOCUPAÇÕES

CLASSE

Catálogos, Matrizes e Diagramas

Funções Corporativas

CxO

CEO, CFO, CIO, COO

Os direcionadores de alto nível, metas e objetivos da organização, e como estes são traduzidos em um processo eficaz e arquitetura de TI para avançar o negócio.

MANTER SATISFEITO

Diagrama de “Footprint” de Negócio Diagrama de Meta/ Objetivo/Serviço Diagrama de Decomposição Organizacional

Funções Corporativas

Program Management Office

Gerentes de Portifólio de Projetos

Priorização, financiamento e alinhamento de atividades de mudança. Uma compreensão do conteúdo do projeto e dependências técnicas entre projetos acrescenta uma nova dimensão de riqueza ao portfólio para tomada de decisões de gestão.

MANTER SATISFEITO

Catálogo de Requisitos Diagrama de “Footprint” de Negócio Diagrama de Comunicação de Aplicação Diagrama de decomposição Funcional

Funções Corporativas

Slide 340

Compras

Compradores

Entender quais blocos de construção da arquitetura podem ser comprados, e quais as restrições (ou regras) existem e que são relevantes para a compra. O adquirente vai comprar com vários fornecedores que procuram a melhor solução de custo ao aderir às restrições (ou regras), aplicadas pela arquitetura, como padrões. A principal preocupação é fazer com que as decisões de compra que se encaixem na arquitetura, e, assim, reduzir o risco de custos adicionais decorrentes de componentes sem conformidade

PRINCIPAIS ATORES

Catálogo de Portifólio Tecnológico Catálogo de Padrões Tecnológicos

Gerenciamento de Partes Interessadas

O TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 344

de 19

Módulo 12 Visões e Pontos de Vista Edição V9.1 Copyright © 2009-2011

Slide 345

of 33

Todos os direitos reservados Publicado por The Open Group, 2011

Visões e Pontos de Vista

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 346

of 33

Objetivos do Módulo • Entender os conceitos de visões e pontos de vista • Entender o papel das Visões de Arquitetura • Introduzir alguns recursos do TOGAF Fonte: www.pfosphene.com

Slide 347

Conceitos e Definições • • • • •

Sistema Partes Interessadas Preocupações Visão Ponto de Vista

Slide 348

Sistema (System) • Um sistema é uma coleção de componentes organizados para concluir uma função específica ou conjunto de funções.

Source: IONA Source: SGI

Slide 349

Partes Interessadas (Stakeholders) Executive

CxO Programme Management Office

Line Management

Executive

HR

Line Management

IT Service Business Management Domain Experts

Functional / Business Process Experts

As partes interessadas são pessoas que têm papéis chave em, ou preocupações sobre, o sistema. Por exemplo, os usuários, desenvolvedores etc. Partes interessadas podem ser indivíduos, equipes, organizações, etc

Application Management

Infrastructure Management

Data / Voice Communications

Stakeholder Types

Corporate

Slide 350

System

End -

Project

QA / Standards Groups

Product Specialists

Enterprise Security

Technical Specialists

Procurement

Preocupações (Concerns) Executive

Line Management

Executive

HR

Line Management

IT Service Business Management Domain Experts

Functional / Business Process Experts

CxO

Preocupações são os interesses chave que são de importância crucial para as partes interessadas, e determinam a aceitabilidade do sistema. - Eles podem incluir confiabilidade, desempenho, segurança, distribuição, evolução, etc

Programme Management Office

Application Management

Infrastructure Management

Data / Voice Communications

Stakeholder Types

Corporate

Slide 351

System

End -

Project

QA / Standards Groups

Product Specialists

Enterprise Security

Technical Specialists

Procurement

Visão (View) • A visão é uma representação de um sistema a partir da perspectiva de um conjunto relacionado de preocupações. • Um arquiteto cria modelos de arquitetura. Uma visão consiste de partes destes, escolhidas para mostrar às partes interessadas que as suas preocupações estão sendo atendidas.

Slide 352

Ponto de Vista (Viewpoint) • Um ponto de vista define a perspectiva de que uma visão é tomada. • Ele define como construir e usar uma visão, a informação necessária, as técnicas de modelagem para expressar e analisá-la e uma justificativa para essas escolhas (por exemplo, ao descrever a finalidade e público-alvo da visão).

Slide 353

Source: IEEE Std 1471-2000. Used with permission

Slide 354

Visões e Pontos de Vista • O arquiteto usa visões e pontos de vista nas fases A a D para o desenvolvimento de arquiteturas para cada domínio (negócio, dados, aplicação, tecnologia). • A visão é o que você vê. • Um ponto de vista é de onde você está olhando, a visada ou perspectiva que determina o que você vê. • Cada visão possui um ponto de vista associado que a descreve, pelo menos implicitamente. • Pontos de vista são genéricos, e podem ser armazenados em bibliotecas para reutilização. A visão é sempre específica para a arquitetura para a qual foi criada.

Slide 355

O Que é uma Visão de Arquitetura? • Uma representação de uma arquitetura global de significado para uma ou mais partes interessadas no sistema • Por exemplo, um arquiteto civil pode criar diagramas elétricos, plantas e elevações para descrever as diferentes facetas de um edifício para as suas diferentes partes interessadas (eletricistas, proprietários, funcionários de planejamento etc.) • Um arquiteto corporativo pode criar visões física e de segurança de um sistema de TI

Slide 356

Um Exemplo Simples de um Ponto de Vista Elemento do Ponto De Vista

Descrição

Partes Interessadas Comitê diretor, CEO Preocupações Mostrar as relações de alto nível entre locais geográficos e funções de negócio Técnica de Diagrama com caixas aninhadas Modelagem caixas externas = locais; caixas internas = funções de negócio Semântica de aninhamento = funções executadas nos locais Slide 357

A Simple Example of a View Burlington Burlington

Reading Reading

San San Francisco Francisco Dynamic/ Dynamic/ Virtual Virtual

Home Home Offices Offices

Program Management

Program Management

Program Management

Program Management

Program Management

Research

Enterprise Architecture

Event Management

Event Management

Event Management

IT Development

IT Development

IT

Marketing

Marketing

Finance

Legal

HR

HR

HR

Management

Management

Management

Off-site Off-site IT Infrastructure

Sales

Management

Miscellaneous

Out-sourced Out-sourced PR

Desktop

Figura 1: Exemplo da visão - Os Domínios de Negócio do The Open Group em 2008 Slide 358

Desenvolvendo Visões no A escolha de quais visões de arquitetura em particular serão desenvolvidas é uma das decisões chave que um arquiteto deve fazer. O Arquiteto tem a responsabilidade de garantir: • A completude da arquitetura – Ela atende a todas as preocupações das partes interessadas?

• A integridade da arquitetura – As visões podem ser conectadas umas às outras? – As preocupações em conflito podem ser reconciliadas? – Quais “trocas” foram feitas (exemplo: entre segurança e performance)? Slide 359

Exercício: Visões e Pontos de Vista para um Sistema Simples de Aeroporto O piloto tem uma visão do sistema, o controlador de tráfego aéreo tem outra. Nenhuma das visões representa todo o sistema - a perspectiva de cada parte interessada limita como eles veem o sistema como um todo. P. 1.Relacione alguns elementos na visão do piloto, que não são enxergados pelo controlador 2.Relacione alguns elementos na visão do controlador, que não são enxergados pelo piloto 3.Relacione alguns elementos compartilhados Continua

Slide 360

Exercício: Visões e Pontos de Vista para um Sistema Simples de Aeroporto 1. Descrever 2 Pontos de Vista para este sistema 2. Por que o uso de Pontos de Vista é útil?

Slide 361

O Processo de Criação de Visão 1. 2. 3. 4.

Consultar as bibliotecas existentes de pontos de vista. Selecionar as principais partes interessadas. Analisar as suas preocupações e documentá-las. Selecionar pontos de vista adequados (com base nas partes interessadas e suas preocupações). 5. Gerar visões do sistema usando os pontos de vista selecionados como modelos.

Slide 362

Benefícios • Menos trabalho para os arquitetos (os pontos de vista já foram definidos e por isso as visões podem ser criadas mais rápido) • Melhor compreensão para as partes interessadas (os pontos de vista já são familiares) • Maior confiança na validade das visões (os seus pontos de vista têm um histórico conhecido)

Slide 363

O Processo de Criação de Visão Se não existem bibliotecas de pontos de vista, então: 1. Selecione as principais partes interessadas. 2. Analise suas preocupações e as documente. 3. Desenvolva novos pontos de vista (baseados nas partes interessadas e suas preocupações). 4. Gere visões do sistema usando os novos pontos de vista como modelos. Alternativamente crie uma visão ad hoc e então verifique se uma forma generalizada do ponto de vista implícito deve ser definida explicitamente e salva. Slide 364

Usando Artefatos do TOGAF • O TOGAF inclui um conjunto de exemplos de artefatos recomendados que podem ser adotados, melhorados e combinados para produzir visões de arquitetura • Três classes de artefatos são definidos: – Catálogos – Matrizes – Diagramas

Slide 365

Catálogos • Catálogos são listas de blocos de construção de um tipo específico, ou de tipos relacionados • Por exemplo – Catálogo de Princípios criado na Fase Preliminar – Catálogo de Organização/Ator criado na Fase B – Catálogo de Direcionador/Meta/Objetivo

Slide 366

Matrizes • Matrizes mostram as relações entre os blocos de construção de tipos específicos • Matrizes são usadas para representar relacionamentos em um formato baseado em listas ao invés de baseado em gráficos • Por exemplo – A Matriz de Mapa de Partes Interessadas criada na Fase A

Slide 367

Matriz de Mapa de Partes Interessadas Parte Interessada

PRINCIPAIS PREOCUPAÇÕES

CLASSE

Catálogos, Matrizes e Diagramas

CxO – CEO, CFO, CIO, COO

Os direcionadores de alto nível, metas e objetivos da organização, e como estes são traduzidos em um processo eficaz e numa arquitetura de TI para o negócio progredir.

MANTER SATISFEITO

Diagrama de “footprint” de Negócio Diagrama de Meta/Objetivo/Serviço Diagrama de Decomposição da Organização

Escritório de Gerenciamento do Programa – gerentes de Portifólio de Projetos

Priorizar, financiar e alinhar atividade de mudança. Uma compreensão do conteúdo do projeto e dependências técnicas entre projetos acrescenta uma nova dimensão de riqueza a gerência de tomada de decisão

Aquisição – Compradores

Entender quais blocos de construção da arquitetura podem ser comprados, e quais as restrições (ou regras) existem que são relevantes para a compra. O adquirente vai fazer compras com vários fornecedores que procuram a melhor solução de custo ao aderir às restrições (ou regras), aplicadas pela arquitetura, como normas. A principal preocupação é fazer as decisões de compra que se encaixam na arquitetura, e, assim, reduzir o risco de custos adicionais decorrentes da não conformidade de componentes.

Slide 368

MANTER SATISFEITO

Catálogo de Requisitos Diagrama de “footprint” do Negócio Diagrama de Comunicação de Aplicação Diagrama de Decomposição Funcional

PESSOAS CHAVE

Catálogo de Portifólio de Tecnologia Catálogo de Normas de Tecnologia

Diagramas • Diagramas representam blocos de construção de uma forma rica e visual, especialmente adequado para a comunicação com as partes interessadas. • Por exemplo: – Diagrama de Cadeia de Valor criado na Fase A – Diagrama de “Footprint” de Negócio criado na Fase B

Slide 369

Exemplo de Diagrama de “Footprint”de Negócio

Slide 370

Fase Preliminar • Catálogo de Principios

Gerenciamento de Requisitos

Fase A, Visão de Arquitetura • Matriz de Mapa de Partes interessadas

TOGAF 9 Artifacts • Catálogo de Requisitos

Fase B, Arquitetura de Negócio • • • • • • • • • • • • • • • • • •

• Diagrama Conceitual • Diagrama de Cadeia de Valor da Soluçao

Catálogo de Organização/Ator Catálogo de Direcionador/Meta/Objetivo Catálogo de Papéis Catálogo de Serviço de Negócio/Função Catálogo de Localidades Catálogo de Processo/Evento/Controle/Produ to Catálogo de Contrato/Medida Matriz de Interação de Negócio Matriz de Ator//Papel Diagrama de “Footprint” de Negócio Diagrama de Serviço de Negócio/Informação Diagrama de Decomposição Funcional Diagrama de Ciclo de Vida de Produto Diagrama de Meta/Objetivo/Serviço Diagrama de Casos de Uso de Negócio Diagrama de Decomposição da Organização Diagrama Slide 371 de Fluxo de Processo Diagrama de Evento

Fase C, Arquitetira de Dados

Fase C, Arquitetura de Aplicação

Fase D, Arquitetura Tecnológica

•

•

•

• • • • • • • •

Catálogo de Entidade de Dados/ Componente de Dados Matriz de Entidade de Dados/Funções de Negócio Matriz de Aplicação/Dados Diagrama lógico de dados Diarama de Disseminação de Dados Diagrama de segurança de Dados Diagrama hierárquico de Classes Diagrama de Migração de Dados Diagrama de Ciclo de Vida de Dados

• • • •

• • •

• • • • •

of 33

•

Catálogo de Portifólio de Aplicação Catálogo de Interface Matriz de Aplicação/Organização Matriz de Papel/Aplicação Matriz de Aplicação/Função Matriz de Interação de Aplicação Diagrama de Comunicação de Aplicação Diagrama de Localização de Aplicação e Usuário Diagrama de caso de Usos de Aplicações Diagrama de gerenciabiliade da Corporação Diagrama de Realização de Processo/Aplicação Diagrama de Engenharia de Software Diagrmaa de Migração de Aplicação Diagrama de Distribuição de Software

• • •

• • • •

Catálogo de Normas de Tecnologia Catálogo de Portifólio de Tecnologia Matriz de Sistema/Tecnologia Diagrmaa de Ambientes e Locais Diagrmaa de Decomposição de Plataforma Diagrama de Processamento Diagrmaa de Computação em Rede/Hardware Diagrama de Engenhari de Comunicação

Artefatos

Visões de Arquitetura Recomendadas • Visão de Arquitetura de Negócio • Visão de Segurança da Corporação • Visão de Engenharia de Software • Visão de Engenharia de Sistemas • Visão de Engenharia de Comunicações • Visão de Fluxo de Dados • Visão de Gerenciabilidade da Corporação • Visão de Adquirente Slide 372

Visões e Pontos de Vista

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 378

of 33

Módulo 13 Blocos de Construção Edição V9.1 Copyright © 2009-2011

Slide 379

of 24

Todos os direitos reservados Publicado por The Open Group, 2011

Blocos de Construção

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 380

of 24

Roap Parte I - Introdução Prefácio, Preface, Visão global executiva, Principais Conceitos, Definições e Notas da Versão

Parte II – Método de Desenvolvimento da Arquitetura Introdução ao Narrativas das Fases do

Parte III – Orientações e Técnicas do Orientações para Adaptação do Processo do Técnicas para o Desenvolvimento da Arquitetura

Parte IV – Framework de Conteúdo da Arquitetura Metamodelo de Conteúdo Artefatos Arquiteturais Entregáveis da Arquitetura Blocos de Construção

Parte V – Continuum da Corporação e Ferramentas Continuum da Corporação Particionamento da Arquitetura Repositório da Arquitetura Ferramentas para o Desenvolvimento da Arquitetura

Parte VI – Modelos de Referência do TOGAF Arquitetura de Fundação: Modelo de Referência Técnico Modelo de Referência da Infraestrutura Integrada da Informação

Parte VII – Framework de Capacidade da Arquitetura Comitê de Arquitetura Aderência da Arquitetura Contratos da Arquitetura Governança da Arquitetura Modelos de Maturidade da Arquitetura Frameworks de Competências da Arquitetura

Slide 381

• Parte IV, Framework de Conteúdo de Arquitetura, Capítulo 37

Características de um Bloco de Construção • Um pacote de funcionalidade definido para atender as necessidades do negócio da organização • Um bloco de construção possui interfaces publicadas para expor sua funcionalidade • Um bloco de construção pode interagir com outros blocos de construção interdependentes

Slide 383

Um Bom Bloco de Construção • Considera a implementação e a utilização e evolui para explorar a tecnologia e os padrões • Pode ser montado ou desmontado a partir de outros blocos de construção • É reusável e substituível

Slide 384

Blocos de Construção • A maneira em que as funcionalidades, produtos e desenvolvimentos personalizados são montados em blocos de construção varia muito • Cada organização deve decidir por si mesmo a disposição • Uma boa escolha pode levar a melhorias na interoperabilidade, integração e flexibilidade de sistemas

Continua Slide 385

Blocos de Construção • Sistemas são construídos a partir de coleções de blocos de construção • Eles podem ser definidos em vários níveis de detalhe – Agrupamentos no nível funcional como “base de dados de cliente” são conhecidos como Blocos de Construção de Arquitetura – Produtos reais ou desenvolvimentos customizados específicos são conhecidos como Blocos de Construção de Solução

Slide 386

Blocos de Construção de Arquitetura (BCAs) • Documentação de Arquitetura e modelos do Continuum da Arquitetura da Corporação • Eles são definidos ou selecionados durante a aplicação do – Principalmente nas Fases A, B, C e D

• As características são as seguintes – – – –

Eles definem quais funcionalidades serão implementadas Eles capturam requisitos técnicos e de negócio Eles são cientes de tecnologia Eles direcionam e guiam o desenvolvimento de Blocos de Construção de Solução

Slide 387

Especificação de BCAs • Funcionalidade fundamental e atributos: semântica, inequívocos, incluindo capacidade de segurança e gerenciabilidade • Interfaces: conjunto escolhido, fornecido (APIs, formatos de dados, protocolos, interfaces de hardware, normas) • Blocos de construção dependentes com as funcionalidades requeridas as interfaces nomeadas • Mapeamento para entidades e políticas de negócios/organizações

Slide 388

Blocos de Construção de Solução (BCSs) • Blocos de Construção de Solução se relacionam com o Continuum de Soluções • Eles podem ser adquiridos ou desenvolvidos • As características são as seguintes: – Eles definem quais produtos e componentes implementarão a funcionalidade – Eles definem a implementação – Eles cumprem os requisitos de negócio – Eles são cientes e consideram produtos e fornecedores

Slide 389

Especificação de BCSs • Funcionalidade e atributos específicos • Interfaces: o conjunto implementado • BCSs requeridos usados com funcionalidades necessárias e nomes das interfaces utilizadas • Mapeamento desde os BCSs até a topologia de TI e políticas operacionais • Especificações de atributos compartilhados como segurança, gerenciabilidade, escalabilidade • Performance, configurabilidade • Direcionadores e restrições de design, incluindo a arquitetura física • Relacionamentos entre os BCAs e BCSs

Slide 390

Blocos de Construção e o • Uma arquitetura é um conjunto de blocos de construção – Descrito em um modelo arquitetural – Uma especificação de como os blocos de construção são conectados para satisfazer os requisitos gerais de um sistema de informação

• Os vários blocos de construção em uma arquitetura especificam os serviços necessários em um sistema corporativo específico • Os seguintes princípios gerais devem aplicar-se: – Uma arquitetura precisa conter apenas blocos de construção para implementar os serviços de que necessita – Os blocos de construção podem implementar um, mais do que um, ou apenas uma parte de um serviço identificado na arquitetura – Blocos de construção devem obedecer a normas

Slide 391

Design de Blocos de Construção • •

O processo de identificação de blocos de construção inclui procurar conjuntos de funções que requerem integração Considere três classes de blocos de construção: 1. Blocos de construção reutilizáveis, tais como itens de legado 2. Blocos de construção a serem desenvolvidos (novas aplicações) 3. Blocos de construção a serem adquiridos (aplicações COTS)

•

Use o nível desejado de integração para decidir como vincular funções em blocos de construção

Slide 392

Na Fase A nós iniciamos com entidades abstratas

Um modelo de alto nível de candidatos a blocos de construção

Slide 393

Na Fase A nós iniciamos com entidades abstratas

Nas Fases B, C e D: Blocos de construção dentro da Arquitetura de Negócio, Dados, Aplicações e Tecnológica evoluem através de um padrão comum de os

o 1: Selecionar Modelos de Referência, Pontos de Vista e Ferramentas O TOGAF fornece exemplos de catálogos, matrizes e diagramas para utilização

Slide 394

Na Fase A nós iniciamos com entidades abstratas

o 2: Desenvolver a Descrição da Arquitetura de Linha de Base

Desenvolver um modelo de alto nível de blocos de construção existentes, reutilizando definições a partir do Repositório de Arquitetura onde eles estão disponíveis

Slide 395

Na Fase A nós iniciamos com entidades abstratas

o 3: Desenvolver a Descrição da Arquitetura Alvo Desenvolver a visão de blocos de construção necessários através da criação de catálogos, matrizes e diagramas Documentar inteiramente cada bloco de construção Documentar a lógica de decisão sobre blocos de construção Identificar os blocos de construção impactados dentro do Repositório de Arquitetura, reutilizando sempre que necessário Quando necessário, definir novos blocos de construção Selecionar normas para cada bloco de construção

Documentar o mapeamento de blocos de construção para o Panorama da Arquitetura Identificar blocos de construção para reutilização, publicar quer como normas ou modelos de referência

Slide 396

Na Fase A nós iniciamos com entidades abstratas

o 4: Realizar Análise de Diferença Identificar blocos de construção herdados Identificar blocos de construção eliminados

Identificar novos blocos de construção Identificar lacunas e determinar abordagem de realização

Slide 397

Na Fase A nós iniciamos com entidades abstratas

o 5: Definir Componentes Candidatos para o Roap o 6: Resolver Impactos em todo o Panorama da Arquitetura o 7: Revisão formal pelas partes interessadas o 8: Finalizar a Arquitetura

o 9: Criar o Documento de Definição de Arquitetura

Slide 398

Na Fase A nós iniciamos com entidades abstratas Nas Fases B, C e D: Blocos de construção dentro da Arquitetura de Negócio, Dados, Aplicações e Tecnológica evoluem através de um padrão comum de os

Blocos de Construção em forma de BCAs e BCSs Associar os blocos de construção com os pacotes de trabalho que abordarão as lacunas

Slide 399

Padrões de Arquitetura (Architecture Patterns) • Padrão: definido como "uma ideia que foi útil em um contexto prático e provavelmente será útil em outros" • No TOGAF, os padrões são considerados como sendo uma forma de colocar os blocos de construção em contexto, por exemplo, para descrever uma solução reutilizável para um problema. • Blocos de construção são o que você usa: padrões podem dizer como você os usa, quando, por quê, e quais trocas ("trade-offs") que você terá que fazer.

Slide 400

Blocos de Construção

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 402

of 24

Módulo 14 Técnicas de e para a Implementação da Arquitetura Edição V9.1 Copyright © 2009-2011

Slide 403

of 30

Todos os direitos reservados Publicado por The Open Group, 2011

Técnicas de e para a Implementação da Arquitetura

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 404

of 30

Roap Parte I - Introdução Prefácio, Preface, Visão global executiva, Principais Conceitos, Definições e Notas da Versão

Parte II – Método de Desenvolvimento da Arquitetura Introdução ao Narrativas das Fases do

Parte III – Orientações e Técnicas do Orientações para Adaptação do Processo do Técnicas para o Desenvolvimento da Arquitetura

Parte IV – Framework de Conteúdo da Arquitetura Metamodelo de Conteúdo Artefatos Arquiteturais Entregáveis da Arquitetura Blocos de Construção

Parte V – Continuum da Corporação e Ferramentas Continuum da Corporação Particionamento da Arquitetura Repositório da Arquitetura Ferramentas para o Desenvolvimento da Arquitetura

Parte VI – Modelos de Referência do TOGAF Arquitetura de Fundação: Modelo de Referência Técnico Modelo de Referência da Infraestrutura Integrada da Informação

Parte VII – Framework de Capacidade da Arquitetura Comitê de Arquitetura Aderência da Arquitetura Contratos da Arquitetura Governança da Arquitetura Modelos de Maturidade da Arquitetura Frameworks de Competências da Arquitetura

Slide 405

• Part III, Orientações e Técnicas do • Capítulos 29, 30, 31 e 32

Interoperabilidade • A interoperabilidade é “a capacidade de compartilhar informações e serviços”. • O TOGAF fornece técnicas para – Definir interoperabilidade – Refinar a interoperabilidade – Determinar os requisitos de interoperabilidade

• A determinação da interoperabilidade ocorre durante todo o ciclo de

Slide 407

Interoperabilidade e o A determinação da interoperabilidade ocorre ao longo do : • Visão da arquitetura: as considerações da natureza e segurança de intercâmbios de informações e serviços são encontradas usando cenários de negócios. • Arquitetura de Negócio: trocas de informações e serviços são definidas em termos de negócio. • Arquitetura de Dados: o conteúdo do intercâmbio de informações é detalhado utilizando modelo de intercâmbio de dados corporativos e/ou informações. • Arquitetura de Aplicação: a forma como as aplicações devem compartilhar informações e serviços é especificada. • Arquitetura Tecnológica: mecanismos técnicos apropriados que permitam o intercâmbio de informações e de serviços são especificados. • Oportunidades e Soluções: as soluções reais são selecionadas. • Plano de Migração: a interoperabilidade é implementada de forma lógica.

Slide 408

Exemplos

Slide 409

Requisitos de Interoperabilidade e Soluções O arquiteto deve garantir que não há conflitos de interoperabilidade, especialmente se reutilizando BCSs existentes ou usando COTS que têm os seus próprios processos de negócios e arquiteturas de informação. Mudanças nos processos de negócio serão as mais difíceis. O workflow entre os vários sistemas também deve ser levado em conta. O arquiteto corporativo também deve garantir que qualquer alteração dos requisitos de interoperabilidade de negócio seja acordada pelos arquitetos de negócio e patrocinadores em uma Declaração de Trabalho de Arquitetura devidamente revisada. Slide 410

Requisitos de Interoperabilidade e Soluções Para encontrar restrições de interoperabilidade, considere: • A Visão da Arquitetura • A Arquitetura Alvo • A Matriz de Avaliação e Dedução de Fatores de Implementação (Implementation Factor Assessment and Deduction matrix) • Matriz Consolidada de Lacunas, Soluções e Dependências (Consolidated Gaps, Solutions, and Dependencies matrix)

Slide 411

Avaliação de Prontidão para Transformação do Negócio • A Arquitetura Corporativa muitas vezes envolve mudanças consideráveis. • Compreender a prontidão de uma organização para aceitar a mudança, identificando os problemas e lidar com eles nos planos de implementação e migração é a chave de sucesso para a transformação da arquitetura nas Fases E e F. Uma avaliação inicial é realizada na Fase A. • Este é um esforço conjunto entre o staff corporativo (recursos humanos principalmente), linhas de negócio e planejadores de TI.

Slide 412

A Avaliação de Prontidão para Transformação do Negócio Atividades recomendadas para avaliar a Prontidão para Transformação do Negócio são: 1. Determinar os fatores de prontidão 2. Apresentar os fatores de prontidão usando modelos de maturidade 3. Avaliar os fatores de prontidão, e determinar os níveis destes fatores 4. Avaliar os riscos para cada fator de prontidão e identificar ações de mitigação 5. Incluir ações de mitigação no Plano de Implementação e Migração produzido nas fases E e F

Slide 413

Fatores de Prontidão Fatores típicos que podem afetar a transformação de negócio incluem: • Visão - a capacidade de definir claramente e comunicar o que deve ser alcançado. • Desejo, vontade, e resolução • Necessidade • Caso de Negócio (Business Case) • Financiamento • Patrocínio e Liderança • Governança • Prestação de contas • Abordagem e Modelo de execução viáveis • Capacidade de execução pela TI • Capacidade de execução pela corporação • Capacidade da corporação para implementar e operar Slide 414

Avalir os Fatores de Prontidão

Slide 415

Índice de Fator de Prontidão

Slide 416

Riscos do Fator de Prontidão & Ações • Avaliar cada fator, utilizando técnicas de Gestão de Risco • Identificar uma série de ações de melhoria • Incorporar no Plano de Implementação e Migração

Slide 417

Gerenciamento de Risco • •

Uma técnica usada para reduzir o risco ao implementar um projeto de arquitetura. É importante identificar, classificar e mitigar esses riscos antes de começar, para que possam ser monitorados durante todo o esforço de transformação.

Slide 418

Gerenciamento de Risco no Existem dois níveis de risco que devem ser considerados: 1. Nível inicial de risco: classificação dos riscos antes da determinação e implementação de ações de mitigação. 2. Nível residual de risco: classificação de risco após a implementação de ações de mitigação.

•

Processo para Gerenciamento de Risco é: – – – – –

Slide 419

Classificação de riscos Identificação de riscos Avaliação de risco inicial Mitigação de riscos e avaliação de risco residual Monitoramento de riscos

Gerenciamento de Risco no Os riscos são identificados na Fase A, como parte da primeira Avaliação de Prontidão para Transformação do Negócio As planilhas de identificação de riscos e de avaliação de mitigação são guardadas como artefatos de governança e são mantidos em dia na Fase G (Governança da Implementação), onde o monitoramento do risco é conduzido. A Governança da Implementação pode identificar riscos críticos que não estão sendo mitigados e que poderiam exigir um outro ciclo total ou parcial do .

Slide 420

Avaliação Inicial de Risco A avaliação inicial de riscos é feita classificando os riscos em relação ao seu efeito e frequência. O Efeito pode ser avaliado como: • Catastrófico: perda financeira crítica que poderia resultar em falência. • Crítica: grave perda financeira em mais de uma linha de negócios que levaria a uma perda de produtividade e sem nenhum ROI. • Marginal: perda financeira menor em uma linha de negócios e um ROI reduzido sobre o investimento em TI. • Desprezível: impacto mínimo sobre os serviços e / ou produtos. Continua… Slide 421

Avaliação Inicial de Risco A Frequência pode ser avaliada como: • Frequente: provável de ocorrer muitas vezes e / ou continuamente. • Provável: ocorre várias vezes ao longo de um ciclo de transformação. • Ocasional: ocorre esporadicamente. • Raramente: remotamente possível e provável de não ocorrer mais do que uma vez no decurso de um ciclo de transformação. • Improvável: provavelmente não ocorre durante o curso de um ciclo de transformação. Slide 422

Avaliação Inicial de Risco As avaliações de efeito e frequência podem então ser combinadas: • Risco extremamente elevado (E): A transformação provavelmente irá falhar com consequências graves. • Alto Risco (A): falha significativa de partes da transformação, resultando em determinadas metas não serem alcançadas. • Risco moderado (M): falha visível de partes da transformação, ameaçando o sucesso de algumas metas. • Baixo Risco (B): Algumas metas não serão inteiramente bem sucedidas. Slide 423

Esquema de Classificação de Risco

Slide 424

Planilha de Identificação e Mitigação de Riscos

Slide 425

Planejamento Baseado em Capacidade Planejamento Baseado em Capacidade é uma técnica que se concentra no planejamento, engenharia e entrega de capacidades estratégicas de negócios. Ele enquadra todas as fases do desenvolvimento da arquitetura no contexto de resultados de negócios, claramente ligando a visão de TI, arquiteturas (BCAs e BCSs), e os Planos de Implementação e Migração com os planos corporativos estratégicos, de negócios, e de linha de negócios.

Slide 426

Capacidades

Slide 427

Planejamento Baseado em Capacidade Capacidades são diretamente derivadas do plano estratégico corporativo. Elas devem satisfazer os objetivos, metas e estratégias da corporação. A maioria das organizações também terá um plano de negócios anual. • Todas as arquiteturas serão expressas em termos de resultados de negócios e de valor. • Fase A: a direção estratégica corporativa deve conduzir a fase. • Fases B, C e D: capacidades específicas devem ser direcionadas para a realização. • Fase E: os incrementos de capacidade devem conduzir a fase. Slide 428

Planejamento Baseado em Capacidade

Slide 429

Técnicas de e para a Implementação da Arquitetura

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 432

of 30

Módulo 15 Fase A Visão da Arquitetura Edição V9.1 Copyright © 2009-2011

Slide 433

de 31

Todos os direitos reservados Publicado por The Open Group, 2011

Phase A Fase A: Visão da Arquitetura

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 434

de 31

Visão da Arquitetura - Objetivos •

Desenvolver uma visão aspiracional de alto nível das capacidades e valor de negócio a serem entregues como resultado da arquitetura corporativa proposta

•

Obter aprovação de uma Declaração de Trabalho de Arquitetura que define um programa de trabalhos para desenvolver e implementar a arquitetura descrita na Visão de Arquitetura

Slide 436

Abordagem • A Fase A define o que está dentro e o que está fora do esforço de arquitetura, e as restrições • As restrições são informadas por princípios, objetivos de negócio e direcionadores estratégicos • Cria o Documento de Visão da Arquitetura – Esclarecendo e acordando o propósito da arquitetura – Demonstrando como ela será alcançada – A primeira descrição de alto nível das arquiteturas de Linha de Base e Alvo – A técnica de Cenários de Negócio pode ser usada para desenvolver a Visão da Arquitetura

Slide 437

Fase A: Entradas • Requisição para Trabalho de Arquitetura (ver próximo slide) • Princípios de negócios, metas e direcionadores de negócios • Modelo Organizacional para a Arquitetura Corporativa • Framework de Arquitetura Adaptado, incluindo os Princípios de Arquitetura • Repositório Arquitetura populado

Slide 438

Requisição para Trabalho de Arquitetura • Patrocinadores da organização

• Declaração de missão da organização • Objetivos de negócio e mudanças • Planos estratégicos do negócio • Limites de tempo • As mudanças no ambiente de negócios • Restrições organizacionais • Informações sobre o orçamento, limitações financeiras Slide 439

• Restrições externas, restrições de negócio • Descrição do sistema atual de negócio • Descrição atual da arquitetura do sistema de TI • Descrição da organização de desenvolvimento

• Descrição de recursos que a organização de desenvolvimento tem disponíveis

11. Desenvolver a Declaração de Trabalho da Arquitetura e obter aprovação

os

10. Identificar os riscos e as atividades de mitigação para a transformação do negócio

9. Definir a proposta de valor da Arquitetura Alvo e KPIs 8. Desenvolver a Visão da Arquitetura

7. Confirmar e elaborar princípios de arquitetura, incluindo princípios de negócio 6. Definir o Escopo 5. Avaliar a prontidão para transformação do negócio 4. Avaliar as Capacidades do Negócio 3. Confirmar metas de negócio, direcionadores, e limitações 2. Identificar as partes interessadas, preocupações, e requisitos de negócio 1. Estabelecer o projeto de arquitetura Slide 440

o 1: Estabelecer o projeto Conduzir os procedimentos necessários para garantir:

• Reconhecimento do projeto • Endosso da gestão corporativa • Apoio e compromisso da gestão de linha Referir-se a outros frameworks de gerenciamento • Explicar como este projeto se relaciona com estes frameworks

Slide 441

o 2: Identificar partes interessadas, preocupações, e requisitos de negócio • Aqui precisamos identificar: – Componentes e requisitos candidatos da visão – Fronteiras do escopo candidatas para o engajamento – Preocupações das partes interessadas, problemas, e fatores culturais – As preocupações e pontos de vista que são relevantes para este projeto – As partes interessadas que estão envolvidas neste projeto – Os papéis e responsabilidades chaves dentro do projeto Outra tarefa importante que deverá ser considerada é quais visões e pontos de vista precisam ser desenvolvidos para satisfazer os vários requisitos das partes interessadas.

Slide 442

Mapa das Partes Interessadas Parte Interessada

Principal Preocupação

Classific ação

Catálogos, matrizes e Diagramas

CxO

Os direcionadores de alto nível, metas e objetivos da organização, e como estes são traduzidos em um processo eficaz e arquitetura de TI para o negócio avançar

Manter Satisfeito

Diagrama de “Footprint” de Negócio; Diagrama de Meta/Objetivo/Serviço; Diagrama de Decomposição da Organização

Gabinete de Gestão do Programa

Priorizando, financiando, e alinhando a atividade de mudança. Uma compreensão do conteúdo do projeto e dependências técnicas acrescenta uma nova dimensão de riqueza para gestão de portfólio e tomada de decisão.

Manter Satisfeito

Diagrama de Contexto de Projeto Diagrama de “Footprint” de Negócio Diagrama de Comunicação de Aplicação Diagrama de Decomposição Funcional

RH

Os papéis e atores que am as funções, aplicações e tecnologia da organização. Os RHs são atores importantes para garantir que as funções e atores corretos sejam representados.

Manter Informado

Diagrama de Decomposição da Organização Catálogo da Organização/Ator Catálogo de Localizações

Slide 443

o 3: Confirmar metas de negócio, direcionadores, e limitações Identificar as metas de negócio e direcionadores estratégicos da organização. • Se estes foram definidos em outros lugares, garantir que as definições estão atualizadas, e esclarecer quaisquer áreas de ambiguidade. • Caso contrário, definir as metas e garantir a sua aprovação pela istração. Definir quaisquer limitações que precisam ser trabalhadas

Slide 444

o 4: Avaliar as Capacidades do Negócio Neste o nós vamos: • Procurar entender as capacidades e desejos do negócio • Identificar as opções para realizar essas capacidades • Avaliar as implicações para a capacidade de arquitetura da organização • Criar um panorama inicial da nova capacidade que será necessária • Documentar os resultados em uma Avaliação de Capacidades

Slide 445

Diagrama de Cadeia de Valor

Fonte: Wikipedia.org

Slide 446

o 5: Avaliar a prontidão para transformação do negócio Essa avaliação é baseada na determinação e avaliação de uma série de fatores de prontidão Estes resultados são usados para: • moldar o escopo da arquitetura, • identificar as atividades exigidas dentro do projeto de arquitetura, e • identificar áreas de risco a serem abordadas

Slide 447

o 6: Definir o Escopo Definir: • Amplitude da cobertura • Nível de detalhe • As características de particionamento da arquitetura • Domínios a serem cobertos • Agendar os marcos do projeto • Identificar os ativos do Continuum da Corporação para uso: – Criados a partir de ciclos anteriores do – Frameworks de referência existentes, modelos, e assim por diante…

Slide 448

o 7: Confirmar e elaborar princípios de arquitetura, incluindo princípios de negócio Assegurar que quaisquer definições existentes estão atualizadas, e esclarecer todas as áreas de ambiguidade. Se os princípios não existirem, vá ao órgão responsável pela governança da arquitetura e juntos definam os princípios. Garantir a sua aprovação pela istração.

Slide 449

o 8: Desenvolver a Visão da Arquitetura Criar uma visão de alto nível das Arquiteturas de linha de base e alvo. • Técnicas informais são muitas vezes utilizadas, por exemplo, um simples diagrama de conceito da solução pode ilustrar os principais componentes da solução e as suas vantagens. • Cenários de negócios são úteis aqui para descobrir e documentar os requisitos de negócios. • O resultado é a primeira definição, de nível muito alto, dos ambientes de linha de base e alvo, a partir da perspectiva do negócio, de SI e tecnológica. • Isto deve ser armazenado no Repositório de Arquitetura.

Slide 450

Diagrama de Conceito da Solução • Uma representação de alto nível da solução prevista • Um “esboço a lápis” da solução esperada no início do engajamento Filiação Atendimento a Conferência Clientes Certificação Publicações Interesse, consideração, Se associa, renova Slide 451

confiável, 24x7, Infraestrutura de auto atendimento

o 9: Definir a proposta de valor da Arquitetura Alvo e KPIs • • • • • • •

Desenvolver o caso de negócio para as arquiteturas e as mudanças necessárias Produzir a proposta de valor para cada um dos grupos de partes interessadas Avaliar e definir os requisitos de compras Rever e acordar as propostas de valor com os patrocinadores e partes interessadas Definir as métricas de desempenho Avaliar o risco do negócio Incorporar as saídas na Declaração de Trabalho de Arquitetura

Slide 452

o 10: Identificar os riscos e as atividades de mitigação para a transformação do negócio •

Identificar os riscos associados com a Visão da Arquitetura, avaliar o nível inicial de risco e sua frequência potencial. Existem dois níveis de risco a serem considerados: – Nível inicial de risco: classificação dos riscos antes de determinar e implementar ações de mitigação – Nível residual de risco: classificação de risco após a implementar as ações de mitigação (se houver)

•

Atribuir uma estratégia de mitigação para cada risco. Estes devem ser considerados para a inclusão dentro da Declaração de Trabalho de Arquitetura Slide 453

o 11: Desenvolver a Declaração de Trabalho da Arquitetura, obter aprovação Avaliar os produtos de trabalho necessários contra o conjunto de requisitos de desempenho de negócios.

As atividades incluem: • Identificar novos produtos de trabalho que precisam ser alterados • Fornecer direção sobre quais produtos de trabalho existentes, incluindo blocos de construção, precisam ser alterados. Garantir que todas as dependências estão coordenadas • Identificar o impacto da mudança sobre outros produtos de trabalho • Escolher quais domínios da arquitetura desenvolver, dependendo da finalidade, foco, escopo, restriçõesContinued… Slide 454

o 11: Desenvolver a Declaração de Trabalho da Arquitetura, obter aprovação • • • • •

•

Avaliar os requisitos de recursos Estimar os recursos necessários, desenvolver um roteiro e cronograma para o desenvolvimento proposto e documentar na Declaração de Trabalho de Arquitetura Definir as métricas de desempenho Desenvolver o Plano de Comunicação específico da arquitetura corporativa Analisar e aprovar os planos com os patrocinadores, e garantir a aprovação formal da Declaração de Trabalho de Arquitetura no âmbito dos procedimentos adequados de governança Obter aprovação do patrocinador Slide 455

Declaração de Trabalho de Arquitetura • Título • Solicitação de projeto de arquitetura e background

• Descrição e escopo do projeto de arquitetura • Visão geral Visão da Arquitetura • Procedimentos de mudança de escopo Slide 456

• Papéis, responsabilidades e entregáveis • Critérios e procedimentos de aceitação • Plano do projeto de Arquitetura e cronograma • Aprovações

Fase A: Saídas • Declaração de Trabalho de Arquitetura aprovada incluindo: – Descrição do projeto e escopo – Visão geral da Visão da Arquitetura – Plano do projeto e cronograma • Declarações refinadas de princípios de negócio, metas e direcionadores • Princípios de arquitetura incluindo princípios de negócio Continua… Slide 457

Fase A: Saídas • Avaliação de Capacidades • Framework de Arquitetura adaptado • Visão de Arquitetura • Rascunho de Documento de Definição de Arquitetura • Plano de Comunicação • Conteúdo adicional populando o Repositório de Arquitetura

Slide 458

Resumo • Fase A é sobre o estabelecimento de projeto • Ela inicia uma iteração do processo de arquitetura • Ela define o escopo, as restrições e as expectativas para esta iteração • Ela valida o contexto de negócios • Ela cria a Declaração de Trabalho de Arquitetura

Slide 459

Resumo Fase A: Visão da Arquitetura Objetivos

os

Entradas

Saídas

Desenvolver uma visão de alto nível aspiracional das capacidades e valor de negócio a ser entregue como resultado da arquitetura corporativa proposta

Estabelecer o projeto de arquitetura Identificar as partes interessdas, preocupações, e requisitos de negócio Confirmar metas de negócio, direcionadores, e limitações Avaliar as Capacidades do Negócio Avaliar a prontidão para transformação do negócio Definir o Escopo Confirmar e elaborar princípios de arquitetura, incluindo princípios de negócio Desenvolver a Visão da Arquitetura Desenvolver a Visão da Arquitetura Definir a proposta de valor da Arquitetura Alvo e KPIs Identificar os riscos e as atividades de mitigação para a transformação do negócio Desenvolver a Declaração de Trabalho da Arquitetura, aprovação segura

Solicitação de Trabalho de Arquitetura

Declaração de Trabalho de Arquitetura aprovado incluindo: Descrição do projeto e escopo Visão geral da Visão da Arquitetura Plano do projeto e cronograma

Obter aprovação de uma Declaração de Trabalho de Arquitetura que define um programa de trabalhos para desenvolver e implementar a arquitetura descrita na visão de arquitetura

Slide 460

Princípios de negócios, metas de negócios e orientadores Modelo de organização para a arquitetura corporativa Framework de Arquitetura Adaptado, incluindo os princípios de arquitetura Repositório Arquitetura populado

Declarações refinadas de princípios de negócio, metas e direcionadores Princípios de arquitetura incluindo princípios de negócio Avaliação de Capacidades Framework de Arquitetura adaptado Visão de Arquitetura Rascunho de Documento de Definição de Arquitetura Plano de Comunicação Conteúdo adicional populando o Repositório de Arquitetura

Fase Preliminar • Catálogo de Principios

Gerenciamento de Requisitos

Fase A, Visão de Arquitetura • Matriz de Mapa de Partes interessadas • Catálogo de Requisitos

TOGAF 9 Artifacts

Fase B, Arquitetura de Negócio • • • • • • • • • • • • • • • • • •

• Diagrama de Cadeia de Valor

• Diagrama Conceitual da Soluçao

Catálogo de Organização/Ator Catálogo de Direcionador/Meta/Objetivo Catálogo de Papéis Catálogo de Serviço de Negócio/Função Catálogo de Localidades Catálogo de Processo/Evento/Controle/Produ to Catálogo de Contrato/Medida Matriz de Interação de Negócio Matriz de Ator//Papel Diagrama de “Footprint” de Negócio Diagrama de Serviço de Negócio/Informação Diagrama de Decomposição Funcional Diagrama de Ciclo de Vida de Produto Diagrama de Meta/Objetivo/Serviço Diagrama de Casos de Uso de Negócio Diagrama de Decomposição da Organização Diagrama Slide 461 de Fluxo de Processo Diagrama de Evento

Fase C, Arquitetira de Dados

Fase C, Arquitetura de Aplicação

Fase D, Arquitetura Tecnológica

•

•

•

• • • • • • • •

Catálogo de Entidade de Dados/ Componente de Dados Matriz de Entidade de Dados/Funções de Negócio Matriz de Aplicação/Dados Diagrama lógico de dados Diarama de Disseminação de Dados Diagrama de segurança de Dados Diagrama hierárquico de Classes Diagrama de Migração de Dados Diagrama de Ciclo de Vida de Dados

• • • •

• • •

• • • • •

of 33

•

Catálogo de Portifólio de Aplicação Catálogo de Interface Matriz de Aplicação/Organização Matriz de Papel/Aplicação Matriz de Aplicação/Função Matriz de Interação de Aplicação Diagrama de Comunicação de Aplicação Diagrama de Localização de Aplicação e Usuário Diagrama de caso de Usos de Aplicações Diagrama de gerenciabiliade da Corporação Diagrama de Realização de Processo/Aplicação Diagrama de Engenharia de Software Diagrmaa de Migração de Aplicação Diagrama de Distribuição de Software

• • •

• • • •

Catálogo de Normas de Tecnologia Catálogo de Portifólio de Tecnologia Matriz de Sistema/Tecnologia Diagrmaa de Ambientes e Locais Diagrmaa de Decomposição de Plataforma Diagrama de Processamento Diagrmaa de Computação em Rede/Hardware Diagrama de Engenhari de Comunicação

Artefatos

Teste P. Complete a seguinte sentença: A Fase A, Visão da Arquitetura tem como objetivo de fazer tudo isso, exceto: A. Validar os princípios e objetivos de negócio da organização B. Garantir que os Princípios de Arquitetura estejam corretos C Estabelecer Governança de TI D Esclarecer e corrigir ambiguidades nos princípios de arquitetura E Definir os domínios de arquitetura específicos para serem tratados

Slide 462

Fase A Fase A: Visão da Arquitetura

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 463

de 31

Módulo 16 Fase B Arquitetura de Negócio Edição V9.1 Copyright © 2009-2011

Slide 464de

35

Todos os direitos reservados Publicado por The Open Group, 2011

Phase B Fase B: Arquitetura de Negócio

Business Architecture

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 465de

35

Objetivos da Arquitetura de Negócio Os objetivos da Fase B são: • Desenvolver a Arquitetura de Negócio Alvo descrevendo como a corporação precisa operar para alcançar os objetivos de Negócio, respondendo aos direcionadores estratégicos definidos na Visão da Arquitetura e abordando a Requisição para Trabalho de Arquitetura e preocupações das partes interessadas. • Identificar os componentes candidatos ao Roap de Arquitetura com base em diferenças entre as Arquiteturas de Negócio de Linha de Base e Alvo.

Slide 467

Abordagem •

Conhecimento da Arquitetura de Negócio é um prérequisito para o trabalho de arquitetura em outros domínios (dados, aplicações, tecnologia) – E também é a primeira atividade que precisa ser realizada.

•

A Estratégia de Negócio define o que alcançar

•

A Arquitetura de Negócio descreve como alcançar.

•

Esta Fase é frequentemente requerida para demonstrar o valor de negócio do trabalho subsequente para as partes interessadas

Slide 468

Abordagem • O Escopo depende da estratégia e planejamento existentes – Atualizar e verificar – Fazer a ligação entre direcionadores de negócio de alto nível, estratégia e metas, e requisitos de negócio específicos – Descobertas da arquitetura atual devem incluir todos os detalhes relevantes

• Se não houver nenhuma estratégia ou planejamento atual: – Identificar qualquer definição existente de arquitetura, então verificar e atualiza-la – Definições de um novo processo podem demandar um trabalho detalhado

• Em ambos os casos, use Cenários de Negócio para identificar os principais objetivos e processos de negócio Slide 469

Fase B: Entradas •

• • • • • • • • • • •

Slide 470

Requisição para Trabalho de Arquitetura Declaração de princípios de Negócio, metas e direcionadores refinados Avaliação de Capacidade Plano de Comunicação Modelo Organizacional para arquitetura corporativa Framework de arquitetura adaptado Declaração de Trabalho de Arquitetura Aprovada Princípios de Arquitetura Continuum da Corporação Repositório de Arquitetura Visão da Arquitetura Rascunho do Documento de Definição da Arquitetura

os A ordem dos os deve ser adaptada à situação. Você deve em particular determinar se é apropriado fazer primeiro a Arquitetura de Negócio de Linha de Base ou a Arquitetura de Negócio Alvo

9. Criar o Documento de Definição de Arquitetura 8. Finalizar a Arquitetura de Negócio 7. Conduzir uma revisão formal das Partes Interessadas 6. Resolver os impactos ao longo do Panorama da Arquitetura 5. Definir os componentes de Roap Candidatos 4. Executar a análise de diferenças

3. Desenvolver a Descrição da Arquitetura de Negócio Alvo 2. Desenvolver a Descrição da Arquitetura de Negócio de Linha de Base 1. Selecionar modelos de referência, pontos de vista, e ferramentas Slide 471

o 1: Selecionar modelos de referência, pontos de vista e ferramentas • Selecionar recursos relevantes de Arquitetura de Negócio no Repositório de Arquitetura, com base nos direcionadores de negócio, partes interessadas e preocupações. • Selecionar pontos de vista relevantes de Arquitetura de Negócio que possibilitarão ao arquiteto demonstrar como as preocupações das partes interessadas serão atendidas. • Identificar as ferramentas e técnicas apropriadas para serem usadas para capturar, modelar, e analisar junto com os pontos de vista. Continua… Slide 472

Fase Preliminar • Catálogo de Principios Gerenciamento de Requisitos Fase B, Arquitetura de Negócio • • • • • • • • • • • •

• • •

• • •

Fase A, Visão da Arquitetura •

TOGAF 9 Artifacts • Catálogo de Requisitos

Catálogo de Organização/Ator Catálogo de Direcionador/Meta/Objetivo Catálogo de Papéis Catálogo de Serviço de Negócio/Função Catálogo de Localidades Catálogo de Processo/Evento/Controle/Produto Catálogo de Contrato/Medida Matriz de Interação de Negócio Matriz de Ator/Papel Diagrama de “Footprint” de Negócio Diagrama de Serviço de Negócio/Informação Diagrama de Decomposição Funcional Diagrama de Ciclo de Vida de Produto Diagrama de Meta/Objetivo/Serviço Diagrama de Casos de Uso de Negócio Diagrama de Decomposição da Organização Diagrama de Fluxo de Processo Diagrama de Evento

Slide 473of

33

Matriz de Mapa de Partes interessadas

• Diagrama Conceitual • Diagrama de Cadeia de Valor da Soluçao

Fase E. Oportunidades e Soluções • Diagrama de Contexto de Projeto

Fase C, Arquitetira de Dados •

• •

• • • • • •

Fase C, Arquitetura de Aplicação

Catálogo de • Catálogo de Portfólio de Entidade de Aplicação Dados/ • Catálogo de Interface Componente de • Matriz de Dados Aplicação/Organização Matriz de Entidade • Matriz de Papel/Aplicação de Dados/Funções • Matriz de Aplicação/Função de Negócio • Matriz de Interação de Nota: Matriz de Aplicação O Módulo• 16A fornece Aplicação/Dados Diagrama de Comunicação Diagrama lógico de de Aplicação informações detalhadas dados • Diagrama de Localização de sobre os Catálogos, Matrizes Diagrama de Aplicação e Usuário Disseminação de • Diagrama de caso e Diagramas da Fase B de Usos Dados de Aplicações Diagrama de • Diagrama de gerenciabiliade segurança de da Corporação Dados • Diagrama de Realização de Diagrama Processo/Aplicação hierárquico de • Diagrama de Engenharia de Classes Software Diagrama de • Diagrama de Migração de Migração de Aplicação Dados • Diagrama de Distribuição de Diagrama de Ciclo Software de Vida de Dados

Fase D, Arquitetura Tecnológica •

• • • • •

• •

Catálogo de Normas de Tecnologia Catálogo de Portfólio de Tecnologia Matriz de Sistema/Tecnologi a Diagrama de Ambientes e Locais Diagrama de Decomposição de Plataforma Diagrama de Processamento Diagrama de Computação em Rede/Hardware Diagrama de Engenharia de Comunicação

o 1: Selecione modelos de referência,

pontos de vista e ferramentas • Determinar o Processo global de Modelagem • Identificar o nível de granularidade de serviço, fronteiras, e contratos necessários

• Identificar os Catálogos requeridos de Blocos de Construção de Negócio • Identificar os tipos de requisitos a serem capturados – Identificar requisitos a serem atendidos pela Arquitetura – Formalizar os requisitos orientados ao Negócio – Fornecer informações de requisitos para Arquitetura de Dados, Aplicação e Tecnologia – Se aplicável, fornecer uma orientação detalhada a ser seguida durante o design e implementação

Slide 474

Exemplos de Modelagem

Slide 475

o 2: Desenvolver a Descrição da Arquitetura de Negócio de Linha de Base • Deve ser completa, mas sem detalhes desnecessários • Se possível, identificar os blocos de construção relevantes da Arquitetura de Negócio, com base no Repositório de Arquitetura • Se não, desenvolver uma nova descrição de arquitetura: – Usar os modelos identificados no o 1 como orientação

Slide 476

o 3: Desenvolver a Descrição da Arquitetura de Negócio Alvo • Se possível, identificar os blocos de construção de Arquitetura de Negócio relevantes, com base no Repositório de Arquitetura • Se não, desenvolver uma nova descrição de arquitetura: – Usar os modelos identificados no o 1 como orientação

Slide 477

o 4: Executar Análise de Diferença Verificar os modelos de arquitetura enquanto a sua consistência e precisão: • Realize análise de trade-offs para resolver conflitos (se houver algum) entre visões (views) diferentes • Confirme se os modelos am os princípios, objetivos e restrições • Observe as alterações no Ponto de Vista representado nos modelos selecionados do Repositório Arquitetura e documente isso • Teste os modelos de arquitetura quanto a completude em relação aos requisitos • Identifique as diferenças entre a linha de base e alvo Continua… utilizando a técnica de Análise de Diferenças Slide 478

o 4: Realizar Análise de Diferenças A Análise de Diferenças destaca serviços e/ou funcionalidades que foram omitidas ou estão para serem desenvolvidas; estas são as diferenças (“gaps”). Eles devem ser marcadas como “eliminado corretamente” ou como “a ser resolvido por recolocação, desenvolvimento ou compra” 1. Criar uma matriz de BCAs de Negócio: – Coloque “Arquitetura Atual” + “Novos Serviços” no eixo vertical – Coloque “Arquitetura Alvo” + “Serviços Eliminados” no eixo horizontal

2. Marque os BCAs que são comuns aos dois como “Incluído” Continua… Slide 479

o 4: Realizar Análise de Diferenças 3. Revisar os blocos faltantes entre os atuais: – Confirmar como “Eliminado” – Se não marcar como “Rever”

4. Marcar quaisquer “Novos Serviços” como uma diferença a ser preenchida através de aquisição da função: – Desenvolvendo – Comprando

Slide 480

Exercício de Análise de Diferenças Dados os seguintes BCAs na arquitetura de linha de base: • Serviços de "broadcasting", serviços de videoconferência, serviços de telefonia avançada, serviços de compartilhamento de tela. E os seguintes BCAs na arquitetura alvo: • Serviços de conferência de vídeo, serviços de telefonia avançada, serviços de mailing list. Suponha que "serviços de compartilhamento de tela" foi involuntariamente excluído e que os "serviços de telefonia avançada" da linha de base podem corresponder às necessidades. Desenhe a matriz de análise de diferenças. Slide 481

Análise de Diferenças: Resposta

Slide 482

o 5: Definir os componentes de Roap Candidatos • O roap inicial de Arquitetura de Negócio será utilizado como matéria prima para apoiar a definição mais detalhada de um roap consolidado e interdisciplinar na Fase de Oportunidades e Soluções.

Slide 483

o 6: Resolver os impactos ao longo do Panorama da Arquitetura • Artefatos de Arquitetura no Panorama de Arquitetura devem ser examinados para identificar: – Esta Arquitetura de Negócio cria um impacto sobre quaisquer arquiteturas pré-existentes? – Mudanças recentes foram feitas com impacto na Arquitetura de Negócio? – Existem oportunidades para alavancar o trabalho a partir desta Arquitetura de Negócio em outras áreas da organização? – Será que esta Arquitetura de Negócio tem impacto em outros projetos? – Será que esta Arquitetura de Negócio será impactada por outros projetos?

Slide 484

o 7: Conduzir uma revisão formal pelas Partes Interessadas • Esta é uma revisão formal do modelo e dos blocos de construção selecionados.

• O objetivo é comparar a Arquitetura de Negócio proposta contra a Declaração de Trabalho (SOW).

• É possível voltar para os os anteriores, se necessário.

Slide 485

o 8: Finalizar a Arquitetura de Negócio •

• • • •

Selecionar padrões para cada um dos BCAs, sempre que possível reutilizando a partir do Repositório de Arquitetura. Documentar detalhadamente cada BCAs. Executar uma verificação cruzada da arquitetura geral contra as metas de negócio. Documentar o relatório final de rastreabilidade de requisitos. Documentar o mapeamento final da arquitetura no Repositório de Arquitetura. A partir dos BCAs selecionados, identificar quais podem ser reutilizados e publicar através do repositório de arquitetura Slide 486

o 9: Criar o Documento de Definição de Arquitetura • Documentar a justificativa para todas as decisões de blocos de construção no Documento de Definição de Arquitetura. • Preparar as seções de Negócio do Documento de Definição de Arquitetura. • Se for o caso, use relatórios e / ou gráficos gerados por ferramentas de modelagem para demonstrar visões fundamentais da arquitetura. Envie o documento para revisão pelas partes interessadas, e incorpore o .

Slide 487

Resumo sobre o uso de Blocos de Construção na Fase B • Quando estiver criando as descrições das Arquiteturas de Linha de Base e Alvo, o arquiteto deve identificar blocos de construção relevantes para a Arquitetura de Negócio: – A partir do Repositório de Arquitetura – O TOGAF inclui exemplos de catálogos, matrizes e diagramas que podem ser usados para modelar a decomposição de um bloco de construção

• A Análise de Diferenças é usada para identificar Blocos de Construção que devem ser transportados para a arquitetura alvo; Blocos de Construção eliminados; e novos Blocos de Construção necessários • Quando finalizada a Arquitetura de Negócio, os padrões são selecionados para cada um dos blocos de construção – Cada bloco de construção deve ser documentado – Aqueles que são candidatos a reuso, devem ser publicados no Repositório de Arquitetura

Slide 488

Fase B: Saídas • Declaração de Trabalho de Arquitetura • Princípios de Negócio, metas e direcionadores validados • Princípios de Arquitetura de Negócio revisados • Rascunho de Documento de Definição de Arquitetura • Rascunho de Especificação de Requisitos de Arquitetura • Componentes de Arquitetura de Negócio do Roap de Arquitetura Slide 489

Documento de Definição de Arquitetura • • • • •

Escopo Metas, objetivos, e restrições Princípios de Arquitetura Arquitetura de Linha de Base Modelos de Arquitetura (para cada estado a ser modelado): – Modelos de Arquitetura de Negócio – Modelos de Arquitetura de Dados – Modelos de Arquitetura de Aplicação – Modelos de Arquitetura Tecnológica

• Razão e justificativa para a abordagem arquitetural Slide 490

• Mapeamento para o Repositório de Arquitetura: – Mapeamento para o Panorama de Arquitetura – Mapeamento para modelos de referência – Mapeamento para normas/padrões – Avaliação de Reuso

• Análise de Diferenças • Avaliação de Impacto • Arquitetura de Transição

Documento de Definição de Arquitetura – Componentes de Arquitetura de Negócio •

•

Arquitetura de Negócio de Linha de Base, se necessário - esta é uma descrição da arquitetura do Negócio existente Arquitetura de Negócio Alvo , incluindo: – Estrutura organizacional - identificando locais de negócio e relacionando-os às unidades organizacionais – Metas e objetivos de Negócio - para a corporação e para cada unidade organizacional – Funções de Negócio - um o detalhado e recursivo envolvendo a decomposição sucessiva de grandes • áreas funcionais em subfunções – Serviços de Negócio - os serviços que a corporação e cada uma de suas unidade proporciona aos seus clientes, tanto interna como externamente

Slide 491

– Processos de Negócio, incluindo medidas e entregáveis – Papéis de Negócio, incluindo o desenvolvimento e modificação de necessidades de competências – Modelo de Dados do Negócio – Correlação de organização e funções - relacionar funções de negócio com as unidades organizacionais na forma de uma matriz

Visões correspondentes aos pontos de vista selecionados abordando preocupações das principais partes interessadas

Especificação de Requisitos de Arquitetura • • • • • • • • • • •

Medidas de sucesso (métricas) Requisitos de arquitetura Contratos de Serviço de Negócio Contratos de Serviços de Aplicação Orientações para a Implementação Especificações para a implementação Normas para a Implementação Requisitos de Interoperabilidade Requisitos de gerenciamento de serviços de TI Restrições Pressupostos Slide 492

Especificação de Requisitos de Arquitetura – Componentes de Arquitetura de Negócio • Resultados da Análise de Diferenças • Requisitos técnicos • Requisitos de Negócio atualizados

Slide 493

Fase B Fase B: Arquitetura de Negócio

Business Architecture

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 498de

35

Módulo 16A Fase B Arquitetura de Negócio - Catálogo, Matrizes e Diagramas Edição V9.1 Copyright © 2009-2011

Slide 499de

35

Todos os direitos reservados Publicado por The Open Group, 2011

Phase B

Fase B: Arquitetura de Negócio – Catálogos, Matrizes e Diagramas Business Architecture

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 500de

35

Fase Preliminar • Catálogo de Principios Gerenciamento de Requisitos Fase B, Arquitetura de Negócio • • • • • • • • • • • •

• • • • • •

Fase A, Visão da Arquitetura •

TOGAF 9 Artifacts • Catálogo de Requisitos

Catálogo de Organização/Ator Catálogo de Direcionador/Meta/Objetivo Catálogo de Papéis Catálogo de Serviço de Negócio/Função Catálogo de Localidades Catálogo de Processo/Evento/Controle/Produto Catálogo de Contrato/Medida Matriz de Interação de Negócio Matriz de Ator//Papel Diagrama de “Footprint” de Negócio Diagrama de Serviço de Negócio/Informação Diagrama de Decomposição Funcional Diagrama de Ciclo de Vida de Produto Diagrama de Meta/Objetivo/Serviço Diagrama de Casos de Uso de Negócio Diagrama de Decomposição da Organização Diagrama de Fluxo de Processo Diagrama de Evento

Slide 502of

33

Matriz de Mapa de Partes interessadas

• Diagrama Conceitual • Diagrama de Cadeia de Valor da Soluçao

Fase E. Oportunidades e Soluções • Diagrama de Contexto de Projeto

Fase C, Arquitetira de Dados

Fase C, Arquitetura de Aplicação

Fase D, Arquitetura Tecnológica

•

•

•

• •

• • • • • •

Catálogo de Entidade de Dados/ Componente de Dados Matriz de Entidade de Dados/Funções de Negócio Matriz de Aplicação/Dados Diagrama lógico de dados Diagrama de Disseminação de Dados Diagrama de segurança de Dados Diagrama hierárquico de Classes Diagrama de Migração de Dados Diagrama de Ciclo de Vida de Dados

• • • • • • • • •

• • • •

Catálogo de Portfólio de Aplicação Catálogo de Interface Matriz de Aplicação/Organização Matriz de Papel/Aplicação Matriz de Aplicação/Função Matriz de Interação de Aplicação Diagrama de Comunicação de Aplicação Diagrama de Localização de Aplicação e Usuário Diagrama de caso de Usos de Aplicações Diagrama de gerenciabiliade da Corporação Diagrama de Realização de Processo/Aplicação Diagrama de Engenharia de Software Diagrama de Migração de Aplicação Diagrama de Distribuição de Software

• • • • •

• •

Catálogo de Normas de Tecnologia Catálogo de Portfólio de Tecnologia Matriz de Sistema/Tecnologi a Diagrama de Ambientes e Locais Diagrama de Decomposição de Plataforma Diagrama de Processamento Diagrama de Computação em Rede/Hardware Diagrama de Engenharia de Comunicação

Artefatos

Catálogos, Matrizes e Diagramas Catálogos Diagramas • Catálogo de Ator/Organização • Diagrama de “Footprint” de • Catálogo de Negócio Direcionador/Meta/Objetivo • Diagrama de Serviço/Informação • Catálogo de Papel de Negócio • Catálogo de Serviço/Função de • Diagrama de Decomposição Negócio Funcional •O formato exato dos e • Catálogo de Localizaçãocatálogos, matrizes • Diagrama de Ciclo de Vida de diagramas dependerá • Catálogo de Produto das ferramentas usadas Processo/Evento/Controle/Produ • Diagrama de to Meta/Objetivo/Serviço • Catálogo de Contrato/Medidas • Diagrama de Caso de Uso Matrizes • Diagrama de Decomposição • Matriz de Interação de Negócio Organizacional • Matriz Ator/Papel • Diagrama de Fluxo de Processo • Diagrama de Evento Slide 503

Catálogos Catálogo Catálogo de Organização/ Ator

Propósito Uma listagem definitiva de todos os participantes que interagem com TI, incluindo usuários e proprietários de sistemas de TI. Ele contém as seguintes entidades de metamodelo: •Unidade organizacional, localidade de ator (pode ser incluído neste catálogo se um catálogo de localidade independente não existir)

Catálogo de Direcionador/ Meta/Objetivo

Uma referência cruzada organizacional de como uma organização atende a seus direcionadores na prática através das metas, objetivos, e (opcionalmente) medidas. Ele contém as seguintes entidades de metamodelo: •Unidade organizacional, Direcionador, Meta, Objetivo, Medida (pode opcionalmente ser incluída)

Catálogo de Papel

O Propósito do Catálogo de Papel é prover uma lista de todos os níveis ou zonas de autorização dentro de uma corporação. Frequentemente, a segurança ou o comportamento da aplicação são definidos através de um entendimento local do conceito de autorização que gera consequências complexas e inesperadas quando combinadas. Ele contém as seguintes entidades de metamodelo: •Papel

Slide 504

Catálogos Catálogo

Propósito

Catálogo de Serviço/Função de Negócio

A decomposição funcional de uma forma que pode ser filtrada, relatada, e consultada, como um suplemento para diagramas de decomposição funcional. Ele contém as seguintes entidades de metamodelo: •Unidade Organizacional, Função de Negócio, Serviço de Negócio, Serviço de Sistema de Informação (podem, opcionalmente, ser incluídos aqui)

Catálogo de Localidades

Uma lista de todos os locais onde a empresa realiza operações de negócio ou guarda ativos arquiteturalmente relevantes, tais como data centers ou equipamentos de usuário final. Ele contém as seguintes entidades de metamodelo: •Localidade

Catálogo de Processo/Evento/ Controle/ Produto

O Catálogo de Processo/Evento/Controle/Produto fornece uma hierarquia de processos, eventos desencadeadores de processos, saídas a partir de processos e controles existentes para a execução dos processos. Este catálogo fornece um suplemento para os diagramas de fluxo de processo e permitem a uma organização filtrar, informar e consultar ao longo das organizações e processos para identificar o escopo, aspectos comuns, ou impacto. Ele contém as seguintes entidades de metamodelo: •Processo, Evento, Controle, Produto

Slide 505

Catálogos Catálogo

Propósito

Catálogo de Contrato/Medida

Uma listagem de todos os contratos de serviços acordados e (opcionalmente) as medidas associadas a esses contratos. Ele forma a lista principal de níveis de serviço acordados para toda a empresa. Ele contém as seguintes entidades de metamodelo:

•Serviço de Negócio •Serviço de Sistema de Informação (opcionalmente) •Contrato •Medida

Slide 506

Exercício

Slide 507

Matrizes • Matriz de Interação de Negócio • Matriz Ator/Papel

Slide 508

Matriz de Interação de Negócio • O objetivo desta matriz é descrever as interações entre organizações e funções de negócio em toda a corporação. Providing Business Services Consuming Business Services

Engineering Procurement

Manufacturing

Sales and Distribution

Engineering Procurement Contract for supply of materials

Manufacturing

Sales and Distribution

Customer Service

Slide 509

Contract for supply of product specification

Contract for supply of sales forecasts Contract for supply of product Contract for fulfillment of customer orders

Customer Service

Matriz Ator/Papel • Esta matriz mostra quais atores executam quais papéis, apoiando a definição de requisitos de segurança e competências.

Slide 510

I I I I

R R R R R

I C I R C

I I I I I

I I I I I

R R R R R

I I I I R

C C C C R

C C C C C

C R R

C C C C

I A I R R R C A

Vendedores/Fornecedores Externos

C C C C

I I R I I

Gerente de Projeto

C C C C

C R I I I

Operações de TI

I I I I

C C I R A

Projetista de Infraestrutura

I I I I

Líder de Implementação

A A A A C

I C

Arquiteto Corporativo de Infraestrutura

C I

Gerente de Arquitetura de Configuração

R C I I I

Arquiteto de Solução de Infraestrutura

C C I I C

Arquiteto de Aplicação de Unidade de Negócio

C R I A C

Estrategista de Infraestrutura

I

I I I I C

Atores de Implementação de Infraestrutura

Atores de Estratégia e Arquitetura

Líder de Estratégia e Arquitetura

I

Proprietário de Serviços da Unidade de Negócio

C

Líder da Unidade de Negócio

Autoridade de Design Corporativo A A I

Fórum de Gerenciamento de TI

I

R C I C C

Atores de Unidades de Negócio

Autoridade de Desenho técnico

I I I

Arquiteto Corporativo

R = Responsável por desempenhar o papel E = Encarregados pelo atores desempenhando o papel C = Consultado no desempenho do papel I = Informado no desempenho do papel Papéis de Ciclo de vida Estratégico Atualização da Arquitetura Roap de Arquitetura Avaliação de Benefícios Gerência de Mudança Atualização do Framework Papéis de Ciclo de vida de Projeto Visão da Arquitetura de Solução Arquitetura Lógica de Solução Arquitetura Física de Solução Governança de Design Gerência de Configuração de Arquitetura

CIO

Domínio de Atores do Grupo Atores do De Orientação CIO

C C

Diagramas • • • • • • • • •

Diagrama de “Footprint” de Negócio Diagrama de Serviço/Informação de Negócio Diagrama de Decomposição Funcional Diagrama de Ciclo de Vida de Produto Diagrama de Meta/Objetivo/Serviço Diagrama de Caso de Uso Diagrama de Decomposição Organizacional Diagrama de Fluxo de Processo Diagrama de Evento

Slide 511

Diagrama de “Footprint” de Negócio • Descreve as conexões entre os objetivos de negócio, unidades organizacionais, funções de negócio e serviços, mapeando essas funções para os componentes técnicos que entregam a capacidade necessária. • Demonstra apenas os fatos principais ligando as funções das unidades organizacionais aos serviços de entrega, e é utilizado como uma plataforma de comunicação para partes interessadas seniores (CxO)

Slide 512

Examplo de Diagrama de “Footprint” de Negócio

Slide 513

Diagrama de Serviço/Informação de Negócio • Mostra as informações necessárias para apoiar um ou mais serviço de negócio. • Mostra os dados que são consumidos ou produzidos por um serviço de negócio. Pode mostrar também a origem da informação. • Mostra uma representação inicial da informação presente dentro da arquitetura e, portanto, forma uma base para a elaboração e aperfeiçoamento dentro da Fase C (Arquitetura de Dados).

Slide 514

Exemplo de Diagrama de Serviço/Informação de Negócio Complaint Complaint Handling Service Customer Details

Complaint Resolution

Exemplo básico Slide 515

Customer Details

Common Faults

Exemplo de Diagrama de Serviço/Informação de Negócio Complaint Complaint Handling Service Customer Details Customer Complaint Resolution

Customer Details

Lead Management Service

Exemplo estendido mostrando interações de atores e serviços Slide 516

Common Faults

Fault Management Service

Diagrama de Decomposição Funcional • Mostra em uma única página as capacidades de uma organização que são relevantes para se considerar em uma arquitetura. • Ao examinar os recursos de uma organização a partir de uma perspectiva funcional, é possível desenvolver rapidamente modelos sobre o que a organização faz, sem ser levado para um debate extenso sobre como a organização faz.

Slide 517

Exemplo de um Diagrama de Decomposição Funcional

Slide 518

Diagrama de Ciclo de Vida de Produto • Ajuda na compreensão dos ciclos de vida de entidades chave dentro da corporação. • Compreender ciclos de vida de produtos está se tornando cada vez mais importante no que diz respeito às preocupações, legislação e regulamentação ambientais, onde os produtos devem ser rastreados desde a fabricação até o descarte. • Igualmente, as organizações que criam produtos que envolvem informações pessoais ou confidenciais devem possuir um entendimento detalhado do ciclo de vida do produto durante o desenvolvimento da Arquitetura de Negócio, a fim de garantir o rigor no desenho de controles, processos e procedimentos. Exemplos disso incluem cartões de crédito, cartões de débito, cartões de loja / fidelidade, cartões inteligentes, credenciais de identidade do usuário (carteiras de identidade, aportes, etc.) Slide 519

Exemplo de Diagrama de Ciclo de Vida de Produto

Slide 520

Diagrama de Meta/Objetivo/Serviço • Define as formas pelas quais um serviço contribui para a realização de uma visão de negócio ou estratégia. • Serviços estão associados com os direcionadores, metas, objetivos e medidas que eles apoiam, permitindo que a corporação entenda quais serviços contribuem para aspectos similares de desempenho do negócio. • Isso também proporciona uma informação qualitativa sobre o que constitui alto desempenho para um serviço em particular.

Slide 521

Exemplo do Diagrama de Meta/Objetivo/Serviço Papel:CFO

Meta: Aumentar a Receita

Papel: VP Marketing Objetivo: Mercado de Carros usados

Objetivo: Criar uma nova linha de carros até…

Função: Vendas e Marketing Serviço: Marketing Serviço:Veículos usados Serviço: Campanha

Serviço: Vendas Serviço: Pre-Vendas

Slide 522

Serviço: Entrega do Pedido

Papel: VP de Vendas

Diagrama de Caso de Uso de Negócio • Este diagrama mostra as relações entre consumidores e fornecedores dos Serviços de Negócio. • Serviços de Negócio são consumidos por atores ou outros Serviços de Negócio, e o Diagrama de Caso de Uso de Negócio oferece uma riqueza adicional em descrever uma capacidade, ilustrando como e quando essa capacidade é usada. • Eles ajudam a descrever e a validar a interação entre os atores e seus papéis nos processos e funções. • A medida que a arquitetura evolui, o caso de uso pode evoluir a partir do nível de negócio para incluir dados, aplicações, e detalhes tecnológicos. Casos de Uso Arquiteturais de Negócio também podem ser reusados no trabalho de concepção de sistemas. Slide 523

Exemplo de Diagrama de Caso de Uso de Negócio

Slide 524

Diagrama de Decomposição Organizacional • Este diagrama descreve as conexões entre ator, papéis e localidades dentro de uma árvore organizacional. • Um mapa da organização deve fornecer uma cadeia de comando dos proprietários e tomadores de decisão ​da organização.

Slide 525

Exemplo de Organização

Slide 526

Diagrama de Fluxo de Processo • Descreve todos os modelos e mapeamentos relacionados com a entidade de metamodelo “processo”. • Ele mostra o fluxo sequencial de controle entre as atividades e pode utilizar técnicas de “raias” (“swim-lane”) para representar a propriedade e realização das etapas do processo. • Além de mostrar uma sequência de atividades, os fluxos de processos também podem ser usado para detalhar os controles que se aplicam a um processo, os eventos que desencadeiam ou resultam da conclusão do processo, e também os produtos que são gerados a partir da execução do processo. Slide 527

Exemplo de Diagrama de Fluxo de Processo Início

o 2

o 1

o 5

Slide 528

o 3

o 6

o 4

o 6

o 6

PARAR

Exemplo de Diagrama de Fluxo de Processo Equipe de e técnico

Início

o 1

Representante De vendas

o 2

Aplicação Proprietária

Email

Aprovador De proposta

Representante Do Cliente

o 5

IWF

Precificador

o 3

CRM

o 6

email

Representante Do Cliente

o 6

Ferramenta De Consolidação

Fluxo do Processo (com Papeis e Aplicações) Slide 529

Precificador

o 4

MS Word MS Excel

Representante Do Cliente

o 6

Planilha

PARAR

Diagrama de Eventos • Descreve a relação entre eventos e processos. • Certos eventos - como a chegada de informações (por exemplo, um pedido do cliente) ou um momento no tempo (por exemplo, final do trimestre fiscal) - gera trabalho e atividades a serem desenvolvidas dentro da empresa.

Slide 530

Exemplo de Diagrama de Eventos

Impacta/Gera

Triggers

Evento (ex. Fim do trimestre fiscal)

Slide 531

Processo

(ex. Processo de relatório financeiro)

Resultado de Negócio (ex. resultados do primeiro trimestre informado para agência governamental)

Exemplo de Matriz de Eventos EVENTO

RESULTADO(S) DE NEGÓCIO

PROCESSO DESENCADEADO

Cliente submete um pedido

Processamento de pedidos  Criar e salvar pedido  Gerar conhecimento  Recibo de confirmação do pedido do cliente  Iniciar atividades de execução do pedido



Pedido de venda capturado no livro de pedidos

Cliente submete um pedido de um produto customizado

Configuração de produto customizado  Capturar requisitos do cliente  Definir especificações de customização  Precificar configuração customizada  Negociar com o cliente  Aprovar, de forma segura, com o cliente a configuração e preço



Produto customizado configurado Contrato assinado pelo cliente

Fim do Trimestre

Processo de relatório financeiro



Slide 532



Relatório financeiro gerado

Fase B Fase B: Arquitetura de Negócio – Catálogos, Matrizes e Diagramas Business Architecture

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 533de

35

Módulo 17 Fase C Arquiteturas de Sistemas de Informação – Visão Geral Edição de Direitos Autorais V9.1 © 2009-2011

Slide 534of

14

Todos os direitos reservados Publicado por The Open Group, 2011

Phase C Fase C: Visão Geral Arquiteturas de Sistemas de Informação

Arquitetura Arquitetura de Aplicativos de Dados

TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países

Slide 535of

14

Arquiteturas de Sistemas de Informação – Objetivos • Desenvolver a Arquitetura Alvo de Sistemas de Informação (Dados e Aplicativos), descrevendo como a Arquitetura de Sistemas de Informação da corporação habilitará a Arquitetura de Negócio e a Visão da Arquitetura, de forma que aborde a Requisição para o Trabalho de Arquitetura e os interesses e preocupações das partes interessadas. • Identificar os componentes candidatos para o Roap de Arquitetura baseados nas diferenças entre as Arquiteturas Alvo e as de Linha de Base de Sistemas de Informação (Dados e Aplicativos).

Slide 537

Abordagem A Fase C envolve a Arquitetura de Dados e a de Aplicativos, em qualquer ordem. Existem defensores para ambas as sequências: •

O Enterprise Architecture Planning de Spewak recomenda uma sequência orientada por dados.

•

Os principais sistemas aplicativos (ERP, CRM, …) muitas vezes combinam infraestrutura tecnológica e lógica de aplicativos. Uma abordagem orientada por aplicativos considera as aplicações principais (que sustentam os processos de negócio críticos para a missão) como o foco principal do esforço de arquitetura.

•

Problemas de integração muitas vezes constituem um grande desafio.

Continua…

Slide 538

Design Top-Down – Implementação Bottom-up •

Design: 1. Arquitetura de Negócio 2. Arquitetura de Dados (ou Aplicativos) 3. Arquitetura de Aplicativos (ou Dados) 4. Arquitetura Tecnológica

•

Implementação: 1. Arquitetura Tecnológica 2. Arquitetura de Aplicativos (ou Dados) 3. Arquitetura de Dados (ou Aplicativos)

4. Arquitetura de Negócio

Slide 539

Abordagem Alternativa: Sequência de Implementação Orientada por Dados 1. Primeiro implemente sistemas aplicativos que criam dados 2. Então aplicativos que processam os dados 3. Finalmente, aplicativos que arquivam os dados

Slide 540

Abordagem: Repositório de Arquitetura • Considere modelos genéricos relevantes para o setor vertical de uma organização – Recursos de Arquitetura de Dados • Modelos de dados genéricos, por exemplo o modelo de dados ARTS (setor de varejo), e o modelo de dados Energistics (indústria Petrotécnica)

– Recursos de Arquitetura de Aplicativos • Modelos de aplicativos genéricos, por exemplo o TeleManagement Forum (setor de telecomunicações), e o OMG que tem uma série de modelos de software para verticais específicas (Saúde, Transporte, Finanças, etc)

Slide 541

Considerações sobre a Arquitetura de Dados • Gerenciamento de Dados • Migração de Dados • Governança de Dados

Slide 542

Fase C: Entradas • Requisição para Trabalho de Arquitetura • Avaliação de Capacidade • Plano de Comunicações • Modelo Organizacional para a Arquitetura Corporativa • Framework de Arquitetura Padronizado • Princípios de Dados/Aplicativos • Declaração de Trabalho de Arquitetura • Visão da Arquitetura • Repositório de Arquitetura Slide 543

• Rascunho do Documento de Definição da Arquitetura • Rascunho da Especificação de Requisitos da Arquitetura, incluindo: – Resultados da Análise de Diferenças – Requisitos técnicos relevantes • Componentes da Arquitetura de Negócio do Roap da Arquitetura

os Nota:

1. Arquitetura de Dados Os detalhes para esses os 2. Arquitetura de Aplicativos serão cobertos nos próximos dois módulos Os os seguem um padrão comum com as Fases B e D

Slide 544

Fase C: Saídas: Arquitetura de Aplicativos •

Declaração de Trabalho de

•

Arquitetura •

Princípios validados, ou novos princípios (dados/aplicativos)

•

Rascunho do Documento de Definição da Arquitetura, contendo: – Arquitetura de Linha de Base de Aplicativos/Dados – Arquitetura Alvo de Aplicativos/Dados – Visões da Arquitetura de Aplicativos/Dados dos principais interesses e preocupações das partes interessadas Slide 545

•

Rascunho da Especificação dos Requisitos da Arquitetura, incluindo: – Resultados da Análise de Diferença – Requisitos de interoperabilidade de Aplicativos/Dados – Requisitos técnicos relevantes – Restrições sobre a Arquitetura Tecnológica – Requisitos de Negócio atualizados Componentes da Arquitetura de Aplicativos/Dados do Roap de Arquitetura

Phase C Fase C: Visão Geral Arquiteturas de Sistemas de Informação

Arquitetura Arquitetura de Aplicativos de Dados

TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países

Slide 548of

14

Módulo 18 Fase C Arquitetura de Dados Edição de Direitos Autorais V9.1 © 2009-2011

Slide 549de 28 Todos os direitos reservados Publicado por The Open Group, 2011

Phase C Fase C: Arquitetura de Dados

Arquitetura de Dados

TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países.

Slide 550de 28

Objetivos – Arquitetura de Dados Desenvolver a Arquitetura de Dados Alvo que habilita a Arquitetura de Negócio e a Visão da Arquitetura, enquanto aborda a Requisição para Trabalho de Arquitetura e as preocupações e interesses das partes interessadas. Identificar componentes candidatos do Roap de Arquitetura baseado nas diferenças entre as Arquiteturas de Dados de Linha de Base e Alvo.

Slide 552

Fase C: Entradas • Requisição para Trabalho de Arquitetura • Avaliação de Capacidade • Plano de Comunicações • Modelo Organizacional para a Arquitetura Corporativa • Framework de Arquitetura Adaptado • Princípios de Dados • Declaração de Trabalho de Arquitetura Continua… Slide 553

Fase C: Entradas • Visão da Arquitetura • Repositório de Arquitetura • Rascunho do Documento de Definição de Arquitetura • Rascunho da Especificação dos Requisitos da Arquitetura, incluindo: – Resultados da Análise de Diferenças – Requisitos técnicos relevantes

• Componentes da Arquitetura de Negócio do Roap de Arquitetura Slide 554

os A ordem destes os deve ser adaptada à situação. Em particular, você deve determinar se é apropriado fazer a Arquitetura de Dados de Linha de Base ou o desenvolvimento da Arquitetura de Dados Alvo primeiro.

9. Criar o Documento de Definição da Arquitetura 8. Finalizar a Arquitetura de Dados 7. Conduzir a revisão formal Pelas partes interessadas 6. Resolver os impactos em todo o Panorama da Arquitetura 5. Definir componentes candidatos do Roap 4. Realizar uma Análise de Diferenças

3. Desenvolver a Descrição da Arquitetura de Dados Alvo 2. Desenvolver a Descrição da Arquitetura de Dados de Linha de Base 1. Selecionar modelos de referência, pontos de vista e ferramentas Slide 555

o 1: Selecionar modelos de referência, pontos de vista e ferramentas • Revisar/gerar e validar os princípios de dados – ver Princípios Arquiteturais • Selecionar recursos da Arquitetura de Dados (modelos de referência, padrões, …)

• Selecionar pontos de vista relevantes à Arquitetura de Dados • Identificar ferramentas e técnicas apropriadas (incluindo formulários) para serem utilizados na captura, modelagem e análise dos dados, em associação com os pontos de vista selecionados. • São exemplos de técnicas de modelagem de dados: – Diagrama de entidade-relacionamento – Diagramas de classes Continua… Slide 556

Fase Preliminar • Catálogo de Princípios Gerenciamento de Requisitos

Fase A, Visão da Arquitetura • Matriz de Mapeamento de Partes Interesssadas

• Diagrama da Cadeia de Valores • Diagrama de Conceito de Soluções

TOGAF 9 Artifacts • Catálogo de Requisitos

Fase B, Arquitetura de Negócio

Fase C, Arquitetura de Dados

Fase C, Arquitetura de Aplicativos

Fase D, Arquitetura Tecnológica

• •

•

•

•

• • • •

• • • • • • • • • • •

Catálogo de Organização / Ator Catálogo de Motivador / Meta / Objetivo Catálogo de Papéis Catálogo de Serviço de Negócio / Função Catálogo de Localização Catálogo de Processo / Evento / Controle / Produto Catálogo de Contrato / Medida Matriz de Interação de Negócio Matriz de Ator / Papel Diagrama de Footprint de Negócio Diagrama de Serviço de Negócio / Informação Diagrama de Decomposição Funcional Diagrama de Ciclo de Vida de Produto Diagrama de Meta / Objetivo / Serviço Diagramam de Decomposição da Organização Diagrama de Fluxo de Processo Diagrama de Eventos

Fase E. Oportunidades e Soluções • Diagrama de Contexto de Projeto • Diagrama de Benefícios

Slide 557

• •

Catálogo de Entidade de Dados / Componente de Dados Matriz de Entidade de Dados / Função de Negócio Matriz de Aplicativo / Dados Diagrama Lógico de Dados Diagrama de Disseminação de Dados Diagrama de Segurança de Dados Diagrama de Hierarquia de Classes Diagrama de Migração de Dados Diagrama de Ciclo de Vida de Dados

• • • • •

Catálogo de Portfólio de Aplicativos Catálogo de Interfaces Matriz de Aplicativos / Organização Matriz de Papel / Aplicativo Matriz de Aplicativo / Função Matriz de Interação entre Aplicativos Diagrama de Comunicação entre Aplicativos Diagrama de Aplicativos e Localização de Usuário Diagramam de Caso de Uso de Aplicativo Diagrama de Gerenciabilidade Corporativa Diagrama de Processo / Relização de Aplicativo Diagrama de Engenharia de Software Diagrama de Migração de Aplicativos Diagrama de Distribuição de Software

Nota: • • O módulo 18A fornece • informações detalhadas • sobre a Fase C: Arquitetura • • de Dados, Catálogos , • Diagramas e Matrizes • • •

• • • •

• • •

• • • •

Catálogo de Padrões Tecnológicos Catálogo de Portfólio Tecnológico Matriz de Sistema / Tecnologia Diagrama de Ambientes e Localizações Diagrama de Decomposição de Plataforma Diagrama de Processamento Diagrama de Computação em Rede / Hardware Diagrama de Engenharia de Comunicações

TOGAF 9 Artefatos

o 1: Selecione modelos de referência, pontos de vista e ferramentas •

Determine o Processo de Modelagem Geral –

Para cada ponto de vista, selecione os modelos necessários para ar a visão específica requerida, utilizando o método ou ferramenta selecionada. Exemplos de modelos de dados lógicos incluem: • • •

•

•

o DODAF Logical Data Model o ARTS Data Model for the Retail Industry e o Energistics Data Model para a indústria Petrotécnica

Confirme se todos os interesses das partes interessadas são abordados. Se não, crie novos modelos para abordar os interesses não cobertos, ou aprimore os modelos existentes

Identifique Catálogos Requeridos de Blocos de Construção de Dados –

O inventário de dados da organização é capturado como um catálogo dentro do Repositório de Arquitetura. Continua…

Slide 558

o 1: Selecione modelos de

referência, pontos de vista e ferramentas • Identifique as Matrizes Requeridas – Matrizes mostram os principais relacionamentos entre modelos de entidades relacionados.

• Identifique os Diagramas Requeridos – Diagramas apresentam a informação da Arquitetura de Dados de um conjunto de diferentes pontos de vista.

• Identifique Tipos de Requisitos a serem Coletados – Identifique requisitos a serem satisfeitos pela Arquitetura – Formalize os requisitos focados em dados – Proveja entrada de requisitos para as Arquiteturas de Aplicativos e Tecnológica

Slide 559

o 2 Desenvolva uma Descrição da Arquitetura de Dados de Linha de Base Se possível, identifique os BCAs de Dados relevantes, a partir do Repositório de Arquitetura

•

Senão, desenvolva novos modelos de arquitetura: –

use os modelos identificados no o 1 como diretrizes

Continua… Slide 560

o 3 Desenvolva a Descrição da Arquitetura de Dados Alvo •

Se possível, identifique os blocos de construção relevantes da Arquitetura de Dados, a partir do Repositório da Arquitetura

•

Senão, desenvolva um novo modelo de arquitetura: –

Slide 561

use os modelos identificados no o 1 como diretriz

o 4 Realize uma Análise de Diferenças Verifique os modelos de arquitetura em relação a consistência interna e precisão Observe as alterações nos pontos de vista representados nos modelos selecionados do Repositório de Arquitetura e as documente Teste os modelos de arquitetura quanto a completude contra os requisitos Identifique as diferenças entre a linha de base e o alvo utilizando a técnica de Análise de Diferenças padrão

Slide 562

o 5: Defina os componentes candidados do roap • Este roap inicial da Arquitetura de Dados será utilizado como matéria prima para ar uma definição mais detalhada de um roap consolidado, multidisciplinar, na fase Oportunidades e Soluções.

Slide 563

o 6: Resolva os impactos em todo o Panorama da Arquitetura • Artefatos arquiteturais no Panorama da Arquitetura devem ser examinados para identificar: – Esta Arquitetura de Dados cria um impacto nas arquiteturas préexistentes? – Foram feitas mudanças recentes que podem impactar a Arquitetura de Dados? – Existem oportunidades que possam alavancar o trabalho desta Arquitetura de Dados em outras áreas da organização? – Esta Arquitetura de Dados tem impacto em outros projetos? – Esta Arquitetura de Dados será impactada por outros projetos?

Slide 564

o 7 Conduza uma Revisão Formal com as Partes Interessadas Verificar a motivação original para o projeto de arquitetura e a Declaração de Trabalho de Arquitetura contra a Arquitetura de Dados proposta. Conduza uma análise de impacto para: • Identificar quaisquer áreas onde a Arquitetura de Aplicativos e a Arquitetura de Negócio possam necessitar de alterações para atender às mudanças na Arquitetura de Dados. Se o impacto for significativo, revisite a Arquitetura de Negócio.

Continua… Slide 565

o 7 Conduza uma Revisão Formal com as Partes Interessadas •

• •

Slide 566

Identificar quaisquer áreas onde a Arquitetura de Aplicativos possa necessitar de alterações para atender às mudanças na Arquitetura de Dados (ou para identificar restrições na Arquitetura de Aplicativos prestes a serem desenhadas). Se o impacto for significativo, revisite a Arquitetura de Aplicativos. Identificar quaisquer restrições na Arquitetura Tecnológica. Refinar a Arquitetura de Dados proposta, se necessário.

o 8: Finalize a Arquitetura de Dados • • • • •

•

Selecione padrões para cada um dos BCAs, reutilizando tanto quanto for possível. Documente completamente cada BCA. Verifique toda a arquitetura contra os requisitos de negócio. Documente o relatório final de rastreabilidade de requisitos. Documente o mapeamento final da arquitetura dentro do Repositório de Arquitetura. Identifique os BCAs que podem ser reutilizados e publique-os via repositório de arquitetura. Finalize todos os produtos de trabalho. Continua…

Slide 567

o 9: Crie o Documento de Definição da Arquitetura • Documente as razões para todas as decisões sobre os blocos de construção no documento de definição de arquitetura. • Prepare as seções da Arquitetura de Dados do documento de definição da arquitetura. • Se for o caso, use relatório e/ou gráficos gerados por ferramentas de modelagem para demonstrar as visões chave da arquitetura. Encaminhe o documento para revisão pelas partes interessadas relevantes e incorpore o .

Slide 568

Fase C: Resultados: Arquitetura de Dados • Declaração de Trabalho de Arquitetura • Princípios de dados validados ou novos princípios de dados • Rascunho do Documento de Definição de Arquitetura • Rascunho da Especificação de Requisitos de Arquitetura • Componentes da Arquitetura de Dados do Roap de Arquitetura Slide 569

Documento de Definição da Arquitetura – Componentes da Arquitetura de Dados • Arquitetura de Dados de Linha de Base, se for o caso • Arquitetura de Dados Alvo, incluindo: – – – –

Modelo de dados de negócio Modelo de dados lógico Modelos de processos de gerenciamento de dados Matriz de Função de Negócio / Entidade de Dados

• Visões da Arquitetura de Dados correspondendo aos pontos de vista selecionados abordando os interesses das principais partes interessadas

Slide 570

Especificação dos Requisitos de Arquitetura – Componentes da Arquitetura de Dados • Resultados da Análise de Diferenças • Requisitos de interoperabilidade de dados • Áreas onde a Arquitetura de Negócio pode precisar mudar de forma a atender às mudanças na Arquitetura de Dados • Restrições na Arquitetura Tecnológica que será projetada • Requisitos atualizados de negócio/aplicações/dados, se for o caso

Slide 571

Phase C Fase C: Arquitetura de Dados

Arquitetura de Dados

TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países.

Slide 576de 28

Módulo 18A Fase C Arquitetura de Dados – Catálogos, Matrizes e Diagramas Edição de Direitos Autorais V9.1 © 2009-2011

Slide 577de

25

Todos os direitos reservados Publicado por The Open Group, 2011

Phase C Fase C: Arquitetura de Dados – Catálogos, Matrizes e Diagramas Arquitetura de Dados

TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países.

Slide 578de

25

Fase Preliminar • Catálogo de Princípios

Gerenciamento de Requisitos

Fase A, Visão da Arquitetura • Matriz de Mapeamento de Partes Interesssadas

• Diagrama da Cadeia de Valores • Diagrama de Conceito de Soluções

TOGAF 9 Artifacts • Catálogo de Requisitos

Fase B, Arquitetura de Negócio

Fase C, Arquitetura de Dados

Fase C, Arquitetura de Aplicativos

Fase D, Arquitetura Tecnológica

• •

•

•

•

• • • • • • • • • •

• • • • •

Catálogo de Organização / Ator Catálogo de Motivador / Meta / Objetivo Catálogo de Papéis Catálogo de Serviço de Negócio / Função Catálogo de Localização Catálogo de Processo / Evento / Controle / Produto Catálogo de Contrato / Medida Matriz de Interação de Negócio Matriz de Ator / Papel Diagrama de Footprint de Negócio Diagrama de Serviço de Negócio / Informação Diagrama de Decomposição Funcional Diagrama de Ciclo de Vida de Produto Diagrama de Meta / Objetivo / Serviço Diagramam de Decomposição da Organização Diagrama de Fluxo de Processo Diagrama de Eventos

Fase E. Oportunidades e Soluções • Diagrama de Contexto de Projeto • Diagrama de Benefícios

Slide 580

• • • • • • • •

Catálogo de Entidade de Dados / Componente de Dados Matriz de Entidade de Dados / Função de Negócio Matriz de Aplicativo / Dados Diagrama Lógico de Dados Diagrama de Disseminação de Dados Diagrama de Segurança de Dados Diagrama de Hierarquia de Classes Diagrama de Migração de Dados Diagrama de Ciclo de Vida de Dados

• • • • • • • • •

• • • •

Catálogo de Portfólio de Aplicativos Catálogo de Interfaces Matriz de Aplicativos / Organização Matriz de Papel / Aplicativo Matriz de Aplicativo / Função Matriz de Interação entre Aplicativos Diagrama de Comunicação entre Aplicativos Diagrama de Aplicativos e Localização de Usuário Diagramam de Caso de Uso de Aplicativo Diagrama de Gerenciabilidade Corporativa Diagrama de Processo / Realização de Aplicativo Diagrama de Engenharia de Software Diagrama de Migração de Aplicativos Diagrama de Distribuição de Software

• • • • • •

•

Catálogo de Padrões Tecnológicos Catálogo de Portfólio Tecnológico Matriz de Sistema / Tecnologia Diagrama de Ambientes e Localizações Diagrama de Decomposição de Plataforma Diagrama de Processamento Diagrama de Computação em Rede / Hardware Diagrama de Engenharia de Comunicações

Artefatos do TOGAF 9

Catálogos, Matrizes e Diagramas Catálogos • Catálogo de Entidade de Dados / Componente de Dados

Matrizes • Matriz de Entidade de Dados / Função de Negócio • Matriz de Sistema / Dados O formato exato dos catálogos, matrizes e diagramas dependerão das ferramentas utilizadas Slide 581

Diagramas • Diagrama de Classes • Diagrama de Disseminação de Dados • Diagrama de Segurança de Dados • Diagrama de Hierarquia de Classes • Diagrama de Migração de Dados • Diagrama de Ciclo de Vida de Dados

Catálogos Catálogo • Catálogo de Entidade de Dados / Componente de Dados

Slide 582

Propósito Identificar e manter uma lista de todos os dados utilizados na corporação, incluindo entidades de dados e também os componentes de dados onde as entidades de dados são armazenadas. Ele contém as seguintes entidades do metamodelo: • Entidade de Dados • Componente de Dados Lógico • Componente de Dados Físico

Exercício

Slide 583

Matrizes • Matriz de Entidade de Dados / Função de Negócio • Matriz de Aplicação / Dados

Slide 584

Matriz de Entidade de Dados / Função de Negócio • O propósito da matriz de Entidade de Dados / Função de Negócio é mostrar o relacionamento entre entidades de dados e funções de negócio dentro da corporação. • O mapeamento do relacionamento Entidade de Dados – Função de Negócio permite que o seguinte aconteça: – Atribuição de propriedade das entidades de dados às organizações – Compreensão dos requisitos dos serviços de negócio de troca de informações e dados – Apoio à análise de diferenças e determinação se alguma entidade de dados está faltando e deve ser criada – Definição do sistema de origem, sistema de registro e sistema de referência para as entidades de dados – Garantia de desenvolvimento dos programas de governança de dados em toda a corporação (estabelecimento do papel de de dados, desenvolvimento dos padrões de dados pertinentes à função de negócio, etc.) Slide 585

Exemplo de Matriz de Entidade de Dados / Função de Negócio FUNÇÃO DE NEGÓCIO (EIXO-Y) / ENTIDADE DE DADOS (EIXO-X) Gestão de Relacionamento com Cliente

DADOS MESTRES DE CLIENTE

  

Serviço de gerenciamento de dados de parceiros de Negócio Proprietário – executivo da unidade de Negócio de Vendas & Marketing A Função pode Criar, Ler, Atualizar e Excluir dados mestres de clientes

PARCEIRO DE Negócio







Gestão da Cadeia de Suprimentos

Slide 586

 

Serviço de Processamento de Requisitos do Cliente Proprietário – Gerente da Cadeia de Suprimentos



CLIENTE EM POTENCIAL

Serviço de gerenciamento de dados de parceiros de Negócio Proprietário da entidade de dados (pessoa ou organização) A Função pode Criar, Ler, Atualizar e Excluir



N/A







DADOS MESTRES DE PRODUTO

Sistema de processamento de oportunidades Proprietário – Gerente de Relacionamento com o Cliente A Função pode somente Criar, Ler e Atualizar clientes em potencial



N/A

N/A



Serviço de gerenciamento de dados de produtos



Proprietário – organização global de desenvolvimento de produtos

Matriz de Aplicativos / Dados • O propósito da matriz de Aplicativos / Dados é demonstrar o relacionamento entre os aplicativos e as entidades de dados que são ados e atualizadas por eles. • Aplicativos irão criar, ler, atualizar e excluir entidades de dados específicas que estão associadas a eles. – Por exemplo, um aplicativo de CRM irá criar, ler, atualizar e excluir informações de entidades de clientes.

Slide 587

Exemplo de Matriz de Aplicativos / Dados APLICATIVO (EIXO-Y) E DADOS (EIXO-X)

DESCRIÇÃO OU COMENTÁRIOS

ENTIDADE DE DADOS

TIPO DE ENTIDADE DE DADOS

CRM

 Sistema de registro de dados mestres de cliente

 Dados de cliente

 Dado mestre

Mecanismo de Comércio

 Sistema de registro para livro de pedido

 Pedido de venda

 Dado transacional

Business Warehouse de Vendas

 Data Warehouse e Data Mart que a a região da América do Norte

 Interseção de múltiplas entidades de dados (e.g. todos os pedidos de vendas por cliente XYZ e por mês para 2006)

 Dado Histórico

Slide 588

Diagramas • • • • • •

Diagrama Conceitual de Dados Diagrama Lógico de Dados Diagrama de Disseminação de Dados Diagrama de Segurança de Dados Diagrama de Migração de Dados Diagrama de Ciclo de Vida de Dados

Slide 589

Diagrama Conceitual de Dados • O propósito é demonstrar os relacionamentos entre as entidades de dados críticas (ou classes) dentro da empresa ou corporação. I.A1

Information

Update P.A12

Actor

Customer Profile I.C2

Trigger



Process P.CS13

Payment P.CS5 Service Request

T.P8 Agent A.A4

Enquiry T.C1

Customer A.C2

Slide 590

Customer Information I.C1

Appeal

Complaint T.C19

T.C16

Diagrama Lógico de Dados • O objetivo é demonstrar relacionamentos de visões lógicas entre as entidades de dados críticas (ou classes) dentro da empresa ou corporação. • O público é: – Desenvolvedores de aplicativos – Projetistas de Bancos de Dados

Slide 591

Diagrama de Disseminação de Dados • O objetivo do Diagrama de Disseminação de Dados é mostrar a relação entre – entidade de dados – serviço de negócio – componentes de aplicativos

• O diagrama deve mostrar como as entidades lógicas são fisicamente realizadas pelos componentes de aplicativos. • Adicionalmente, o diagrama pode mostrar replicação de dados e propriedade dos sistemas de referência mestre para dados.

Slide 592

Exemplo de Diagrama de Disseminação de Dados Warehouse Warehouse Customer Order History Stock

Online Online Self SelfService Service Billing Billing Customer Balance Invoice History

Slide 593

Serviço de Negócio

Entidades de Dados

Aplicativo

Self Service de Conta Online

Cliente

Depósito único Faturamento

Histórico de Pedidos

Depósito único

Estoque

Depósito único

Saldo da Conta

Faturamento

Histórico de Faturas

Faturamento

Diagrama de Ciclo de Vida de Dados • O Diagrama de Ciclo de Vida de Dados é uma parte essencial do gerenciamento de dados de negócio ao longo de seu ciclo de vida da concepção ao descarte dentro das restrições do processo de negócio. Fulfilment Order New

Fulfilled

Invoiced

Paid

Dispatched

Closed

Archived

Deleted

Customer Order New

Slide 594

Closed

Archived

Deleted

Diagrama de Segurança de Dados • O propósito do Diagrama de Segurança de Dados é demonstrar qual ator (pessoa, organização ou sistema) pode ar qual dado corporativo. • Esta relação pode também ser mostrada em forma de matriz entre dois objetos ou pode ser mostrada como um mapa.

Slide 595

Exemplo de Diagrama de Segurança de Dados Classes de Papéis (por função de trabalho)

Ator

Função de Negócio

o Físico

Localização

Single - Sign On ou Controle de o

Serviço de Negócio

Controle de o (níveis de Granularidade) Controle de o (níveis de Granularidade)

Slide 596

Componente Lógico de Aplicativo

Processo

Exemplo de Matriz de Segurança de Dados ATOR

Analista Financeiro

CLASSE DE PAPÉIS (FUNÇÃO DE TRABALHO) Analista Financeiro de Portifólio SOA

FUNÇÃO

Análise Financeira

SERVIÇO DE NEGÓCIO Serviço de Portifólio SOA

TIPO DE O

LOCALIZAÇÃO   

NA (US, CA) EMEA (UK, DE) APJ

 

Físico Controle de o (tabelas xyz somente)

Analista de Compras & Gastos

Gerenciamento de Compras e Controle

WW Compra Direta

Serviço de Portal Provedor



NA (US Midwest)



Controle de o

Sistema de Contratos WW (aplicativo)

Não aplicável

WW Compra Direta

Serviço de Portal Provedor



LA



Controle de o (sistema a sistema)

Desenvolvimento de Produto WW (Org Unit)

Gerentes de Marca Geo

WW Compra Direta

Serviço de Portal Provedor



WW (todas as regiões)



Controle de o

Slide 597

Diagrama de Migração de Dados • O objetivo do Diagrama de Migração de Dados é mostrar o fluxo de dados desde a fonte em direção aos aplicativos alvo. • O diagrama proverá uma representação visual da difusão de fontes/alvos e serve como uma ferramenta para a auditoria de dados e o estabelecimento de rastreabilidade.

Slide 598

Exemplo de Diagrama de Migração de Dados componentes de aplicativos “atuais”

componentes de tecnologia de migração de dados

componentes de aplicativos “alvo”

ABM

CRM

Fonte de registro de clientes

Sistema de Registro para dados mestre de Clientes

CCB

ERP BDW Fonte de Histórico de pedidos

MRPA Fonte de dados de materiais

VLC (one per geo) Fonte de dados de vendedores

Slide 599

Armazenamento Temporário

Fonte

Transformação & Qualidade de Dados

Armazenamento Temporário

Sistema de Registro para dados mestre de Materiais & Histórico de Pedidos

Alvo

SRM Sistema de Registro para dados mestre de Vendedores & Contratos

Exemplo de Mapeamento de Migração de Dados FONTE LÓGICA DO COMPONENTE DE APLICATIVO

ABM

Slide 600

ELEMENTO DE DADOS FONTE

Cust_Name

ALVO LÓGICO DO COMPONENTE DE APLICATIVO

CRM

ELEMENTO DE DADOS ALVO

CUSTNAME

Cust_Street_Addr

CUSTADDR_LINE1

Cust_Street_Addr

CUSTADDR_LINE2

Cust_Street_Addr

CUSTADDR_LINE3

Cust_Name

CUST

Cust_Tele

CUSTTELEPHONE

Phase C Fase C: Arquitetura de Dados – Catálogos, Matrizes e Diagramas Arquitetura de Dados

TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países.

Slide 601de

25

Módulo 19 Modelo de Referência de Infraestrutura de Informação Integrada (III-RM) Edição de Direitos Autorais V9.1 © 2009-2011

Slide 602de

18

Todos os direitos reservados Publicado por The Open Group, 2011

III-RM O Modelo de Referência de Infraestrutura de Informação Integrada

TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países.

Slide 603de

18

Roap Parte I - Introdução Prefácio, Visão Geral Executiva, Conceitos Principais, Definições e Notas de Publicação Parte II – Método de Desenvolvimento da Arquitetura Introdução ao Narrativas das Fases do

Parte III – Técnicas e Orientações Orientações para Adaptar o Processo do Técnicas para o Desenvolvimento da Arquitetura Parte IV – Framework de Conteúdo de Arquitetura Metamodelo de Conteúdo Artefatos da Arquitetura Entregáveis da Arquitetura Blocos de Construção

Parte V – Continuum Corporativa e Ferramentas Continuum Corporativo Particionamento da Arquitetura Repositório da Arquitetura Ferramentas para o Desenvolvimento da Arquitetura

Parte VI – Modelos de Referência Arquitetura de Fundação: Modelo de Referência Técnica Modelo de Referência de Infraestrutura de Informação Integrada

Parte VII – Framework de Capacidade Arquitetural Comitê de Arquitetura Conformidade da Arquitetura Contratos de Arquitetura Governança da Arquitetura Modelos de Maturidade da Arquitetura Framework de Proficiências de Arquitetura

Slide 604

• Parte VI, Modelos de Referência do TOGAF, Capítulo 44

Principais Motivadores Técnicos e de Negócio Espaço do Problema: A Necessidade por Boundaryless Information Flow • O problema em se obter informações para as pessoas certas no momento certo de forma segura e confiável Espaço da Solução: A Necessidade de uma Infraestrutura de Informação Integrada Nós precisamos: • Informação integrada de forma que itens de informação potencialmente conflitantes e diferentes não sejam distribuídas por diferentes sistemas • o integrado a essas informações de forma que a equipe possa álas de acordo com suas necessidades e tenha os direitos para tal, através de uma interface conveniente • A infraestrutura que permite que esta visão aconteça é chamada de “infraestrutura de informações integradas”.

Slide 606

Modelo de Referência de Infraestrutura de Informações Integradas • Um modelo de componentes chave para o desenvolvimento, gerenciamento e operação de uma infraestrutura de informações integrada. – ar “Boundaryless Information Flow”

• Um modelo de um conjunto de aplicativos que ficam no topo de uma plataforma de aplicativos. • Um subconjunto expandido do Modelo de Referência Técnica do TOGAF, utilizando uma orientação diferente.

Slide 607

TOGAF TRM Qualities

Infrastructure Applications

Business Applications

Application Platform Interface

Communications Infrastructure Interface

Communication Infrastructure Qualities

Slide 608

Graphics & Image

Network Services

Data Management

Data Interchange

Interface

International Operations

Location & Directory

Transaction Processing

Security

Software Engineering

System & Network Management

Operating System Services

• Fundamentalmente uma visão em camadas, sendo as camadas maiores – Aplicativos – Plataforma de Aplicativos – Comunicações

Orientações do TOGAF TRM Visão Lateral

Visão Top Down

Qualities Infrastructure Applications

Business Applications

Qualities

Application Platform Interface Communication Infrastructure Graphics & Image

Data Management

Data Interchange

Interface

International Operations

Location & Directory

Transaction Processing

Security

Software Engineering

System & Network Management

Comm Infrastructure Interfaces Network Services Operating System Services Application Platform Appl Platform Interface

Operating System Services

Infra Apps

Bus Apps

Network Services Communications Infrastructure Interface

Communication Infrastructure Qualities

Slide 609

Qualities

Foco do Fluxo de Informações sem Fronteiras (Boundaryless Information Flow) Visão Lateral

Visão Top Down

Qualities Business Applications

Infrastructure Applications

Qualities

Application Platform Interface Communication Infrastructure Graphics & Image

Data Management

Data Interchange

Interface

International Operations

Location & Directory

Transaction Processing

Security

Software Engineering

System & Network Management

Comm Infrastructure Interfaces Network Services Operating System Services

Application Platform Appl Platform Interfaces

Operating System Services

Infra Apps

Bus Apps

Network Services Communications Infrastructure Interface

Qualities Communication Infrastructure

Qualities

Slide 610

Modelo de Referência de Infraestrutura de Informação Integrada – Alto Nível Mobility

Qualities

Security

Application Platform

Information Consumer Applications

Development Tools

Brokering Applications

Management Utilities

Information Provider Applications Performance SLAs Slide 611

Qualities

Management Policy

Componentes do III-RM O III-RM tem 2 componentes principais: 1. Uma taxonomia, que define a terminologia e provê uma descrição coerente dos components e estrutura conceitual de uma infraestrutura de informação integrada 2. Um gráfico de III-RM associado, que provê uma representação visual da taxonomia e os interrelacionamentos dos componentes, como uma ajuda ao entendimento

Slide 612

Componentes do III-RM de Alto Nível •

Information Consumer Applications

Brokering Applications

Information Provider Applications

Slide 613

Aplicativos de Negócio: – Aplicativos de Corretagem, que gerenciam as requisições de qualquer número de clientes para qualquer número de Aplicativos Provedores de informação – Aplicativos Provedores de Informação, que proveem respostas às requisições dos clientes e o rudimentar aos dados gerenciados por um servidor em particular – Aplicativos Consumidores de Informação, que entregam conteúdo ao usuário do sistema e proveem serviços para requisitar o à informação no sistema em nome do usuário

Componentes do III-RM de Alto Nível • Aplicativos de Infraestrutura:

Development Tools

Slide 614

Management Utilities

– Ferramentas de Desenvolvimento, para desenvolver e disponibilizar aplicativos que requeiram o à infraestrutura de informação integrada – Utilitários de Gerenciamento, para entender, operar, refinar e gerenciar um sistema de tempo real de forma a atender as demandas de um negócio que está em constante mudança

Componentes do III-RM de Alto Nível • Uma Plataforma de Aplicativos, que provê serviços de e a todos os aplicativos e desta forma provê a habilidade de localizer, ar e mover informação dentro do ambiente. Application Platform

Slide 615

Componentes do III-RM de Alto Nível • As Interfaces utilizadas entre os components. Interfaces incluem formatos e protocolos, APIs, switches, valores de dados, etc. • O backplane de Qualidades. O Software Aplicativo e a Plataforma de Aplicativos devem ser aderentes às políticas e requisitos mostrados pelo backplane de qualidades.

Slide 616

Modelo de Referência de Infraestrutura de Informação Integrada – Detalhado Qualities

Security

Mobility

Application Platform Information Consumer Applications

Web Portal

Streaming audio / video

Languages Libraries Registries

information Access

Directory Referencing/Dereferencing Naming Registration Publish Subscribe Discovery

Application Message Format Application Messaging Application to application communications services Enterprise Appl Integration

Brokering Applications

Business modeling tools Design tools Construction tools Languages and Libraries

Information Brokers Application Integrators

Presentation Transformation Browser services Portal and personalization Meta indices

Management Utilities Monitors Executory Utilities Copy Managers Information Access Transformation Mapping Query distribution Aggregation Search File services Desktop Video Conference Web services Phone / Fax

Info Format eForm services Instant messaging services

Information Provider Applications information Access Messaging/Event Brokering

Performance SLAs Slide 617

Phone / Fax

Mail

Development Tools

Digital Signature Intrusion Detection Key Management Firewall Encryption AAAC Web Portal SSO Streaming audio / video

Desktop Video Conference

Mail

Process/Workflow Control

Qualities

Management Policy

III-RM O Modelo de Referência de Infraestrutura de Informação Integrada

TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países.

Slide 620de

18

Módulo 20 Fase C Arquitetura de Aplicativo Edição de Direitos Autorais V9.1 © 2009-2011

Slide 621de 32 Todos os direitos reservados Publicado por The Open Group, 2011

Phase C Fase C: Arquitetura de Aplicativos

Arquitetura de Aplicativo

TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países.

Slide 622de 32

Fase C: Entradas: Arquitetura de Aplicativos • Requisição para o Trabalho de Arquitetura • Avaliação de Capacidade • Plano de Comunicação • Modelo Organizacional para a Arquitetura Corporativa • Framework de Arquitetura adaptado • Princípios de Aplicativos • Declaração do Trabalho de Arquitetura Continua… Slide 625

Fase C: Entradas: Arquitetura de Aplicativos • Visão da Arquitetura • Repositório de Arquitetura • Rascunho do Documento de Definição da Arquitetura • Rascunho da Especificação de Requisitos da Arquitetura, incluindo: – Resultados da Análise de Diferenças – Requisitos técnicos relevantes

• Componentes da Arquitetura de Dados e de Negócio do Roap de Arquitetura Slide 626

os A ordem dos os deve ser adaptada à situação. Em particular você deve determinar se é apropriado desenvolver a Arquitetura de Aplicativos de Linha de Base ou a Arquitetura de Aplicativos Alvo primeiro.

9. Criar o Documento de Definição da Arquitetura 8. Finalizar a Arquitetura de Aplicativos 7. Conduzir uma revisão formal com as partes interessadas 6. Resolver impactos em todo o Panorama da Arquitetura 5. Definir componentes candidatos no roap de arquitetura

4. Realizar a análise de diferenças

3. Desenvolver a Descrição da Arquitetura de Aplicativos Alvo 2. Desenvolver a Descrição da Arquitetura de Aplicativos de Linha de Base

1. Selecionar modelos de referência, pontos de vista e ferramentas

Slide 627

o 1: Selecione modelos de referência, pontos de vista e ferramentas • Revisar/gerar e validar os princípios de aplicativos – ver Princípios Arquiteturais • Selecionar os recursos da Arquitetura de Aplicativos (modelos de referência, padrões, …)

• Selecionar pontos de vista relevantes para a Arquitetura de Aplicativos • Identificar ferramentas e técnicas apropriadas (incluindo formulários) a serem utilizados para capturar, modelar e analisar, em associação com os pontos de vista selecionados. • Considerar utilizar descrições independentes de plataforma para a lógica do Negócio (ex.: MDA da OMG) Continua… Slide 628

Fase Preliminar • Catálogo de Princípios Gerenciamento de Requisitos

Fase A, Visão da Arquitetura • Matriz de Mapeamento de Partes Interesssadas

• Diagrama da Cadeia de Valores • Diagr.ama de Conceito de Soluções

TOGAF 9 Artifacts • Catálogo de Requisitos

Fase B, Arquitetura de Negócio

Fase C, Arquitetura de Dados

Fase C, Arquitetura de Aplicativos

Fase D, Arquitetura Tecnológica

• •

•

•

•

• • • •

• • • • • • • • • • •

Catálogo de Organização / Ator Catálogo de Motivador / Meta / Objetivo Catálogo de Papéis Catálogo de Serviço de Negócio / Função Catálogo de Localização Catálogo de Processo / Evento / Controle / Produto Catálogo de Contrato / Medida Matriz de Interação de Negócio Matriz de Ator / Papel Diagrama de Footprint de Negócio Diagrama de Serviço de Negócio / Informação Diagrama de Decomposição Funcional Diagrama de Ciclo de Vida de Produto Diagrama de Meta / Objetivo / Serviço Diagramam de Decomposição da Organização Diagrama de Fluxo de Processo Diagrama de Eventos

Fase E. Oportunidades e Soluções • Diagrama de Contexto de Projeto • Diagrama de Benefícios

Slide 629

• •

• • •

• • •

Catálogo de Entidade de Dados / Componente de Dados Matriz de Entidade de Dados / Função de Negócio Matriz de Aplicativo / Dados Diagrama Lógico de Dados Diagrama de Disseminação de Dados Diagrama de Segurança de Dados Diagrama de Hierarquia de Classes Diagrama de Migração de Dados Diagrama de Ciclo de Vida de Dados

• • • • •

Catálogo de Potifólio de Aplicativos Catálogo de Interfaces Matriz de Aplicativos / Organização Matriz de Papel / Aplicativo Matriz de Aplicativo / Função Matriz de Interação entre Aplicativos Diagrama de Comunicação entre Aplicativos Diagrama de Aplicativos e Localização de Usuário Diagramam de Caso de Uso de Aplicativo Diagrama de Gerenciabilidade Corporativa Diagrama de Processo / Relização de Aplicativo Diagrama de Engenharia de Software Diagrama de Migração de Aplicativos Diagrama de Distribuição de Software

Nota: • O Módulo 20A provê • informações detalhadas • sobre a Fase C: Arquitetura • de Aplicativos, Catálogos, Matrizes e Diagramas • • • •

• • •

• • • •

Catálogo de Padrões Tecnológicos Catálogo de Po´rtifólio Tecnológico Matriz de Sistema / Tecnologia Diagrama de Ambientes e Localizações Diagrama de Decomposição de Plataforma Diagrama de Processamento Diagrama de Computação em Rede / Hardware Diagrama de Engenharia de Comunicações

TOGAF 9 Artefatos

o 1: Selecionar modelos de referência, pontos de vista e ferramentas •

Determinar o Processo Geral de Modelagem • Para cada ponto de vista, selecione os modelos necessários para ar a visão específica requerida, utilizando as ferramentas ou métodos selecionados. Ex.: O TMF tem desenvolvido modelos de aplicativos detalhados relevantes ao setor de Telecomunicações. O OMG tem algumas Forças de Trabalho de Domínio verticais desenvolvendo modelos para domínios específicos como Saúde, Transporte, Finanças, etc. • Confirme que todas os interesses das partes interessadas são abordados. Se não, crie novos modelos para abordar os interesses não cobertos ou amplie os modelos existentes. Continua…

Slide 630

Processo Recomendado • Entender a lista de aplicativos ou componentes de aplicativos que são requeridos, baseada no Portfolio de Aplicativos de linha de base, seus requisitos e o escopo da arquitetura de negócio • Simplificar aplicativos complicados ao decompô-los em dois ou mais aplicativos • Assegurar que o conjunto de definições de aplicativos é internamente consistente, ao remover funcionalidades duplicadas tanto quanto seja possível, e combinar aplicativos similares em um único aplicativo • Identificar aplicativos lógicos e os aplicativos físicos mais apropriados • Desenvolver matrizes por toda a arquitetura relacionando os aplicativos aos serviços de negócio, funções de negócio, dados, processos, etc. • Elaborar um conjunto de visões de Arquitetura de Aplicativos ao examinar como os aplicativos funcionam, capturando: integração, migração, desenvolvimento e interesses operacionais

Slide 631

o 1: Selecionar modelos de referência, pontos de vista e ferramentas •

Identificar os Catálogos Requeridos dos Blocos de Construção dos Aplicativos – O portfólio de Aplicativos da organização é definido como um catálogo dentro do Repositório de Arquitetura.

•

Identificar Matrizes Requeridas – Matrizes mostram os principais relacionamentos entre as entidades do modelo

•

Identificar os Diagramas Requeridos – Diagramas apresentam a informação da Arquitetura de Aplicativos de um conjunto de diferentes pontos de vista

•

Identificar os Tipos de Requisitos a serem Coletados – Identifique os requisitos a serem satisfeitos pela Arquitetura – Formalize os requisitos focados nos aplicativos

– Forneça requisitos de entrada para as Arquiteturas Tecnológica e de Dados

Slide 632

Exemplo – O Modelo de Infraestrutura de Informação Integrada • É um modelo de referência para a Arquitetura de Aplicativos – um modelo de componentes de aplicativos e serviços de aplicativos essenciais para uma infraestrutura de informação integrada

• Baseado no TRM • Tem como objetivo ajudar o design de arquiteturas para capacitar e ar a visão de Boundaryless Information Flow

Slide 633

III-RM Motivadores Técnicos e de Negócio A causa: • sistemas múltiplos, concebidos e desenvolvidos individualmente Agravando o problema: • equipes multifuncionais continuamente em formação, novos parceiros de Negócio, informações encalhadas

Espaço de Vendas e de vendas ao Cliente

Espaço Interno Apl 1 Apl 2

Espaço de Compra

Apl 50 Apl 1

Manufatura Legal Financeiro Montagem Sistemas De Design

Compra

Sistemas de ERP Sistemas De Requisitos

Parceiro 1

Apl 2 Parceiro 2

Apl 50

Apl 1 Apl 2

Slide 634de 32

Parceiro 3000

Sistemas Online

Apl 50

Sistemas de Compra

Sistemas

Foco do III-RM

Slide 635

Visão de Alto Nível do III-RM

Slide 636

o 2: Desenvolver uma Descrição da Arquitetura de Aplicativos de Linha de Base Se possível, identifique os BCAs de aplicativos relevantes, com base no Repositório de Arquitetura.

•

Senão, defina cada aplicativo alinhado com o catálogo do portfólio de Aplicativos

Continua… Slide 637

o 3: Descrição da Arquitetura de Aplicativos Alvo •

Se possível, identifique os blocos de construção relevantes da Arquitetura de Aplicativos, com base no Repositório de Arquitetura

•

Senão, desenvolva um novo modelo de arquitetura: –

Slide 638

Use os modelos identificados no o 1 como guia

o 4: Realizar uma Análise de Diferença Verifique os modelos de arquitetura visando consistência interna e precisão

Observe as alterações nos pontos de vista representados nos modelos selecionados do Repositório de Arquitetura e os documente Teste a completude dos modelos de arquitetura em relação aos requisitos Identifique as diferenças entre a linha de base e o alvo, utilizando a Técnica de Análise de Diferença

Slide 639

o 5: Definir os componentes candidatos ao roap • Este roap da Arquitetura de Aplicativos inicial será utilizado como matéria prima para apoiar uma definição mais detalhada de um roap consolidado, multidisciplinar dentro da fase de Oportunidades e Soluções.

Slide 640

o 6: Resolver impactos em todo o Panorama da Arquitetura • Os artefatos de arquitetura no Panorama da Arquitetura devem ser examinados para identificar: – Esta Arquitetura de Aplicativos gera um impacto em alguma das arquiteturas pré-existentes? – Mudanças recentes foram feitas que impactam na Arquitetura de Aplicativos? – Existe alguma oportunidade para alavancar o trabalho a partir desta Arquitetura de Aplicativos em outras áreas da organização? – Esta Arquitetura de Aplicativos impacta outros projetos? – Esta Arquitetura de Aplicativos será impactada por outros projetos?

Slide 641

o 7: Conduzir uma Revisão Formal com as Partes Interessadas Verifique a motivação original para o projeto de arquitetura e a Declaração para o Trabalho de Arquitetura versus a Arquitetura de Aplicativos proposta. Conduza uma análise de impacto para: • Identificar quaisquer áreas onde a Arquitetura de Dados e de Negócio possam precisar de mudanças para atender às alterações na Arquitetura de Aplicativos. Se o impacto for significativo, revisite as Arquiteturas de Dados e de Negócio.

Continued… Slide 642

o 8: Finalizar a Arquitetura de Aplicativos • • • •

•

•

Selecione padrões para cada um dos BCAs, reutilizando tanto quanto possível. Documente completamente cada BCA. Cruze a arquitetura geral contra os requisitos de negócio. Documente o relatório final de rastreabilidade de requisitos. Documente o mapeamento final da arquitetura dentro do Repositório de Arquitetura. Identifique os BCAs que podem ser reutilizados e publique-os via repositório de arquitetura. Finalize todos os produtos de trabalho.

Slide 643

o 9: Criar um Documento de Definição da Arquitetura • Documente as justificativas para todas as decisões sobre os blocos de construção no documento de definição da arquitetura. • Prepare as seções da Arquitetura de Aplicativos no documento de definição de arquitetura. • Se apropriado, utilize relatórios e/ou gráficos gerados pelas ferramentas de modelagem para demonstrar as visões fundamentais da arquitetura. Encaminhe o documento para revisão pelas partes interessadas relevantes e incorpore o .

Slide 644

Fase C: Saídas da Arquitetura de Aplicativos • Declaração de Trabalho de Arquitetura • Princípios de aplicativo validados ou novos princípios de aplicativo desenvolvidos • Rascunho do Documento de Definição da Arquitetura • Rascunho da Especificação de Requisitos da Arquitetura • Componentes da Arquitetura de Aplicativos do Roap de Arquitetura Slide 645

Documento de Definição da Arquitetura – Componentes da Arquitetura de Aplicativos • Arquitetura de Aplicativos de Linha de Base, se apropriado • Arquitetura de Aplicativos Alvo, incluindo: – – – –

Modelo de sistemas de processos Modelo de sistemas de local Modelo de sistemas de tempo Modelo de sistemas de pessoas

• Visões da Arquitetura de Aplicativos correspondendo aos pontos de vista selecionados, abordando os interesses fundamentais das partes interessadas

Slide 646

Especificação de Requisitos de Arquitetura – Componentes da Arquitetura de Aplicativos • Resultados da Análise de Diferenças • Requisitos de interoperabilidade dos aplicativos • Áreas onde a Arquitetura de Negócio pode necessitar mudanças para estar de acordo com as alterações na Arquitetura de Aplicativos • Restrições na Arquitetura Tecnológica a ser projetada • Requisitos de negócio / aplicativos / dados atualizados, se for o caso

Slide 647

Phase C Fase C: Arquitetura de Aplicativos

Arquitetura de Aplicativo

TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países.

Slide 652de 32

Módulo 20A Fase C Arquitetura de Aplicativos – Catálogos, Matrizes e Diagramas Edição de Direitos Autorais V9.1 © 2009-2011

Slide 653de 34 Todos os direitos reservados Publicado por The Open Group, 2011

Phase C Fase C: Arquitetura de Aplicativos – Catálogos, Matrizes e Diagramas Application Architecture

TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países.

Slide 654de 34

Fase Preliminar • Catálogo de Principios Gerenciamento de Requisitos

•

• •

• • • • • • • • • • • • • •

•

Diagrama de Cadeia de Valor

• Catálogo de Requisitos

Catálogo de Organização/Ator Catálogo de Direcionador/Meta/Objetivo Catálogo de Papéis Catálogo de Serviço de Negócio/Função Catálogo de Localidades Catálogo de Processo/Evento/Controle/Produto Catálogo de Contrato/Medida Matriz de Interação de Negócio Matriz de Ator//Papel Diagrama de “Footprint” de Negócio Diagrama de Serviço de Negócio/Informação Diagrama de Decomposição Funcional Diagrama de Ciclo de Vida de Produto Diagrama de Meta/Objetivo/Serviço Diagrama de Casos de Uso de Negócio Diagrama de Decomposição da Organização Diagrama de Fluxo de Processo Diagrama de Evento

Fase E. Oportunidades e Soluções Slide 656de Contexto de Projeto • Diagrama • Diagrama de Benefícios

of 33

Diagrama Conceitual da Soluçao

TOGAF 9 Artifacts

Fase B, Arquitetura de Negócio • •

• Matriz de Mapa de Partes interessadas

Fase A, Visão da Arquitetura

Fase C, Arquitetira de Dados

Fase C, Arquitetura de Aplicação •

•

• • • • • • •

•

Catálogo de Entidade de Dados/ Componente de Dados Matriz de Entidade de Dados/Funções de Negócio Matriz de Aplicação/Dados Diagrama lógico de dados Diagrama de Disseminação de Dados Diagrama de segurança de Dados Diagrama hierárquico de Classes Diagrama de Migração de Dados Diagrama de Ciclo de Vida de Dados

• • • • • • •

• • • •

• •

Catálogo de Portifólio de Aplicação Catálogo de Interface Matriz de Aplicação/Organização Matriz de Papel/Aplicação Matriz de Aplicação/Função Matriz de Interação de Aplicação Diagrama de Comunicação de Aplicação Diagrama de Localização de Aplicação e Usuário Diagrama de caso de Usos de Aplicações Diagrama de capacidade de gerência da Corporação Diagrama de Realização de Processo/Aplicação Diagrama de Engenharia de Software Diagrama de Migração de Aplicação Diagrama de Distribuição de Software

Fase D, Arquitetura Tecnológica • • • • • • • •

Catálogo de Normas de Tecnologia Catálogo de Portfólio de Tecnologia Matriz de Sistema/Tecnologia Diagrama de Ambientes e Locais Diagrama de Decomposição de Plataforma Diagrama de Processamento Diagrama de Computação em Rede/Hardware Diagrama de Engenharia de Comunicação

Artefatos do TOGAF 9

Catálogos, Matrizes e Diagramas Catálogos • Catálogo do Portfólio de Aplicativos • Catálogo de Interfaces Matrizes • Matriz de Aplicativo x Organização • Matriz de Aplicativo x Papel • Matriz de Aplicativo x Função • Matriz de Interação de Aplicativos

O formato exato dos catálogos, matrizes e diagramas dependerá das ferramentas utilizadas

Slide 657

Diagramas • Diagrama de Comunicação entre Aplicativo • Diagrama de Localização de Usuários e Aplicativos • Diagrama de Caso de Uso de Aplicativo • Diagrama de Gerenciabilidade Corporativa/Empresarial • Diagrama de Processo e Realização de Aplicativo • Diagrama de Engenharia de Software • Diagrama de Migração de Aplicativo • Diagrama de Distribuição de Software

Catálogos Catálogo Catálogo dao Portifólio de Aplicação

Propósito Identificar e manter uma lista de todos os aplicativos da corporação. Esta lista ajuda a definir o escopo horizontal das iniciativas de mudanças que podem impactar em tipos particulares de aplicações. Um Portfólio de Aplicativos acordado permite que um conjunto padronizado de aplicativos seja definido e governado. Ele contém as entidades do metamodelo que seguem: •Serviços de Sistemas de Informação •Componente Lógico de Aplicativo •Componente Físico de Aplicativo

Catálogo de Interfaces

O propósito do catálogo de interfaces é delimitar e documentas as interfaces entre aplicativos para permitir que as todas as dependências entre aplicativos sejam delimitadas o quanto antes. Ele contém as entidades do metamodelo que seguem: •Componente Lógico de Aplicativo •Componente Físico de Aplicativo •Aplicativos comunicam-se usando relacionamento entre aplicativos

Slide 658

Matrizes • • • •

Matriz Aplicativo x Organização Matriz Aplicativo x Papel Matriz Aplicativo x Função Matriz de Interação de Aplicativos

Slide 660

Matriz Aplicativo x Organização • O propósito desta matriz é descrever o relacionamento entre aplicativos e unidades organizacionais dentro da empresa. • O mapeamento do relacionamento “Componente de Aplicação – Unidade Organizacional” é um o importante, pois permite: – Atribuir o uso de aplicativos a unidades organizacionais que realizam funções de negócio. – Compreender os requisitos de e de aplicativos dos processos e serviços de negócio realizados por uma unidade organizacional. – ar a análise de diferenças e determinar se algum aplicativo está faltando e desta forma precisa ser criado. – Definir o conjunto de aplicativos utilizado por uma unidade organizacional em particular. Slide 661

Exemplo de Matriz Aplicativo x Organização APLICATIVO (EIXO-Y) E UNIDADE ORGANIZACIONAL (EIXO-X)

ATENDIMENTO AO CLIENTE

AQUISIÇÃO E ARMAZENAGEM

RH

SAP HR

X

X

X

SIEBEL

X

X

SAP FINANCIALS

X

X

PROCURESOFT

X

X

Slide 662

FINANÇAS CORPORATIVAS

X

Matriz Papel x Aplicativo • O propósito desta matriz é descrever o relacionamento entre aplicativos e papéis de negócio que os utilizam, dentro da empresa. • O mapeamento do relacionamento “Componente de Aplicativo – Papel” é um o importante pois permite: – Atribuir uso de aplicativos a papéis específicos na organização. – Entender os requisitos de segurança dos aplicativos nos processo e serviços de negócio que am a função, e verificar que eles estejam de acordo com a política vigente. – ar a análise de diferença e determinar se quaisquer dos aplicativos estão faltando e desta forma precisam ser criados. – Definir o conjunto de aplicativos a serem utilizados em um papel de negócio em particular; essencial em qualquer movimento em direção a computação baseada em papeis.

Slide 663

Exemplo de Matriz Papel x Aplicativo APLICATIVO (EIXO-Y) E FUNÇÃO (EIXO-X)

OPERADOR DE CALL CENTER

GERENTE DE CALL CENTER

ANALISTA FINANCEIRO

GERENTE DE CONTAS

SAP HR

X

X

X

X

SIEBEL

X

X

SAP FINANCIALS

X

X

X

X

PROCURESOFT

X

X

Slide 664

Matriz de Aplicativo x Função • O propósito desta matriz é descrever o relacionamento entre aplicativos e funções de negócio dentro da empresa. • O mapeamento do relacionamento “Componente de Aplicativo – Função” é um o importante pois permite: – Atribuir o uso de aplicativos a funções de negócio que são adas por eles. – Entender os requisitos de e de aplicativos dos serviços de negócio e processos. – ar a análise de diferenças e determinar se qualquer um dos aplicativos está faltando e desta forma precisa ser criado. – Definir o conjunto de aplicativos utilizados por uma função de negócio em particular.

Slide 665

Exemplo de Matriz Aplicativo x Função APLICATIVO (EIXO-Y) E FUNÇÃO (EIXO-X)

CALL CENTER DE 1o NÍVEL

CONTROLE DE ARMAZENAGEM

PREENCHIMENTO DE VAGAS

SAP HR

X

X

X

SIEBEL

X

X

SAP FINANCIALS

X

X

PROCURESOFT

X

X

Slide 666

MANUTENÇÃO GERAL

X

X

Exemplo de Matriz de Interação entre Aplicativos Aplicativo 1

Aplicativo 2

Aplicativo 1 Aplicativo 2

Aplicativo 3

Aplicativo 4

Slide 667

Aplicativo 3

Aplicativo 4

Consome Comunica-se com

Consome

Comunica-se com

Diagramas • Diagrama de Comunicações entre Aplicativos • Modelo N2 ou Diagrama de Conectividade de Nós • Diagrama de Aplicativos e Localização de Usuários • Diagrama de Caso de Uso de Aplicativos • Diagrama de Gerenciabilidade Corporativa • Diagrama de Processo e Realização de Aplicação • Diagrama de Engenharia de Software • Diagrama de Migração de Aplicativo • Diagrama de Distribuição de Software Slide 668

Diagrama de Comunicação de Aplicativos • O propósito deste diagrama é descrever todos os modelos e mapeamentos relacionados à comunicação entre aplicativos na entidade do meta-modelo. • Ele mostra componentes de aplicativos e interfaces entre componentes. • A comunicação deve ser lógica e apenas mostrar a tecnologia intermediária arquiteturalmente relevante.

Slide 669

Diagrama de Comunicação entre Aplicativos

Slide 670

Exemplo Alternativo: Modelo N2 1c

ABC 1a

1b

ABM

2a 3c

CCD

3a

4a 3b

CRM

1d 4b 3d

Slide 671

IPC

Exemplo Alternativo: Matriz de Troca de Informação RÓTULO

FONTE

ENTIDADE DE DADOS

DESTINO

EVENTO DISPARADO

1a



ABC



ABM



Pedido de vendas (cria requisição)



Novo pedido de vendas do front end

1b



ABM



ABC



Pedido de vendas (confirma criação)



Pedido criado no Sistema ERP de backend

2a



ABM



CCD



Catálogo de produtos



Cronômetro de Publicação /

Slide 672

Diagrama de Aplicativo & Localização de Usuário • O propósito deste diagrama é descrever claramente as localizações de negócio das quais os usuários deste negócio tipicamente interagem com os aplicativos, e a localização dos servidores da infraestrutura de aplicativos. • O diagrama permite: – – – –

Identificação do número de instâncias de pacotes necessários Estimativa do número e tipo de licenças de usuário Estimativa do nível de e necessário Seleção das ferramentas de gerenciamento de sistemas, estrutura e sistemas de gerenciamento – Planejamento apropriado para os componentes tecnológicos do negócio – Considerações de performance ao implementar soluções

Slide 673

Exemplo de Matriz de Aplicativo & Localização de Usuário APLICATIVO

CRM

SAP R/3

Slide 674

TIPO DE USUÁRIO Desenvolvedor Super Usuário

Engenheiro de Testes Engenheiro Mecânico Gerente de Compras

INTERNO, CLIENTE OU PARCEIRO Interno

LOCALIZAÇÃO DE NEGÓCIO DO USUÁRIO

UNIDADE ORGANIZACIONAL (usuário pertence a)

NA Região Oriental EMEA Matriz, UK

Interno

ENDEREÇO DA LOCALIZAÇÃO

Planta de manufatura Beijing

Torre da Sears De Chicago - Chicago Escritório do centro Middlesex, London

NA Vendas & Marketing Vendas – EMEA

Manufatura e Logística

Exemplo de Diagrama Aplicativo & Localização de Usuário

Slide 675

Diagrama de Caso de Uso de Aplicação

Fonte: wikipedia.org Slide 676

Diagrama de Gerenciabilidade Corporativa • O Diagrama de Gerenciabilidade Corporativa mostra como um ou mais aplicativos interagem com os componentes tecnológicos e de aplicativos, que am o gerenciamento operacional de uma solução. • Análises podem revelar duplicidades, diferenças e oportunidades na operação do gerenciamento de serviços de TI de uma organização.

Slide 677

Exemplo de Diagrama de Gerenciabilidade Corporativa

Slide 678

Diagrama de Processo & Realização de Aplicativo • O propósito deste diagrama é descrever a sequência de eventos que ocorrem quando múltiplos aplicativos estão envolvidos na execução de um processo de Negócio. • Isto adiciona valor ao diagrama de Comunicação entre Aplicativos ao estendê-lo com as restrições de sequenciamento e pontos de hand-off entre processamentos de lotes e em tempo real.

Slide 679

Exemplo de Diagrama de Processo & Realização de Aplicativo

Slide 680

Diagrama de Engenharia de Software • O diagrama de Engenharia de Software quebra as aplicações em pacotes, módulos, serviços e operações a partir da perspectiva do desenvolvimento. • Ele permite uma análise de impacto mais detalhada ao planejar estágios de migração e analisar oportunidades e soluções. • Ele é ideal para equipes de desenvolvimento de aplicativos e de gerenciamento de sistemas em ambientes de desenvolvimento complexos.

Slide 681

Exemplo de Diagrama de Engenharia de Software

Slide 682

Diagrama de Migração de Aplicativo • O Diagrama de Migração de Aplicativo identifica a migração de aplicativos da linha de base em direção aos componentes de aplicativos alvo. • Ele permite uma estimativa mais precisa dos custos de migração. • Ele deve ser utilizado para identificar aplicativos temporários, um cenário intermediário dos aplicativos e a infraestrutura requerida para ar as migrações.

Slide 683

Exemplo de Diagrama de Migração de Aplicativo

Slide 684

Diagrama de Distribuição de Software • Este diagrama é uma composição do diagrama de Engenharia de Software e o diagrama de Aplicativo & Localização de Usuário. • Dependendo das circunstâncias, este diagrama sozinho pode ser suficiente ou até mesmo não ser necessário.

Slide 685

Phase C Fase C: Arquitetura de Aplicativos – Catálogos, Matrizes e Diagramas Application Architecture

TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países.

Slide 686de 34

Módulo 21 Arquitetura de Fundação Edição de Direitos Autorais V9.1 © 2009-2011

Slide 687de 23 Todos os direitos reservados Publicado por The Open Group, 2011

Arquitetura de Fundação

TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países.

Slide 688de 23

Arquitetura de Fundação do TOGAF Uma Arquitetura de Fundação é uma arquitetura de blocos de construção e padrões correspondentes que am todas as Arquiteturas de Sistemas Comuns e, portanto, todos os ambientes operacionais da empresa. • O TOGAF provê a Arquitetura de Fundação TRM. • O a a especialização destes tipos de Arquiteturas de Fundação de forma a criar modelos específicos para a organização. • O TRM é um exemplo de uma Arquitetura de Fundação na qual outras arquiteturas mais específicas podem ser criadas. Slide 690

Componentes do TRM • O TRM tem dois componentes principais: – A taxonomia que define a terminologia e provê uma descrição coerente dos componentes e da estrutura conceitual de um sistema de informação. – Um diagrama do TRM que provê uma representação visual para ajudar o entendimento.

Slide 691

O TRM

A Portabilidade de Aplicativo é alcançada via Interface da Plataforma de Aplicativo, identificando o conjunto de serviços que são disponibilizados de forma padrão para os aplicativos através da plataforma.

A Interoperabilidade é alcançada via Interface da Infraestrutura de Aplicativos, identificando o conjunto de serviços de Infraestrutura de Comunicações que são construídos de forma padronizada.

Slide 692

Aplicativos de Negócio Aplicativos de Infraestrutura A API especifica a interface entre O TRM o tem duas categorias de A Plataforma de Aplicativo é uma implementam processos de provêem funcionalidade de Software Aplicativo e a plataforma Software Aplicativo. entidade conceitual que contém Negócio e são específicos por propósito geral, normalmente Serviços do Sistema Operacional, subjacente. vertical ou empresa. Serviços deCOTS. Rede e um conjunto

The TRM in Detail

genérico de Serviços de Plataforma.

Qualidades são os conjuntos de atributos aplicáveis sobre todos os componentes.

A Interface da Infraestrutura de Comunicações é uma interface entre a Plataforma de Aplicativos e a Infraestrutura de Comunicações.

Qualidades típicas são gerenciabilidade e segurança. Algumas qualidades podem ser melhor especificadas em termos de medidas no lugar de padrões, ex.: Performance. A Infraestrutura de Comunicações contém serviços básicos para interconectar sistemas e prover transferência de dados. Ela manipula a Slide 693 infraestrutura de comunicações física.

Utilizando o TRM • A Plataforma de Aplicativo é uma entidade conceitual única e genérica • Ela contém todos os serviços possíveis de serem representados • O arquiteto corporativo deve analisar os serviços realmente necessários de forma a definir blocos de construção de solução ótimos • O uso do não é dependente do uso da taxonomia do TRM do TOGAF. Outras taxonomias são possíveis e podem ser preferíveis. • Uma organização pode descrever a taxonomia do TOGAF (ou sua própria) utilizando gráficos diferentes, os quais melhor capturam conceitos legados para a comunicação interna. Slide 694

Taxonomia dos Serviços de Plataforma • Define a terminologia • Fornece uma descrição coerente de um sistema de informação:

– Componentes denominados categorias de serviços – Estrutura conceitual • Definição útil, amplamente aceitável, consistente e estruturada da entidade da plataforma de aplicativo.

Continua… Slide 695

Taxonomia dos Serviços de Plataforma • Sem uma definição ótima ou exclusiva • O do TOGAF não é dependente do TRM

Slide 696

Taxonomia dos Serviços de Plataforma • Serviços de Troca de Dados

• Serviços de Rede

• Serviços de Gerenciamento de Dados

• Serviços de Sistema Operacional

• Serviços Gráficos e de Imagem

• Serviços de Engenharia de Software

• Serviços de Operação Internacional • Serviços de Localização e Diretório

• Serviços de Processamento de Transação

• Serviços de Interface com o Usuário • Serviços de Segurança

• Serviços de Gerenciamento de Sistemas e Rede Slide 697

Taxonomia das Qualidades de Serviço da Plataforma de Aplicativos • Uma qualidade de serviço descreve o comportamento – Como adaptabilidade ou gerenciabilidade

• As qualidades de serviço tem um efeito penetrante sobre a operação da maioria, senão todas, as categorias de serviços funcionais • Durante o desenvolvimento da arquitetura, o arquiteto tem que estar atento às qualidades desejadas e à extensão de suas influências nas escolhas dos blocos de construção.

Slide 698

Disponibilidade Disponibilidade é o nível no qual algo está disponível para o uso. Ela pode ser dividida em 6 critérios: • Gerenciabilidade – a capacidade de colher informação sobre o estado de algo e controlá-lo. • Manutenibilidade – a capacidade de identificar problemas e tomar ações corretivas como reparo ou atualização de um componente em um sistema em execução. • Performance – a capacidade de um componente realizar suas tarefas no tempo apropriado. Continua… Slide 699

Disponibilidade • Confiabilidade – resistência a falhas. • Recuperabilidade – a capacidade de restaurar um sistema a um estado de funcionamento depois de uma interrupção.

• Localizabilidade – a capacidade de um sistema ser encontrado quando necessário.

Continua… Slide 700

Garantia Garantia pode ser dividada nos critérios que seguem: • Segurança – a proteção da informação de o não autorizado. • Integridade – a garantia de que os dados não foram corrompidos. • Credibilidade – o nível de confiança na integridade do sistema e de seus dados. Continua… Slide 701

Usabilidade Usabilidade é a facilidade do sistema ser operado pelos usuários, incluindo: • Operação internacional, o que inclui habilidades multilíngue e multicultural

Continua… Slide 702

Adaptabilidade Adaptabilidade pode ser dividida em 5 critérios: • Interoperabilidade – seja dentro ou fora da organização (por exemplo, interoperabilidade das funções de calendário ou agenda podem ser cruciais para a utilidade de um sistema).

• Escalabilidade – a capacidade de um componente aumentar ou diminuir sua performance ou capacidade de acordo com as demandas do ambiente no qual opera.

Continua… Slide 703

Adaptabilidade • Portabilidade – de dados, pessoas, aplicativos e componentes.

• Extensibilidade – capacidade de aceitar novas funcionalidades. • ibilidade – o a serviços em novos paradigmas, como a orientação a objetos.

Slide 704

Personalizando o TRM • As empresas podem precisar padronizar o TRM – “One-size fits all” não funciona em qualquer lugar

• A meta subjacente é assegurar que os blocos de construção de nível superior que compõem soluções de negócio tenham uma plataforma robusta. • Outros modelos, taxonomias e gráficos podem ser preferíveis para algumas empresas. • O TRM é visto como uma ferramenta quando se aplica o – O sempre é válido, independentemente da escolha de uma taxonomia específica. Slide 705

Arquitetura de Fundação

TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países.

Slide 709de 23

Módulo 22 Fase D Arquitetura Tecnológica Edição de Direitos Autorais V9.1 © 2009-2011

Slide 710de

30

•Todos os direitos reservados •Publicado por The Open Group, 2011

Phase D Fase D: Arquitetura Tecnológica

Arquitetura Tecnológica

•TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países.

Slide 711de

30

TM

Abordagem • Revisar os Recursos da Arquitetura Tecnológica disponível no Repositório de Arquitetura: – Serviços de TI existentes no Repositório de TI ou Catálogo de Serviços de TI. – O TRM do TOGAF. – Modelos tecnológicos relevantes à organização.

Slide 714

Arquitetura Tecnológica: Entradas • Requisição para o Trabalho de Arquitetura • Avaliação de Capacidade • Plano de Comunicações • Modelo Organizacional para a Arquitetura Corporativa • Framework de Arquitetura adaptado • Princípios tecnológicos • Declaração de Trabalho de Arquitetura • Visão da Arquitetura • Repositório de Arquitetura Continua… Slide 715

Arquitetura Tecnológica: Entradas •

Rascunho do Documento de Definição da Arquitetura, contendo: – – – – – – –

–

• •

Slide 716

Arquitetura de Negócio de Linha de Base (detalhada) Arquitetura de Negócio Alvo (detalhada) Arquitetura de Dados de Linha de Base (detalhada) Arquitetura de Dados Alvo (detalhada) Arquitetura de Aplicativos de Linha de Base (detalhada) Arquitetura de Aplicativos Alvo (detalhada) Arquitetura Tecnológica de Linha de Base (alto nível) Arquitetura Tecnológica Alvo (alto nível)

Rascunho da Especificação de Requisitos de Arquitetura, incluindo os resultados da análise de diferenças e os requisitos técnicos. Componentes de um Roap de Arquitetura da Arquitetura de Negócio, Dados e Aplicativos.

os A ordem dos os deve ser adaptada à situação. Em particular, você deve determinar se é apropriado realizar o desenvolvimento da Arquitetura Tecnológica de Linha de Base ou da Arquitetura Tecnológica Alvo primeiro.

9. Crie o Documento de Definição da Arquitetura 8. Finalize a Arquitetura Tecnológica 7. Conduza uma revisão formal com as partes interessadas 6. Resolva impactos em todo Panorama da Arquitetura 5. Defina componentes candidatos ao roap 4. Realize uma análise de diferenças

3. Desenvolva a Descrição da Arquitetura Tecnológica Alvo 2. Desenvolva a Descrição da Arquitetura Tecnológica de Linha de Base 1. Selecione os modelos de referência, pontos de vista e ferramentas. Slide 717

o 1: Selecione modelos de referência, pontos de vista e ferramentas •

Revise / gere e valide os princípios tecnológicos – veja “Princípios Arquiteturais”

•

Selecione os recursos da Arquitetura Tecnológica (modelos de referência, padrões, ...)

•

Selecione os pontos de vista relevantes à Arquitetura Tecnológica

•

Identifique as ferramentas e técnicas apropriadas a serem utilizadas para captura de dados, modelagem e análise em associação com os pontos de vista selecionados.

Continua… Slide 718

o 1: Selecione modelos de referência, pontos de vista e ferramentas •

Determine o Processo Geral de Modelagem –

Para cada ponto de vista, selecione os modelos necessários para ar a visão requerida, utilizando a ferramenta ou método selecionado. Confirme se todas as preocupações das partes interessadas estão sendo abordadas. Senão, crie novos modelos para abordar os interesses não cobertos ou complemente os modelos existentes.

Continua… Slide 719

Fase Preliminar • Catálogo de Princípios Gerenciamento de Requisitos

Fase A, Visão da Arquitetura • Matriz de Mapeamento de Partes Interesssadas

• Diagrama da Cadeia de Valores • Diagr.ama de Conceito de Soluções

TOGAF 9 Artifacts • Catálogo de Requisitos

Fase B, Arquitetura de Negócio

Fase C, Arquitetura de Dados

Fase C, Arquitetura de Aplicativos

Fase D, Arquitetura Tecnológica

• •

•

•

•

• • • •

• • • • • • • • • • •

Catálogo de Organização / Ator Catálogo de Motivador / Meta / Objetivo Catálogo de Papéis Catálogo de Serviço de Negócio / Função Catálogo de Localização Catálogo de Processo / Evento / Controle / Produto Catálogo de Contrato / Medida Matriz de Interação de Negócio Matriz de Ator / Papel Diagrama de Footprint de Negócio Diagrama de Serviço de Negócio / Informação Diagrama de Decomposição Funcional Diagrama de Ciclo de Vida de Produto Diagrama de Meta / Objetivo / Serviço Diagramam de Decomposição da Organização Diagrama de Fluxo de Processo Diagrama de Eventos

Fase E. Oportunidades e Soluções • Diagrama de Contexto de Projeto • Diagrama de Benefícios

Slide 720

• •

• • •

• • •

Catálogo de Entidade de Dados / Componente de Dados Matriz de Entidade de Dados / Função de Negócio Matriz de Aplicativo / Dados Diagrama Lógico de Dados Diagrama de Disseminação de Dados Diagrama de Segurança de Dados Diagrama de Hierarquia de Classes Diagrama de Migração de Dados Diagrama de Ciclo de Vida de Dados

• • • • •

Catálogo de Potifólio de Aplicativos Catálogo de Interfaces Matriz de Aplicativos / Organização Matriz de Papel / Aplicativo Matriz de Aplicativo / Função Matriz de Interação entre Aplicativos Diagrama de Comunicação entre Aplicativos Diagrama de Aplicativos e Localização de Usuário Diagramam de Caso de Uso de Aplicativo Diagrama de Gerenciabilidade Corporativa Diagrama de Processo / Relização de Aplicativo Diagrama de Engenharia de Software Diagrama de Migração de Aplicativos Diagrama de Distribuição de Software

Nota: • O Módulo 22A fornece • informações detalhadas • sobre a Fase D: Arquitetura • Tecnológica, Catálogos, Matrizes e Diagramas. • • • •

• • •

• • • •

Catálogo de Padrões Tecnológicos Catálogo de Portfólio Tecnológico Matriz de Sistema / Tecnologia Diagrama de Ambientes e Localizações Diagrama de Decomposição de Plataforma Diagrama de Processamento Diagrama de Computação em Rede / Hardware Diagrama de Engenharia de Comunicações

Artefatos do TOGAF 9

o 1: Selecione os modelos de referência, pontos de vista e ferramentas •

Identifique os Catálogos Requeridos dos Blocos de Construção de Dados Os catálogos que seguem devem ser considerados para o desenvolvimento dentro de uma Arquitetura Tecnológica: – Catálogo de Padrões Tecnológicos – Catálogo de Portfólio de Tecnologias

Continua… Slide 721

o 1: Selecione os modelos de referência, pontos de vista e ferramentas • Identifique as Matrizes Requeridas – Matrizes mostram os relacionamentos principais entre entidades do modelo relacionadas. – Recomendado desenvolver uma Matriz Aplicação x Tecnologia.

• Identifique os Diagramas Requeridos – Diagramas apresentam a informação da Arquitetura Tecnológica a partir de um conjunto de diferentes pontos de vista. – Os seguintes diagramas são recomendados: • Diagrama de Ambientes & Localizações • Diagrama de Decomposição de Plataforma • Diagrama de Computação em Rede & Hardware • Diagrama de Comunicação Continua… Slide 722

o 1: Selecione os modelos de referência, pontos de vista e ferramentas • Identifique os Tipos de Requisitos a serem Coletados – Identifique os requisitos a serem atendidos pela Arquitetura. – Formalize os requisitos focados em tecnologia. – Se for o caso, forneça um orientação detalhada a ser refletida durante o design e implementação.

Continua… Slide 723

o 1: Selecione modelos de referência, pontos de vista e ferramentas • Selecione os Serviços – Os portfólios de serviços são combinações de serviços básicos das categorias de serviços no TRM do TOGAF. – Para cada bloco de construção, construa um portfólio de descrições de serviços como um conjunto de serviços não conflitantes. – O conjunto de serviços deve ser testado para assegurar que a funcionalidade provida atende aos requisitos dos aplicativos.

Slide 724

o 2 Desenvolva uma Descrição de Arquitetura Tecnológica de Linha de Base Se possível, identifique os BCAs de Tecnologia relevantes, com base no Repositório de Arquitetura.

• •

Se nada existir, defina cada aplicativo alinhado com o catálogo de Portfólio de Tecnologias. Onde novos modelos de arquitetura precisem ser desenvolvidos, utilize os modelos identificados no o 1 como uma orientação para a criação de novos conteúdos arquiteturais para descrever a Arquitetura de Linha de Base.

Slide 725

o 3 Desenvolva uma Descrição de Arquitetura Tecnológica Alvo •

Se possível, identifique os blocos de construção relevantes da Arquitetura Tecnológica, com base no Repositório de Arquitetura.

•

Onde novos modelos arquiteturais precisem ser desenvolvidos, utilize modelos identificados no o 1 como orientação.

Slide 726

o 4 Realize uma Análise de Diferenças Verifique os modelos de arquitetura do ponto de vista de consistência interna e precisão. Observe mudanças nos pontos de vista representados nos modelos selecionados do Repositório de Arquitetura e os documente. Teste os modelos de arquitetura em relação à completude dos requisitos. Identifique diferenças entre a linha de base e o alvo, utilizando técnicas padrão de Análise de Diferença.

Slide 727

o 5: Defina os componentes candidatos ao roap • Este roap inicial de Arquitetura Tecnológica será utilizado como matéria prima para ar uma definição mais detalhada de um roap consolidado e multidisciplinar dentro da fase Oportunidade & Soluções.

Slide 728

o 6: Resolva impactos em todo o Panorama da Arquitetura • Artefatos de arquitetura no Panorama da Arquitetura devem ser examinados para identificar: – Esta Arquitetura Tecnológica cria um impacto em alguma arquitetura pré-existente? – Mudanças recentes foram realizadas que impactam a Arquitetura Tecnológica? – Existem oportunidades para alavancar o trabalho desta Arquitetura Tecnológica em outras áreas da organização? – Esta Arquitetura Tecnológica impacta outros projetos? – Esta Arquitetura Tecnológica será impactada por outros projetos?

Slide 729

o 7 Conduza uma Revisão Formal com as Partes Interessadas Verifique a motivação original para o projeto de arquitetura e a Declaração do Trabalho de Arquitetura e compare com a Arquitetura Tecnológica proposta. • A Arquitetura Tecnológica está ajustada aos propósitos de ar um trabalho subsequente nos outros domínios de arquitetura? Refine a Arquitetura Tecnológica proposta, se necessário.

Continua… Slide 730

o 8 Finalize a Arquitetura Tecnológica • • • • •

•

Selecione padrões para cada um dos BCAs, reutilizando tanto quanto possível. Fala uma documentação completa de cada BCA. Faça uma verificação cruzada geral de toda a arquitetura contra as metas de Negócio. Documente os relatórios finais de rastreabilidade de requisitos. Documente o mapeamento final da arquitetura dentro do repositório de Arquitetura. Identifique os BCAs que podem ser reutilizados e os publique no Repositório de Arquitetura. Finalize todos os produtos de trabalho.

Slide 731

o 9: Crie um Documento de Definição de Arquitetura • Documente as razões das decisões referentes aos blocos de construção no documento de definição da arquitetura. • Prepare as seções da Arquitetura Tecnológica do documento de definição da arquitetura. • Se for o caso, utilize relatórios e/ou gráficos gerados por ferramentas de modelagem para demonstrar as principais visões da arquitetura. Envie o documento às partes interessadas relevantes para revisão e incorpore seus s.

Slide 732

Saídas da Arquitetura Tecnológica • Declaração do Trabalho de Arquitetura, atualizada se necessário • Princípios tecnológicos validados ou novos princípios tecnológicos • Rascunho do Documento de Definição da Arquitetura • Rascunho da Especificação de Requisitos de Arquitetura • Componentes da Arquitetura Tecnológica do Roap de Arquitetura Slide 733

Documento de Definição da Arquitetura – Componentes da Arquitetura Tecnológica • •

Arquitetura Tecnológica de Linha de Base, se for o caso. Arquitetura Tecnológica Alvo, incluindo: – Componentes tecnológicos e seus relacionamentos com os sistemas de informação. – Plataformas tecnológicas e suas decomposições, mostrando as combinações de tecnologias requeridas para realizar uma “pilha” (stack) de tecnologia em particular. – Ambientes e localizações – um agrupamento de tecnologias requeridas nos ambientes computacionais (ex.: desenvolvimento, produção). – Carga de processamento esperada e distribuição de carga pelos componentes tecnológicos. – Comunicações (rede) físicas – Especificações de hardware e rede

•

Visões correspondendo aos pontos de vista selecionados, abordando as principais preocupações das partes interessadas.

Slide 734

Especificação de Requisitos de Arquitetura – Componentes da Arquitetura Tecnológica • Resultados da análise de diferenças • Requisitos tecnológicos atualizados

Slide 735

Phase D Fase D: Arquitetura Tecnológica

Arquitetura Tecnológica

•TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países.

Slide 739de

30

TM

Módulo 22A Fase D Arquitetura Tecnológica – Catálogos, Matrizes e Diagramas •Edição de Direitos Autorais V9.1 © 2009-2011

Slide 740de 24

•Todos os direitos reservados •Publicado por The Open Group, 2011

Phase D Fase D: Arquitetura Tecnológica – Catálogos, Matrizes e Diagramas

Arquitetura Tecnológica

TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países.

Slide 741de 24

Fase Preliminar • Catálogo de Princípios Gerenciamento de Requisitos

Fase A, Visão da Arquitetura • Matriz de Mapeamento de Partes Interesssadas

• Diagrama da Cadeia de Valores • Diagr.ama de Conceito de Soluções

TOGAF 9 Artifacts • Catálogo de Requisitos

Fase B, Arquitetura de Negócio

Fase C, Arquitetura de Dados

Fase C, Arquitetura de Aplicativos

Fase D, Arquitetura Tecnológica

• •

•

•

•

• • • •

• • • • • • • • • • •

Catálogo de Organização / Ator Catálogo de Motivador / Meta / Objetivo Catálogo de Papéis Catálogo de Serviço de Negócio / Função Catálogo de Localização Catálogo de Processo / Evento / Controle / Produto Catálogo de Contrato / Medida Matriz de Interação de Negócio Matriz de Ator / Papel Diagrama de Footprint de Negócio Diagrama de Serviço de Negócio / Informação Diagrama de Decomposição Funcional Diagrama de Ciclo de Vida de Produto Diagrama de Meta / Objetivo / Serviço Diagramam de Decomposição da Organização Diagrama de Fluxo de Processo Diagrama de Eventos

Fase E. Oportunidades e Soluções • Diagrama de Contexto de Projeto • Diagrama de Benefícios

Slide 743

• •

• • •

• • •

Catálogo de Entidade de Dados / Componente de Dados Matriz de Entidade de Dados / Função de Negócio Matriz de Aplicativo / Dados Diagrama Lógico de Dados Diagrama de Disseminação de Dados Diagrama de Segurança de Dados Diagrama de Hierarquia de Classes Diagrama de Migração de Dados Diagrama de Ciclo de Vida de Dados

• • • • •

• • • • • • • •

Catálogo de Portfólio de Aplicativos Catálogo de Interfaces Matriz de Aplicativos / Organização Matriz de Papel / Aplicativo Matriz de Aplicativo / Função Matriz de Interação entre Aplicativos Diagrama de Comunicação entre Aplicativos Diagrama de Aplicativos e Localização de Usuário Diagramam de Caso de Uso de Aplicativo Diagrama de Gerenciabilidade Corporativa Diagrama de Processo / Realização de Aplicativo Diagrama de Engenharia de Software Diagrama de Migração de Aplicativos Diagrama de Distribuição de Software

• • •

• • • •

Catálogo de Padrões Tecnológicos Catálogo de Portfólio Tecnológico Matriz de Sistema / Tecnologia Diagrama de Ambientes e Localizações Diagrama de Decomposição de Plataforma Diagrama de Processamento Diagrama de Computação em Rede / Hardware Diagrama de Engenharia de Comunicações

Artefatos do TOGAF 9

Catálogos, Matrizes and Diagramas Catálogos • Catálogo de Padrões Tecnológicos • Catálogo de Portfólio de Tecnologias Matrizes • Matriz Aplicativo x Tecnologia

O formato exato dos catálogos, matrizes e diagramas dependerá das ferramentas utilizadas. Slide 744

Diagramas • Diagrama de Ambientes & Localizações • Diagrama de Decomposição de Plataforma • Diagrama de Processamento • Diagrama de Computação em Rede & Hardware • Diagrama de Engenharia de Comunicações

Catálogos • Catálogo de Padrões Tecnológicos • Catálogo de Portfólio de Tecnologias

Slide 745

Catálogos Catálogo Catálogo de Padrões Tecnológicos

Propósito Ele documenta os padrões acordados para a tecnologia em toda a empresa cobrindo tecnologias, os ciclos de vida da tecnologia e os ciclos de renovação para a tecnologia. Pode ser implementado como uma extensão ao Catálogo do Portfólio de Tecnologia e desta forma compartilhará das mesmas entidades do metamodelo: • Serviço de Plataforma, Componente Lógico de Tecnologia, Componente Físico de Tecnologia.

Catálogo de Portfólio de Tecnologia

Este catálogo identifica e lista todas as tecnologias em uso em toda a corporação, incluindo hardware, software de infraestrutura e software aplicativo. Um portfólio de tecnologia acordado a o gerenciamento do ciclo de vida dos produtos tecnológicos e versões, e também forma a base para a definição de padrões tecnológicos. Ele contém as entidades de metamodelo que seguem: • Serviço de Plataforma, Componente Lógico de Tecnologia, Componente Físico de Tecnologia.

Slide 746

Matrizes • Matriz de Aplicativo/Tecnologia

Slide 748

Matriz de Aplicativo x Tecnologia • A matriz de Aplicativo/Tecnologia documenta o mapeamento de aplicativos na plataforma tecnológica. • A matriz Aplicativo/Tecnologia mostra: – Componentes Lógicos e Físicos de Aplicativos. – Serviços, Componentes Lógicos de Tecnologia e Componentes Físicos de Tecnologia. – Componentes Físicos de Tecnologia – Componentes Físicos de Tecnologia realizam relacionamentos de Componentes Físicos de Aplicativos

Slide 749

Exemplo de Matriz de Aplicativo x Tecnologia COMPONENTE LÓGICO DE APLICATIVO ABM

Balanceador de carga e Dispatcher

Slide 750

COMPONENTE FÍSICO DE TECNOLOGIA

ENDEREÇO DO SERVIDOR

ENDEREÇO IP

Servidor Web - nó 1

[email protected]

10.xx.xx.xx

Servidor Web - nó 2

[email protected]

10.xx.xx.xx

Servidor Web - nó 3

[email protected]

10.xx.xx.xx

App server – nó 1

[email protected]

10.xx.xx.xx

App server – nó 2

[email protected]

10.xx.xx.xx

App server – nó 3

[email protected]

10.xx.xx.xx

Servidor de Banco de dados (produção)

[email protected]

10.xx.xx.xx

Servidor de Banco de dados (desenvolvimento)

[email protected]

10.xx.xx.xx

Servidor de Dispatcher

[email protected]

242.xx.xx.xx

Exemplo de Matriz de Aplicativo x Tecnologia FUNÇÃO TECNOLÓGICA Balanceamento de Carga

Slide 751

LÓGICO DE HARDWARE Nome – Balancer Fornecedor- IBM Tipo – eServer Em Cluster – No No. de Nós– N/A Endereço Ló[email protected] Janela de Manutenção – Domingo 01:00 a 03:00

FÍSICO DE HARDWARE Model/Type – IBM P7xx Serial Number – 1S4568 Processador RISC Power p5 No. de Processadores - 8 way Memória - 1GB HD - 40 GB IP - 11.xx.xx.xx

LÓGICO DE SOFTWARE

FÍSICO DE SOFTWARE

Produto- IBM Load balance manager Fornecedor- IBM SO – UNIX

 Componentes de SW – LB v3.2 (liste todos os outros componentes de SW) AIX 10.2.1 Tipo de Licença Licença para toda empresa Licença Expira – 31/12/2014

Exemplo de Matriz de Aplicativo x Tecnologia COMPONENTE DE APLICATIVO

UNIDADE DE IMPLANTAÇÃO

COMPONENTE TECNOLÓGICO

Balanceador de Carga

Smart dispatch v1.2

Servidor de Balanceamento de Carga ([email protected])

Páginas de Comércio Eletrônico

HTML Applets JSP

 Cluster de Servidor Web ([email protected])

Motor de Comércio Eletrônico

•Entrada de Pedido •Carrinho de Compras

•Servidor de Aplicação ([email protected])

Slide 752

Diagramas • • • • •

Diagrama de Ambientes & Localizações Diagrama de Decomposição de Ambientes Diagrama de Processamento Diagrama de Computação em Rede & Hardware Diagrama de Engenharia de Comunicações

Slide 753

Diagrama de Ambientes & Localizações • Descreve quais localidades hospedam quais aplicativos. • Identifica quais tecnologias e/ou aplicativos são utilizados em quais localidades. • Identifica quais localidades de quais usuários de negócio tipicamente interagem com os aplicativos. • Deve sempre mostrar a existência e a localização de ambientes de implantação diferentes: – Incluindo ambientes que não são de produção, como os de desenvolvimento e de pré-produção.

Slide 754

Exemplo de Diagrama de Ambientes & Localizações

Slide 755

Diagrama de Decomposição de Plataforma • O Diagrama de Decomposição de Plataforma descreve a plataforma tecnológica que a as operações da Arquitetura de Sistemas de Informação. • O diagrama cobre todos os aspectos da plataforma de infraestrutura e fornece uma visão geral da plataforma tecnológica da empresa.

Slide 756

Exemplo de Diagrama de Decomposição de Plataforma Decomposição de Plataforma

(e a Aplicativo)

Hardware

Software

Logical Technology Components

Physical Technology Components

Tech Function

Tech Function

Web Server Layer

Web server layer

Application Layer

Application Layer

Database Layer

Database Layer

Attributes • • • • • • • •

Slide 757

Name Model/Type Clusters Number of Components Vendor Server Type (mainframe, Mid range, RISC, Intel) Server logical name IP Address etc

Logical Technology Components

Physical Technology Components

Tech Function

Tech Function

Web Server Layer

Web Server Layer

Application Layer

Application Layer

Database Layer

Database Layer

Attributes      

Product Name Vendor OS SW components License Type License Expiry etc

Diagrama de Processamento • O Diagrama de Processamento foca nas unidades de implantação de código/configuração e como eles são implantados na plataforma tecnológica. • O Diagrama de Processamento aborda: – Qual conjunto de componentes de aplicativo precisa estar agrupado para formar uma unidade de implantação. – Como uma unidade de implantação conecta / interage com outra (LAN, WAN e os protocolos aplicáveis). – Como configuração de aplicativo e padrões de uso geram carga ou requisitos de capacidade para diferentes componentes de tecnologia.

• A organização e agrupamento das unidades de implantação dependem de interesses referentes à separação das camadas de apresentação, lógica de negócio e armazenamento de dados, e requisitos de nível de serviço dos componentes. Slide 758

Exemplo de Diagrama de Processamento Open Internet

DMZ

Internet Zone

Intranet Zone

File Explorer, HTML, Images (DFS Distributed File System Server)

Order capture (DB server) HTML Code (Web server cluster with 2 nodes)

Load Balancer Code

Order Entry & Shopping Cart (Application Server cluster with 2 nodes)

App Server

Messaging Server

Over LAN HTTP

Firewall

Slide 759

Firewall

Firewall

DB

Diagrama de Hardware de Computação em Rede •

O propósito deste diagrama é mostrar a visão “implantada” dos componentes lógicos de aplicativo em um ambiente distribuído de computação em rede.

•

Este diagrama é útil pelas razões que seguem: – Permite o entendimento de qual aplicativo é implantado onde. – Estabelece autorização, segurança e o aos componentes tecnológicos. – Entende a Arquitetura Tecnológica que a os aplicativos durante a soluções de problemas e troubleshooting. – Isola problemas de performance encontrados e realiza atualizações necessárias a componentes físicos tecnológicos específicos. – Identifica áreas de otimização. – Permite a auditoria de aplicativo / tecnologia e provê conformidade. – Serve como uma ferramenta importante no e ao gerenciamento de mudanças efetivas.

Slide 760

Exemplo de Diagrama de Hardware de Computação em Rede DMZ

Zona da Internet

Web server Web cluster server cluster

Load Balancer and Dispatcher

Web server clusternode 3 (ABM)

Web server cluster Web server cluster-node 2 (eCommerce)

Load Balancer and Dispatcher

Application Server cluster Application (node 3) Server cluster (node 3) App Server cluster - node 3 (ABM)

Zona da Intranet

Database (ABM Staging)

Database (ABM Production)

DFS Distributed File System (html, images)

Database Application Server (Order Engine)

App Server

App Server

Firewall

Slide 761

Firewall

Firewall

DB

Diagrama de Engenharia de Comunicações • O Diagrama de Engenharia de Comunicações descreve os meios de comunicação entre os componentes na Arquitetura Tecnológica. • Representa conexões lógicas entre os componentes cliente e servidor e identifica limites de infraestrutura de rede requeridos para fisicamente implementar estas conexões. • Não descreve o formato ou conteúdo da informação, mas aborda questões de protocolo e capacidade.

Slide 762

Diagrama de Engenharia de Comunicações DMZ Internet

OBMG Proprietary Protocol (Encrypted)

GPRS (OBMG / Encrypted)

KEY Port xxx Opened on Firewall

Port xxx Opened on Firewall

Mobile Device

Network

OBMG Proprietary Protocol (Encrypted)



Server

Mobile Device

Data Store

Firewall

Network Linking Device

G OBM ry rieta Prop col Proto ted) ryp (Enc

OBMG DMZ Proxy

Networ k Area

Client PC

LAN MS Exchange Mail Synch Protocol

MG OB ietary pr l Pro otoco d) Pr ypte cr (En Cradle / USB Cable

Mobile Device

OBMG Server

Au th

Pr o

to c

ol

th Au

Desktop PC (OBMG Desktop Proxy) Active Directory

Slide 763

o Pr

c to

ol

Microsoft Exchange

Phase D Fase D: Arquitetura Tecnológica – Catálogos, Matrizes e Diagramas

Arquitetura Tecnológica

TOGAF é marca registrada pelo The Open Group nos Estados Unidos e outros países.

Slide 764de 24

Módulo 23

Técnicas de Planejamento de Migração V9.1 Edition Copyright © 2009-2011

Slide 765of

17

Todos os direitos reservados Publicado por The Open Group, 2011

Técnicas de Planejamento de Migração

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 766of

17

Roap Parte I - Introdução Prefácio, Visão global executiva, Principais Conceitos, Definições e Notas da Versão

Parte II – Método de Desenvolvimento da Arquitetura Introdução ao Narrativas das Fases do

Parte III – Orientações e Técnicas do Orientações para Adaptação do Processo do Técnicas para o Desenvolvimento da Arquitetura

Parte IV – Framework de Conteúdo da Arquitetura Metamodelo de Conteúdo Artefatos Arquiteturais Entregáveis da Arquitetura Blocos de Construção

Parte V – Continuum da Corporação e Ferramentas Continuum da Corporação Particionamento da Arquitetura Repositório da Arquitetura Ferramentas para o Desenvolvimento da Arquitetura

Parte VI – Modelos de Referência do TOGAF Arquitetura de Fundação: Modelo de Referência Técnico Modelo de Referência da Infraestrutura Integrada da Informação

Parte VII – Framework de Capacidade da Arquitetura Comitê de Arquitetura Aderência da Arquitetura Contratos da Arquitetura Governança da Arquitetura Modelos de Maturidade da Arquitetura Frameworks de Competências da Arquitetura

Slide 767

• Parte III, Orientações e Técnicas do , Capítulo 28

A Matriz de Avaliação e Dedução de Fatores de Implementação • • • • •

Esta matriz documenta os fatores que impactam o Plano de Implementação e Migração É criada no o 1 da Fase E e atualizada ao longo da Fase E É uma entrada para a Fase F Serve como um repositório para decisões na implementação e migração da arquitetura A matriz deve incluir: – Uma lista de fatores a serem considerados – Suas descrições – As deduções que indicam as ações ou restrições que devem ser levadas em consideração quando os planos forem formulados

Slide 769

Exemplo – Matriz de Avaliação e Dedução de Fatores de Implementação

Slide 770

A Matriz Consolidada de Diferenças (gaps), Soluções e Dependências • •

• • • •

Esta matriz é usada quando consolida-se os resultados das Análises de Diferenças da Fase B a D É utilizada para agrupar as diferenças identificadas nos resultados das Análises de Diferenças dos domínios de arquitetura e avaliar possíveis soluções e dependências para uma ou mais diferenças (gaps) É criada inicialmente no o 3 da Fase E É uma entrada para a Fase F Esta matriz pode ser usada como uma ferramenta de planejamento quando forem criados pacotes de trabalhos. As dependências identificadas direcionarão a criação de projetos e planos de migração nas Fases E e F

Slide 771

Exemplo – Matriz Consolidada de Diferenças (gaps), Soluções e Dependências

Slide 772

Tabela de Incrementos da Definição de Arquitetura •

• •

Esta tabela permite que o arquiteto planeje uma série de Arquiteturas de Transição descrevendo a situação da Arquitetura Corporativa em momentos específicos É criada na Fase F Consiste em listar os projetos e então atribuir seus entregáveis incrementais através das Arquiteturas de Transição

Slide 773

Tabela de Incrementos da Definição de Arquitetura

Slide 774

A Tabela de Evolução de Estado de Transição da Arquitetura • •

Permite ao arquiteto demonstrar o estado proposto das arquiteturas em vários níveis usando o TRM É parte do Plano de Implementação e Migração – Apresenta o estado proposto das arquiteturas conforme elas evoluem

•

Deve ser desenhada na Fase F, listando: – – – –

Slide 775

Serviços do TRM usados na corporação Arquiteturas de Transição Transformações propostas Todos os Blocos de Construção de Solução (BCSs) devem ser descritos com respeito a sua entrega e impacto nos serviços

A Tabela de Evolução de Estado de Transição da Arquitetura

Slide 776

A Técnica de Avaliação do Valor de Negócio • •

•

•

Esta técnica serve para avaliar o valor de negócio desenhando uma matriz com dimensões de valor e de índice de risco É utilizada na Fase F para desenvolver um valor estimado para o negócio de cada projeto O índice de valor devem incluir critérios como aderência aos princípios, contribuição financeira, alinhamento estratégico, e posição competitiva O índice de risco deve incluir critérios como tamanho e complexidade, tecnologia, capacidade organizacional e impacto de uma falha. Cada critério deve ser associado a um peso individual

Slide 777

A Técnica de Avaliação de Valor de Negócio

Slide 778

Resumo Este módulo explicou as técnicas utilizadas na Fase E e F para o planejamento de migração. Em particular, foi discutido: 2 matrizes (A Matriz de Avaliação e Dedução de Fatores de Implementação e a Matriz Consolidada de Diferenças (gaps), Soluções e Dependências). 2 tabelas (A Tabela de Incrementos de Definição da Arquitetura, e a Tabela de Evolução de Estado de Transição da Arquitetura). 1 técnica (A Técnica de Avaliação do Valor de Negócio)

Slide 779

Exercício: A Técnica de Avaliação de Valor do Negócio • Suponha que você é o arquiteto chefe de um grande projeto em sua empresa. O projeto está em conformidade com os princípios de sua arquitetura. Ele fará uma contribuição financeira considerável. Está estrategicamente alinhado com o seu negócio e vai fortalecer sua vantagem competitiva. • No entanto, o projeto é complexo e vai usar tecnologia de ponta. Sua capacidade organizacional é elevado, mas o impacto da falha também é elevado. • Pontuar cada critério em uma escala de 0 a 10 e dar a cada um, uma ponderação utilizando estas informações e sua experiência e produza assim uma dimensão de índice de valor e uma dimensão de índice de risco para o projeto. Slide 780

Técnicas de Planejamento de Migração

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 781of

17

Módulo 24 Fase E Oportunidades e Soluções Edição V9.1 Copyright © 2009-2011

Slide 782de 32

Todos os direitos reservados Publicado por The Open Group, 2011

Phase E Fase E: Oportunidades e Soluções

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 783de 32

Partes Interessadas • A Fase E é um esforço colaborativo – As Partes Interessadas de Negócio e TI são necessárias

• Deve-se incluir aqueles que implementarão e os que operarão a infraestrutura • Deve-se incluir também os que são responsáveis pelo planejamento estratégico – Especialmente para a criação de Arquiteturas de Transição, se necessária

Slide 786

Abordagem • Esta é a primeira fase relacionada à implementação • Ela leva em consideração o conjunto completo de diferenças (gaps) entre as Arquiteturas de Base e Alvo em todos os domínios de arquitetura • Ela agrupa logicamente as mudanças em pacotes de trabalho • Ela constrói um roap que melhor se adeque baseado: – Nos requisitos das partes interessadas – Na prontidão para a transformação de negócio da empresa – Nas oportunidades e soluções identificadas – Nas restrições de implementação identificadas Slide 787

Abordagem • Os quatro conceitos seguintes são fundamentais para a transição desde o desenvolvimento até a entrega da Arquitetura Alvo: – Roap de Arquitetura

– Pacotes de Trabalho – Arquiteturas de Transição – Plano de Implementação e Migração

Slide 788

Fase E: Entradas • Informação de Produtos • Requisição para Trabalho de Arquitetura • Avaliação da Capacidade • Plano de Comunicação • Metodologias de Planejamento • Modelos e Frameworks de Governança • Framework de Arquitetura Adaptado Continua Slide 789

Fase E: Entradas • Declaração de Trabalho de Arquitetura • Visão da Arquitetura • Repositório de Arquitetura • Rascunho do Documento de Definição da Arquitetura • Rascunho da Especificação de Requisitos da Arquitetura • Solicitações de Mudança para programas e projetos existentes • Componentes candidato do Roap de Arquitetura das Fases B, C e D

Slide 790

os

11. Criar o Roap de Arquitetura e o Plano de Implementação e Migração

10. Identificar as Arquiteturas de Transição 9. Identificar e agrupar os pacotes de trabalho principais 8. Formular a Estratégia de Implementação e Migração 7. Confirmar a prontidão e os riscos da transformação de negócio

6. Refinar e validar as dependências 5. Consolidar e reconciliar os requisitos de interoperabilidade

4. Revisar os requisitos consolidados das funções de negócio relacionadas 3. Revisar e consolidar os resultados das análises de diferenças das Fases B, C e D 2. Determinar as restrições de negócio para implementação 1. Determinar os atributos corporativos para mudanças Slide 791

o 1: Determinar os Atributos Corporativos para Mudanças • Criar uma Matriz de Avaliação e Dedução de Fatores de Implementação • Avaliar as Capacidades de Transição das Organizações Corporativas e Parceiras • Avaliar as Capacidades de Transição da Organização Corporativa e de TI

Slide 792

o 2: Determinar as Restrições de Negócio da Implementação • Revisar o Plano Estratégico Corporativo • Revisar os Planos Estratégicos Corporativos de Linhas de Negócio

• Revisar a Avaliação de Maturidade da Arquitetura Corporativa

Slide 793

o 3: Revisar e Consolidar os Resultados das Análises de Diferenças das Fases B, C e D • Criar uma Matriz Consolidada de Diferenças (gaps), Soluções e Dependências • Revisar os resultados das Análises de Diferenças das Fases B, C e D • Racionalizar a Matriz Consolidada de Diferenças (gaps), Soluções e Dependências

Slide 794

o 4: Revisar os Requisitos Consolidados das Funções de Negócio Relacionadas •

•

Avaliar os requisitos, diferenças, soluções e fatores para se identificar um conjunto mínimo de requisitos para criar pacotes de trabalho Essa perspectiva funcional leva à satisfação de requisitos múltiplos através do provisionamento de soluções e serviços compartilhados

Slide 795

o 5: Consolidar e Reconciliar os Requisitos de Interoperabilidade •

•

Consolidar os Requisitos de Interoperabilidade identificados nas fases anteriores Identificar restrições sobre a interoperabilidade impostas pelo conjunto potencial de soluções

Slide 796

o 6: Refinar e Validar as Dependências • •

Refinar as dependências iniciais, assegurando que quaisquer restrições sobre os Planos de Implementação e Migração sejam identificadas As dependências chave incluem: – Implementações existentes de Serviços de Negócio – Implementações existentes de Serviços de Sistemas da Informação

•

• •

As dependências devem ser utilizadas para se determinar a ordem da implementação e a coordenação necessária Isto pode ser utilizado para se identificar incrementos lógicos de entregáveis e o momento em que podem ser entregues Uma vez finalizado, documentar como parte do Roap de Arquitetura e de quaisquer Arquiteturas de Transição necessárias Slide 797

o 7: Confirmar a Prontidão e os Riscos da Transformação de Negócio • •

• •

Revisar a Avaliação de Prontidão para a Transformação do Negócio conduzida previamente na Fase A Determinar o impacto sobre o Roap de Arquitetura e a Estratégia de Implementação e Migração É importante identificar, classificar e mitigar os riscos associados com o esforço de transformação Os riscos devem ser documentados na Matriz Consolidada de Diferenças (gaps), Soluções e Dependências

Slide 798

o 8: Formular a Estratégia de Implementação e Migração •

Determinar uma abordagem estratégica genérica para a implementação de soluções e/ou a exploração de oportunidades – “Greenfield” – Revolucionária – Evolucionária

•

Determinar uma Abordagem de Implementação – Quick wins - Ganhos rápidos (snapshots) – Alvos alcançáveis – Método da Cadeia de Valor (ver metodologia NASCIO)

•

Essas abordagens e as dependências identificadas devem se tornar a base para a criação de pacotes de trabalhos Slide 799

o 9: Identificar e Agrupar os Pacotes de Trabalho Principais •

• • •

Utilizar a Matriz de Matriz Consolidada de Diferenças (gaps), Soluções e Dependências junto com a Matriz de Avaliação e Dedução de Fatores de Implementação para agrupar logicamente atividades em pacotes de trabalho Preencher a coluna “Solução” na Matriz Consolidada de Diferenças (gaps), Soluções e Dependências para se recomendar a solução proposta Indicar, para cada diferença/atividade, se a solução deve ser um novo desenvolvimento ou baseada num produto existente e/ou uma solução que deve ser adquirida Classificar cada sistema atual – – –

•

Sistemas principais Sistemas a conter Sistemas a substituir

Analisar os Pacotes de Trabalho com relação à Transformação de Negócio e agrupá-los em portfólios e projetos Slide 800

o 10: Identificar as Arquiteturas de Transição •

• •

Aplicável quando o escopo de mudança para implementar a Arquitetura Alvo requer uma abordagem incremental Identificar uma ou mais metas claras ao longo do roap para realizar a Arquitetura Alvo O desenvolvimento deve ser baseado na abordagem de implementação preferida, na Matriz Consolidada de Diferenças (gaps), Soluções e Dependências, na lista de projetos e portfólios assim como na capacidade da empresa para criar e absorver mudanças

Slide 801

o 11:Criar o Roap de Arquitetura e o Plano de Implementação e Migração •

Consolidar os pacotes de trabalho e Arquiteturas de Transição no Roap de Arquitetura, Versão 0.1 – O Roap de Arquitetura deve demonstrar como a seleção e o cronograma das Arquiteturas de Transição e os pacotes de trabalho realizam a Arquitetura Alvo

•

•

O Plano de Implementação e Migração, Versão 0.1 deve ser alinhado com o Roap de Arquitetura e ser suficiente para identificar os projetos e recursos necessários para realizar o roap Atualizar a Visão da Arquitetura, o Documento de Definição da Arquitetura e a Especificação de Requisitos da Arquitetura, se necessário Slide 802

Saídas da Fase E • Declaração de Trabalho de Arquitetura • Visão da Arquitetura • Rascunho do Documento de Definição da Arquitetura, incluindo: – Arquiteturas de Transição, se existirem

• Rascunho da Especificação de Requisitos da Arquitetura, incluindo: – Avaliação consolidada de Diferenças, Soluções e Dependências Continua Slide 803

Saídas da Fase E • Avaliação da Capacidade, incluindo: – Avaliação da Capacidade de Negócio – Avaliação da Capacidade de TI

• Roap de Arquitetura, incluindo: – Portfólio de Pacotes de Trabalho – Identificação de Arquiteturas de Transição, se houver – Recomendações de Implementação

• Plano de Implementação e Migração (esboço) Slide 804

Diagrama de Contexto do Projeto

Slide 808

Diagrama de Contexto do Projeto

Slide 809

E

Slide 810

Diagrama de Benefícios

E

Slide 811

Diagrama de Benefícios

Phase E Fase E: Oportunidades e Soluções

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 813de 32

Módulo 25 Fase F Planejamento da Migração

Edição V9.1 Copyright © 2009-2011

Slide 814of

18

Todos os direitos reservados Publicado por The Open Group, 2011

Phase F Fase F Planejamento da Migração

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 815of

18

Objetivos da Fase F • Finalizar o Roap de Arquitetura e o Plano de Implementação e de Migração que o a • Garantir que o Plano de Implementação e Migração seja coordenado com a abordagem corporativa para gerenciar e implementar mudanças no portfólio global de mudanças da corporação • Garantir que o valor de negócio e o custo dos pacotes de trabalho e Arquiteturas de Transição sejam entendidos pelas principais partes interessadas

Slide 817

Abordagem • O foco da é a criação de um Plano de Implementação e Migração em cooperação com os gerentes de projeto e de portfolio • As atividades incluem a avaliação das dependências, custos e benefícios dos vários projetos de migração dentro do contexto das outras atividades da corporação

Slide 818

Fase F: Entradas • Requisição para trabalho de Arquitetura • Plano de Comunicação • Modelo Organizacional para a Arquitetura Corporativa • Modelos e Frameworks de Governança • Framework de Arquitetura adaptado • Declaração de Trabalho da Arquitetura • Visão da Arquitetura • Repositório de Arquitetura Continua Slide 819

Fase F: Entradas •

Rascunho de Documento de Definição de Arquitetura, incluindo: –

• • •

Rascunho de Especificação de Requisitos de Arquitetura Solicitações de Mudança para programas e projetos existentes Roap de Arquitetura, incluindo: – – –

• •

Slide 820

Arquiteturas de Transição, se houver

Identificação de pacotes de trabalho Identificação de Arquiteturas de Transição Matriz de Avaliação e Dedução de Fatores de Implementação

Avaliação de Capacidades Plano de Implementação e Migração (esboço)

os 7. Completar o ciclo de desenvolvimento da arquitetura e documentar lições aprendidas 6. Gerar o Plano de Implementação e Migração 5. Confirmar o Roap de Arquitetura e atualizar o Documento de Definição de Arquitetura, 4. Priorizar os projetos de migração através da realização de uma avaliação de custo/benefício e validação de risco

3. Estimar os Requisitos de Recursos, Tempos de Projeto e Disponibilidade / Veículo de Entrega 2. Atribuir um valor de negócio para cada pacote de trabalho 1.

Slide 821

Confirmar as Interações dos Frameworks de Gerenciamento para o Plano de Implementação e Migração

o 1: Confirmar as Interações dos Frameworks de Gerenciamento para o Plano de Implementação e Migração •

Coordene o Plano de Implementação e Migração com os frameworks de gerenciamento em uso pela organização – – – –

•

Planejamento de Negócio Arquitetura Corporativa Gerenciamento de Portfolio/Projeto Gerenciamento de Operações

O resultado deste o pode ser o que o Plano de Implementação e Migração se torne parte de um plano diferente produzido por outro framework com a participação da Arquitetura Corporativa.

Slide 822

o 2: . Atribuir um valor de negócio para cada pacote de trabalho •

•

• •

•

Determinar o que constitui valor de negócio dentro da organização, como o valor pode ser medido, e depois aplicar isso para cada um dos projetos e incrementos de projetos Se o planejamento baseado em capacidade for utilizado, então os valores de negócio relacionados às capacidades e seus incrementos de capacidade associados, devem ser usados ​para atribuir os valores de negócio para as entregas. Use os pacotes de trabalho como base de identificação de projetos que estarão no Plano de Implementação e Migração Os riscos devem ser atribuídos aos projetos e incrementos de projetos agregando riscos identificados na Matriz Consolidada de Diferenças (gaps), Soluções e Dependências Estimar o valor de negócio para cada projeto usando o Técnica de Avaliação de Valor de Negócio. Slide 823

o 3: . Estimar os Requisitos de Recursos, Tempos de Projeto e Disponibilidade / Veículo de Entrega • • • •

Determinar custos para criar a capacidade Determinar custos para executar e sustentar a capacidade Identificar oportunidades para compensar custos desativando sistemas existentes Atribuir recursos para cada atividade e agregá-los aos níveis de incremento de projeto e de projeto

Slide 824

o 4: Priorizar os projetos de migração através da realização de uma avaliação de custo/benefício e validação de risco •

Priorizar os projetos verificando seu valor de negócio contra o custo de entregá-los

•

Determinar o benefício líquido de todos os BCSs entregues pelos projetos

•

Verificar que os riscos foram efetivamente mitigados e considerados

•

Conseguir o consenso para criar uma lista priorizada de projetos que proverá uma base para alocação de recursos

Slide 825

o 5: Confirmar o Roap de Arquitetura e atualizar o Documento de Definição de Arquitetura •

Atualizar o Roap de Arquitetura incluindo quaisquer Arquiteturas de Transição –

– –

•

Rever o trabalho até o momento para avaliar qual deve ser o período de tempo entre as Arquiteturas de Transição, levando em consideração os acréscimos no valor do negócio, capacidade e outros fatores, como o risco Uma vez que os incrementos de capacidade sejam finalizados, consolidar os entregáveis por projeto Uma Tabela de Evolução de Estado de Transição da Arquitetura pode ser usada para mostrar o estado proposto das arquiteturas

Se a abordagem de implementação mudou após confirmar os incrementos de implementação, o Documento de Definição de Arquitetura deve ser atualizado.

Slide 826

o 6: Gerar o Plano de Implementação e Migração • • •

•

Integrar todos os projetos e atividades, bem como dependências e impacto de mudanças em um plano de projeto Quaisquer Arquiteturas de Transição atuarão como marcos de portfolio Todas as dependências externas devem ser capturadas e incluídas, e a disponibilidade geral dos recursos deve ser avaliada Planos de projetos podem ser incluídos no Plano de Implementação e Migração

Slide 827

o 7: Completar o Ciclo de Desenvolvimento da Arquitetura e Documentar Lições Aprendidas • •

Este o transfere a governança do desenvolvimento da arquitetura para a realização da arquitetura As lições aprendidas durante o desenvolvimento da arquitetura devem ser documentadas e capturadas pelo processo de governança adequado na Fase H como entradas para a gerenciar a Capacidade da Arquitetura

Slide 828

Saídas da Fase F • •

Plano de Implementação e Migração (detalhado) Documento de Definição da Arquitetura Finalizado, incluindo: – Arquiteturas de Transição Finalizadas, se houver

• • • •

• • Slide 829

Especificação de Requisitos da Arquitetura Finalizada Roap de Arquitetura Finalizado BCAs Reusáveis Requisições para Trabalho de Arquitetura para uma nova iteração do (se houver) Modelo de Governança da Implementação Solicitações de Mudança

Phase F Fase F Planejamento da Migração

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 833of

18

Módulo 26 Fase G Governança da Implementação Edição V9.1 Copyright © 2009-2011A

Slide 834of

19

Todos os direitos reservados Publicado por The Open Group, 2011

Phase G Fase G Governança da Implementação

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 835of

19

Abordagem • •

•

A Fase G relaciona a arquitetura com a implementação através do Contrato de Arquitetura A informação para um gerenciamento de projetos de sucesso deve agregada O desenvolvimento acontece em paralelo com a Fase G

Slide 838

Abordagem • Estabelecer um programa de implementação que permitirá a entrega das Arquiteturas de Transição acordadas para a implementação durante a fase de Planejamento da Migração • Adotar um cronograma de implantação gradual que reflita as prioridades de negócio incorporadas no Roap de Arquitetura • Seguir o padrão da organização para governança corporativa, de TI e de arquitetura • Usar a abordagem de gerenciamento de portfolio/programa estabelecida da organização, quando houver • Definir um framework de operações para garantir efetivamente uma vida longa para a solução implantada Slide 839

Abordagem •

Estabelecer a conexão entre a arquitetura e a organização de implementação através do Contrato de Arquitetura

•

Detalhes dos projetos são desenvolvidos incluindo: – – – – –

Slide 840

Nome, descrição, e objetivos Escopo, entregáveis, e restrições Medidas de efetividade Critérios de aceite Risco e problemas

Fase G: Entradas • Requisição para Trabalho de Arquitetura • Avaliação de Capacidade • Modelo Organizacional para a Arquitetura Corporativa • Framework de Arquitetura adaptado • Declaração de Trabalho de Arquitetura • Visão da Arquitetura • Repositório de Arquitetura • Documento de Definição de Arquitetura Continua Slide 841

Fase G: Entradas • Especificação de Requisitos de Arquitetura • Roap de Arquitetura • Modelo de Governança da Implementação • Contrato de Arquitetura • Requisição para Trabalho de Arquitetura proveniente das Fases E e F • Plano de Implementação e Migração

Slide 842

os 6. Fazer revisão pós-implementação; fechar a implementação 5. Implementar operações de TI e Negócio 4. Executar Avaliações de Conformidade

3. Orientar o desenvolvimento de soluções para implantação 2. Identificar os recursos e habilidades para implantação 1. Confirmar o escopo e as prioridades para a implantação com a gerência do desenvolvimento

Slide 843

o 1: Confirmar o escopo e prioridades • • •

• • •

Revisar saídas do planejamento da migração e produzir recomendações para a implantação Identificar as prioridades de arquitetura corporativa para os times de desenvolvimento Identificar questões de implantação e fazer recomendações Identificar Blocos de Construção para substituição, atualização, etc. Executar análise de diferenças (gaps) no framework corporativo de arquitetura e soluções Produzir um relatório de análise de diferenças

Slide 844

o 2: Identificar os recursos e habilidades para implantação •

Identificar métodos de desenvolvimento de sistemas requeridos para o desenvolvimento das soluções

•

Garantir que o método de desenvolvimento dos sistemas forneça “” sobre os designs para o time de arquitetura

Slide 845

o 3: Orientar o desenvolvimento da implantação de soluções • • •

• • • • •

Formular recomendações aos projeto Documentar o Contrato de Arquitetura Atualizar o diretório do Continuum da Corporação e o repositório com as soluções Orientar o desenvolvimento de modelos operacionais de Negócio e TI para serviços Prover os requisitos de serviços derivados de EA Orientar a definição de requisitos operacionais de Negócio e TI Realizar análise de diferenças: Arquitetura da Solução versus Operações Produzir Plano de Implementação Slide 846

o 4: Executar Avaliações de Conformidade •

• •

Revisar a governança da implementação e a conformidade da arquitetura em andamento para cada Bloco de Construção (BC) Conduzir revisões de pós-desenvolvimento Concluir a parte de desenvolvimento dos projetos de implantação

Slide 847

o 5: Implementar operações de Negócio e TI •

Executar projetos de implantação, incluindo: implementação de entrega de serviços de TI; implementação de entrega de serviços de Negócio; implementação de desenvolvimento de habilidades e treinamento; publicação de documentação de comunicação

•

Publicar uma nova Arquitetura de Linha de Base no Repositório de Arquitetura e atualizar outros repositórios, como o repositório de gerenciamento de configuração operacional

Slide 848

o 6: Fazer revisão pós-implementação, fechar a implementação • •

Conduzir revisões de pós-implementação Publicar as revisões e fechar projetos

Slide 849

Phase G - Saídas • • • •

Contrato de Arquitetura (assinado) Avaliações de conformidade Solicitações de Mudança Soluções aderentes à Arquitetura implantadas, incluindo: – – – – – – – –

Sistema Implementado Repositório de Arquitetura populado Recomendações e dispensas Requisitos de entrega de serviço Métricas de performance SLAs Visão da Arquitetura Documento de Definição de Arquitetura – Arquitetura de Transição – Modelos operacionais de Negócio e de TI

Slide 850

Phase G Fase G Governança da Implementação

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 854of

19

Módulo 27 Fase H Gerenciamento de Mudanças na Arquitetura Edição V9.1 Copyright © 2009-2011

Slide 855of

28

Todos os direitos reservados Publicado por The Open Group, 2011

Phase H Fase H Gerenciamento de Mudanças na Arquitetura

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 856of

28

Fase H: Objetivos • Garantir que o ciclo de vida da arquitetura é mantido • Garantir que o Framework de Governança de Arquitetura seja executado • Garantir que as Capacidades da Arquitetura da Corporação atendam aos requisitos atuais

Slide 858

Abordagem •

•

O objetivo de um processo de Gerenciamento de Mudanças na Arquitetura é garantir que a arquitetura alcance seu alvo original gerando valor de negócio. Isto pode ser feito: 1. Garantindo que mudanças na arquitetura sejam gerenciadas adequadamente 2. Dando e a uma arquitetura dinâmica

•

O processo determinará as circunstâncias sob as quais: 1. A arquitetura poderá mudar após a implantação, e o processo para isto. 2. O será usado novamente.

Slide 859

Exercício: Motivadores para Mudança na Arquitetura 1. Faça um “brainstorm” e relate o maior número de motivadores de tecnologia para mudança que você conseguir.

2. Faça um “brainstorm” e relate o maior número de exemplos de motivadores de negócio para mudança que você conseguir.

Slide 860

Processo de Gerenciamento de Mudanças Há três principais categorias de mudanças da arquitetura: 1. Simplificação: pode ser tratada via técnicas de gerenciamento de mudanças 2. Incremental: pode ser tratada via técnicas de gerenciamento de mudanças, ou pode requerer uma rearquitetura parcial 3. Re-arquitetura: requer ar toda a arquitetura pelo ciclo de desenvolvimento de arquitetura novamente. Exercício: por quê cada uma destas mudanças podem ocorrer? Slide 861

Processo de Gerência de Mudança Para determinar se uma mudança é simplificação, incremental ou re-arquitetura: 1. Registre todos os eventos que possam impactar a arquitetura 2. Aloque recursos e gerenciamento para as tarefas de arquitetura 3. O processo (ou papel) responsável pelos recursos deve fazer uma avaliação do que precisa ser feito 4. Avalie o impacto

Slide 862

Manutenção versus Redesenho Se a mudança: • Impacta 2 partes interessadas ou mais, então é provável que necessite de um redesenho de arquitetura e uma reentrada no • Impacta apenas 1 parte interessada, então é provável ser um candidato para gerenciamento de mudanças • Pode ser permitida através de uma dispensa, então é provável ser uma candidata a gerenciamento de mudanças

Slide 863

Exercício de Impacto de Mudança Q. Determinar o impacto da mudança dos seguintes cenários: 1. O impacto da mudança é significante para a estratégia de Negócio. 2. Surge uma nova tecnologia ou padrão. 3. A mudança é no nível da infraestrutura. Por exemplo, 10 sistemas foram reduzidos para um sistema. 4. A Arquitetura de Fundação precisa ser realinhada com a estratégia de negócio. 5. Uma mudança substancial é necessária nos componentes e diretrizes para uso na implantação da arquitetura.

Slide 864

Fase H: Entradas • Requisição para Trabalho de Arquitetura • Modelo Organizacional para Arquitetura Corporativa • Framework de Arquitetura adaptado • Declaração de Trabalho de Arquitetura • Visão da Arquitetura • Repositório de Arquitetura • Documento de Definição de Arquitetura • Especificação de Requisitos da Arquitetura Continua Slide 865

Fase H: Entradas • Roap de Arquitetura

• Solicitações de Mudança (originadas de mudanças de tecnologia, mudanças de negócio, lições aprendidas) • Modelo de Governança da Implementação • Contrato de Arquitetura

• Avaliação de Conformidade • Plano de Implementação e Migração

Slide 866

Solicitações de Mudança • Descrição da mudança proposta • Justificativa para a mudança proposta • Avaliação de impacto da mudança proposta, incluindo: – – – – – –

Referência a requisitos específicos Prioridade de requisitos, até a data, das partes interessadas Fases a serem revisitadas Fase que irá liderar a priorização de requisitos Resultados das investigações das fases e prioridades revistas Recomendações sobre o gerenciamento dos requisitos

• Número de referência no repositório

Slide 867

os 7. Ativar o processo para implementar a Mudança 6. Gerenciar Processo de Governança 5. Desenvolver Requisitos de Mudança para atender aos objetivos de performance 4. Fornecer Análise para o Gerenciamento de Mudanças de Arquitetura 3. Gerenciar Riscos 2. Implantar Ferramentas de Monitoração

1. Estabelecer o processo de Realização de Valor

Slide 868

o 1. Estabelecer o processo de Realização de Valor • Influenciar projetos de negócio a explorar a arquitetura corporativa para realização de valor (resultados)

Slide 869

o 2. Implantar Ferramentas de Monitoração • Monitorar mudanças de tecnologia que podem impactar a Arquitetura de Linha de Base • Monitorar mudanças no negócio que podem impactar a Arquitetura de Linha de Base • Rastreamento de valor do negócio; ex.: o método de avaliação de investimento para determinar métricas de valor para os objetivos do negócio • Monitorar a maturidade da capacidade da Arquitetura Corporativa • Acompanhar e avaliar os programas de gestão de ativos • Acompanhar o desempenho e uso de QoS (Quality of Service) • Determinar e acompanhar os requisitos de continuidade de negócio Slide 870

o 3. Gerenciar Riscos • Gerenciar os riscos da arquitetura corporativa e fornecer recomendações • Ver Capítulo 31 Gerenciamento de Riscos

Slide 871

o 4. Fornecer Análise para o Gerenciamento de Mudanças na Arquitetura • Analisar a performance • Conduzir revisões de performance da arquitetura corporativa com o gerenciamento de serviços • Avaliar Solicitações de Mudança e relatórios para garantir que a realização de valor e o SLA esperado pelos clientes foram alcançados • Realizar uma análise de diferenças do desempenho da arquitetura corporativa • Garantir que solicitações de gerenciamento de mudanças sejam aderentes à governança e ao framework da arquitetura corporativa Slide 872

o 5. Desenvolver Requisitos de Mudança para atender aos objetivos de Performance • Fazer recomendações sobre os requisitos de mudança – Para atender aos requisitos de performance – Para desenvolver uma posição para agir

Slide 873

o 6. Gerenciar o Processo de Governança • Organizar reuniões do Comitê de Arquitetura (ou outro Comitê de Governança) • Realizar reuniões do Comitê de Arquitetura com o foco em como lidar com as mudanças (tecnologia, negócio e dispensas)

Slide 874

o 7. Ativar o Processo para Implementar a Mudança • Produzir uma nova Requisição para Trabalho de Arquitetura e pedido de investimento • Garantir que quaisquer mudanças implementadas nesta fase sejam capturadas e documentadas no Repositório de Arquitetura

Slide 875

Saídas de Fase H • Atualizações da Arquitetura • Mudanças no framework de arquitetura e nos princípios • Nova Requisição para Trabalho de Arquitetura, para iniciar outro ciclo do • Declaração de Trabalho de Arquitetura • Contrato de Arquitetura • Avaliações de Conformidade

Slide 876

Contrato de Arquitetura dos Usuários de Negócio • • • • • • • • •

Introdução e background A natureza do acordo Escopo Requisitos estratégicos Requisitos de conformidade Adotantes da Arquitetura Janela de tempo Métricas de negócio da arquitetura Arquitetura de serviço (Inclui Acordo de Nível de Serviço (SLA)) Slide 877

Requisição para Trabalho de Arquitetura • Patrocinadores da organização • Declaração da missão da organização • Objetivos de Negócio (e mudanças) • Planos estratégicos do negócio • Limites de tempo • Mudanças no ambiente de negócio • Restrições organizacionais • Informação de orçamento, restrições financeiras Slide 878

• Restrições externas, restrições de negócio • Descrição atual do sistema de negócio • Descrição atual do sistema de arquitetura/TI • Descrição da organização de desenvolvimento • Descrição de recursos disponíveis para a organização de desenvolvimento

Phase H Fase H Gerenciamento de Mudanças na Arquitetura

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 882of

28

Módulo 28 Gerenciamento de Requisitos de Arquitetura do Edição V9.1 Copyright © 2009-2011

Slide 883of

21

Todos os direitos reservados Publicado por The Open Group, 2011

Gerenciamento de Requisitos de Arquitetura do

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 884of

21

Gerenciamento de Requisitos do O Processo de gerenciar requisitos de arquitetura: – Se aplica a todas as fases do ciclo do

– É central para o processo do – É um processo dinâmico, abordando a identificação dos requisitos, o seu armazenamento e entrega para as fases

Slide 886

Abordagem •

• •

•

A habilidade de lidar com as mudanças nos requisitos é crucial para o processo do considerando que arquitetura lida com incertezas e mudanças. Arquitetura faz a ligação entre as aspirações das partes interessadas e uma solução prática. O processo de Gerenciamento de Requisitos não elimina, endereça ou prioriza os requisitos, isto é feito dentro das fases relevante da . É recomendado que um Repositório de Requisitos seja usado para registrar e gerenciar todos o requisitos de arquitetura. Slide 888

Desenvolvimento de Requisitos • Os primeiros requisitos de alto nível são desenvolvidos na Visão da Arquitetura • Para cada fase do , desde a Preliminar até a Fase H – Selecione os requisitos aprovados para a fase da forma em que está guardado no Repositório de Requisitos e na Especificação de Requisitos de Arquitetura – Ao completar a fase os estados de todos os requisitos devem ser atualizados

• Durante a execução das Fases – Novos requisitos gerados para trabalhos futuros de arquitetura dentro do escopo da atual Declaração de Trabalho de Arquitetura precisam ser documentados dentro da Especificação de Requisitos de Arquitetura – Novos requisitos, os quais estão fora do escopo da atual Declaração de Trabalho de Arquitetura precisam ser alimentados no Repositório de Requisitos para gerenciamento através do processo de Gerenciamento de Requisitos.

Slide 889

Recursos • O TOGAF especifica as necessidades genéricas para requisitos, não processos ou ferramentas específicas • É recomendado o uso de – Cenários de Negócio – Ferramentas de prateleira

Slide 890

Modelo de Especificação de Requisitos Volère • •

Este é um exemplo de modelo adequado de requisitos A “Sala de Espera” (Waiting Room) – Este é um repositório para requisitos que estão além do escopo planejado, ou do tempo disponível, para a iteração atual. A habilidade de armazenar requisitos futuros ajuda a evitar a percepção que eles simplesmente são descartados, enquanto ao mesmo tempo ajuda a gerenciar as expectativas sobre o que será entregue.

Slide 891

Gerenciamento de Requisitos: Entradas • Saídas relacionadas a requisitos de cada fase do • Os primeiros requisitos de alto nível são produzidos como parte da Visão da Arquitetura • Cada domínio de arquitetura então produz requisitos detalhados

• Entregáveis em fases posteriores do contém mapeamentos para novos tipos de requisitos

Slide 892

Visão Geral dos os os do Gerenciamento de Requisitos

os das Fases do 1. Identificar/documentar requisitos

2. Criar a linha de base dos requisitos 3. Monitorar requisitos de linha de base 4. Identificar requisito alterado

5. Identificar requisito alterado e registrar a prioridade 8. Atualizar o Repositório de Requisitos com as informações relacionadas às mudanças solicitadas, incluindo as visões afetadas das partes interessadas

6. Avaliar impacto da mudança 7. Implementar mudanças levantadas na Fase H 9. Implementar a mudança na fase atual 10. Avaliar e revisar a análise de diferenças para as fases anteriores

Slide 893

os em Detalhe 1. Identificar/documentar requisitos (o das Fases do ) •

Use Cenários de Negócio ou técnica semelhante

2. Criar a linha de base dos requisitos (o de Gerenciamento de Requisitos)

1. Determinar as prioridades levantadas na fase atual do 2. Confirmar a aceitação das prioridades resultantes pelas partes interessas 3. Registrar as prioridades e armazenar no Repositório de Requisitos

3. Monitorar os requisitos de linha de base (o de Gerenciamento de Requisitos)

Slide 894

os em Detalhe 4. Identificar requisito alterado (o das Fases do ) 1. Remover ou reavaliar prioridades 2. Adicionar requisitos e reavaliar prioridades 3. Modificar requisitos existentes

5. Identificar requisitos alterados e registrar prioridades

(o

de Gerenciamento de Requisitos)

1. Identificar requisitos alterados e garantir que os requisitos foram priorizados pelos arquitetos e pelas partes interessadas 2. Registrar novas prioridades 3. Garantir que quaisquer conflitos foram identificados e gerenciados ao longo das fases para uma conclusão e priorização de sucesso 4. Gerar Declaração de Impacto de Requisitos para orientar a equipe de arquitetura Slide 895

os em Detalhe 6. Avaliar o impacto dos requisitos alterados em (o das Fases do )

1. Fase atual 2. Fases anteriores 3. Decidir se: • •

Implementa-se a mudança (necessita de agendamento para implementação de gerenciamento de mudanças) Deferir para um ciclo futuro do

4. Emitir uma nova versão da Declaração de Impacto de Requisitos

7. Implementar os requisitos levantados na Fase H (Gerenciamento de Mudanças na Arquitetura) (o das Fases do )

•

Slide 896

A arquitetura pode ser mudada ao longo de seu ciclo de vida até a Fase H. O processo de Gerenciamento de Requisitos garante que requisitos novos ou alterados sejam gerenciados apropriadamente

os em Detalhe 8. Atualizar o Repositório de Requisitos com a informações relacionadas às mudanças solicitadas, incluindo as visões das partes interessadas afetadas (o de Gerenciamento de Requisitos)

9. Implementar a mudança na fase atual (o das Fases do ) 10. Avaliar e revisar a análise de diferenças para as fases anteriores (o das Fases do ) – Se a análise de diferenças gerar requisitos de diferença, então este o garantirá que eles sejam abordados, documentados, e registrados no repositório de requisitos, e que a Arquitetura Alvo será apropriadamente revisada

Slide 897

Gerenciamento de Requisitos: Saídas • Especificação de Requisitos da Arquitetura atualizada • Declaração de Impacto dos Requisitos

Slide 898

Avaliação de Impacto de Requisitos • Quando novos requisitos surgem, ou existentes são alterados, uma Declaração de Impacto de Requisitos é gerada • Ela identifica as fases do que precisam ser revisitadas para endereçar as mudanças • A declaração a através de várias iterações até a versão final, a qual inclui todas as implicações dos requisitos (exemplo: custos, escalas de tempo, e métricas de negócio) no desenvolvimento da arquitetura • Uma vez que os requisitos para o ciclo atual do tenham sido finalizados, a Especificação de Requisitos da Arquitetura precisará ser atualizada Slide 899

Gerenciamento de Requisitos de Arquitetura do

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 903of

21

Módulo 29

Particionamento da Arquitetura Edição V9.1 Copyright © 2009-2011

Slide 904of

26

Todos os direitos reservados Publicado por The Open Group, 2011

Particionamento da Arquitetura

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 905of

26

Roap Parte I - Introdução Prefácio, Visão global executiva, Principais Conceitos, Definições e Notas da Versão

Parte II – Método de Desenvolvimento da Arquitetura Introdução ao Narrativas das Fases do

Parte III – Orientações e Técnicas do Orientações para Adaptação do Processo do Técnicas para o Desenvolvimento da Arquitetura

Parte IV – Framework de Conteúdo da Arquitetura Metamodelo de Conteúdo Artefatos Arquiteturais Entregáveis da Arquitetura Blocos de Construção

Parte V – Continuum da Corporação e Ferramentas Continuum da Corporação Particionamento da Arquitetura Repositório da Arquitetura Ferramentas para o Desenvolvimento da Arquitetura

Parte VI – Modelos de Referência do TOGAF Arquitetura de Fundação: Modelo de Referência Técnico Modelo de Referência da Infraestrutura Integrada da Informação

Parte VII – Framework de Capacidade da Arquitetura Comitê de Arquitetura Aderência da Arquitetura Contratos da Arquitetura Governança da Arquitetura Modelos de Maturidade da Arquitetura Frameworks de Competências da Arquitetura

Slide 907

• Capítulo 40 na Parte V, Continuum da Corporação e Ferramentas

Particionamento

Permite o gerenciamento de custos e complexidade, dividindo a Corporação e atribuindo papéis e responsabilidades apropriadas para cada partição Slide 908

A Necessidade de Particionar • • • •

Gerenciar Complexidade Gerenciar Conflitos Gerenciar Desenvolvimentos Paralelos Gerenciar Reuso

Slide 909

Aplicando uma Classificação à Arquiteturas Particionadas: Particionamento de Solução • Assunto (Abrangência) – Seu conteúdo, estrutura e função

• Tempo – Todas as soluções existem por um período de tempo

• Maturidade/Volatilidade – A extensão na qual o assunto e o ambiente de uma solução tem probabilidade de mudar ao longo do tempo

Slide 910

Aplicando uma Classificação à Arquiteturas Particionadas: Particionamento da Arquitetura • Profundidade (Nível de Detalhe) – O nível de detalhe tem uma forte correlação com os grupos de partes interessadas – Tipicamente, arquiteturas com menos detalhes são de interesse para as partes interessadas de nível executivo – Conforme as arquiteturas aumentam em detalhes, sua relevância para a implementação e para o pessoal operacional aumenta

Slide 911

Aplicando o Particionamento ao • A Fase Preliminar dá e à identificação de partições de arquitetura adequadas e o estabelecimento de relações de governança entre as partições de arquitetura que se relacionam.

Slide 912

Fase Preliminar • Determinar a estrutura da organização para a arquitetura dentro da corporação – Identificar as equipes

• Determinar as responsabilidades para cada equipe de arquitetura – – – –

Áreas de assuntos Nível de detalhes Período de tempo Partes interessadas

• Determinar o relacionamento entre as arquiteturas – Onde as arquiteturas se sobrepõem? – Quais são os requisitos de conformidade entre as arquiteturas? Slide 913

Exemplo de Equipe Alocadas

Slide 914

Particionamento da Arquitetura

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 916of

26

Módulo 30 Adaptando o : Iterações e Níveis Edição V9.1 Copyright © 2009-2011

Slide 917of

29

Todos os direitos reservados Publicado por The Open Group, 2011

Adaptando o : Iterações e Níveis

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 918of

29

Roap Parte I - Introdução Prefácio, Visão global executiva, Principais Conceitos, Definições e Notas da Versão

Parte II – Método de Desenvolvimento da Arquitetura Introdução ao Narrativas das Fases do

Parte III – Orientações e Técnicas do Orientações para Adaptação do Processo do Técnicas para o Desenvolvimento da Arquitetura

Parte IV – Framework de Conteúdo da Arquitetura Metamodelo de Conteúdo Artefatos Arquiteturais Entregáveis da Arquitetura Blocos de Construção

Parte V – Continuum da Corporação e Ferramentas Continuum da Corporação Particionamento da Arquitetura Repositório da Arquitetura Ferramentas para o Desenvolvimento da Arquitetura

Parte VI – Modelos de Referência do TOGAF Arquitetura de Fundação: Modelo de Referência Técnico Modelo de Referência da Infraestrutura Integrada da Informação

Parte VII – Framework de Capacidade da Arquitetura Comitê de Arquitetura Aderência da Arquitetura Contratos da Arquitetura Governança da Arquitetura Modelos de Maturidade da Arquitetura Frameworks de Competências da Arquitetura

Slide 919

• Parte III, Orientações e Técnicas, Capítulos 19 e 20

Iterações e Níveis

Slide 921

Iterações e o • O a uma quantidade de conceitos que podem ser caracterizados como iteração: • Iterações para descrever um Panorama de Arquitetura compreensível ao longo de múltiplos ciclos do baseados em iniciativas individuais ligadas ao escopo da Requisição para Trabalho de Arquitetura • Iterações para descrever o processo integrado de desenvolvimento de uma arquitetura onde as atividades descritas nas diferentes fases do interagem produzindo uma arquitetura integrada • Iterações para descrever o processo de gerenciamento de mudanças na Capacidade de Arquitetura da organização

Slide 922

Iteração para desenvolver um Panorama de Arquitetura abrangente •

Os projetos exercitarão ao longo do ciclo de inteiro, começando com a Fase A. – Cada ciclo do é conectado por uma Requisição para Trabalho de Arquitetura – A saída preenche o Panorama de Arquitetura, estendendo ou mudando o panorama

•

•

Projetos separados podem operar seus próprios ciclos do concorrentemente com relacionamentos entre eles. Um projeto pode deflagrar o início de outro projeto.

Slide 923

Iteração dentro de um Ciclo do • Os projetos podem operar múltiplas Fases do concorrentemente – Tipicamente seu uso é para gerenciar a inter-relação entre a Arquitetura de Negócio, Arquitetura de Sistemas de Informação e Arquitetura Tecnológica

• Os projetos podem circular entre as fases para convergir em uma Arquitetura Alvo • Os Projetos podem retornar para fases anteriores visando atualizar produtos de trabalho com a nova informação Slide 924

Iterações para Gerenciar a Capacidade da Arquitetura •

•

Os projetos podem necessitar uma nova iteração da Fase Preliminar para estabelecer aspectos da Capacidade da Arquitetura identificados na Fase A endereçando assim uma Requisição para Trabalho de Arquitetura Os projetos podem necessitar de uma nova iteração da Fase Preliminar para ajustar a Capacidade de Arquitetura da organização como um resultado de requisitos novos ou alterados, resultado de uma solicitação de mudança na Fase H

Slide 925

Fatores que influenciam o uso de Iteração • A formalidade e a natureza dos pontos de controle estabelecidos na organização • O nível de envolvimento das partes interessadas no processo • A quantidade de equipes envolvidas e o relacionamento entre as diferentes equipes • A maturidade da área de solução e o retrabalho esperado para se chegar a uma solução aceitável • Atitude perante ao risco

Slide 926

Iterações de Capacidade da Arquitetura am a criação e evolução de uma Capacidade de Arquitetura

Iterações de Desenvolvimento da Arquitetura am a criação e a evolução de conteúdo de arquitetura por rodar através das fases B, C, e D

Ciclos de Iteração

Iterações de Governança de Arquitetura am a governança da atividade de mudança

Iterações de Planejamento de Transição am a criação de roaps de mudanças formais Slide 927

Conforme as iterações vão convergindo para um alvo, as extensões dentro das Fases E e F garantem que a viabilidade de implementação seja considerada

Abordagens para o Desenvolvimento da Arquitetura • Linha de Base Primeiro – Uma avaliação do panorama de linha de base é usado para identificar áreas de problemas e oportunidades de melhoria – Esta é uma abordagem adequada para quando a linha de base for complexa ou não for claramente entendida

• Alvo Primeiro – A solução alvo é elaborada em detalhes e então mapeada de volta para a linha de base – Esta é uma abordagem indicada para quando o estado alvo for acordado em alto nível e onde a corporação deseje efetivamente migrar para este modelo alvo

Slide 928

Classes de Engajamento da Arquitetura • O TOGAF define três áreas típicas de engajamento: – Identificação de Mudança Necessária – Definição da Mudança – Implementação da Mudança

Slide 929

Classes de Engajamento da Arquitetura

Slide 930

Foco de Iteração para Classes de Engajamento de Arquitetura (Extrato) Engajamento e a Estratégia de Negócio

Foco de Iteração Capacidade de Arquitetura Desenvolvimento da Arquitetura (Linha de Base Primeiro)

Gerenciamento Arquitetural de Portifólio do Panorama

Capacidade da Arquitetura

Gerenciamento Arquitetural de Portfólio de Projetos

Planejamento de Transição

Slide 931

Desenvolvimento da Arquitetura (Linha de Base Primeiro)

Governança da Arquitetura

Escopo Considerações amplas, rasas, dadas ao Panorama da Arquitetura, visando atender questões estratégicas específicas e definir termos para um esforço de arquitetura mais detalhado endereçando uma realização estratégica. Foco na avaliação física de aplicações da linha de base e da infraestrutura tecnológica para identificar oportunidades de melhoria, tipicamente dentro das restrições de manter o negócio como de costume (BAU). Foco nos projetos, dependências dos projetos, e impacto do panorama para alinhar a sequência de projetos de uma forma que seja arquiteturalmente otimizada.

Considerações sobre Iterações • Iterações entre os ciclos do – Adequado quando uma arquitetura de nível superior orienta e restringe outra arquitetura mais detalhada – Esta abordagem utiliza a Fase de Planejamento da Migração de um ciclo de para iniciar novos projetos que também irão desenvolver arquiteturas – É um método para desenvolver um panorama de arquitetura completo em múltiplas iterações

Slide 932

Uma Hierarquia de Processos do

Slide 933

Iterações dentro do Ciclo do – Linha de Base Primeiro

Slide 934

Iterações dentro do Ciclo do – Alvo Primeiro

Slide 935

Iteração de Desenvolvimento da Arquitetura “Linha de Base Primeiro” • Iteração 1 – Definir a Arquitetura de Linha de Base

• Iteração 2 – Definir a Arquitetura Alvo e diferenças (gaps)

• Iteração n – Refinar a Arquitetura de Linha de Base, Arquitetura Alvo, e diferenças

Slide 936

Iteração de Desenvolvimento da Arquitetura “Alvo Primeiro” • Iteração 1 – Definir a Arquitetura Alvo

• Iteração 2 – Definir a Arquitetura de Liha de Base e diferenças (gaps)

• Iteração n – Refinar a Arquitetura de Linha de Base, Arquitetura Alvo, e diferenças

Slide 937

Planejamento de Transição • Iteração 1 – Definir e acordar um conjunto de oportunidades de melhoria alinhadas com uma Arquitetura de Transição provisória

• Iteração n – Acordar a Arquitetura de Transição, refinando as oportunidades de melhorias identificadas

Slide 938

Governança da Arquitetura • Iteração 1 – Mobilizar a governança da arquitetura e os processos de genreciamento de mudança

• Iteração n – Realizar a governança de arquitetura e de controle de mudanças

Slide 939

A Arquitetura Estratégica fornece um framework organizado para a atividades operacionais e de mudança e permite o estabelecimento de direção no nível de execução

Aplicando o Através do Panorama da Arquitetura

Arquitetura de Segmento fornece um framework organizado para a atividade operacional e de mudança e permite o estabelecimento de direção e o desenvolvimento de roaps de arquitetura eficazes no nível dos programas ou portfólio

A Arquitetura de Capacidade fornece um framework organizado para a atividade de mudança e desenvolvimento de eficazes roaps de arquitetura realizando incrementos de capacidade Slide 940

Aplicando o ao Longo do Panorama da Arquitetura (continuação)

Slide 941

Organizando o Panorama da Arquitetura • As seguintes características podem ser usadas para organizar o Panorama da Arquitetura – – – –

Abrangência (assunto) Profundidade Tempo Recência (caráter recente)

Slide 942

Adaptando o : Iterações e Níveis

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 945of

29

Módulo 31 Adaptando o : Segurança V9.1 Edition Copyright © January 2009

Slide 946of 31

All rights reserved Published by The Open Group, January 2009

Adaptando o : Segurança

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 947of 31

TM

Roap Parte I - Introdução Prefácio, Visão global executiva, Principais Conceitos, Definições e Notas da Versão

Parte II – Método de Desenvolvimento da Arquitetura Introdução ao Narrativas das Fases do

Parte III – Orientações e Técnicas do Orientações para Adaptação do Processo do Técnicas para o Desenvolvimento da Arquitetura

Parte IV – Framework de Conteúdo da Arquitetura Metamodelo de Conteúdo Artefatos Arquiteturais Entregáveis da Arquitetura Blocos de Construção

Parte V – Continuum da Corporação e Ferramentas Continuum da Corporação Particionamento da Arquitetura Repositório da Arquitetura Ferramentas para o Desenvolvimento da Arquitetura

Parte VI – Modelos de Referência do TOGAF Arquitetura de Fundação: Modelo de Referência Técnico Modelo de Referência da Infraestrutura Integrada da Informação

Parte VII – Framework de Capacidade da Arquitetura Comitê de Arquitetura Aderência da Arquitetura Contratos da Arquitetura Governança da Arquitetura Modelos de Maturidade da Arquitetura Frameworks de Competências da Arquitetura

Slide 948

• Parte III, Orientações e Técnicas do , Capítulo 21

Segurança e o • O TOGAF introduz orientações para ajudar os profissionais a evitar o esquecimento de preocupações críticas de segurança • As orientações não tem a intenção de ser uma metodologia de desenvolvimento de arquitetura de segurança • Elas se propõem a informar ao Arquiteto Corporativo sobre as tarefas e papeis da arquitetura de segurança • Foram desenvolvidos objetivos de segurança para cada fase do

Slide 950

Características da Arquitetura de Segurança • • • • • •

Ela tem sua própria metodologia de segurança Ela compõe seus próprios pontos de vista e visões distintas Ela atende a fluxos não normativos Ela introduz seu próprio fluxo normativo único Introduz componentes únicos, de propósito único no design Ela exige um conjunto único de habilidades do arquiteto corporativo

Slide 951

Preocupações das Partes Interessadas Executive

Executive

Line Management

IT Service Business Management Domain Experts

Programme Management Office

Autenticação Autorização Auditoria Confiabilidade Disponibilidade Proteção de Ativos istração Gestão de Riscos

Line Management

HR

CxO

Functional / Business Process Experts

Application Management

Infrastructure Management

Data / Voice Communications

Stakeholder Types

Corporate

Slide 952

System

End -

Project

QA / Standards Groups

Product Specialists

Enterprise Security

Technical Specialists

Procurement

Artefatos de Segurança Típicos • Regras de Negócio em relação ao manuseio de ativos de dados / informação • Políticas de segurança escritas e publicadas • Propriedade e custódia de ativos de dados / informações codificados • Documentação de análise de risco • Documentação de política para classificação de dados

Slide 953

O do TOGAF

Slide 954

Gerenciamento de Requisitos do • Políticas de Segurança e Normas de Segurança se tornam parte do processo de gerenciamento de requisitos • Novos requisitos de Segurança surgem de várias origens: – Uma nova obrigação estatutária ou regulatória – Uma nova ameaça percebida ou experienciada – Uma nova iniciativa de arquitetura descobre novas partes interessadas com novos requisitos Slide 955de 31

Fase Preliminar • Demarcar as unidades organizacionais da corporação que serão impactadas pela arquitetura de segurança • Definir e documentar requisitos para políticas regulatórias e de segurança aplicáveis • Definir as capacidades de segurança requeridas como parte da Capacidade de Arquitetura • Implementar ferramentas de arquitetura de segurança Slide 956

Fase Preliminar – Entradas/Saídas • Entradas: – Política de Segurança escrita – Estatutos relevantes – Lista de jurisdições aplicáveis

Slide 957

• Saídas: – Lista de regulações aplicáveis – Lista de políticas de segurança aplicáveis – Lista da equipe de segurança – Lista de pressupostos de segurança e condições de contorno

Fase A Visão da Arquitetura • •

•

• •

Slide 958

Obter apoio gerencial para medidas de segurança Definir os marcos gerenciais necessários de aprovação de assuntos relacionados a segurança Determinar os requisitos de recuperação de desastres ou planos de continuidade de negócio aplicáveis Identificar antecipadamente o(s) ambiente(s) que o(s) sistema(s) será(ão) implantado(s) Determinar a criticidade do sistema: de Segurança Crítica/de Missão Crítica/Não Crítica

Fase A Visão da Arquitetura – Entradas/Saídas • Entradas – Lista de políticas de segurança aplicáveis – Lista de jurisdições aplicáveis – Planos completos de recuperação de desastres e de continuidade

Slide 959

• Saídas – Declaração de segurança física – Declaração de Segurança de Negócio – Declaração de Segurança regulatória – Carta com política de segurança assinada pelo CEO ou representante – Lista de checkpoints de desenvolvimento de arquitetura – Lista de planos de recuperação de desastre e de continuidade de negócio – Declaração de criticidade de sistemas

Fase B Arquitetura de Negócio •

•

•

• • • •

Determinar quem são os atores legítimos que irão interagir com o sistema Avaliar e criar uma linha de base de específica de segurança de processos de negócio Determinar quem / o quanto é aceitável transtornos em utilizar medidas de segurança: Identificar e documentar sistemas de interconexão além do controle do projeto Determinar os ativos em risco, se algo der errado Determinar o custo da perda de ativos Identificar e documentar a propriedade dos ativos

Continued Slide 960

Fase B Arquitetura de Negócio • •

•

• •

•

Slide 961

Determinar e documentar os processos de segurança forenses apropriados Identificar a criticidade da disponibilidade e da correta operação do serviço em geral Determinar e documentar o quanto de segurança (custo) é justificado pelas ameaças e valor dos ativos Reavaliar e confirmar as decisões da visão de arquitetura Avaliar o alinhamento ou conflito de políticas de segurança identificadas com os objetivos de Negócio Determinar "o que pode dar errado?"

Fase B: Arquitetura de Negócio – Entradas/Saídas • Entradas – Declarações de segurança iniciais de negócio e regulatória – Lista dos planos aplicáveis de recuperação de desastres e continuidade de negócio – Lista das políticas de segurança e regulamentações aplicáveis

Slide 962

•

Saídas – Lista de processos forenses – Lista de novos requisitos para recuperação de desastres e continuidade de negócio – Declarações dobre ambientes de negócio e regulatório validadas – Lista de políticas e regulamentações de segurança validada – Lista de processos de segurança alvos – Lista de processos de segurança de linha de base – Lista de atores da segurança – Lista de sistemas de interconexão – Declaração de tolerância de segurança para cada classe de atores da segurança – Lista de ativos com valores e propriedade – Lista de caminhos confiáveis – Declaração(ões) de impacto na disponibilidade – Matriz de análise de ameaça

Fase C Arquiteturas de Sistemas de Informação •

Avaliar e criar uma linha de base dos elementos específicos de segurança atuais

•

Identificar ações padrão de segurança e estados de falha

•

Identificar e avaliar diretrizes e padrões reconhecidamente aplicáveis

•

Revisitar suposições relacionadas a interconectar sistemas além do controle do projeto

•

Determinar e documentar o nível de sensibilidade ou classificação da informação armazenada / criada / usada

•

Identificar e documentar a custódia dos ativos

Continued

Slide 963

Fase C Arquiteturas de Sistemas de Informação • •

•

•

Identificar a criticidade da disponibilidade e a operação correta de cada função Determinar o relacionamento do sistema projetado com os planos de continuidade/desastre de negócio Identificar quais aspectos do sistema precisam ser configuráveis para refletir alterações nas políticas/ambiente de negócio/controle de o Identificar o tempo de vida das informações utilizadas, tal como definido pelas necessidades do negócio e requisitos regulamentares Continuação

Slide 964

Fase C Arquiteturas de Sistemas de Informação • Determinar formas de endereçar riscos identificados • Identificar ações / eventos que justifiquem registro para posterior análise ou desencadear processos forenses • Identificar e documentar requisitos rigorosos visando prover a precisão dos eventos registrados (não repúdio) • Identificar possíveis / prováveis caminhos de ataque • Determinar “O que pode dar errado?” Slide 965

Fase C: Arquiteturas de sistemas de Informação – Entradas / Saídas • Entradas

•

Saídas

– Matriz de análise de ameaças – Análise de risco Processos forenses documentados – Políticas de Negócio e regulamentos – – validados – Lista dos sistemas interconectados – – Recuperação de desastres e requisitos de continuidade de – negócio – – – – – – – – – –

Slide 966

Matriz em nível de log de eventos e requisitos Estratégia de gestão de risco Definições de dados de ciclo de vida Lista de elementos configuráveis do sistema Lista de linha de base de elementos relacionados a segurança do sistema Elementos novos ou agregados de elementos relacionados a segurança do sistema Modelos de casos de uso de segurança Lista de normas de segurança aplicáveis​​: Lista validada de sistemas interligados Relatório de classificação de informações Lista de guardiões de ativos Declaração de criticidade da função Planos revistos de desastre e recuperação e continuidade de negócio – Matriz refinada de análise de ameaça

Fase D Arquitetura Tecnológica •

•

•

• •

Slide 967

Avaliar e criar linha de base das tecnologias específicas de segurança atuais Revisitar pressupostos relacionados a interconexão de sistemas além do controle do projeto Identificar e avaliar padrões e diretrizes reconhecidamente aplicáveis Identificar métodos para regular o consumo de recursos Engendrar um método pelo qual a eficácia de medidas de segurança seja medida e comunicada de forma contínua Continuação

Fase D Arquitetura Tecnológica • Identificar o nível de confiança (depuração) aceitável para o sistema • Identificar os privilégios mínimos requeridos para qualquer entidade alcançar um objetivo técnico ou de negócio • Identificar medidas de mitigação de segurança, onde forem justificadas por uma avaliação de risco • Determinar "o que pode dar errado?" Slide 968

Fase D: Arquitetura Tecnológica – Entradas/Saídas • Entradas – Lista dos elementos do sistema relacionados com segurança – Lista dos sistemas interconectados – Lista de normas de segurança aplicáveis – Lista de agentes de segurança – Estratégia de gestão de risco – Políticas de segurança validadas – Requisitos regulamentares validados – Políticas de Negócio validadas relacionados com requisitos de confiança Slide 969

• Saídas – Lista básica de tecnologias de segurança – lista de sistemas interconectados validadas – lista de padrões de segurança selecionados – Plano de conservação de recursos – Métricas de segurança e plano de monitoração – Políticas de autorização de usuários – Plano de gerenciamento de risco – Requisitos de confiança de usuários (depuração)

Fase E Oportunidades e Soluções • Identificar os serviços de segurança existentes disponíveis para reutilização • Engendrar medidas de mitigação endereçando os riscos identificados • Avaliar software de segurança e recursos de segurança do sistema para que sejam testados e reutilizáveis • Identificar novos códigos/recursos/ativos que são apropriados para o reuso • Determinar “o que pode dar errado?” Slide 970

Fase F Plano de Migração •

•

•

•

•

Slide 971

Avaliar o impacto de novas medidas de segurança em novos componentes ou sistemas existentes Implementar métodos de garantia de que a eficácia das medidas de segurança será medida e comunicada de forma contínua Identificar os parâmetros corretos de instalação seguras, condições iniciais e configurações Implementar planos de desastre e recuperação e continuidade de negócio Determinar “O que pode dar errado?”

Fase G Governança da Implementação • Estabelecer revisões de projeto e de código • Implementar métodos e procedimentos para rever evidências reflitam a estabilidade operacional e aderência às políticas de segurança • Implementar treinamento necessário para garantir a correta implantação, configuração e operação • Determinar "o que deu errado?”

Slide 972

Fase H Gerenciamento de Mudança na Arquitetura • Determinar “o que deu errado?” • Incorporar as mudanças relevantes de segurança do ambiente nos requisitos para o aprimoramento futuro

Slide 973

Adaptando o : Segurança

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 976of 31

Módulo 32 Adaptando o : SOA V9.1 Edition Copyright © 2009-2011

Slide de 32 977

All rights reserved Published by The Open Group, 2011

Adaptando o : SOA

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide de 32 978

Roap Parte I - Introdução Prefácio, Visão global executiva, Principais Conceitos, Definições e Notas da Versão

Parte II – Método de Desenvolvimento da Arquitetura Introdução ao Narrativas das Fases do

Parte III – Orientações e Técnicas do Orientações para Adaptação do Processo do Técnicas para o Desenvolvimento da Arquitetura

Parte IV – Framework de Conteúdo da Arquitetura Metamodelo de Conteúdo Artefatos Arquiteturais Entregáveis da Arquitetura Blocos de Construção

Parte V – Continuum da Corporação e Ferramentas Continuum da Corporação Particionamento da Arquitetura Repositório da Arquitetura Ferramentas para o Desenvolvimento da Arquitetura

Parte VI – Modelos de Referência do TOGAF Arquitetura de Fundação: Modelo de Referência Técnico Modelo de Referência da Infraestrutura Integrada da Informação

Parte VII – Framework de Capacidade da Arquitetura Comitê de Arquitetura Aderência da Arquitetura Contratos da Arquitetura Governança da Arquitetura Modelos de Maturidade da Arquitetura Frameworks de Competências da Arquitetura

Slide 979

• Parte III, Orientações e Técnicas do , Capítulo 22

O que é Arquitetura Orientada a Serviços? • Um estilo de arquitetura que a a orientação a serviços • Estilo de Arquitetura – A combinação de descrições as quais demonstram como a arquitetura foi feita ou expressa.

• Orientação a Serviços – Uma maneira de se pensar em termos de serviços e desenvolvimento baseado em serviços e os resultados dos serviços.

Slide 981

O que é Arquitetura Orientada a Serviços? • Ela possui as seguintes características diferenciais: – É baseada no desenho dos serviços – A representação dos serviços utiliza descrições de negócio para prover o contexto e implementa serviços utilizando a orquestração destes – Coloca requisitos únicos na infraestrutura – As implementações são específicas do ambiente – são restritas ou habilitadas por contexto e devem ser descritas dentro deste contexto. – Requer uma elevada governança da representação e implementação do serviço. – Requer uma "Prova dos 9", que determina o que é um "bom serviço". Slide 982

A SOA como um Estilo de Arquitetura • Destina-se a simplificar o negócio – Incluindo a interoperação de partes do negócio • Permite a identificação de capacidades funcionais de uma organização • Pode ser utilizada para evitar a duplicação de capacidades similares ao longo de uma organização • Permite que aplicativos sejam estruturados de modo a facilitar a flexibilidade e a agilidade

Slide 983

Complexidades decorrentes da SOA • Cria um panorama de TI mais granular: – Centenas ou milhares de serviços para se gerenciar ao invés de dezenas ou centenas de aplicativos

• Novos pontos de são ressaltados: – Compreender as relações entre o portfólio de aplicativos e o portfólio de serviços – Definição de SLA, governança e gerenciamento de impacto – Rastrear Negócio para TI – Comunicação, alinhamento e semântica – Plataforma e interoperabilidade – Desempenho, visibilidade e otimização

Slide 984

Como a EA a a SOA • A arquitetura corporativa a a SOA provendo frameworks, ferramentas e técnicas • Os benefícios chave providos pela utilização da EA em SOAs incluem: – Abstrações consistentes de estratégias e entregáveis para ar o planejamento e a análise – Capacidade de relacionar perspectivas diferentes a um único problema de negócio, fornecendo um modelo consistente para tratar vários domínios e testes de completude – Identificação de roaps claros para se alcançar um estado futuro – Rastreabilidade que relaciona TI e outros ativos ao negócio que eles am – e à avaliação de impacto, análise de risco/valor e gerenciamento de portfólio – Princípios, restrições, frameworks, padrões e normas identificados e documentados – Frameworks e processos de governança que asseguram a autoridade necessária para a tomada de decisões Slide 985

Como a EA a a SOA (cont.) A arquitetura corporativa fornece a capacidade de contexto e análise para: – Mostrar como soluções de SOA podem ser arquitetadas eficazmente para ar as capacidades de negócio – Mostrar quais serviços devem ser construídos e quais devem ser reutilizados – Mostrar como serviços devem ser desenhados

Slide 986

Adaptando o a SOA

Fase Preliminar • É aqui que a Capacidade de Arquitetura é adaptada para ar SOA • Princípios – Orientação a Serviços • Determinando a Prontidão da Organização para a SOA – OSIMM • Governança – O Modelo de Governança de SOA e o Método de Vitalidade do The Open Group – Adaptando as Arquiteturas de Referência para a Organização: – A Arquitetura de Referência SOA • Estabelecendo um Centro de Excelência de SOA como um “Alicerce” inicial – Considerações para o Particionamento Slide 988

Fase Preliminar Melhorias Objetivos •Assegurar que a SOA e os Princípios em vigor •Assegurar a Governança de SOA em vigor Entradas •Arquiteturas de Referência SOA existentes •Modelos de Maturidade de SOA da indústria existentes •Frameworks de Governança de SOA existentes •Melhores práticas de princípios de SOA da indústria existentes

Slide 989

os •Identificar e estabelecer Princípios • Princípios que am a SOA •Confirmar a governança • Referir-se ao Framework de Governança SOA do The Open Group e especificamente ao Método de Vitalidade de Governança de SOA (SGVM) •Avaliar a Maturidade da SOA • Utilizar o Modelo de Maturidade de Integração de Serviços do The Open Group (OSIMM) •Definir e estabelecer a organização da arquitetura • Estabelecer um Centro de Excelência de SOA

Saídas •Avaliação de Maturidade de SOA •Princípios de arquitetura • Incluindo princípios de SOA •Framework de Governança de arquitetura • O Framework de Governança de SOA do The Open Group

Fase A: Visão da Arquitetura • A Visão da Arquitetura refletirá a SOA • Uma das diferenças é o estilo de linguagem utilizado – A Ontologia de SOA do The Open Group provê uma taxonomia e uma ontologia para SOA

• É importante assegurar que as partes interessadas compreendam as implicações da SOA e estejam preparadas para os impactos organizacionais de serviços SOA

Slide 990

Fase A Melhorias Objetivos •Não há material de objetivos adicional Entradas •Modelo organizacional • Centro de Excelência de SOA • Avaliação de Maturidade de SOA • Avaliação de Prontidão de SOA • Governança de SOA •Framework de Arquitetura adaptado • Extensões de metamodelo de SOA • Arquitetura de Referência SOA •Arquitetura de alto-nível (Estratégico/Segmento) disponível

Slide 991

os •Identificar interesses/preocupações das partes interessadas • Interesses/preocupações específicos à SOA •Definir o escopo • Assegurar que o escopo é adequado para a SOA • Adaptar os entregáveis para o nível da arquitetura •Avaliar Capacidades de Negócio • Prontidão de SOA •Confirmar Princípios • Princípios que am a SOA

Saídas •Declaração de trabalho de arquitetura • Com SOA como abordagem •Princípios de arquitetura • Incluindo princípios de SOA •Avaliação de capacidade • Incluindo prontidão de SOA •Visão da arquitetura • Com raciocínio de SOA •Conteúdo adicional populando o Repositório de Arquitetura • Incluindo Arquitetura de Referência SOA

Desenvolvimento da Arquitetura: Fases B,C e D • Existem inúmeras entidades de Metamodelo que são chaves para a SOA • Normalmente é necessário estender o Metamodelo para ar totalmente a SOA

Slide 992

Slide de 32 993

Meta-modelo SOA

«TOGAF» Actor

«TOGAF» Event performs a

realizes

can be triggered by «TOGAF» Process

consists of

«TOGAF» Business Service -Service Quality -Location

«TOGAF» Information System Service -Measures -Service Quality -Location

realizes

drives requirements for «TOGAF» Platform Service -Location -ServiceQuality

drives requirements for

operates on

consumes, produces

is realized through is derived from

«TOGAF» Business Service Contract -Service Quality

ís used to on

«TOGAF» IS Service Contract -ServiceQuality

describes interaction with Information Entity

-Location

consists of

consists of

Information Component -Location

«TOGAF» Logical Application Component -Location -ServiceQuality

«TOGAF» Data Entity

influences

-Location

is realized through

influences

«TOGAF» Logical Technology Component -Location -ServiceQuality

operates on

is realized by

«TOGAF» Logical Data Component -Location

«TOGAF» Physical Data Component -Location

requires

operates on

«TOGAF» Physical Application Component -Location -ServiceQuality

is realized by

is run on

«TOGAF» Physical Technology Component -Location -ServiceQuality

consists of

Legend SOA Solution -Location -ServiceQuality

utilizes

Not in TOGAF

Slide 994

Context

Phase B

External relations

Phase C

Phase D

Phase E

Artefatos da Fase B Artefato

Propósito

Diagrama de Interação de Serviços de Negócio

Este diagrama mostra todos os serviços de negócio dentro do escopo e suas relações e a informação que flui entre eles

Diagrama de Processos de Negócio

Este é um conjunto de diagramas que mostra os processos de negócio e sua decomposição, suas interações e a informação com as quais lidam

Catálogo de Vocabulário de Negócio

Lista dos termos chaves utilizados para descrever os processos e informações de negócio

Catálogo de Serviços de Negócio

Esta é uma lista dos serviços de negócio da empresa e seus requisitos funcionais e não-funcionais

Catálogo de Serviços de Negócio/Localização

Para compreender onde os serviços de negócio são executados

Catálogo de Processos/Eventos

Para compreender que processo é executado em relação a um evento

Catálogo de Contratos/Qualidade de Serviço

Para compreender as propriedades nao-funcionais de um contrato

Matriz de Interação de Serviços de Negócio

Para mostrar as relações entre os Serviços de negócio

Matriz de Serviços de Negócio/Informações

Para mostrar como as entidades de informações são utilizadas pelos serviços de negócio e para se encontrar falhas no modelo

Modelo de Componentes de Informação Para definir a estrutura lógica da informação na organização

Slide 995

Fase B Melhorias Objetivos •Não há material de objetivos adicional Entradas •Modelo Organizacional • Centro de Excelência de SOA • Avaliação de Maturidade de SOA • Avaliação de Prontidão de SOA • Governança de SOA •Framework de Arquitetura adaptado • Extensões de metamodelo de SOA • Arquitetura de Referência SOA •Arquitetura de alto-nível (Estratégico/Segmento) disponível

os •Selecionar modelos, pontos de vista e ferramentas de Referência • Meta-modelo e extensões de conteúdo de SOA • Entidade de Informação e Componente de Informação

Saídas •Princípio de Negócio validados • Princípios que am a SOA •Arquitetura alvo de Negócio • Serviço de Negócio (com contrato) • Processo de Negócio • Entidade de Informação • Componente de Informação •Requisitos de Arquitetura de Rascunho • Requisitos técnicos para a SOA •As saídas podem incluir • • • • • • • • •

Slide 996

•

Diagrama de Interação de Serviços de Negócio Diagrama de Processos de Negócio Catálogo de Vocabulário de Negócio Catálogo de Serviços de Negócio Catálogo de Serviços de Negócio/Localização Catálogo de Processos/Eventos Catálogo de Contratos/Qualidade de Serviço Matriz de Interação de Serviços de Negócio Matriz de Serviços de Negócio/Informações Modelo de Componentes de Informação

Fase C Arquiteturas de Sistemas de Informação • A SOA não afeta muito a Arquitetura de Dados • Mas tem um grande impacto na Arquitetura de Aplicativos • Com a SOA, os aplicativos de software tradicionais são substituídos por conjuntos de serviços com baixo acoplamento • Mas a SOA não é somente serviços, é também definida pelas soluções criadas através da utilização da combinações de serviços – Essas soluções são normalmente estruturadas utilizando-se os Processos de Negócio e os Serviços de Negócio definidos na Fase B Slide 997

Artefatos da Fase C Artefato

Propósito

Diagrama de Interações de Serviços de SI

Apresenta os serviços de SOA potenciais (Serviços de SI) e as interações entre eles e utilização das informações

Matriz de Processos de Negócio/Serviços de SI

Essa matriz apresenta as relações entre cada Processo de Negócio e os Serviços de SI que am o processo

Catálogo de Contratos de Serviços de SI

O catálogo mostra todos os Serviços de SI, seus Contratos e as Qualidades de Serviço relacionadas que permitem a análise dos requisitos não-funcionais para Serviços de SOA potenciais.

Catálogo de Serviços de SI/Aplicativos (existentes)

Esse catálogo conecta os Serviços de SI (Serviços de SOA potenciais), Contratos e Qualidades de Serviço com os aplicativos existentes (Componentes Físicos de Aplicativos da linha de base)

Matriz de Serviços de SI/Entidades de Dados

Essa matriz mostra que dados são tratados pelos Serviços de SOA potenciais (Serviços de SI)

Matriz Lógica de Componentes de SOA

Essa matriz mostra as relações entre os Componentes lógicos de SOA (Componentes Lógicos de Aplicativos) e os Serviços de SOA potenciais (Serviços de SI)

Diagrama Lógico de Soluções de Esse diagrama mostra as relações entre os componentes lógicos de SOA (Componentes SOA Lógicos de Aplicativos) e outras soluções lógicos (Componentes lógicos de Aplicativos)

Matriz de Distribuição de Serviços

Slide 998

Essa matriz mostra os serviços distribuídos nas localizações físicas para preencher requisitos funcionais ou outros

Fase C Melhorias Objetivos •Estender a seção Aplicativos para incluir ‘Aplicativos e Serviços’ Entradas •Modelo Organizacional • Centro de Excelência de SOA • Avaliação de Maturidade de SOA • Avaliação de Prontidão de SOA • Governança de SOA •Framework de Arquitetura adaptado • Extensões de meta-modelo de SOA • Arquitetura de Referência SOA •Arquitetura de alto-nível (Estratégico/Segmento) disponível

os •Selecionar modelos, pontos de vista e ferramentas de Referência •Meta-modelo e extensões de conteúdo de SOA •Contrato de Serviços de SI •Relações entre Serviços de SI e Entidades de Dados

Saídas •Validar princípios de Negócio • Princípios que am a SOA •Arquitetura alvo de Sistemas de Informação • Serviço de SI (com contrato) • Portfólio de Serviços •Requisitos de Arquitetura de Rascunho • Requisitos técnicos para a SOA •As saídas podem incluir • •

• • • • •

Slide de 32 999

•

Diagrama de Interações de Serviços Matriz de Processos de Negócio/Serviços Catálogo de Contratos de Serviços Catálogo de Serviços de SI/Aplicativos (existentes) Matriz de Serviços de SI/Entidades de Dados Matriz Lógica de Componentes de SOA Diagrama de Solução Lógico para SOA Matriz de Distribuição de Serviços

Fase D •A Arquitetura Tecnológica define a infraestrutura de software e hardware necessária para ar o portfólio de serviços •Um bom ponto de partida é a Arquitetura de Referência SOA do The Open Group •O Modelo de Referência da Infraestrutura Orientada a Serviços (SOI) do The Open Group também provê orientação para a adaptação da infraestrutura de uma organização para a orientação a serviços

Slide 1000

Artefatos da Fase D Artefato

Propósito

Diagrama Lógico de Arquitetura Tecnológica

Esse diagrama é utilizado para apresentar e analisar a instanciação da Arquitetura de Referência SOA do The Open Group.

Matriz Lógica de Aplicativos e Tecnologia

Essa matriz é utilizado para apresentar e analisar as relações entre os Componentes Lógicos de Aplicativos e os Componentes Lógicos de Tecnologia

Slide 1001

Fase D Melhorias Objetivos •Não há material de objetivos adicional Entradas •Modelo Organizacional • Centro de Excelência de SOA • Avaliação de Maturidade de SOA • Avaliação de Prontidão de SOA • Governança de SOA •Framework de Arquitetura adaptado • Extensões de meta-modelo de SOA • Arquitetura de Referência SOA •Arquitetura de alto-nível (Estratégico/Segmento) disponível

Slide 1002

os •Selecionar modelos, pontos de vista e ferramentas de Referência • Modelo de Referência de SOA • Relação entre Componente Lógico de Tecnologia e Componente Lógico de Aplicativo

Saídas •Validar princípios de Negócio • Princípios que am a SOA •Arquitetura alvo de Tecnologia • Carga esperada de processamento e distribuição da carga através da tecnologia •Requisitos de Arquitetura de Rascunho • Requisitos técnicos para a SOA •As saídas podem incluir • Diagrama Lógico de Arquitetura Tecnológica • Matriz Lógica de Aplicativos e Tecnologia

Fase E • Esta fase trata da questão de quais soluções de SOA a empresa terá e como elas serão gerenciadas • São consideradas as opções de entrega de soluções – Uma opção de entrega que é frequentemente considerada é o outsourcing de serviços ao invés do desenvolvimento interno ou a aquisição de produtos de software que executem os serviços

Slide 1003

Artefatos da Fase E Artefato

Propósito

Matriz Física de Soluções de SOA

Essa matriz mostra todos os componentes de solução de SOA

Diagrama Físico de Soluções de SOA

Esse diagrama mostra as relações entre a solução física de SOA (Componentes Físicos de Aplicativos) e as outras soluções (Componentes Físicos de Aplicativos)

Matriz física de Soluções de Serviços

Essa matriz mostra quais serviços existentes são reutilizados e quais podem ser providos por serviços externos (SaaS) e quais serviços precisam ser desenvolvidos como encapsulamentos de aplicativos novos/existentes e quais precisam ser desenvolvidos

Orientações de Aplicativos

Esse documento provê as orientações sobre como desenvolver a Solução e Serviços de SOA

Diagrama Físico de Arquitetura Tecnológica

Esse diagrama é utilizado para se mostrar e analisar as soluções físicas técnicas para a infraestrutura de SOA

Matriz física de Aplicativos e Tecnologia

Essa matriz é utilizada para apresentar e analisar a infraestrutura física utilizada para se executar o aplicativos físico

Catálogo de Portfólio de Tecnologia

Essa é uma lista de produtos e tipos de produtos que serão utilizados na implementação, incluído a infraestrutura de tempo de execução de SOA

Orientações de Tecnologia

Esse documento provê orientações sobre como utilizar a infraestrutura de SOA

Slide 1004

Fase E Melhorias Objetivos •Não há material de objetivos adicional Entradas •Modelo Organizacional • Centro de Excelência de SOA • Avaliação de Maturidade de SOA • Avaliação de Prontidão de SOA • Governança de SOA •Framework de Arquitetura adaptado • Extensões de meta-modelo de SOA • Arquitetura de Referência SOA •Arquitetura de alto-nível (Estratégico/Segmento) disponível

Slide 1005

os •Selecionar modelos, pontos de vista e ferramentas de Referência • Componente Físico de Dados • Componente Físico de Aplicativo • Componente Físico de Tecnologia • Solução de SOA

Saídas •Roap de Arquitetura • Roap de SOA e SOI •Requisitos de Arquitetura de Rascunho • Requisitos técnicos para a SOA •As saídas podem incluir • Matriz Física de Soluções de SOA • Diagrama Físico de Soluções de SOA • Matriz física de Soluções de Serviços • Orientações de Aplicativos • Diagrama Físico de Arquitetura Tecnológica • Matriz física de Aplicativos e Tecnologia • Catálogo de Portfólio de Tecnologia • Orientações de Tecnologia

Adaptando o : SOA

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide de 32 1008

Módulo 33 Modelos de Maturidade da Arquitetura V9.1 Edition Copyright © 2009-2011

Slide 1009de 21 All rights reserved Published by The Open Group, 2011

Modelos de Maturidade da Arquitetura

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 1010de 21

Roap Parte I - Introdução Prefácio, Visão global executiva, Principais Conceitos, Definições e Notas da Versão

Parte II – Método de Desenvolvimento da Arquitetura Introdução ao Narrativas das Fases do

Parte III – Orientações e Técnicas do Orientações para Adaptação do Processo do Técnicas para o Desenvolvimento da Arquitetura

Parte IV – Framework de Conteúdo da Arquitetura Metamodelo de Conteúdo Artefatos Arquiteturais Entregáveis da Arquitetura Blocos de Construção

Parte V – Continuum da Corporação e Ferramentas Continuum da Corporação Particionamento da Arquitetura Repositório da Arquitetura Ferramentas para o Desenvolvimento da Arquitetura

Parte VI – Modelos de Referência do TOGAF Arquitetura de Fundação: Modelo de Referência Técnico Modelo de Referência da Infraestrutura Integrada da Informação

Parte VII – Framework de Capacidade da Arquitetura Comitê de Arquitetura Aderência da Arquitetura Contratos da Arquitetura Governança da Arquitetura Modelos de Maturidade da Arquitetura Frameworks de Competências da Arquitetura

Slide 1011

• Parte VII – Framework de Capacidade da Arquitetura, Captulo 51

Modelos de Maturidade de Capacidade •

•

Os Modelos de Maturidade de Capacidade (MMCs) fornecem um método eficaz para o controle e a melhoria de processos de mudanças Os benefícios de tais modelos são: – Descrever as práticas que toda organização deve realizar para melhorar seus processos – Fornecer medições para a melhoria – Fornecer um framework para se gerenciar os esforços de melhoria – Organizar as várias práticas em níveis, cada nível representando um aumento da habilidade para controlar e gerenciar o ambiente de desenvolvimento

Slide 1013

Modelos de Maturidade de Capacidade •

•

Uma avaliação das práticas da organização em relação ao modelo é realizada para se determinar o nível atual na qual ela está Mostram a maturidade da organização e as áreas que precisam ser focadas para serem melhoradas e obter um ROI mais alto

Slide 1014

Modelos de Maturidade de Capacidade •

•

O MMC (CMM) original foi desenvolvido no início dos anos 1990 pelo CMU e ainda é amplamente utilizado hoje em dia MMCs também foram desenvolvidos para outras áreas como: – Pessoal: o P-CMM (Modelo de Maturidade de Capacidade de Pessoal), e o IDEAL Modelo de Ciclo de Vida para Melhorias – Engenharia de Sistemas: o SE-CMM (Modelo de Maturidade de Capacidade de Engenharia de Sistemas) – Aquisição de Software: o SA-CMM (Modelo de Maturidade de Capacidade de Aquisição de Software) – CMMI: Integração dos Modelos de Maturidade de Capacidade

Slide 1015

Modelos de Maturidade de Capacidade Existem modelos para se avaliar: • O estado do processo de arquitetura de TI • A Arquitetura de TI • O compromisso da organização com ambos Modelos MMC também podem ser utilizados para se avaliar uma vasta gama de domínios: • Maturidade de e-Commerce • Implementação e auditoria de processos • Medições de qualidade • Competências de pessoal • Gerenciamento de investimento Slide 1016

O CMMI • •

CMMI significa Integração de Modelos de Maturidade da Capacidade (Capability Maturity Model Integration). O CMMI é um framework utilizado para o gerenciamento da complexidade de diferentes modelos: – IPD-CMM (Modelo de Maturidade da Capacidade de Desenvolvimento Integrado de Produtos) – P-CMM (Modelo de Maturidade da Capacidade de Pessoal) – SA-CMM (Modelo de Maturidade da Capacidade de Aquisição de Software) – SE-CMM (Modelo de Maturidade da Capacidade de Engenharia de Sistemas) – SW-CMM (Modelo de Maturidade da Capacidade para Software)

Slide 1017

O CMMI De acordo com o SEI, a utilização de modelos CMMI aperfeiçoa as melhores práticas ao permitir que organizações: • Vinculem explicitamente atividades de gerenciamento e de engenharia aos objetivos de negócio • Expandam o escopo e a visibilidade de ciclos de vida de produtos e atividades de engenharia • Incorporem lições aprendidas de áreas adicionais de melhores práticas (por ex., medições, gerenciamento de riscos, etc.) • Implementem práticas de alta maturidade mais robustas • Lidem com funções organizacionais adicionais • Sejam conformes com padrões ISO O CMMI está sendo adotado no mundo todo. Slide 1018

O CMMI SCAMPI, o Standard CMMI Appraisal Method for Process Improvement (Método Padrão de Avaliação CMMI para Melhorias de Processos) é utilizado para se identificar forças, fraquezas e níveis relativos aos modelos de referência do CMMI Ele incorpora as melhores práticas e é baseado nas características de vários métodos de avaliação É aplicável a uma vasta gama de modos de utilização de avaliações, incluindo melhorias de processos internas e determinações externas de capacidade

Slide 1019

ACMM do Departamento de Comércio (DoC) dos EUA O Architecture Capability Maturity Model (ACMM – Modelo de Maturidade da Capacidade da Arquitetura) foi desenvolvido para a condução de avaliações internas. É um framework que representa os componentes-chaves de um processo de Arquitetura Corporativa em produção. Seu objetivo é identificar áreas fracas e fornecer um modo de se melhorar o processo geral de arquitetura. O ACMM tem 3 seções: • O modelo de maturidade da arquitetura corporativa • As características de Arquitetura Corporativa (AC) de processos em diferentes níveis de maturidade • A tabela de indicadores (scorecard) do MMC da AC Slide 1020

Níveis de Maturidade do ACMM 5: Mensurado 4:Gerenciado 3: Definido 2: Em desenvolvimento 1: Inicial 0: Nenhum

Slide 1021

•

O ACMM do DoC dos EUA consiste em: – 6 níveis de maturidade – 9 elementos de arquitetura

Elementos do ACMM da Arquitetura Corporativa 1. Processo de Arquitetura •

Existe um processo de Arquitetura Corporativa estabelecido?

2. Desenvolvimento da Arquitetura: •

Até que ponto o desenvolvimento e a progressão da Arquitetura Corporativa das Unidades Operacionais estão documentados?

3. Vínculo aos Negócios: •

Até que ponto a Arquitetura Corporativa está vinculada às estratégias e motivadores de negócio?

4. Envolvimento da gerência sênior •

Até que ponto os gerentes sênior das Unidades Operacionais estão envolvidos no estabelecimento e desenvolvimento contínuo da Arquitetura de TI?

5. Participação da unidade operacional • • Slide 1022

Até que ponto o processo de Arquitetura Corporativa é aceito pela Unidade Operacional? Até que ponto o processo de Arquitetura Corporativa é um esforço representativo da organização como um todo?

Elementos do ACMM da Arquitetura Corporativa 6. Comunicação de Arquitetura • •

•

Até que ponto as decisões da prática de Arquitetura Corporativa são documentadas? Até que ponto o conteúdo da Arquitetura Corporativa é disponibilizado eletronicamente para todos na organização? Até que ponto a educação em arquitetura é realizada em todo o negocio sobre o processo e conteúdo da Arquitetura Corporativa?

7. Segurança de TI •

Até que ponto a Segurança de TI é integrada com a Arquitetura Corporativa?

8. Governança da Arquitetura •

Até que ponto existe um processo de governança (órgão governativo) da Arquitetura Corporativa aceito pela gerência sênior?

9. Investimento de TI e estratégia de aquisição •

Slide 1023

Até que ponto a Arquitetura Corporativa influencia o investimento de TI e a estratégia de aquisição?

Exemplo: Critério de Pontuação do ACMM

Pontuação Elemento 1. Processo de Arquitetura 0

Sem EA

Não estabelecido ou não existente

1

Inicial

Existe de um modo ad-hoc ou localizado ou em uma forma inicial. Alguns processos de Arquitetura Corporativa são definidos. Não existe um processo de arquitetura unificado para todos os processos de tecnologia ou negócio. O sucesso depende de esforços individuais.

2

Desenvolvendo Sendo ativamente desenvolvido. O programa de Processo de Arquitetura Corporativa Básica é documento baseado na Circular OMB A-130 e nas Orientações de Arquitetura Corporativa do Departamento de Comércio. O processo de arquitetura desenvolveu papéis e responsabilidades claros.

3

Definido

4

Gerenciado O processo de Arquitetura Corporativa faz parte da cultura, com vínculos fortes a outros processos centrais de TI e Negócio. Métricas de qualidade associadas ao processo de arquitetura são obtidas. Essas métricas incluem os tempos de ciclo necessários para se gerar revisões da Arquitetura Corporativa, estabilidade do ambiente técnico e tempo para se implementar uma nova aplicação ou sistema ou uma atualização.

5

Otimizando Esforços sincronizados para se utilizar e melhorar continuamente o processo de arquitetura.

Slide 1024

A arquitetura é bem definida e comunicada à equipe de TI e gerência de Negócio com responsabilidades de Unidades Operacionais de TI. O processo é amplamente seguido.

Avaliações de Maturidade no • •

•

•

As avaliações de maturidade são referenciadas na Fase Preliminar, Fase A e Fase E do A abordagem da Fase Preliminar recomenda sua utilização como parte do desenvolvimento do Modelo Organizacional para a Arquitetura Corporativa Na Fase A, a avaliação de maturidade faz parte da Avaliação da Capacidade utilizada para se determinar a capacidade da arquitetura de linha de base e alvo Essa Avaliação da Capacidade também é revisitada na Fase E, ao se prepararem os Planos de Implementação e Migração

Slide 1025

Avaliações de Maturidade no (Cont) •

•

Ao se utilizar MMCs com o , recomenda-se que sejam adaptados e discutidos em workshops envolvendo as principais partes interessadas dentro da organização Os níveis reais de maturidade podem fornecer uma medida estratégica da habilidade da organização para a mudança, assim como uma série de os sequenciais para melhorar essa habilidade

Slide 1026

Modelos de Maturidade da Arquitetura

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 1029de 21

Módulo 34

Framework de Competências da Arquitetura V9.1 Edition Copyright © 2009-2011

Slide 1030de 16 All rights reserved Published by The Open Group, 2011

Framework de Competências da Arquitetura

TOGAF é uma marca registrada do The Open Group nos Estados Unidos e em outros países

Slide 1031de 16

Roap Parte I - Introdução Prefácio, Visão global executiva, Principais Conceitos, Definições e Notas da Versão

Parte II – Método de Desenvolvimento da Arquitetura Introdução ao Narrativas das Fases do

Parte III – Orientações e Técnicas do Orientações para Adaptação do Processo do Técnicas para o Desenvolvimento da Arquitetura

Parte IV – Framework de Conteúdo da Arquitetura Metamodelo de Conteúdo Artefatos Arquiteturais Entregáveis da Arquitetura Blocos de Construção

Parte V – Continuum da Corporação e Ferramentas Continuum da Corporação Particionamento da Arquitetura Repositório da Arquitetura Ferramentas para o Desenvolvimento da Arquitetura

Parte VI – Modelos de Referência do TOGAF Arquitetura de Fundação: Modelo de Referência Técnico Modelo de Referência da Infraestrutura Integrada da Informação

Parte VII – Framework de Capacidade da Arquitetura Comitê de Arquitetura Aderência da Arquitetura Contratos da Arquitetura Governança da Arquitetura Modelos de Maturidade da Arquitetura Frameworks de Competências da Arquitetura

Slide 1032

• Parte VII – Framework de Competências da Arquitetura, Capítulo 52

Papéis Patrocinador da Arquitetura

CxO Gerente de Projetos

Patrocinador da Arquitetura

Membro do Comitê da Arquitetura

Gerente de Projetos

Gerente de EA

Há muitos papéis envolvidos numa prática de arquitetura corporativa

Arquiteto de negócio

Arquiteto Aplicativo

Arquiteto de Tecnologia

Projetista Expert de Arquiteto de TI de negócio Domínio de negócio

Membro do Comitê da Arquitetura

Arquiteto de Dados

Grupos de QA / Normatização

Slide 1034

Projetista de TI

Segurança Corporativa

Projetista de TI

Propósito Rigor de definição • “Arquitetura Corporativa” e “Arquiteto Corporativo” são termos amplamente utilizados mas pobremente definidos na indústria atualmente. Existe uma necessidade de haver definições mais claras. Base de uma Prática de Arquitetura Interna • Uma prática de arquitetura corporativa é um programa formal de desenvolvimento e certificação no qual uma empresa reconhece as competências de seus arquitetos • Tal programa é essencial para assegurar o alinhamento das competências e experiência da equipe com as tarefas de arquitetura que a empresa deseja realizar Slide 1035

Propósito •

A criação de uma prática de arquitetura corporativa é difícil e onerosa

•

O Framework de Competências da Arquitetura do TOGAF procura atender a essa necessidade – Fornecendo definições das competência da arquitetura e níveis de proficiência requeridos do pessoal, interno ou externo, que desempenhará os vários papéis de arquitetura definidos no Framework TOGAF

Slide 1036

Benefícios de se utilizar o Framework de Competências da Arquitetura Os benefícios específicos antecipados são: • Tempo, custo e riscos reduzidos no treinamento, contratação e gerenciamento de profissionais de arquitetura, ambos internos e externos. • Tempo e custo reduzidos para se estabelecer uma prática de arquitetura interna • Isso, por sua vez, ajuda a reduzir o tempo, custo e riscos do desenvolvimento geral de soluções

Slide 1037

A estrutura do Framework de Competências da Arquitetura O Framework de Competências da Arquitetura do TOGAF provê uma visão dos níveis de competência de papéis específicos numa equipe de arquitetura corporativa. O Framework define: • Os papéis dentro de uma área de trabalho de arquitetura corporativa • As competências requeridas por esses papéis • A profundidade de conhecimento requerida para se desempenhar cada papel com sucesso

Slide 1038

A estrutura do Framework de Competências da Arquitetura Uma equipe típica de arquitetura realizando o desenvolvimento de uma arquitetura corporativa compreende os seguintes papéis: • Membros do Comitê de Arquitetura • Patrocinador da Arquitetura • Gerente da Arquitetura • Arquitetos para : – – – – – – – – Slide 1039

Arquitetura Corporativa Arquitetura de Negócio Arquitetura de Dados Arquitetura de Aplicativos Arquitetura Tecnológica Gerentes de Programas e/ou Projetos Projetista de TI etc. . . .

A estrutura do Framework de Competências da Arquitetura Categorias de Competências O conjunto de competências da equipe TOGAF precisará incluir as seguintes categorias: • Competências Genéricas: liderança, trabalho em equipe, competências interpessoais, etc. • Competências e Métodos de Negócio: casos de negócio, processos de negócio, planejamento estratégico, etc. • Competências em Arquitetura Corporativa: modelagem, projeto de blocos de construção, projeto de aplicativos e papéis, integração de sistemas, etc. • Competências em Gerenciamento de Programas ou Projetos: gerenciamento de mudanças de negócio, métodos e ferramentas de gerenciamento de projetos • Competências em Conhecimentos Gerais de TI: aplicativos de intermediação, gerenciamento de ativos, planejamento de migração, SLAs, etc. • Competências técnicas de TI: engenharia de software, segurança, troca de dados, gerenciamento de dados, etc. • Legislação: legislação de proteção de dados, legislação de contratos, legislação de terceirização, fraudes, etc. Slide 1040

A estrutura do Framework de Competências da Arquitetura •

Níveis de Proficiência

Slide 1041

A estrutura do Framework de Competências da Arquitetura •

Matrizes de Competências – Exemplo de Competências Genéricas

Slide 1042