A Pocket Guide To The ArchiMate® 3.1 Specification (Brazilian Translation)

Um Guia de Bolso para a
Especificação ArchiMate® 3.1

A Especificação ArchiMate® 3.1 - Um Guia de Bolso
Copyright © 2012-2019, The Open Group
Todos os direitos reservados.
Nenhuma parte desta publicação pode ser reproduzida, armazenada em um sistema de recuperação ou
transmitida, sob qualquer forma ou por quaisquer meios, eletrônico, mecânico, fotocópia, gravação ou outra
forma, sem a permissão prévia do proprietário dos direitos.
As opiniões expressas neste documento não são necessariamente aquelas de qualquer membro em particular
do The Open Group.
Em caso de qualquer discrepância entre o texto do presente documento e a documentação oficial do

ArchiMate, a documentação do ArchiMate permanece a versão autoritativa para certificação, teste através de
exame e outros fins. A documentação oficial do ArchiMate pode ser obtida on-line em
www.opengroup.org/archimate.
Um Guia de Bolso para a Especificação ArchiMate® 3.1
Número do Documento: G196BR
Publicado pelo The Open Group, novembro de 2020.

Tradução publicada em agosto de 2020.
Atualizado em agosto de 2017 para alinhar com a Especificação ArchiMate 3.0.1.

Atualizado em novembro de 2017 para corrigir a definição do Relacionamento de Agregação (§4,1, Tabela
1), e para substituir o Exemplo 31, uma vez que o relacionamento de atribuição de instalação para material
não é permitido.
Atualizado em junho de 2019 para alinhar com a Especificação ArchiMate 3.1.
Comentários relativos ao material contido neste documento podem ser enviados para:
The Open Group

Apex Plaza
Forbury Road
Reading
Berkshire, RG1 1AX
Reino Unido
ou por correio eletrônico para:
ogspecs@opengroup.org
Guia (2019) Copyright © 2019 The Open Group. Todos os Direitos Reservados. ii
Conteúdo
Capítulo 1 Introdução .......................................................................................................................... 1
1.1 Introdução à Especificação ArchiMate .................................................................... 1
1.2 Visão Geral da Especificação ArchiMate ................................................................ 2
1.3 A Linguagem ArchiMate e a Arquitetura Corporativa ............................................ 3
1.3.1 A Linguagem ArchiMate e o TOGAF ADM ............................................ 3
Capítulo 2 Estrutura da Linguagem ..................................................................................................... 5
2.1 Estrutura de Nível Superior da Linguagem ............................................................. 5
2.2 Estratificação da Linguagem ArchiMate ................................................................. 6
2.3 Uso de Cores e Indicações Notacionais ................................................................... 6
2.4 O Framework Central do ArchiMate ....................................................................... 7
2.5 O Framework Completo do ArchiMate ................................................................... 9
Capítulo 3 Metamodelo Genérico ...................................................................................................... 10
3.1 Elementos de Estrutura e de Comportamento ........................................................ 10
3.1.1 Elementos de Estrutura Ativa .................................................................. 11
3.1.2 Elementos de Comportamento ................................................................ 12
3.1.3 Elementos de Estrutura Passiva ............................................................... 13
3.2 Especializações dos Elementos de Estrutura e Comportamento ............................ 13
3.3 Elementos de Motivação ....................................................................................... 15
3.4 Elementos Compostos ........................................................................................... 15
3.4.1 Agrupamento ........................................................................................... 16
3.4.2 Localização.............................................................................................. 16
Capítulo 4 Relacionamentos .............................................................................................................. 17
4.1 Relacionamentos Estruturais ................................................................................. 18
4.2 Relacionamentos de Dependência ......................................................................... 20
4.3 Relacionamentos Dinâmicos ................................................................................. 21
4.4 Outros Relacionamentos ........................................................................................ 22
4.5 Conectores de Relacionamento .............................................................................. 22
4.6 Exemplos ............................................................................................................... 22
4.6.1 Relacionamento de Composição ............................................................. 22
4.6.2 Relacionamento de Agregação ................................................................ 23
4.6.3 Relacionamento de Atribuição ................................................................ 23
4.6.4 Relacionamento de Realização ................................................................ 23
4.6.5 Relacionamento de Servidão ................................................................... 24
4.6.6 Relacionamento de Acesso ...................................................................... 24
4.6.7 Relacionamento de Influência ................................................................. 24
4.6.8 Relacionamento de Associação ............................................................... 25
4.6.9 Relacionamento de Acionamento ............................................................ 25
4.6.10 Relacionamento de Fluxo ........................................................................ 26
4.6.11 Relacionamento de Especialização .......................................................... 26
4.6.12 Junção ...................................................................................................... 27
4.7 Derivação de Relacionamentos .............................................................................. 27
Capítulo 5 Elementos de Motivação .................................................................................................. 29
5.1 Metamodelo dos Elementos de Motivação ............................................................ 29
5.2 Sumário dos Elementos de Motivação ................................................................... 30
5.3 Exemplos ............................................................................................................... 33
5.3.1 Parte Interessada, Motivador e Avaliação ............................................... 33
5.3.2 Meta, Resultado, Princípio, Requisito e Restrição .................................. 34
5.3.3 Significado e Valor.................................................................................. 35
Guia (2019) Copyright © 2019 The Open Group. Todos os Direitos Reservados. iii
5.4 Relacionamentos com os Elementos Centrais ....................................................... 36

Capítulo 6 Elementos de Estratégia ................................................................................................... 38
6.1 Metamodelo dos Elementos de Estratégia ............................................................. 38
6.2 Sumário dos Elementos de Estratégia .................................................................... 38
6.3 Exemplo de Elementos de Estratégia..................................................................... 40
6.4 Relacionamento com os Elementos de Motivação e Centrais ............................... 42
Capítulo 7 Camada de Negócio ......................................................................................................... 44
7.1 Metamodelo da Camada de Negócio ..................................................................... 44
7.2 Elementos de Estrutura Ativa ................................................................................ 44
7.3 Elementos de Comportamento ............................................................................... 47
7.4 Elementos de Estrutura Passiva ............................................................................. 49
7.5 Elementos Compostos ........................................................................................... 51
7.6 Exemplos ............................................................................................................... 52
7.6.1 Elementos de Estrutura Ativa de Negócio ............................................... 52
7.6.2 Elementos de Comportamento de Negócio ............................................. 53
7.6.3 Elementos de Estrutura Passiva de Negócio ............................................ 54
7.6.4 Elemento Composto de Negócio: Produto .............................................. 54
Capítulo 8 Camada de Aplicativo ...................................................................................................... 56
8.1 Metamodelo da Camada de Aplicativo .................................................................. 56
8.5 Exemplos ............................................................................................................... 61
8.5.1 Elementos de Estrutura Ativa de Aplicativo ........................................... 61
8.5.2 Elementos de Comportamento de Aplicativo .......................................... 62
8.5.3 Elementos de Estrutura Passiva de Aplicativo ........................................ 62
Capítulo 9 Camada de Tecnologia ..................................................................................................... 63
9.1 Metamodelo da Camada de Tecnologia ................................................................. 63
9.5 Exemplos ............................................................................................................... 70
9.5.1 Elementos de Estrutura Ativa de Tecnologia .......................................... 70
9.5.2 Elementos de Comportamento de Tecnologia ......................................... 70
9.5.3 Elemento de Estrutura Passiva de Tecnologia: Artefato ......................... 71
Capítulo 10 Elementos Físicos ............................................................................................................. 72
10.1 Metamodelo dos Elementos Físicos ...................................................................... 72
10.5 Exemplo de Elementos Físicos .............................................................................. 74
Capítulo 11 Relacionamentos entre as Camadas Centrais ................................................................... 76
11.1 Alinhamento da Camada de Negócio e Camadas Inferiores .................................. 76
11.2 Alinhamento das Camadas de Aplicativo e Tecnologia ........................................ 77
11.3 Exemplo de Relacionamento Entre Camadas ........................................................ 78
Capítulo 12 Elementos de Implementação e Migração ........................................................................ 79
12.1 Metamodelo de Elementos de Implementação e Migração ................................... 79
12.2 Elementos de Implementação e Migração ............................................................. 79
12.3 Exemplos de Elementos de Implementação e Migração ....................................... 81
12.4 Relacionamentos .................................................................................................... 81
Guia (2019) Copyright © 2019 The Open Group. Todos os Direitos Reservados. iv
12.5 Relacionamentos com Outros Aspectos e Camadas .............................................. 81

Capítulo 13 Exemplos de Pontos de Vista do ArchiMate .................................................................... 83
13.1 Visões e Pontos de Vista da Arquitetura ............................................................... 83
13.2 Mecanismo de Ponto de Vista ............................................................................... 83
Apêndice A Mudanças da Versão 3.0.1 para a Versão 3.1 ................................................................... 85
Guia (2019) Copyright © 2019 The Open Group. Todos os Direitos Reservados. v
Prefácio
Este Documento
Este documento é o Guia de Bolso para a Especificação ArchiMate® 3.1, um padrão do The
Open Group. Ele se destina a ajudar arquitetos fornecendo uma referência para a linguagem de
modelagem gráfica ArchiMate e também ajudar os gestores a compreender os conceitos básicos
da linguagem ArchiMate. Ele está organizado como segue:
 O Capítulo 1 fornece uma introdução de alto nível para a Especificação ArchiMate e sua
relação com a Arquitetura Corporativa
 O Capítulo 2 descreve a estrutura de alto nível da linguagem ArchiMate, incluindo uma
introdução para estratificação, o Framework Central do ArchiMate e o Framework
Completo do ArchiMate
 O Capítulo 3 descreve o Metamodelo Genérico para a linguagem
 O Capítulo 4 descreve os relacionamentos que a linguagem ArchiMate inclui para modelar
as ligações entre os elementos
 O Capítulo 5 descreve os Elementos de Motivação, que incluem conceitos tais como meta,
princípio e requisito
 O Capítulo 6 descreve os Elementos de Estratégia, que incluem conceitos tais como
recurso, capacidade e curso de ação
 O Capítulo 7 descreve a Camada de Negócio, que inclui conceitos de modelagem relevantes
no domínio dos negócios
 O Capítulo 8 descreve a Camada de Aplicativo, que inclui conceitos de modelagem
relevantes para software aplicativo
 O Capítulo 9 descreve a Camada de Tecnologia, que inclui conceitos de modelagem
relevantes para software de sistema e infraestrutura
 O Capítulo 10 descreve os Elementos Físicos, que incluem conceitos relevantes para a
modelagem de conceitos físicos como as máquinas e as instalações físicas
 O Capítulo 11 descreve os relacionamentos entre as diferentes camadas da linguagem
 O Capítulo 12 descreve os Elementos de Implementação e Migração, que incluem conceitos
para suportar a modelagem da transformação apoiada pela Arquitetura Corporativa
 O Capítulo 13 introduz o conceito de Pontos de Vista do ArchiMate
 O Apêndice A contém um resumo das mudanças do ArchiMate versão 3.0.1 para o
ArchiMate versão 3.1
 Um Glossário de termos e um Índice são fornecidos
Guia (2019) Copyright © 2019 The Open Group. Todos os Direitos Reservados. vi
O público para este documento é:

 Arquitetos Corporativos, arquitetos de negócio, arquitetos de TI, arquitetos de aplicativo,
arquitetos de dados, arquitetos de software, arquitetos de sistemas, arquitetos de soluções,
arquitetos de infraestrutura, arquitetos de processos, arquitetos de domínio, gerentes de
produto, gerentes operacionais e gerentes seniores, que procuram uma primeira introdução à
linguagem de modelagem ArchiMate
Depois de ler este documento, o leitor que busca mais informações deveria consultar a
documentação do ArchiMate1 disponível online em www.opengroup.org/archimate.
Convenções Utilizadas neste Documento
As seguintes convenções são usadas neste documento para ajudar a identificar informações
importantes e evitar confusões sobre o significado desejado:
 Reticências (…)
Indica uma continuação, tal como uma lista incompleta de itens de exemplo, ou uma
continuação do texto anterior.
 Negrito
Usado para destacar termos específicos.

 Itálico
Usado para ênfase. Pode também se referir a outros documentos externos.
Além das convenções tipográficas, a seguinte convenção será usada para destacar segmentos de
texto:
Uma caixa Nota é usada para realçar informações úteis ou interessantes.
1
Especificação ArchiMate® 3.1, um padrão do The Open Group (C197), publicado por The Open Group, novembro de 2019; consulte:
www.opengroup.org/library/c197.
Guia (2019) Copyright © 2019 The Open Group. Todos os Direitos Reservados. vii
Sobre o The Open Group
O The Open Group é um consórcio global que habilita a realização de objetivos de negócio por
meio de padrões de tecnologia. Nossa diversificada base de membros de mais de 700
organizações inclui clientes, fornecedores de sistemas e soluções, fornecedores de ferramentas,
integradores, acadêmicos e consultores em vários setores.
A missão do The Open Group é orientar a criação de um Boundaryless Information Flow™

(Fluxo de Informação sem Fronteiras), obtido por meio de:
 Trabalhar com os clientes para capturar, compreender e endereçar requisitos atuais e
emergentes, estabelecer políticas e compartilhar melhores práticas
 Trabalhar com fornecedores, consórcios e organismos padronizadores para desenvolver o
consenso e facilitar a interoperabilidade, para evoluir e integrar especificações e
tecnologias de código aberto
 Oferecer um conjunto abrangente de serviços para melhorar a eficiência operacional dos
consorciados
 Desenvolver e operar o serviço de certificação líder da indústria e incentivar a aquisição
de produtos certificados
Mais informações sobre o The Open Group estão disponíveis em www.opengroup.org.
Guia (2019) Copyright © 2019 The Open Group. Todos os Direitos Reservados. viii
Marcas Comerciais
ArchiMate®, DirecNet®, Making Standards Work®, logotipo Open O®, logotipo Open O e
Check® Certification, OpenPegasus®, Platform 3.0®, The Open Group®, TOGAF®, UNIX®,
UNIXWARE®, e o logotipo Open Brand X® são marcas registradas, e Agile Architecture
Framework™, Boundaryless Information Flow™, Build with Integrity Buy with Confidence™,
Dependability Through Assuredness™, Digital Practitioner Body of Knowledge™, DPBoK™,
EMMM™, FACE™, o logotipo FACE™, IT4IT™, o logotipo IT4IT™, O-AAF™, O-DEF™,
O-HERA™, O-PAS™, Open FAIR™, Open Platform 3.0™, Open Process Automation™, Open
Subsurface Data Universe™, Open Trusted Technology Provider™, O-SDU™, Sensor
Integration Simplified™, SOSA™, e o logotipo SOSA™ são marcas comerciais do The Open
Group.
A Guide to the Business Architecture Body of Knowledge® e BIZBOK® são marcas registradas
do Business Architecture Guild.
UML® e Unified Modeling Language® são marcas comerciais registradas e BPMN™ e Business
Process Modeling Notation™ são marcas comerciais do Object Management Group.
Todas as outras marcas, empresas e nomes de produtos são utilizados apenas para fins de
identificação e podem ser marcas comerciais que são da exclusiva propriedade de seus
respectivos proprietários.
Guia (2019) Copyright © 2019 The Open Group. Todos os Direitos Reservados. ix
Sobre os Autores
Andrew Josey
Andrew Josey é VP de Padrões e Certificação, supervisionando todos os programas de certificação
e testes do The Open Group. Ele também gerencia o Processo de Padrões para o The Open Group.
Desde a sua adesão à empresa, em 1996, Andrew esteve intimamente envolvido com as atividades
de desenvolvimento de padrões, certificação e testes do The Open Group. Ele tem liderado muitos
projetos de desenvolvimento de padrões, incluindo o desenvolvimento da especificação e
certificação para os programas ArchiMate®, TOGAF®, IT4IT™, POSIX® e UNIX®.
Ele é membro do IEEE, USENIX e da Association of Enterprise Architects (AEA). Ele possui
um mestrado em Ciência da Computação pela University College London.
Marc Lankhorst, BiZZdesign

Marc Lankhorst é Gerente-Consultor e Evangelista Chefe de Tecnologia na BiZZdesign. Ele é
responsável pelo desenvolvimento do mercado, consultoria e treinamento em desenho de negócios
digitais e Arquitetura Corporativa, e pela difusão da linguagem de modelagem ArchiMate para a
Arquitetura Corporativa. A sua experiência e interesses vão desde a Arquitetura Corporativa e o
gerenciamento de processos de negócio até os métodos ágeis, gerenciamento de portfólios, e a
desenho de negócios digitais. Anteriormente, Marc foi um Membro Sênior da Equipe Científica na
Novay (anteriormente Telematica Instituut), onde ele gerenciou o projeto colaborativo de P&D
que desenvolveu a versão inicial da linguagem ArchiMate. Ele lidera a equipe principal do The
Open Group ArchiMate Forum que definiu a nova versão do padrão.
Iver Band, Cambia Health Solutions

Iver Band é um praticante da Arquitetura Corporativa e um desenvolvedor e comunicador dos
padrões e métodos da Arquitetura Corporativa. Na Cambia Health Solutions, ele tem orientado
iniciativas focadas em sistemas de fornecimento, experiências móveis e web, e métodos e
ferramentas de arquitetura. Atualmente ele está focado em soluções que forneçam informações sobre
consumidores e grupos de atenção à saúde. Iver é também o Vice-Presidente eleito do ArchiMate
Forum. Ele liderou o desenvolvimento de vários artigos publicados pelo The Open Group e
contribuiu para a segunda e terceira versões principais da linguagem ArchiMate. Ele possui as
certificações TOGAF 9 e ArchiMate 3 Practitioner emitidas pelo The Open Group. Ele possui as
certificações Certified Information Systems Security Professional (CISSP), Certified Information
Professional, AHIP Information Technology Professional e Prosci Certified Change Consultant.
Henk Jonkers, BiZZdesign

Henk Jonkers é um Consultor Sênior de Pesquisa, envolvido em inovações na BiZZdesign nas áreas
de Arquitetura Corporativa e engenharia. Ele participa em projetos de pesquisa multipartidários,
contribui para a realização de cursos de formação, e executa atribuições de consultoria.
Anteriormente, como um membro da equipe científica no Telematica Instituut, ele esteve envolvido
em projetos de pesquisa em modelagem e análise de processos de negócios, Arquitetura Corporativa,
SOA, e desenvolvimento orientado por modelos. Ele foi um dos principais desenvolvedores da
linguagem ArchiMate e autor das Especificações ArchiMate 1.0, 2.1, 3.0 e 3.1, e está ativamente
envolvido nas atividades do Fórum ArchiMate do The Open Group.
Guia (2019) Copyright © 2019 The Open Group. Todos os Direitos Reservados. x
Dick Quartel, BiZZdesign
Dick Quartel é um Consultor Sênior de Pesquisa na BiZZdesign. Neste papel ele contribui para o
desenvolvimento e a melhoria de produtos e serviços da BiZZdesign, está envolvido em projetos
de pesquisa, supervisiona estudantes de mestrado e estagiários, e executa atribuições de
consultoria. Além disso, ele é autor de várias publicações científicas e profissionais e autor das
Especificações ArchiMate 2.1 e 3.0. Anteriormente, ele trabalhou como Pesquisador Sênior na
Novay (anteriormente Telematica Instituut), onde atuou como pesquisador e gerente de projetos,
e contribuiu para a definição e aquisição de projetos de pesquisa. Como Professor Assistente na
Universidade de Twente, trabalhou nas áreas de projeto de sistemas distribuídos, desenho e
implementação de protocolos, e sistemas de middleware.
Steve Else, EA Principals
Steve Else é CEO da EA Principals, um Gold Member do The Open Group. Steve é certificado
nos programas de certificação TOGAF 8, TOGAF 9, ArchiMate 3, Open FAIR e IT4IT. Um
antigo piloto da Força Aérea, com classificação para voar comercialmente Boeing 717 e Lear
Jet, Steve tornou-se um Arquiteto Corporativo há cerca de vinte anos, enquanto ajudava a
direcionar a iniciativa de Transformação de Negócios da Força Aérea dos EUA. Ele tem sido
Arquiteto-Chefe de numerosas organizações, realizado consultorias em organizações
particularmente desafiadoras, tais como Nações Unidas e Fannie Mae, e ensinou Arquitetura
Corporativa para milhares de estudantes por mais de dez anos. Ele também escreveu dois livros
sobre o framework TOGAF, juntamente com um livro sobre Teoria das Organização e a
Transformação de Organizações Grandes e Complexas.
Antonio Plais, Centus Consultoria (Tradução para o Português Brasileiro)
Antonio Plais é Proprietário e Consultor Sênior em Análise de Negócios, Arquitetura

Corporativa, Gerenciamento de Decisões e de Processos na Centus Consultoria, uma empresa de
Treinamento e Consultoria baseada no Brasil. Antonio tem mais de 40 anos de experiência no
desenvolvimento de sistemas e gerenciamento de TIC, e no desenvolvimento de estratégias de
marketing e de negócios. Nos últimos anos Antonio tem se dedicado à disseminação da análise
de negócios, arquitetura corporativa e gerenciamento de decisões no Brasil, e se empenhado na
formação, orientação e aconselhamento a profissionais na utilização destas disciplinas. Antonio
é representante da BiZZdesign e da SAPIENS Decision no Brasil, e é um profissional certificado
TOGAF 9.1 e ArchiMate 3.0.
Guia (2019) Copyright © 2019 The Open Group. Todos os Direitos Reservados. xi
Agradecimentos
O The Open Group agradece:
 Antigos e atuais membros do The Open Group ArchiMate Forum pelo desenvolvimento do
Padrão
 Os seguintes revisores desta e de edições anteriores deste documento:
 Peter Bates
 Sonia Gonzalez
 Dave Hornford
 Russel Jones
 Jens Kjærby
 Jean-Baptiste Sarrodie
Guia (2019) Copyright © 2019 The Open Group. Todos os Direitos Reservados. xii
Capítulo 1 Introdução
Este capítulo fornece uma introdução para a Especificação ArchiMate, um padrão do The Open
Group.
Os tópicos abordados neste capítulo incluem:

 Uma introdução à Especificação ArchiMate
 Uma breve visão geral da Especificação ArchiMate
 A linguagem ArchiMate e sua relação com a Arquitetura Corporativa e o Padrão TOGAF
1.1 Introdução à Especificação ArchiMate

A Especificação ArchiMate, um padrão do The Open Group, é uma linguagem de modelagem
aberta e independente para a Arquitetura Corporativa que é suportada por diferentes
fornecedores de ferramentas e empresas de consultoria. A linguagem ArquiMate permite aos
Arquitetos Corporativos descrever, analisar e visualizar as relações entre os domínios em uma
arquitetura de forma inequívoca.
Assim como um desenho arquitetônico na arquitetura clássica de edifícios descreve os vários

aspectos da construção e utilização de um prédio, a Especificação ArchiMate oferece uma
linguagem comum para descrever a construção e operação de processos de negócio, estruturas
organizacionais, fluxos de informação, sistemas de TI, e a infraestrutura técnica e física. Esta
percepção ajuda as partes interessadas a desenhar, avaliar e comunicar as consequências das
decisões e mudanças dentro e entre estes domínios da arquitetura.
Este documento é o Guia de Bolso para a Especificação ArchiMate 3.1, referida simplesmente
como a "Especificação ArchiMate" neste documento. A Especificação ArchiMate 3.1 é uma
atualização de manutenção para a especificação ArchiMate.
Desenvolvimento da Linguagem ArchiMate

A linguagem ArchiMate foi criada no período de 2002-2004, nos Países Baixos, por uma
equipe de projeto do Telematica Instituut em cooperação com vários parceiros do governo,
indústria e universidades, incluindo Ordina, Radboud Universiteit Nijmegen, o Leiden
Institute for Advanced Computer Science (LIACS), e o Centrum Wiskunde & Informatica
(CWI). O desenvolvimento incluiu testes em organizações como o ABN AMRO, o Dutch Tax
and Customs Administration, e o Stichting Pensioenfonds ABP.
Em 2008, a propriedade e a administração da linguagem ArchiMate foi transferida da
ArchiMate Fundation para o The Open Group. Desde 2009, o The Open Group ArchiMate
Forum desenvolveu sucessivas versões e as publicou no website público do The Open Group.
Guia (2019) Copyright © 2019 The Open Group. Todos os Direitos Reservados. 1
1.2 Visão Geral da Especificação ArchiMate
A Especificação ArchiMate é um Padrão do The Open Group para a linguagem de modelagem
de arquitetura ArchiMate. Ela contém a definição formal da linguagem de desenho visual.
O conteúdo da especificação inclui o seguinte:

 A introdução, incluindo os objetivos, visão geral, requisitos de conformidade, referências e
terminologia
 As definições dos termos gerais utilizados na especificação
 A estrutura da linguagem de modelagem
 O metamodelo genérico da linguagem
 Os relacionamentos na linguagem
 Uma desagregação detalhada do framework de modelagem cobrindo os elementos de
motivação, elementos de estratégia e as três camadas centrais (Negócio/Aplicativo/
Tecnologia)
 Relacionamentos entre as Camadas Centrais
 Elementos de implementação e migração para exprimir os aspectos de implementação e
migração de uma arquitetura
 Os conceitos de partes interessadas, pontos de vista e visões, e também o mecanismo de
pontos de vista do ArchiMate
 Mecanismos para personalizar a linguagem para propósitos especializados ou específicos de
domínio
 Visões gerais da notação e resumos
 Descrições informativas do relacionamento da linguagem ArchiMate com outros padrões,
incluindo o framework TOGAF, Business Process Modeling Notation (BPMN), Unified
Modeling Language (UML) BIZBOK® Guide2 e Business Motivation Model (BMM)
A Especificação ArchiMate 3.1 é a versão mais recente da especificação, e é uma evolução a

partir do ArchiMate 2.1 e anteriores.
2
Business Architecture Guild. A Guide to the Business Architecture Body of Knowledge® (BIZBOK® Guide), Version 7.0, 2018; consulte:
www.businessarchitectureguild.org.
1.3 A Linguagem ArchiMate e a Arquitetura Corporativa
O papel da Especificação ArchiMate é fornecer uma linguagem gráfica para a representação de
Arquiteturas Corporativas ao longo do tempo (ou seja, incluindo estratégica, transformação e
planejamento de migração), bem como a motivação e a fundamentação lógica para a arquitetura.
A linguagem de modelagem ArchiMate fornece uma representação uniforme para os diagramas
que descrevem as arquiteturas corporativas, e oferece uma abordagem integrada para descrever e
visualizar os diferentes domínios da arquitetura juntamente com as suas relações e dependências
subjacentes.
O desenho da linguagem ArchiMate começou a partir de um conjunto de conceitos relativamente

genéricos (objetos e relacionamentos), que foram especializados para aplicação nas diferentes
camadas arquiteturais para uma Arquitetura Corporativa. A restrição de desenho mais importante
para a linguagem ArchiMate é que ela foi explicitamente desenhada para ser a mais compacta
possível, mas ainda assim utilizável para a maioria das tarefas de modelagem de Arquitetura
Corporativa. No interesse da simplicidade de aprendizagem e uso, a linguagem tem sido limitada
aos conceitos que são suficientes para modelar o proverbial 80% dos casos práticos.
1.3.1 A Linguagem ArchiMate e o TOGAF ADM

A linguagem ArchiMate consiste da linguagem central do ArchiMate, que inclui as camadas de
Negócio, Aplicativo e Tecnologia, e elementos para modelar a Estratégia e a Motivação para
uma arquitetura, bem como a sua Implementação e Migração. A Figura 1 mostra um
mapeamento simplificado de como a linguagem ArchiMate pode ser usada em relação às fases
do TOGAF ADM.
Figura 1: O Relacionamento entre a Linguagem ArchiMate e o TOGAF ADM
As camadas de Negócio, Aplicativo e Tecnologia suportam a descrição dos domínios da

arquitetura definidos pelo framework TOGAF (negócio, sistemas de informação e tecnologia,
bem como as suas inter-relações).
Os elementos de estratégia e de motivação na linguagem ArchiMate podem ser usados para

apoiar as fases Gerenciamento de Requisitos, Preliminar e Visão da Arquitetura, do TOGAF
ADM, que estabelecem as metas de negócio de alto nível, os princípios de arquitetura e os
requisitos iniciais de negócio. Eles também são relevantes para a fase de Gerenciamento de
Mudança na Arquitetura do TOGAF ADM, uma vez que esta fase lida com requisitos de
mudança. Embora não mostrado na figura, deveria ser notado que estes elementos também
poderiam ser utilizados em outras fases de ADM, tais como as fases B, C e D.
Os elementos de implementação e migração da linguagem ArchiMate suportam a

implementação e a migração de arquiteturas através das fases de Oportunidades e Soluções,
Planejamento da Migração e Governança de Implementação do TOGAF ADM.
Capítulo 2 Estrutura da Linguagem
Este capítulo descreve a construção da linguagem ArchiMate.
Os tópicos abordados neste capítulo incluem:

 A estrutura de nível superior da linguagem
 Estratificação
 O Framework do ArchiMate
2.1 Estrutura de Nível Superior da Linguagem

A Figura 2 descreve a estrutura hierárquica de nível superior da linguagem:
 Um modelo é um conjunto de conceitos. Um conceito é um elemento, um relacionamento
ou um conector de relacionamento
 Um elemento é um elemento de comportamento, um elemento de estrutura, um elemento de
motivação ou um elemento composto
Figura 2: Hierarquia de Nível Superior dos Conceitos do ArchiMate
A Figura 2 descreve conceitos abstratos; eles não são destinados a ser utilizados diretamente
em modelos. Para significar isto, eles estão representados em branco com rótulos em itálico.
2.2 Estratificação da Linguagem ArchiMate
A linguagem central do ArchiMate define uma estrutura de elementos genéricos e seus
relacionamentos, que pode ser especializada em diferentes camadas. Três camadas são definidas
dentro da linguagem central do ArchiMate, como segue:
1. A Camada de Negócio descreve os serviços de negócio oferecidos aos clientes, os quais são
realizados na organização por processos de negócio desempenhados por atores de negócio.
2. A Camada de Aplicativo descreve os serviços de aplicativo que suportam o negócio, e os
aplicativos que os realizam.
3. A Camada de Tecnologia descreve os serviços de tecnologia, tais como serviços de
processamento, armazenamento e comunicação, necessários para executar os aplicativos, e o
hardware de computação e comunicação, e o software de sistema, que realizam estes
serviços. Elementos Físicos estão incluídos nesta camada para modelar equipamentos
físicos, materiais e redes de distribuição.
A estrutura geral dos modelos dentro das diferentes camadas é semelhante. Os mesmos tipos de
elementos e relacionamentos são usados, apesar de sua natureza exata e granularidade serem
diferentes.
Em alinhamento com a orientação para serviços, o relacionamento mais importante entre as

camadas é o relacionamento de “servidão”, que mostra como os elementos em uma camada são
servidos pelos serviços de outras camadas. (Observe, contudo, que serviços não precisam servir
apenas elementos em outra camada, mas também podem servir elementos na mesma camada.)
Um segundo tipo de ligação é formado pelo relacionamento de realização: elementos em
camadas inferiores podem realizar elementos comparáveis em camadas mais altas; por exemplo,
um “objeto de dados” (Camada de Aplicativo) pode realizar um “objeto de negócio” (Camada de
Negócio); ou um “artefato” (Camada de Tecnologia) pode realizar tanto um “objeto de dados”
como um “componente de aplicativo” (Camada de Aplicativo).
2.3 Uso de Cores e Indicações Notacionais

Nas figuras do metamodelo neste Guia de Bolso (por exemplo, a Figura 35) e na Especificação
ArchiMate 3.1, tons de cinza são utilizados para distinguir os elementos que pertencem a
diferentes aspectos do Framework do ArchiMate, como segue:
 Branco para conceitos abstratos (ou seja, não instanciáveis)
 Cinza claro para estruturas passivas
 Cinza médio para comportamento
 Cinza escuro para estruturas ativas
Nos modelos ArchiMate, não existe semântica formal atribuída a cores, e o uso de cores é
deixado a critério do modelador. No entanto, elas podem ser usadas livremente para salientar
certos aspectos nos modelos. Por exemplo, em muitos dos modelos de exemplo apresentados
neste Guia, as cores são utilizadas para distinguir entre as camadas do Framework Central do
ArchiMate (ver Seção 2.4), como se segue:
 Amarelo para a Camada de Negócio
 Azul para a Camada de Aplicativo
 Verde para a Camada de Tecnologia
Elas podem ser usadas também para ênfase visual.
Além das cores, outras indicações notacionais podem ser usadas para distinguir entre as camadas
do framework. As letras M, S, B, A, T, P ou I no canto superior esquerdo de um elemento
podem ser usadas para denotar um elemento de Motivação, Estratégia, Negócio, Aplicativo,
Tecnologia, Físico ou de Implementação e Migração, respectivamente.
A notação padrão também usa uma convenção para a forma dos cantos de seus símbolos para
diferentes tipos de elementos, como segue:
 Cantos quadrados são usados para indicar os elementos de estrutura (ver Seção 3.1.1)
 Cantos redondos são usados para indicar os elementos de comportamento (ver Seção 3.1.2)
 Cantos diagonais são usados para indicar os elementos de motivação (ver Seção 3.3)
2.4 O Framework Central do ArchiMate

O Framework Central do ArchiMate é uma estrutura de nove células utilizada para classificar
elementos da linguagem central do ArchiMate. Ele é composto de três aspectos e três camadas,
como ilustrado na Figura 3.
É importante entender que a classificação dos elementos com base em aspectos e camadas é
apenas uma aproximação. Os elementos da arquitetura da vida real não precisam ser confinados
estritamente em um aspecto ou camada, porque elementos que associam os diferentes aspectos e
camadas desempenham um papel central em uma descrição coerente da arquitetura. Por
exemplo, papéis de negócio servem como elementos intermediários entre elementos “puramente
comportamentais" e elementos “puramente estruturais", e pode depender do contexto a definição
se uma determinada peça de software é considerada parte da Camada de Aplicativo ou da
Camada de Tecnologia.
Figura 3: Framework Central do ArchiMate
A estrutura do framework permite a modelagem da empresa a partir de diferentes pontos de

vista, onde a posição dentro das células destaca as preocupações das partes interessadas. Uma
parte interessada normalmente pode ter preocupações que cobrem múltiplas células.
As dimensões do framework são como segue:

 Camadas: Os três níveis em que uma empresa pode ser modelada no ArchiMate - Negócio,
Aplicativo e Tecnologia (como descrito na Seção 2.2)
 Aspectos:
 O Aspecto da Estrutura Ativa, que representa os elementos estruturais (os atores de
negócio, componentes de aplicativo e dispositivos que exibem comportamento real; ou
seja, os “sujeitos” da ação).
 O aspecto do Comportamento, que representa o comportamento (processos, funções,
eventos e serviços) realizados pelos atores. Elementos estruturais são atribuídos aos
elementos comportamentais, para mostrar quem ou o que exibe o comportamento.
 O aspecto de Estrutura Passiva, que representa os objetos sobre os quais o
comportamento é desempenhado. Eles são, normalmente, objetos de informação na
Camada de Negócio, e objetos de dados na Camada de Aplicativo, mas eles também
podem ser usados para representar objetos físicos.
Um elemento composto, como mostrado na Figura 2, é um elemento que não se encaixa

necessariamente em um único aspecto (coluna) do framework, mas pode combinar dois ou mais
aspectos.
Observe que a linguagem ArchiMate não exige que o modelador use qualquer organização
específica, tal como a estrutura deste framework; ela é apenas uma categorização dos
elementos da linguagem.
2.5 O Framework Completo do ArchiMate
O Framework Completo do ArchiMate adiciona várias camadas e um aspecto ao Framework
Central. Os elementos de estratégia (veja Capítulo 6) são introduzidos para modelar a direção e
as escolhas estratégicas. O aspecto de motivação é introduzido em um nível genérico no próximo
capítulo, e descrito em detalhes no Capítulo 5. Os elementos de implementação e migração são
descritos no Capítulo 11. O Framework Completo do ArchiMate é mostrado na Figura 4.
Figura 4: Framework Completo do ArchiMate
Modelagem de Informações
A linguagem ArchiMate não define uma camada específica para informações; no entanto,
elementos do aspecto de estrutura passiva (por exemplo, objetos de negócios, objetos de dados
e objetos de tecnologia) são usados para representar entidades de informação. A modelagem de
informações é suportada através das várias camadas do ArchiMate.
Capítulo 3 Metamodelo Genérico
Este capítulo descreve o metamodelo genérico do ArchiMate que define a estrutura completa da
linguagem.
3.1 Elementos de Estrutura e de Comportamento

A hierarquia principal dos elementos de estrutura e comportamento da linguagem ArchiMate é
apresentada no fragmento de metamodelo da Figura 5. Ele define estes elementos de uma forma
genérica, independente de camada.
Figura 5: Hierarquia dos Elementos de Estrutura e Comportamento
Este fragmento de metamodelo genérico consiste em dois tipos principais de elementos:

elementos de estrutura ('substantivos") e de comportamento ('verbos').
Elementos de estrutura podem ser subdivididos em elementos de estrutura ativa e elementos de

estrutura passiva. Elementos de estrutura ativa podem ser ainda subdivididos em elementos de
estrutura ativa externos (também chamados de interfaces) e elementos de estrutura ativa
internos.
Elementos de comportamento podem ser subdivididos em elementos de comportamento interno,

elementos de comportamento externo (também chamados de serviços) e eventos.
Estes três aspectos - estrutura ativa, comportamento e estrutura passiva - foram inspirados pela
linguagem natural, onde uma sentença tem um sujeito (estrutura ativa), um verbo
(comportamento) e um objeto (estrutura passiva).
A Figura 6 especifica os principais relacionamentos entre os elementos de comportamento e de

estrutura definidos acima. Nesta e em outras figuras do metamodelo, o rótulo de um
relacionamento significa o papel do elemento fonte no relacionamento; por exemplo, um serviço
serve um elemento de comportamento interno.
Figura 6: Metamodelo dos Elementos de Estrutura e Comportamento
3.1.1 Elementos de Estrutura Ativa

Elementos de estrutura ativa são os sujeitos que podem desempenhar comportamento. Eles
podem ser subdivididos em elementos de estrutura ativa internos - ou seja, os atores de negócio,
componentes de aplicativo, nós etc. que realizam este comportamento - e elementos de estrutura
ativa externos - ou seja, as interfaces que expõem este comportamento para o ambiente. Uma
interface fornece uma visão externa sobre o provedor de serviços e oculta sua estrutura interna.
Um elemento de estrutura ativa interno representa uma entidade que é capaz de desempenhar
comportamento.
Elementos de estrutura ativa são representados por meio de caixas com cantos quadrados e um
ícone no canto superior direito, ou pelo seu próprio ícone.
Figura 7: Notação Genérica dos Elementos de Estrutura Ativa Internos
Um elemento de estrutura ativa externo, chamado de interface, representa um ponto de acesso

onde um ou mais serviços são fornecidos para o ambiente.
Figura 8: Notação Genérica dos Elementos de Estrutura Ativa Externos (Interface)
3.1.2 Elementos de Comportamento

Elementos de comportamento representam os aspectos dinâmicos da empresa. Semelhante aos
elementos de estrutura ativa, elementos de comportamento podem ser subdivididos em
elementos de comportamento internos e elementos de comportamento externos; ou seja, os
serviços que são expostos para o ambiente.
Um elemento de comportamento interno representa uma unidade de atividade que pode ser
desempenhada por um ou mais elementos de estrutura ativa.
Elementos de comportamento são representados na iconografia padrão por meio de caixas com
cantos arredondados e um ícone no canto superior direito, ou pelo seu próprio ícone.
Figura 9: Notação Genérica dos Elementos de Comportamento Internos
Um elemento de comportamento externo, chamado de serviço, representa um comportamento

exposto explicitamente definido.
Figura 10: Notação Genérica dos Elementos de Comportamento Externos (Serviço)
Além disso, um terceiro tipo de elemento de comportamento é definido para representar um

evento que pode ocorrer; por exemplo, para sinalizar uma mudança de estado.
Um evento representa uma mudança de estado.
Um evento pode ter um atributo de tempo que indica o momento ou momentos em que o evento
acontece. Por exemplo, isto pode ser usado para modelar cronogramas.
Figura 11: Notação Genérica de Evento
3.1.3 Elementos de Estrutura Passiva

Elementos de estrutura passiva podem ser acessados pelos elementos de comportamento.
Um elemento de estrutura passiva representa um elemento sobre o qual comportamento é

desempenhado.
Um elemento de estrutura passiva é um elemento estrutural que não pode desempenhar

comportamento. Elementos de estrutura ativa podem desempenhar comportamento sobre
elementos de estrutura passiva.
Elementos de estrutura passiva são geralmente informações ou objetos de dados, mas eles
também podem representar objetos físicos.
Figura 12: Notação Genérica dos Elementos de Estrutura Passiva
3.2 Especializações dos Elementos de Estrutura e Comportamento

As especializações dos elementos centrais estão sumarizadas na Figura 13. Dentro de cada
camada, é permitido o uso de relacionamentos de agregação e composição entre processos,
funções e interações; por exemplo, um processo pode ser composto de outros processos, funções
e/ou interações.
Figura 13: Especializações dos Elementos Centrais
Para elementos individuais de comportamento interno, é feita uma distinção entre processos e
funções.
Um processo representa uma sequência de comportamentos que alcança um resultado específico.
Figura 14: Notação Genérica de Processo
Uma função representa uma coleção de comportamentos baseada em critérios específicos, tais
como recursos necessários, competências ou localização.
Figura 15: Notação Genérica de Função
A natureza coletiva de um comportamento pode ser implícita (vários elementos de estrutura

ativa atribuídos ao mesmo comportamento interno por meio de uma junção e) ou explícita, por
meio do uso de um comportamento coletivo interno (interação) que é desempenhado por (uma
colaboração de) vários elementos de estrutura ativa.
Uma colaboração representa uma agregação de dois ou mais elementos de estrutura ativa
internos, trabalhando juntos para desempenhar algum comportamento coletivo.
Figura 16: Notação Genérica de Colaboração
Este comportamento coletivo interno pode ser modelado como uma interação.
Uma interação representa uma unidade de comportamento coletivo que deve ser desempenhada
por dois ou mais elementos de estrutura ativa internos, quer atribuídos diretamente ou agregados
em uma colaboração.
Figura 17: Notação Genérica de Interação
3.3 Elementos de Motivação
Vários elementos de motivação estão incluídos na linguagem: parte interessada, valor,
significado, motivador, avaliação, meta, resultado, princípio e requisito, o qual por sua vez tem
restrição como um subtipo. Nesta seção, é introduzido o elemento genérico de motivação. Os
elementos de motivação mais específicos são descritos no Capítulo 5.
Os elementos de motivação endereçam a forma como a Arquitetura Corporativa é alinhada com

o seu contexto, conforme descrito por estas intenções.
Um elemento de motivação representa o contexto, ou a razão por trás, da arquitetura de uma

empresa.
Figura 18: Notação Genérica dos Elementos de Motivação
Elementos de motivação são normalmente identificados usando caixas com cantos diagonais.
3.4 Elementos Compostos

Elementos compostos consistem em outros conceitos, possivelmente de múltiplos aspectos ou
camadas da linguagem. Agrupamento e localização são elementos compostos genéricos (veja a
Figura 19). Elementos compostos podem, eles mesmos, agregar ou compor outros elementos
compostos.
Figura 19: Elementos Compostos
3.4.1 Agrupamento
O elemento de agrupamento agrega ou compõe conceitos que se juntam com base em alguma
característica comum.
O elemento de agrupamento é usado para agregar ou compor um grupo arbitrário de conceitos,

os quais podem ser elementos e/ou relacionamentos do mesmo tipo ou de tipos diferentes. Um
relacionamento de agregação ou de composição é usado para ligar o elemento de agrupamento
aos conceitos agrupados. Elementos de agrupamento também podem ter outros relacionamentos
de e para eles.
Figura 20: Notação de Agrupamento
Os conceitos podem ser agregados por múltiplos grupos (sobrepostos).
3.4.2 Localização
Uma localização representa um lugar ou posição onde elementos de estrutura podem ser
localizados ou comportamento pode ser desempenhado.
O elemento de localização é utilizado para modelar os lugares onde elementos de estrutura (ativa
e passiva), tais como atores de negócio, componentes de aplicativo e dispositivos, estão
localizados. Isto é modelado por meio de um relacionamento de agregação de uma localização
para o elemento de estrutura. Uma localização também pode agregar um elemento de
comportamento, para indicar onde o comportamento é desempenhado.
Figura 21: Notação de Localização
Capítulo 4 Relacionamentos
Este capítulo descreve os relacionamentos que a linguagem ArchiMate inclui para modelar as
ligações entre objetos, conceitos e elementos. Cada um dos relacionamentos pode conectar um
conjunto predefinido de conceitos de origem e de destino (na maioria dos casos, elementos, mas,
em alguns casos, também outros relacionamentos). Muitos desses relacionamentos são
‘sobrecarregados’; ou seja, seu significado exato difere dependendo dos conceitos de origem e
de destino que eles conectam.
Os relacionamentos na linguagem ArchiMate são classificadas em quatro formas:

 Estrutural, que modela a construção ou composição estática de conceitos do mesmo tipo
ou de tipos diferentes
 Dependência, que modela como elementos são usados para suportar outros elementos
 Dinâmico, que são usados para modelar dependências comportamentais entre elementos
 Outros, que não se encaixam em uma das categorias acima
Isto é sumarizado na Figura 22.
Figura 22: Visão Geral dos Relacionamentos
Relacionamentos com Outros Relacionamentos

Em alguns casos, é permitido haver relacionamentos com outros relacionamentos; por
exemplo, para associar objetos com fluxos ou agregar relacionamentos dentro de platôs.
4.1 Relacionamentos Estruturais
Tabela 1: Relacionamentos Estruturais
Relacionamentos Estruturais Notação Nomes de Papéis
Composição Representa que um elemento consiste em um ou  composto de

mais outros conceitos.  composto em
Um relacionamento de composição é sempre
permitido entre duas instâncias do mesmo tipo de
elemento.
A interpretação de um relacionamento de
composição é que o todo ou parte do elemento
fonte é composto do todo do elemento alvo.
A entidade na extremidade com o diamante é o
“pai” da entidade na outra extremidade (o “filho”).
Uma notação alternativa é aninhar os elementos.
Agregação Representa que um elemento combina um ou mais  agrega

outros conceitos.  agregado em
Um relacionamento de agregação é sempre
permitido entre duas instâncias do mesmo tipo de
elemento.
agregação é que o todo ou parte do elemento fonte
agrega o todo do conceito alvo.
A entidade na extremidade com o diamante é o
“pai” da entidade na outra extremidade (o “filho”).
Atribuição Representa a alocação de responsabilidade,  atribuído a

desempenho de comportamento, armazenamento  tem atribuído
ou execução.
Um relacionamento de atribuição liga elementos de
estrutura ativa com unidades de comportamento
que são desempenhados por eles, atores de negócio
com papéis de negócio que são cumpridos por eles,
e nós com objetos de tecnologia.
Ele sempre aponta da estrutura ativa para o
comportamento, do comportamento para a estrutura
passiva, e da estrutura ativa para a estrutura passiva.
A notação não direcional da Especificação
ArchiMate 2.1 e anteriores, que mostra a bola preta
em ambas as extremidades do relacionamento, ainda
é permitida, mas está descontinuada.
atribuição é que o todo ou parte do elemento fonte
é atribuído ao todo do elemento alvo. Isto significa
que se, por exemplo, dois elementos de estrutura
Relacionamentos Estruturais Notação Nomes de Papéis
ativa são atribuídos ao mesmo elemento de
comportamento, qualquer um deles pode
desempenhar o comportamento completo.
Realização Representa que uma entidade desempenha um  realiza

papel crítico na criação, realização, sustentação ou  realizado por
operação de uma entidade mais abstrata.
Indica que entidades mais abstratas ("o que" ou
"lógico") são realizadas por meio de entidades mais
tangíveis (e.g., "como" ou "físico",
respectivamente).
realização é que o todo ou parte do elemento fonte
realiza o todo do elemento alvo. Isto significa que
se, por exemplo, dois elementos de comportamento
interno têm um relacionamento de realização para
o mesmo serviço, qualquer um deles pode realizar
o serviço completo. Se ambos os elementos de
comportamento interno são necessários para
realizar, o elemento agrupamento ou uma junção e
podem ser usados. Para tipos mais fracos de
contribuição positiva, neutra ou negativa para a
realização de um elemento de motivação, o
relacionamento de influência deveria ser usado.
A entidade na extremidade sem a cabeça de seta
realiza a entidade na extremidade com uma cabeça
de seta.
4.2 Relacionamentos de Dependência
Tabela 2: Relacionamentos de Dependência
Relacionamentos de Dependência Notação Nomes de Papéis
Servidão Representa que um elemento fornece sua  serve

funcionalidade para outro elemento.  servido por
Isto representa uma dependência de controle,
indicada por uma linha sólida.
O relacionamento de servidão descreve como
serviços ou interfaces oferecidas por um elemento
de comportamento ou de estrutura ativa servem
entidades no seu ambiente. Este relacionamento é
aplicado tanto para os aspectos de comportamento
como de estrutura ativa.
A entidade na extremidade sem a cabeça de seta serve
a entidade na extremidade com uma cabeça de seta.
Acesso Representa a capacidade de elementos de  acessa

comportamento e de estrutura ativa observarem ou  acessado por
agirem sobre elementos de estrutura passiva.
Isto representa uma dependência de dados,
indicada por uma linha pontilhada.
O relacionamento de acesso indica que um
processo, função, interação, serviço ou evento “faz
algo” com um elemento de estrutura passiva; por
exemplo, cria um novo objeto, lê dados do objeto,
escreve ou modifica dados no objeto ou exclui o
objeto. O relacionamento também pode ser usado
para indicar que o objeto está apenas associado
com o comportamento; por exemplo, ele modela
informações que chegam com um evento, ou a
informação que é disponibilizada como parte de
um serviço.
A cabeça de seta, se presente, indica a criação,
alteração ou uso de elementos de estrutura passiva.
Influência Representa que um elemento afeta a  influencia

implementação ou realização de algum elemento  influenciado
de motivação. por
Isto representa uma dependência de impacto,
indicada por uma linha tracejada.
Isto é usado para modelar como elementos de
motivação são influenciados por outros elementos.
Relacionamentos de Dependência Notação Nomes de Papéis
Associação Representa um relacionamento não especificado, associado com

ou um que não é representado por outro  associado a
relacionamento do ArchiMate.  associado de
Um relacionamento de associação é sempre
permitido entre dois elementos, ou entre um
relacionamento e um elemento.
A associação é não direcional por padrão, mas
pode ser direcionada.
O Relacionamento de Servidão substitui o Relacionamento Usado Por

Em comparação com as versões anteriores deste padrão, o nome do relacionamento ‘usado por’
foi alterado para 'servidão', para melhor refletir sua direção com um verbo ativo: um serviço
serve um usuário. O significado do relacionamento não foi alterado. A designação ‘usado por’
ainda é permitida, mas está descontinuada e será removida em uma futura versão do padrão.
4.3 Relacionamentos Dinâmicos

Tabela 3: Relacionamentos Dinâmicos
Relacionamentos Dinâmicos Notação Nomes de Papéis
Acionamento Representa um relacionamento temporal ou causal  aciona

entre elementos.  acionado por
acionamento é que alguma parte do elemento fonte
deveria ser completada antes que o elemento alvo
possa iniciar.
Fluxo Representa transferência de um elemento para  flui para

outro.  flui de
Isto é usado para modelar o fluxo de, por exemplo,
informações, bens ou dinheiro entre elementos de
comportamento.
4.4 Outros Relacionamentos
Tabela 4: Outros Relacionamentos
Outros Relacionamentos Notação Nomes de Papéis
Especialização Representa que um elemento é um tipo particular  especializa

de outro elemento.  especializado
por
4.5 Conectores de Relacionamento

Tabela 5: Conectores de Relacionamento
Conectores de Relacionamento Notação
Junção Usada em várias situações para conectar

relacionamentos do mesmo tipo.
Uma junção não é um relacionamento real, no
mesmo sentido que os outros relacionamentos, mas
sim um conector de relacionamentos.
Uma junção pode ter vários relacionamentos de
entrada e um relacionamento de saída, um
relacionamento de entrada e vários relacionamentos
de saída, ou vários relacionamentos de entrada e de
saída (este último caso pode ser considerado uma
contração de duas junções subsequentes).
Uma junção é usada para expressar explicitamente
que todos os elementos juntos devem participar no
relacionamento (junção e) ou que pelo menos um
dos elementos participa no relacionamento (junção
ou). A junção ou pode ser usada para expressar
tanto condições ou-inclusivas como ou-exclusivas,
o que poderia ser indicado por um modelador por
meio da nomeação da junção para refletir seu tipo.
4.6 Exemplos
4.6.1 Relacionamento de Composição
Este exemplo mostra as duas formas de expressar que a função Processamento Financeiro é
composta de três subfunções.
Exemplo 1: Composição
4.6.2 Relacionamento de Agregação

Este exemplo mostra duas formas de expressar que o Arquivo de Cliente agrega uma Apólice de
Seguro e um Sinistro de Seguro.
Exemplo 2: Agregação
4.6.3 Relacionamento de Atribuição

Este exemplo inclui as duas formas de expressar o relacionamento de atribuição. O componente
de aplicativo Financeiro é atribuído à função de aplicativo Processamento de Transações, e a
Interface de Pagamento é atribuída ao Serviço de Pagamento.
Exemplo 3: Atribuição
4.6.4 Relacionamento de Realização

Este exemplo ilustra duas formas de usar o relacionamento de realização. Uma função de
negócio Processamento de Transação realiza um Serviço de Faturamento; o objeto de negócio
Dados de Faturamento é realizado pela representação Fatura em Papel.
Exemplo 4: Realização
4.6.5 Relacionamento de Servidão

Este exemplo ilustra o relacionamento de servidão. A Interface de Pagamento serve o Cliente,
enquanto o Serviço de Pagamento serve o processo Pagar Fatura daquele cliente.
Exemplo 5: Servidão
4.6.6 Relacionamento de Acesso

Este exemplo ilustra o relacionamento de acesso. O subprocesso Criar Fatura grava/cria o objeto
de negócio Fatura; o subprocesso Enviar Fatura lê aquele objeto.
Exemplo 6: Acesso
4.6.7 Relacionamento de Influência

Este exemplo ilustra o uso do relacionamento de influência para modelar diferentes efeitos do
mesmo requisito, Atribuir Assistente Pessoal. Este tem uma forte influência positiva sobre
Reduzir a Carga de Trabalho dos Empregados, mas uma forte influência negativa sobre Reduzir
os Custos.
Exemplo 7: Influência
4.6.8 Relacionamento de Associação

Este exemplo ilustra dois relacionamentos de associação direcionados entre um contrato e dois
objetos de negócio aos quais este contrato se refere. Ele também mostra uma associação entre
um relacionamento de fluxo e este contrato, para indicar o tipo de informação que é comunicada
entre as duas funções.
Exemplo 8: Associação
4.6.9 Relacionamento de Acionamento

Este exemplo ilustra o uso do relacionamento de acionamento para modelar dependências
causais entre (sub)processos e/ou eventos.
Exemplo 9: Acionamento
4.6.10 Relacionamento de Fluxo
Este exemplo mostra uma função de negócio Avaliação de Sinistro que encaminha decisões
sobre os sinistros para a função de negócio Resolução de Sinistro. A fim de determinar a ordem
em que os sinistros devem ser avaliados, Avaliação de Sinistro usa informações de programação
recebidas da função de negócio Programação.
Exemplo 10: Fluxo
4.6.11 Relacionamento de Especialização

Este exemplo ilustra o uso do relacionamento de especialização para um processo. Neste caso
processos de negócio Emitir Seguro de Viagem e Emitir Seguro de Bagagem são uma
especialização de um processo de negócio mais genérico Emitir Seguro.
Exemplo 11: Especialização
4.6.12 Junção
Neste exemplo, a junção e no modelo é usada para indicar que as funções de negócio Vendas e
Financeira realizam em conjunto o serviço de negócio Faturamento.
Exemplo 12: Junção (E)
Neste exemplo, a junção ou é usada para indicar uma escolha: o processo de negócio Avaliar
Solicitação aciona Aceitar Solicitação ou Rejeitar Solicitação. Se, em vez disso, tivesse sido
usada a junção ‘e’, significaria que Avaliar Solicitação aciona ambos os processos.
Exemplo 13: Junção (Ou)
4.7 Derivação de Relacionamentos

Na linguagem ArchiMate, você pode derivar relacionamentos indiretos entre elementos em um
modelo, com base nos relacionamentos modelados. Isto torna possível abstrair os elementos
intermediários que não são relevantes mostrar em um determinado modelo ou visão da
arquitetura, e suporta a análise de impactos. As regras precisas para fazer tais derivações são
especificadas no Apêndice B da Especificação ArchiMate.
Derivação de relacionamentos é concebida como uma forma de criar resumos de modelos

detalhados. É uma maneira de remover (abstrair de) detalhes em um modelo, enquanto ainda faz
“declarações” válidas. Assim, derivação é sempre significativa para ir do mais detalhado para o
menos detalhado. Este mecanismo é uma das propriedades únicas da linguagem ArchiMate
quando comparada com outras linguagens de modelagem.
Aplicabilidade dos Relacionamentos Derivados
Observe que estas regras de derivação não funcionam em relacionamentos com agrupamento,
ou entre elementos centrais e outros elementos, tais como elementos de motivação, estratégia
ou implementação e migração, com exceção dos relacionamentos de realização e influência.
Um exemplo é mostrado na figura abaixo: suponha que a meta seja omitir as funções, sub-
funções e serviços de aplicativo do modelo. Neste caso, um relacionamento indireto de servidão
(seta espessa vermelha à direita) pode ser derivado desde Aplicativo Financeiro até o processo
de negócio Faturar e Cobrar (a partir da cadeia atribuição – composição – realização – servidão).
Exemplo 14: Derivação a partir de uma Cadeia de Relacionamentos
Capítulo 5 Elementos de Motivação
Elementos de motivação são usados para modelar as motivações, ou razões, que guiam o
desenho ou a mudança de uma Arquitetura Corporativa.
5.1 Metamodelo dos Elementos de Motivação

A Figura 23 dá uma visão geral dos elementos de motivação e seus relacionamentos.
Figura 23: Metamodelo dos Elementos de Motivação
5.2 Sumário dos Elementos de Motivação
A Tabela 6 dá uma visão geral dos elementos de motivação, com suas definições.
Tabela 6: Elementos de Motivação
Elemento Definição Notação
Parte O papel de um indivíduo, equipe ou organização

Interessada (ou suas classes) que representam seus interesses
nos efeitos da arquitetura.
A fim de orientar os esforços no sentido dos seus
interesses e preocupações, as partes interessadas
mudam, definem e enfatizam metas. Partes
interessadas podem também influenciar umas às
outras. Exemplos de partes interessadas são
CxOs e diretores e gerentes principais em uma
organização, o conselho de administração,
acionistas, clientes, arquitetos de negócio e de
aplicativos, e parceiros externos e reguladores.
O nome de uma parte interessada deveria ser
preferencialmente um substantivo.
Motivador Uma condição externa ou interna que motiva uma

organização a definir suas metas e implementar as
mudanças necessárias para atingi-las.
Motivadores que são associados com uma parte
interessada são frequentemente chamados de
“preocupações”.
Exemplos de motivadores internos são
satisfação do cliente e lucratividade.
Motivadores de mudança também podem ser
externos à empresa e não precisam ser associados
a uma parte interessada; por exemplo, mudanças
econômicas ou alterações na legislação.
O nome de um motivador deveria ser
Avaliação O resultado de uma análise da situação da

empresa em relação a algum motivador.
Uma avaliação pode revelar forças, fraquezas,
oportunidades ou ameaças para alguma área de
interesse. Estes precisam ser tratados por meio
do ajuste de metas existentes ou definição de
novas.
Forças e fraquezas são internas à organização.
Oportunidades e ameaças são externas à
organização.
O nome de uma avaliação deveria ser um
substantivo ou uma frase curta.
Meta Uma declaração de intenção de alto nível,

direção, ou estado final desejado para uma
organização e suas partes interessadas.
Uma meta pode representar qualquer coisa que
uma parte interessada possa desejar, como um
estado de coisas ou um valor produzido.
Exemplos de metas são: aumentar o lucro,
reduzir os tempos de espera no suporte ao
cliente, ou introduzir o gerenciamento de
portfólio online. Metas são tipicamente usadas
para medir o sucesso de uma organização.
As metas são geralmente expressas usando
palavras qualitativas; por exemplo, “aumentar”,
“melhorar” ou “facilitar”. Metas também
podem ser decompostas.
Resultado Um resultado final.

Resultados são resultados de alto nível e
orientados para o negócio, produzidos pelas
capacidades de uma organização e, por
inferência, pelos elementos centrais de sua
arquitetura que realizam estas capacidades.
Quando modelando um estado futuro, um
resultado modela um resultado final que se
espera ter sido atingido naquele momento no
futuro. Ao contrário das metas, resultados
também podem ser usados para modelar
resultados finais potencialmente indesejados;
por exemplo, para desenhar medidas de
mitigação apropriadas.
Nomes de resultados deveriam identificar
claramente os resultados que teriam sido
alcançados ou que se espera tenham sido
alcançados; por exemplo, “Primeiro lugar na
avaliação da satisfação do cliente alcançada” e
“Parcerias com os principais fornecedores
estabelecidas”. Nomes de resultados também
podem ser mais específicos; por exemplo,
“Aumento dos lucros trimestrais em 10% ano-
sobre-ano em 2020”.
Princípio Uma declaração de intenção definindo uma

propriedade geral que se aplica a qualquer
sistema em um determinado contexto na
arquitetura.
Semelhante aos requisitos, princípios definem
propriedades pretendidas dos sistemas. No
entanto, em contraste com os requisitos,
princípios são mais amplos em escopo e mais
abstratos que os requisitos.
Um princípio é motivado por alguma meta ou
motivador.
O nome de um princípio deveria ser facilmente
entendido, quer seja com uma palavra ou duas,
ou até mesmo com uma frase curta.
Requisito Uma declaração de necessidade definindo uma

propriedade que se aplica a um sistema
específico como descrito pela arquitetura.
Requisitos modelam as propriedades desses
elementos que são necessários para alcançar os
“fins” que são modelados pelas metas. Neste
sentido, requisitos representam os “meios” para
realizar as metas.
O nome de um requisito deveria ser facilmente
entendido e é geralmente uma frase curta.
Restrição Um fator que limita a realização de metas.

Em contraste com um requisito, uma restrição
não prescreve alguma funcionalidade
pretendida para o sistema a ser realizado, mas
impõe uma restrição sobre a forma como ele
opera ou pode ser realizado. Isto pode ser uma
restrição sobre a implementação do sistema
(por exemplo, tecnologias específicas que
devem ser usadas), uma restrição sobre o
processo de implementação (por exemplo,
restrições de tempo ou de orçamento), ou uma
restrição sobre uma funcionalidade do sistema
(por exemplo, restrições legais).
O nome de uma restrição deveria ser facilmente
entendido e é geralmente uma frase curta.
Significado O conhecimento ou experiência presente em, ou

a interpretação dada a, um conceito em um
determinado contexto.
Um significado representa a interpretação de
um conceito da arquitetura. Em particular, isto
é usado para descrever o significado de
elementos de estrutura passiva (por exemplo,
um documento ou mensagem).
Um significado pode ser associado a qualquer
conceito.
O nome de um significado deveria ser um
substantivo ou uma frase curta.
Valor O valor relativo, utilidade ou importância de

um conceito.
Um valor pode ser associado a qualquer
conceito.
É recomendável que o nome de um valor seja
expresso como uma ação ou estado que pode
ser realizado ou alcançado.
5.3 Exemplos
5.3.1 Parte Interessada, Motivador e Avaliação
A parte interessada Diretor de Marketing (CMO) está preocupada com o motivador Participação
de Mercado, a parte interessada Diretor Presidente (CEO) está preocupada com os motivadores
Participação de Mercado e Lucratividade, e a parte interessada Diretor Financeiro (CFO) está
preocupada com o motivador Lucratividade. O motivador Lucratividade é composto de dois
outros motivadores: Receitas e Custos. Várias avaliações estão associadas com estes
motivadores (e.g., a avaliação Participação de Mercado Está Diminuindo está associada com o
motivador Participação de Mercado), e avaliações podem influenciar umas às outras de uma
forma positiva ou negativa (e.g., Participação de Mercado Está Diminuindo resulta em Receitas
Estão Diminuindo, o que por sua vez resulta em Lucratividade Está Diminuindo).
Exemplo 15: Parte Interessada, Motivador e Avaliação
5.3.2 Meta, Resultado, Princípio, Requisito e Restrição

A meta Melhorar a lucratividade da oferta de serviços é realizada pelo resultado Lucro
aumentado em 10% no próximo ano fiscal. Este resultado é influenciado positivamente pelos
resultados Receita aumentada em 20% no próximo ano fiscal e Custo de aquisição de clientes
reduzido em 25%. O resultado Receita aumentada em 20% no próximo ano fiscal é influenciado
positivamente por um resultado Participação de mercado aumentada em 10% no próximo ano
fiscal. Há também um resultado negativo: Gastos com tecnologia aumentados em 10% Estes
resultados são realizados por meio de uma combinação de dois princípios: Servir os Clientes
onde eles estiverem e Servir os Clientes quando eles precisem de nossa ajuda. Estes dois
princípios são realizados por meio de uma combinação de dois requisitos: Aplicativos móveis
devem funcionar em todas as plataformas móveis populares e Serviços devem ser acessíveis
através de navegadores móveis. O resultado Custo de aquisição de Clientes reduzido é realizado
por um princípio Responder a mudanças nas necessidades, preferências e expectativas do Cliente
com rapidez e eficiência, que por sua vez é realizado pela restrição Aplicativos móveis devem
ser desenvolvidos através de frameworks multiplataformas.
Exemplo 16: Meta, Resultado, Princípio, Requisito e Restrição
5.3.3 Significado e Valor

Envio de Notificação tem um valor de Eficiência em Custos para a parte interessada Seguradora,
e um valor de Estar Informado e Paz de Espírito (o que é devido parcialmente a um valor de
Certeza) para a parte interessada Cliente. Diferentes significados podem ser atribuídos a vários
tipos específicos de mensagens de notificação. Uma Mensagem de Confirmação de Recebimento
tem o significado Sinistro foi Recebido, uma Mensagem de Revisão Completada tem o
significado Revisão do Sinistro Completada, e uma Mensagem de Pagamento Completado tem o
significado Sinistro foi Pago.
Exemplo 17: Significado e Valor
5.4 Relacionamentos com os Elementos Centrais

O propósito dos elementos de motivação é modelar a motivação por trás dos elementos centrais
em uma Arquitetura Corporativa. Por conseguinte, deveria ser possível relacionar os elementos
de motivação com os elementos centrais.
Como mostrado na Figura 24, um requisito (e, indiretamente, também um princípio, resultado e
meta) pode ser relacionado diretamente a um elemento de estrutura ou comportamento por meio
de um relacionamento de realização. Além disso, o relacionamento mais fraco de influência é
permitido entre estes elementos. Significado e valor podem ser associados com qualquer
elemento de estrutura ou comportamento.
Além disso, um elemento de estrutura ativa de negócio interno (ou seja, ator, papel ou
colaboração de negócio) pode ser atribuído a uma parte interessada para expressar que alguém
com uma posição operacional dentro da empresa é também uma parte interessada daquela
empresa.
Figura 24: Relacionamentos entre Elementos de Motivação e Elementos Centrais
Capítulo 6 Elementos de Estratégia
Os elementos de estratégia são introduzidos para modelar a direção e as escolhas estratégicas de
uma empresa. Eles podem ser usados para mostrar como a empresa pretende criar valor para
suas as partes interessadas e as capacidades e os recursos de que necessita para isso.
6.1 Metamodelo dos Elementos de Estratégia

A Figura 25 dá uma visão geral dos elementos de estratégia e seus relacionamentos.
Figura 25: Metamodelo dos Elementos de Estratégia
6.2 Sumário dos Elementos de Estratégia

A Tabela 7 dá uma visão geral dos elementos de estratégia, com suas definições.
Tabela 7: Elementos de Estratégia
Elemento Descrição Notação
Recurso Um ativo possuído ou controlado por um

indivíduo ou organização.
Recursos são um conceito central no campo da
gestão estratégica, economia, ciências da
computação, gerenciamento de portfólio, e
muito mais.
Recursos podem ser classificados de diferentes
formas, incluindo ativos tangíveis, ativos
intangíveis e ativos humanos. Exemplos de
ativos tangíveis incluem ativos financeiros
(dinheiro, títulos, capacidade de endividamento
etc.) e recursos físicos (instalações,
equipamento, terra, reservas minerais etc.).
Exemplos de bens intangíveis incluem ativos de
tecnologia (patentes, direitos autorais, segredos
comerciais etc.), ativos de reputação (marca,
relacionamentos etc.) e ativos culturais.
Exemplos de ativos humanos incluem
habilidades/conhecimentos, capacidade para
comunicação e colaboração, e motivação.
O nome de um recurso deveria ser
Capacidade Uma habilidade que um elemento de estrutura

ativa, tal como uma organização, pessoa ou
sistema, possui.
Capacidades focam nos resultados de negócio.
Elas fornecem uma visão de alto nível das
habilidades atuais e desejadas de uma
organização, em relação à sua estratégia e ao
seu ambiente. Elas são realizadas através de
vários elementos (pessoas, processos, sistemas,
e assim por diante) que podem ser descritos,
desenhados e implementados usando
abordagens de Arquitetura Corporativa.
Capacidades podem também ter
relacionamentos de servidão, para indicar que
uma capacidade contribui para outra.
Capacidades são muitas vezes utilizadas para o
planejamento baseado em capacidades; ou seja,
para descrever a evolução das capacidades ao
longo do tempo. Para modelar os assim
chamados incrementos de capacidade, o
relacionamento de especialização pode ser
usado para denotar que um certo incremento de
capacidade é uma versão específica daquela
capacidade.
O nome de uma capacidade deveria enfatizar “o
que fazemos” em vez de “como fazemos”.
Normalmente ele deveria ser expresso como um
substantivo composto; por exemplo,
“Gerenciamento de Projetos”,
“Desenvolvimento do Mercado”, “Engenharia
do Produto” etc.
Fluxo de Valor Uma sequência de atividades que cria um

resultado global para um cliente, parte
interessada ou usuário final.
Um fluxo de valor descreve como uma empresa
organiza as suas atividades para criar valor. Um
princípio importante dos fluxos de valor é que
valor é sempre definido a partir da perspectiva
da parte interessada - o cliente, usuário final ou
o destinatário do produto, serviço ou resultado
produzido pelo trabalho.
Fluxos de valor são tipicamente realizados por
processos de negócio e, possivelmente, outros
elementos centrais de comportamento. Os
estágios de um fluxo de valor fornecem uma
estrutura para organizar e definir os processos
de negócio, mas diferentes partes da
organização podem ter suas próprias
implementações de processos de negócio que
realizam o mesmo estágio de fluxo de valor. Da
mesma forma, um processo de negócio pode
realizar vários estágios em um fluxo de valor.
É recomendado que o nome de um fluxo de
valor seja expresso por meio de uma construção
verbo-substantivo no indicativo; por exemplo,
“Adquirir Produto de Seguro”.
Curso de ação Uma abordagem ou plano para configurar

algumas capacidades e recursos da corporação,
realizada para atingir uma meta.
Um curso de ação representa o que uma
empresa decidiu fazer. Cursos de ação podem
ser categorizados como estratégias e táticas.
Não é possível fazer uma distinção rígida entre
as duas, mas estratégias tendem a ser de longo
prazo e bastante amplas no escopo, enquanto
táticas tendem a ser de curto prazo e de escopo
mais restrito.
6.3 Exemplo de Elementos de Estratégia

O Exemplo 18 mostra a meta Aumentar o lucro, que pode ser decomposta em várias outras
metas: Reduzir Custos e Aumentar Receitas. A primeira está relacionada com a estratégia de
Excelência Operacional da empresa, modelada como um curso de ação. Isto é decomposto em
dois outros cursos de ação: Centralizar Sistemas de TI e Padronizar Produtos. Isso resulta em
dois resultados: Custos Reduzidos e Perda de Clientes, que influenciam as metas em maneiras
positivas e negativas. Isso mostra uma diferença importante entre metas e resultados: nem todos
os resultados levam às metas pretendidas.
Os cursos de ação são realizados por várias capacidades: Gerenciamento & Operações de TI e
Gerenciamento de Produtos, e os recursos adequados Recursos Humanos e Recursos de TI são
atribuídos ao primeiro. O fragmento de modelo também mostra que esses recursos estão
localizados no Escritório, em linha com o curso de ação Centralizar Sistemas de TI.
Exemplo 18: Elementos de Estratégia
O Exemplo 19 mostra um modelo de um fluxo de valor de alto nível para uma seguradora, onde
cada estágio do fluxo de valor é servido por várias capacidades. Entre estes estágios, vemos o
valor fluir por meio de itens de valor associados, e no final o resultado de negócio que este fluxo
de valor realiza para uma determinada parte interessada.
Exemplo 19: Mapeamento Cruzado Fluxo de Valor - Capacidade
6.4 Relacionamento com os Elementos de Motivação e Centrais

A Figura 26 mostra como os elementos de estratégia estão relacionados com os elementos
centrais e com os elementos de motivação. Elementos de comportamento internos e externos
podem realizar elementos de comportamento de estratégia (fluxos de valor e capacidades),
enquanto um elemento de estrutura ativa ou passiva pode realizar um recurso. Capacidades,
fluxos de valor, cursos de ação e recursos podem realizar ou influenciar requisitos (e,
indiretamente, também princípios ou metas), e um curso de ação também pode realizar ou
influenciar um resultado (e, indiretamente, também uma meta).
Figura 26: Relacionamentos entre Elementos de Estratégia e Motivação e Elementos Centrais
Capítulo 7 Camada de Negócio
Os elementos da Camada de Negócio são usados para modelar a organização operacional de uma
empresa de uma maneira independente de tecnologia, enquanto os elementos de estratégia (veja
o Capítulo 6) são usados para modelar a direção e as escolhas estratégicas da empresa.
7.1 Metamodelo da Camada de Negócio

A Figura 27 dá uma visão geral dos elementos da Camada de Negócio e seus relacionamentos.
Elemento de estrutura ativa de negócio interno, elemento de comportamento de negócio interno
e elemento de estrutura de negócio passiva são elementos abstratos; apenas suas especializações
(conforme definido nas seções a seguir) são instanciadas em modelos.
Figura 27: Metamodelo da Camada de Negócio
7.2 Elementos de Estrutura Ativa

O aspecto de estrutura ativa da Camada de Negócio se refere à estrutura estática de uma
organização, em termos das entidades que compõem a organização e seus relacionamentos. As
entidades ativas são os sujeitos (por exemplo, atores de negócio ou papéis de negócio) que
desempenham comportamentos tais como processos ou funções de negócio. Atores de negócio
podem ser pessoas individuais (por exemplo, clientes ou funcionários), mas também grupos de
pessoas (unidades organizacionais) e recursos que têm um status permanente (ou pelo menos a
longo prazo) dentro das organizações. Exemplos típicos deste último são um departamento e
uma unidade de negócio.
O elemento de interface de negócio é introduzido para modelar explicitamente os locais ou
canais (lógicos ou físicos) onde os serviços que um papel oferece para o ambiente podem ser
acessados. O mesmo serviço pode ser oferecido por meio de várias interfaces diferentes; por
exemplo, por correio eletrônico, por telefone ou pela Internet. Em contraste com a modelagem
de aplicativos, é incomum nas abordagens atuais de modelagem da Camada de Negócio
reconhecer o elemento interface de negócio.
Na Camada de Negócio, três tipos de elementos de estrutura ativa internos são definidos: ator de
negócio, papel de negócio e colaboração de negócio.
Figura 28: Elementos de Estrutura Ativa de Negócio Internos
Tabela 8: Elementos de Estrutura Ativa da Camada de Negócio
Ator de negócio Uma entidade de negócio que é capaz de

realizar comportamento.
Um ator de negócio é uma entidade de negócio
em oposição a uma entidade técnica; ou seja, ele
pertence à Camada de Negócio. Atores podem,
contudo, incluir entidades fora da organização
real; por exemplo, clientes e parceiros.
Um ator de negócio pode ser atribuído a um ou
mais papéis de negócio. Ele pode, então,
executar os comportamentos aos quais estes
papéis de negócio são atribuídos. Um ator de
negócio pode ser agregado em uma localização.
O nome de um ator de negócio deveria ser
Papel de A responsabilidade pelo desempenho de um

negócio comportamento específico, à qual um ator pode
ser atribuído, ou a parte que um ator representa
em uma ação ou evento em particular.
Papéis de negócio com certas responsabilidades
ou competências são atribuídos a processos de
negócio ou funções de negócio. Um papel de
negócio pode ser atribuído a um ou mais
processos de negócio ou funções de negócio,
enquanto um ator de negócio pode ser atribuído
a um ou mais papéis de negócio.
O nome de um papel de negócio deveria ser
Colaboração de Uma agregação de dois ou mais elementos de

negócio estrutura ativa de negócio internos que
trabalham juntos para desempenhar um
comportamento coletivo de negócio.
Uma colaboração de negócio é uma coleção
(possivelmente temporária) de papéis, atores ou
outras colaborações de negócio dentro de uma
organização que desempenha comportamento
colaborativo (interações). Uma colaboração de
negócio não precisa ter um status permanente
dentro de uma organização.
O nome de uma colaboração de negócio deveria
ser preferencialmente um substantivo. Também
é comum deixar uma colaboração de negócio
não nomeada.
Interface de Um ponto de acesso onde um serviço de

negócio negócio é disponibilizado para o ambiente.
Uma interface de negócio expõe a
funcionalidade de um serviço de negócio para
outros papéis ou atores de negócio. É, muitas
vezes, referida como um canal (telefone,
Internet, escritório local etc.). O mesmo serviço
de negócio pode ser exposto por meio de
diferentes interfaces.
O nome de uma interface de negócio deveria
ser preferencialmente um substantivo.
7.3 Elementos de Comportamento
Baseado na orientação para serviços, uma decisão crucial de desenho para a parte
comportamental do metamodelo do ArchiMate é a distinção entre o comportamento “externo” e
“interno” de uma organização.
O comportamento externamente visível é modelado pelo elemento serviço de negócio. Uma

distinção pode ser feita entre serviços de negócio “externos”, oferecidos a clientes externos, e
serviços de negócio “internos”, que oferecem funcionalidade de suporte a processos ou funções
dentro da organização.
Vários tipos de elementos de comportamento interno que podem realizar um serviço são
distinguidos: uma visão de processo e uma visão de função; são definidos dois elementos
associados com estas visões, processo de negócio e função de negócio.
Uma interação de negócio é uma unidade de comportamento similar a um processo ou função de

negócio, mas que é realizada por uma colaboração de dois ou mais papéis dentro da organização.
Um evento de negócio é algo que acontece (externamente) e pode influenciar processos, funções
ou interações de negócio.
Na Camada de Negócio, três tipos de elementos de comportamento interno são definidos:

processo de negócio, função de negócio e interação de negócio.
Figura 29: Elementos de Comportamento de Negócio Internos
Tabela 9: Elementos de Comportamento da Camada de Negócio
Processo de Uma sequência de comportamentos de negócio

negócio que alcança um resultado específico, tal como
um conjunto definido de produtos ou serviços
de negócio.
Um processo de negócio descreve o
comportamento interno, desempenhado por um
papel de negócio, que é necessário para
produzir um conjunto de produtos e serviços.
Para o consumidor, apenas os produtos e
serviços são relevantes, e o comportamento é
meramente uma caixa preta, daí a designação
"interno".
O nome de um processo de negócio deveria
indicar claramente uma sequência predefinida
de ações, usando um verbo no modo indicativo
ou uma combinação verbo-substantivo, e pode
incluir a palavra “processo”. Exemplos são
“adjudicar sinistro”, “ambientar funcionário”,
“processo de aprovação” ou “reportar registros
financeiros”.
Função de Uma coleção de comportamentos de negócio

negócio com base em um conjunto escolhido de
critérios (normalmente recursos de negócio
e/ou competências necessários), estreitamente
alinhada com uma organização, mas não
necessariamente explicitamente governada pela
organização.
Como um processo de negócio, uma função de
negócio descreve o comportamento interno
realizado por um papel de negócio. No entanto,
enquanto um processo de negócio agrupa
comportamento com base em uma sequência ou
fluxo de atividades que são necessários para
obter um produto ou serviço, uma função de
negócio geralmente agrupa comportamento
com base em recursos de negócio, habilidades,
competências, conhecimento etc. necessários.
O nome de uma função de negócio deveria
indicar claramente um comportamento bem
definido. Exemplos são: gerenciamento de
cliente, administração de sinistros, serviços
para membros, reciclagem, ou processamento
de pagamento.
Interação de Uma unidade de comportamento coletivo de

negócio negócio desempenhada por (uma colaboração
de) dois ou mais atores, papéis ou colaborações
de negócio.
Uma interação de negócio é semelhante a um
processo/função de negócio, mas enquanto um
processo/função pode ser desempenhado por
um único papel, uma interação é desempenhada
por meio de uma colaboração entre vários
papéis. Os papéis na colaboração compartilham
a responsabilidade pelo desempenho da
interação.
O nome de uma interação de negócio deveria
ser preferencialmente um verbo no modo
indicativo.
Evento de Uma mudança de estado organizacional.

negócio Processos de negócio e outros comportamentos
de negócio podem ser acionados ou
interrompidos por um evento de negócio. Além
disso, processos de negócio podem disparar
eventos que acionam outros processos, funções
ou interações de negócio. Ao contrário dos
processos, funções e interações de negócio, um
evento de negócio é instantâneo: ele não tem
duração.
Eventos podem ser originários do ambiente da
organização (por exemplo, de um cliente), mas
também podem ocorrer eventos internos
gerados por, por exemplo, outros processos
dentro da organização.
O nome de um evento de negócio deveria ser
preferencialmente um verbo no particípio
passado; e.g., sinistro recebido.
Serviço de Um comportamento explicitamente definido

negócio que um papel, ator ou colaboração de negócio
expõe para o seu ambiente.
Um serviço de negócio expõe a funcionalidade
de papéis ou colaborações de negócio para o
seu ambiente. Essa funcionalidade é acessada
por meio de uma ou mais interfaces de negócio.
O nome de um serviço de negócio deveria ser
preferencialmente um substantivo; e.g.,
“processamento de transação”. Além disso,
pode ser usado um nome que contenha
explicitamente a palavra “serviço”.
7.4 Elementos de Estrutura Passiva

O aspecto de estrutura passiva na Camada de Negócio modela elementos de estrutura passiva
(objetos de negócio) que são manipulados por comportamento, tais como processos ou funções
de negócio. As entidades passivas representam os conceitos importantes nos quais a empresa
pensa sobre um domínio.
Na Camada de Negócio, existem dois tipos principais de elementos de estrutura passiva: objeto
de negócio e representação. Além disso, um contrato, utilizado no contexto de um produto, é
uma especialização de um objeto de negócio.
Figura 30: Elementos de Estrutura Passiva de Negócio
Tabela 10: Elementos de Estrutura Passiva da Camada de Negócio
Objeto de Um conceito usado dentro de um domínio de

negócio negócio em particular.
Um objeto de negócio geralmente modela um
tipo de objeto (por exemplo, uma classe UML)
do qual podem existir várias instâncias em uso.
Apenas ocasionalmente objetos de negócio
representam instâncias reais de informação
produzida e consumida pelos elementos de
comportamento, como os processos de negócio.
Este é o caso particular dos tipos singulares; ou
seja, tipos que têm apenas uma instância.
O nome de um objeto de negócio deveria ser
Contrato Uma especificação formal ou informal de um

acordo entre um fornecedor e um consumidor
que especifica os direitos e obrigações
associados a um produto, e estabelece
parâmetros funcionais e não-funcionais para
interação.
O elemento contrato pode ser utilizado para
modelar um contrato no sentido jurídico, mas
também um acordo mais informal associado a
um produto. Pode também ser ou incluir um
acordo de nível de serviço (SLA-Service-Level
Agreement), descrevendo um acordo sobre a
funcionalidade e a qualidade dos serviços que
são parte de um produto. Um contrato é uma
especialização de um objeto de negócio.
O nome de um contrato deveria ser
Representação Uma forma perceptível da informação

transportada por um objeto de negócio.
Representações (por exemplo, mensagens ou
documentos) são os transportadores
perceptíveis de informações que estão
relacionadas a um objeto de negócio. Se for o
caso, representações podem ser classificadas de
diversas maneiras; por exemplo, em termos de
meio (eletrônico, papel, áudio etc.) ou de
formato (HTML, ASCII, PDF, RTF etc.).
O nome de uma representação deveria ser
7.5 Elementos Compostos

A Camada de Negócio contém um elemento composto: produto. Ele agrega ou compõe serviços
e elementos de estrutura passiva através das camadas da linguagem central do ArchiMate.
A Figura 31 mostra a parte aplicável do metamodelo.
Figura 31: Metamodelo de Produto
Tabela 11: Elementos Compostos da Camada de Negócio
Produto Uma coleção coerente de serviços e/ou

elementos de estrutura passiva, acompanhado
de um contrato/conjunto de acordos, que é
oferecido como um todo para os clientes
(internos ou externos).
Isto abrange tanto os produtos intangíveis,
baseados em serviços, ou produtos de
informação, que são comuns em organizações
com uso intensivo de informações, como
produtos físicos tangíveis.
“Comprar” um produto dá ao cliente o direito
de usar os serviços associados.
O nome de um produto é normalmente o nome
que é usado na comunicação com os clientes,
ou, possivelmente, um substantivo mais
genérico (por exemplo, “seguro de viagem”).
7.6 Exemplos
7.6.1 Elementos de Estrutura Ativa de Negócio
O Centro de Atendimento da ArchiSurance, modelado como um ator de negócio, é composto por
três empregados, também modelados como atores de negócio: Greg, Joan e Larry. O Centro de
Atendimento tem três interfaces de negócio para servir os clientes: Telefone, eMail e Web Chat.
Greg desempenha o papel de negócio de Analista de Sinistro de Seguro de Viagem, Joan
desempenha o papel de negócio de Especialista de Produto de Seguro Residencial, e Larry
desempenha o papel de negócio de Representante do Serviço de Atendimento ao Cliente. Os
dois primeiros papéis de negócio são especializações de um papel de negócio Especialista.
Adjudicação de Sinistro de Alto Risco é uma colaboração de negócio entre dois papéis de
negócio: Especialista e Representante do Serviço ao Cliente.
Exemplo 20: Elementos de Estrutura Ativa de Negócio
7.6.2 Elementos de Comportamento de Negócio

Administração de Sinistros é uma função de negócio composta de vários processos de negócio e
uma interação de negócio. Esta função de negócio realiza um serviço de negócio Processamento
de Sinistros. Um evento de negócio Sinistro Preenchido aciona o primeiro processo de negócio,
Aceitar Sinistro, que por sua vez aciona um processo de negócio Atribuir Sinistro. Dependendo
do tipo de sinistro, ou o processo de negócio Adjudicar Sinistro Padrão, ou a interação de
negócio Adjudicar Sinistro de Alto Risco, é executado. Adjudicar Sinistro de Alto Risco é uma
interação de negócio, pois, de acordo com a política da empresa, duas pessoas deveriam ser
sempre envolvidas nesta atividade para minimizar o risco de fraude. Após a adjudicação, os
processos de negócio Notificar o Cliente e Pagar o Sinistro são executados em paralelo e,
quando ambos tiverem terminado, o processo de negócio Fechar Sinistro é acionado.
Exemplo 21: Elementos de Comportamento de Negócio
7.6.3 Elementos de Estrutura Passiva de Negócio

O objeto de negócio Sinistro pode ser realizado por qualquer uma das três representações físicas
seguintes (em diferentes fases do processo de Administração de Sinistros): Formulário de
Submissão, Sumário do Arquivo de Sinistro, ou Aviso de Sinistro. Todas estas representações se
referem a uma representação Sumário da Apólice, a qual realiza um contrato Apólice de Seguro.
Exemplo 22: Elementos de Estrutura Passiva de Negócio
7.6.4 Elemento Composto de Negócio: Produto

Um produto Seguro consiste em um contrato Apólice de Seguro e um serviço de negócio
Serviço ao Cliente, que agrega quatro outros serviços de negócio: Aplicação, Renovação,
Processamento de Sinistros e Apelação. Um produto Seguro de Automóvel é uma especialização
do produto genérico Seguro, com um serviço de negócio adicional Dirija Bem e Economize e o
respectivo contrato Acordo Dirija Bem e Economize.
Exemplo 23: Elemento Composto de Negócio: Produto
Capítulo 8 Camada de Aplicativo
Elementos da Camada de Aplicativo são normalmente usados para modelar a Arquitetura de
Aplicativo que descreve a estrutura, comportamento e interação dos aplicativos da empresa.
8.1 Metamodelo da Camada de Aplicativo

A Figura 32 dá uma visão geral dos elementos da Camada de Aplicativo e seus relacionamentos.
Sempre que aplicável, a inspiração foi buscada na analogia com a Camada de Negócio.
Figura 32: Metamodelo da Camada de Aplicativo

O principal elemento de estrutura ativa para a Camada de Aplicativo é o componente de
aplicativo. Este conceito é utilizado para modelar qualquer entidade estrutural na Camada de
Aplicativo. Ele pode descrever componentes de software (reutilizáveis) que podem ser parte de
um ou mais aplicativos, e também aplicativos de software completos, sub-aplicativos ou
sistemas de informação.
O elemento colaboração de aplicativo é introduzido aqui porque os inter-relacionamentos dos

componentes são importantes em uma arquitetura de aplicativos. Ele é definido como uma
coleção de componentes de aplicativo que desempenham interações de aplicativo.
Figura 33: Elementos de Estrutura Ativa de Aplicativo Internos
Uma interface de aplicativo é o canal (lógico) através do qual os serviços de um componente podem
ser acessados. O conceito interface de aplicativo pode ser usado para modelar tanto interfaces
aplicativo-para-aplicativo, que oferecem serviços de aplicativo internos, como interfaces aplicativo-
para-negócio (e/ou interfaces de usuário), que oferecem serviços de aplicativo externos.
Tabela 12: Camada de Aplicativo - Elementos de Estrutura Ativa
Componente de Um encapsulamento de funcionalidade de

aplicativo aplicativo alinhado com a estrutura de
implementação, o qual é modular e substituível.
Um componente de aplicativo é uma unidade
autocontida. Como tal, é implementável de
forma independente, reutilizável e substituível.
Um componente de aplicativo desempenha uma
ou mais funções de aplicativo. Ele encapsula
seu comportamento e dados, expõe serviços, e
torna-os disponíveis por meio de interfaces.
O nome de um componente de aplicativo
deveria ser preferencialmente um substantivo.

aplicativo estrutura ativa de aplicativo internos que
comportamento coletivo de aplicativo.
Uma colaboração de aplicativo especifica quais
componentes de aplicativo e/ou outras
colaborações de aplicativo cooperam para
desempenhar alguma tarefa. O comportamento
colaborativo, incluindo, por exemplo, o padrão
de comunicação destes componentes, é
modelado por uma interação de aplicativo. Uma
colaboração de aplicativo geralmente modela
uma colaboração temporária ou lógica de
componentes de aplicativo e não existe como
uma entidade separada na empresa.
O nome de uma colaboração de aplicativo
Interface de Um ponto de acesso onde serviços de aplicativo

aplicativo são disponibilizados para um usuário, outro
componente de aplicativo ou um nó.
Uma interface de aplicativo especifica como a
funcionalidade de um componente pode ser
acessada por outros elementos. Uma interface
de aplicativo expõe serviços de aplicativo para
o ambiente. O mesmo serviço de aplicativo
pode ser exposto por meio de diferentes
interfaces, e a mesma interface pode expor
vários serviços.
O nome de uma interface de aplicativo deveria

Comportamento na Camada de Aplicativo é descrito de uma forma semelhante ao comportamento na
Camada de Negócio. Como na Camada de Negócio, é feita uma distinção entre o comportamento
externo dos componentes de aplicativo, em termos de serviços de aplicativo, e o comportamento
interno desses componentes; por exemplo, as funções de aplicativo que realizam estes serviços.
Um serviço de aplicativo é definido como uma unidade de funcionalidade externamente visível,

fornecido por um ou mais componentes, exposto por meio de interfaces bem definidas, e
significativo para o ambiente. A funcionalidade que um programa de computador interativo fornece
por meio de uma interface de usuário também é modelada utilizando um serviço de aplicativo,
exposta por uma interface aplicativo-para-negócio representando a interface com o usuário. Serviços
de aplicativo internos são expostos por meio de uma interface aplicativo-para-aplicativo.
Uma função de aplicativo descreve o comportamento interno de um componente necessário para

realizar um ou mais serviços de aplicativo. Um processo de aplicativo modela um ordenamento
de comportamento de aplicativo, como contrapartida de um processo de negócio.
Uma interação de aplicativo é o comportamento de uma colaboração de dois ou mais componentes

de aplicativo. Uma interação de aplicativo é comportamento externo a partir da perspectiva de cada
um dos componentes participantes, mas o comportamento é interno à colaboração como um todo.
Figura 34: Elementos de Comportamento de Aplicativo Internos
Tabela 13: Camada de Negócio - Elementos de Comportamento
Função de Um comportamento automatizado que pode ser

aplicativo realizado por um componente de aplicativo.
Uma função de aplicativo descreve o
comportamento interno de um componente de
aplicativo. Se este comportamento é exposto
externamente, isto é feito por meio de um ou
mais serviços.
O nome de uma função de aplicativo deveria
ser preferencialmente um substantivo; e.g.,
“contabilização”.

aplicativo aplicativo realizado por (uma colaboração de)
dois ou mais componentes de aplicativo.
Uma interação de aplicativo descreve o
comportamento coletivo que é desempenhado
pelos componentes que participam em uma
colaboração de aplicativo. Uma interação de
aplicativo também pode especificar o
comportamento conjunto necessário para
realizar um serviço de aplicativo.
O nome de uma interação de aplicativo deveria
identificar claramente uma série de
comportamentos de aplicativo; por exemplo,
"Criar perfil do Cliente" ou "Atualizar registros
dos clientes".
Processo de Uma sequência de comportamentos de

aplicativo aplicativo que alcança um resultado específico.
Um processo de aplicativo descreve o
comportamento interno realizado por um
componente de aplicativo, que é necessário
para realizar um conjunto de serviços. Para o
consumidor (humano ou automatizado), apenas
os serviços são relevantes e o comportamento é
meramente uma caixa preta, daí a designação
“interno”.
O nome de um processo de aplicativo deveria
comportamentos de aplicativo usando um verbo
ou uma combinação verbo-substantivo; por
exemplo, “Processo de adjudicação de sinistro”
ou “Atualizar livro razão”.
Evento de Uma mudança de estado de aplicativo.

aplicativo Funções de aplicativo e outros comportamentos
de aplicativo podem ser acionados ou
interrompidos por um evento de aplicativo.
Além disso, comportamento de aplicativo pode
disparar eventos que acionam outros
comportamentos de aplicativo. Ao contrário dos
processos, funções e interações, um evento é
instantâneo: ele não tem duração. Os eventos
podem ser originários do ambiente da
organização (por exemplo, a partir de um
aplicativo externo), mas também podem ocorrer
eventos internos gerados por, por exemplo,
outros aplicativos dentro da organização.
O nome de um evento de aplicativo deveria ser
passado; e.g., “sinistro recebido”.
Serviço de Um comportamento de aplicativo exposto

aplicativo explicitamente definido.
Um serviço de aplicativo expõe a
funcionalidade dos componentes para o seu
ambiente. Esta funcionalidade é acessada por
meio de uma ou mais interfaces de aplicativo.
Um serviço de aplicativo é realizado por uma
ou mais funções de aplicativo que são
desempenhadas pelo componente. Ele pode
requerer, usar e produzir objetos de dados.
O nome de um serviço de aplicativo deveria ser
preferencialmente um substantivo; por
exemplo, ”processamento de transação”. Além
disso, pode ser usado um nome que contenha
explicitamente a palavra “serviço”.
A contrapartida passiva do componente de aplicativo na Camada de Aplicativo é chamada de
objeto de dados. Um objeto de dados é uma representação de um objeto de negócio, como uma
contrapartida do elemento Representação na Camada de Negócio.
Tabela 14: Camada de Aplicativo - Elementos de Estrutura Passiva
Objeto de dados Dados estruturados para processamento

automatizado.
Um objeto de dados deveria ser uma peça de
informação autocontida com um sentido claro
para o negócio, não apenas para o nível do
aplicativo. Exemplos típicos de objetos de
dados são o registro de um cliente, um banco de
dados de cliente ou um sinistro de seguro.
O nome de um objeto de dados deveria ser
8.5 Exemplos
8.5.1 Elementos de Estrutura Ativa de Aplicativo
A colaboração de aplicativo Venda de Seguro de Viagem Online agrega dois componentes de
aplicativo: Cotação e Compra. A colaboração de aplicativo fornece uma interface de aplicativo
Interface de Serviços Web que serve outro componente de aplicativo Website de Viagens.
Exemplo 24: Elementos de Estrutura Ativa de Aplicativo
8.5.2 Elementos de Comportamento de Aplicativo
A interação de aplicativo Compra de Seguro de Viagem é composta de duas funções de
aplicativo: Preparação de Cotação, realizando um serviço de aplicativo Obtenção de Cotação, e
Finalização de Compra, realizando um serviço de aplicativo Compra de Seguro Cotado. Estas
funções de aplicativo modelam o comportamento cooperativo dos componentes de aplicativo
Cotação e Compra, modelados como a colaboração de aplicativo Venda de Seguro de Viagem
Online no Exemplo 24. Um evento de aplicativo Cotação solicitada aciona um processo de
aplicativo Obter seguro de viagem, que é servido pelos dois serviços de aplicativo acima
referidos.
Exemplo 25: Elementos de Comportamento de Aplicativo
8.5.3 Elementos de Estrutura Passiva de Aplicativo

Um objeto de dados Cotação de seguro on-line é composto por três outros objetos de dados:
Preço Cotado, Termos e Condições e Certificado de Autenticidade. Cotação de Seguro de
Automóvel e Cotação de Seguro de Viagem são duas especializações do objeto de dados
Cotação de Seguro Online. Cotação de Seguro de Viagem contém um objeto de dados adicional
Itinerário Comprado.
Exemplo 26: Elementos de Estrutura Passiva de Aplicativo
Capítulo 9 Camada de Tecnologia
Os elementos da Camada de Tecnologia são usados tipicamente para modelar a Arquitetura de
Tecnologia da empresa, descrevendo a estrutura e o comportamento da infraestrutura tecnológica
da empresa.
9.1 Metamodelo da Camada de Tecnologia

A Figura 35 dá uma visão geral dos elementos da Camada de Tecnologia e seus
relacionamentos. Sempre que aplicável, a inspiração foi buscada na analogia com as Camadas de
Negócio e de Aplicativo.
Figura 35: Metamodelo da Camada de Tecnologia

O principal elemento de estrutura ativa para a Camada de Tecnologia é o nó. Este elemento é
utilizado para modelar entidades estruturais nesta camada. Uma interface de tecnologia é o local
(lógico) onde os serviços de tecnologia oferecidos por um nó podem ser acessados por outros
nós ou por componentes de aplicativo a partir da Camada de Aplicativo.
Os inter-relacionamentos dos componentes da Camada de Tecnologia são formados

principalmente pela infraestrutura de comunicação. Um caminho modela o relacionamento entre
dois ou mais nós, por meio do qual estes nós podem trocar informações. A realização física de
um caminho é modelada com uma rede de comunicação; ou seja, um meio de comunicação
físico entre dois ou mais dispositivos (ou outras redes).
Figura 36: Elementos de Estrutura Ativa de Tecnologia
Tabela 15: Camada de Tecnologia - Elementos de Estrutura Ativa
Nó Um recurso computacional ou físico que

hospeda, manipula ou interage com outros
recursos computacionais ou físicos.
Nós são elementos de estrutura ativa que
desempenham comportamento de tecnologia e
executam, armazenam e processam objetos de
tecnologia, tais como artefatos (ou materiais).
Nós podem ser interligados por caminhos.
O nome de um nó deveria ser preferencialmente
um substantivo.
Dispositivo Um recurso físico de TI no qual software de

sistema e artefatos podem ser armazenados ou
implantados para execução.
Um dispositivo é uma especialização de um nó
que representa um recurso de TI físico com
capacidade de processamento. Ele é tipicamente
usado para modelar sistemas de hardware,
como mainframes, PCs ou roteadores.
Geralmente, eles são parte de um nó em
conjunto com software de sistema. Dispositivos
podem ser compostos; ou seja, consistirem em
sub-dispositivos.
O nome de um dispositivo deveria ser
preferencialmente um substantivo se referindo
ao tipo de hardware; por exemplo, “Mainframe
IBM Sistema z”.
Software de Software que fornece ou contribui para um

sistema ambiente para armazenar, executar e usar
software ou dados implementados neste
ambiente.
Software de sistema é uma especialização de
um nó que é usado para modelar o ambiente de
software em que artefatos são executados. Estes
podem ser, por exemplo, um sistema
operacional, um servidor de aplicativo JEE, um
sistema de banco de dados ou um motor de
fluxo de trabalho.
O nome de um software de sistema deveria ser
ao tipo de ambiente de execução; por exemplo,
“Servidor JEE”.

tecnologia estrutura ativa de tecnologia internos que
comportamento coletivo de tecnologia.
Uma colaboração de tecnologia especifica quais
nós e/ou outras colaborações de tecnologia
cooperam para desempenhar alguma tarefa. O
comportamento colaborativo, incluindo, por
exemplo, o padrão de comunicação destes nós,
é modelado por uma interação de tecnologia.
Uma colaboração de tecnologia geralmente
modela uma colaboração temporária ou lógica
de nós e não existe como uma entidade
separada na empresa.
O nome de uma colaboração de tecnologia
Interface de Um ponto de acesso onde serviços de

tecnologia tecnologia oferecidos por um nó podem ser
acessados.
Uma interface de tecnologia especifica como
serviços de tecnologia podem ser acessados por
outros nós. Uma interface de tecnologia expõe
um serviço de tecnologia para o ambiente. O
mesmo serviço pode ser exposto por meio de
diferentes interfaces.
O nome de uma interface de tecnologia deveria
Caminho Uma ligação entre dois ou mais nós, por meio

do qual estes nós podem trocar dados, energia
ou materiais.
Um caminho é utilizado para modelar os
relacionamentos lógicos de comunicação (ou
distribuição) entre nós. Ele é realizado por uma
ou mais redes de comunicação (ou redes de
distribuição, quando modelando elementos
físicos), que representam os enlaces físicos de
comunicação (ou de distribuição). As
propriedades (por exemplo, largura de banda,
latência) de um caminho geralmente são
agregadas a partir destas redes subjacentes.
Rede de Um conjunto de estruturas que conecta nós para

comunicação transmissão, roteamento e recepção de dados.
Uma rede de comunicação representa a
infraestrutura física de comunicação.

Elementos de comportamento na Camada de Tecnologia são semelhantes aos elementos de
comportamento nas outras duas camadas. Como nas camadas de Negócio e Aplicativo, é feita
uma distinção entre o comportamento externo dos nós em termos de serviços de tecnologia, e o
comportamento interno desses nós; ou seja, as funções de tecnologia, processos de tecnologia e
interações de tecnologia que realizam estes serviços.
Figura 37: Elementos de Comportamento de Tecnologia Internos
Tabela 16: Camada de Tecnologia - Elementos de Comportamento
Função de Um conjunto de comportamentos de tecnologia

Tecnologia que pode ser desempenhado por um nó.
Uma função de tecnologia descreve o
comportamento interno de um nó; para o
usuário de um nó que desempenha uma função
de tecnologia, esta função é invisível. Se este
comportamento é exposto externamente, isto é
feito por meio de um ou mais serviços de
tecnologia.
Processo de Uma sequência de comportamentos de

Tecnologia aplicativo que alcança um resultado específico.
Um processo de tecnologia descreve o
comportamento interno de um nó; para o
usuário deste nó este comportamento é
invisível. Se este comportamento é exposto
externamente, isto é feito por meio de um ou
mais serviços de tecnologia.
O nome de um processo de tecnologia deveria
comportamentos de tecnologia usando um
verbo no modo indicativo ou uma combinação
verbo-substantivo; por exemplo, “Inicializar o
sistema” ou “Replicar o banco de dados”.

Tecnologia tecnologia desempenhado por (uma
colaboração de) dois ou mais nós.
Uma interação de tecnologia descreve o
comportamento coletivo que é desempenhado
por dois ou mais nós, possivelmente pela sua
participação em uma colaboração de tecnologia.
Isto pode incluir, por exemplo, o padrão de
comunicação entre estes componentes. Uma
interação de tecnologia também pode
especificar o comportamento conjunto
necessário para realizar um serviço de
tecnologia.
O nome de uma interação de tecnologia deveria
comportamentos de tecnologia; por exemplo,
"Criar o perfil do Cliente" ou "Atualizar os
registros dos clientes".
Evento de Uma mudança de estado na tecnologia.

tecnologia Funções de tecnologia e outros
comportamentos de tecnologia podem ser
acionados ou interrompidos por um evento de
tecnologia. Além disso, funções de tecnologia
podem disparar eventos que acionam outros
comportamentos de tecnologia. Ao contrário
dos processos, funções e interações, um evento
é instantâneo: ele não tem duração.
O nome de um evento de tecnologia deveria ser
passado; e.g., “mensagem recebida”.
Serviço de Um comportamento de tecnologia exposto

tecnologia explicitamente definido.
Um serviço de tecnologia expõe a
funcionalidade de um nó para o seu ambiente.
Esta funcionalidade é acessada por meio de
uma ou mais interfaces de tecnologia. Ele pode
requerer, usar e produzir artefatos.
O nome de um serviço de tecnologia deveria ser
preferencialmente um substantivo; e.g.,
“mensageria”. Além disso, pode ser usado um
nome que contenha explicitamente a palavra
“serviço”.
Objetos de tecnologia modelam os elementos de estrutura passiva que são utilizados e processados
pela infraestrutura. Objetos de tecnologia representam os objetos “físicos” manipulados pela
infraestrutura de uma empresa. Objetos de tecnologia são elementos abstratos; ou seja, eles não são
instanciados em modelos, mas servem como tipo genérico das coisas manipuladas pela Camada de
Tecnologia. Isto pode incluir tanto artefatos (por exemplo, arquivos) como material físico.
Figura 38: Elementos de Estrutura Passiva de Tecnologia
Objetos de tecnologia podem ser acessados por comportamento de tecnologia (funções, processos,
interações, eventos e serviços). Um objeto de tecnologia pode ter relacionamentos de associação,
especialização, agregação ou composição com outros objetos de tecnologia. Um objeto de tecnologia
pode realizar um objeto de dados ou objeto de negócio. Ele pode ser um artefato ou material (dos
elementos físicos). O nome de um objeto de tecnologia deveria ser preferencialmente um substantivo.
Tabela 17: Camada de Tecnologia - Elementos de Estrutura Passiva
Artefato Uma peça de dados que é usada ou produzida em

um processo de desenvolvimento de software, ou
pela implantação e operação de um sistema.
Um artefato representa um elemento “físico” no
mundo da TI. Artefato é uma especialização de
um objeto de tecnologia. Ele é geralmente usado
para modelar produtos (de software) como
arquivos-fonte, executáveis, scripts, tabelas de
banco de dados, mensagens, documentos,
especificações e arquivos de modelo. Uma
instância (cópia) de um artefato pode ser
implantada em um nó. Um artefato poderia ser
usado para representar um componente de dados
físico que realiza um objeto de dados.
O nome de um artefato deveria ser
preferencialmente o nome do arquivo que ele
representa; por exemplo, “order.jar”.
9.5 Exemplos
9.5.1 Elementos de Estrutura Ativa de Tecnologia
Dois dispositivos Blade System estão conectados a uma rede de comunicação Rede do
Datacenter. Esta, por sua vez, está ligada a outra rede de comunicação Rede de Longa Distância
através de um nó Switch do Datacenter. As duas redes de comunicação, em conjunto, realizam
um caminho Caminho de Replicação de Dados. Tanto os dispositivos Blade System como o nó
Switch do Datacenter têm uma interface de tecnologia Interface de Gerenciamento. O
dispositivo Blade System 1 implementa o software de sistema Hypervisor para virtualização de
hardware. Dois componentes de software de sistema são implantados no Hypervisor: um
Sistema Operacional de Código Aberto e um Sistema Operacional Proprietário, criando dois
hosts virtuais, modelados como os nós Host Virtual de Cotação e Host Virtual de Compra.
Exemplo 27: Elementos de Estrutura Ativa de Tecnologia
9.5.2 Elementos de Comportamento de Tecnologia

Um evento de tecnologia Banco de Dados Atualizado aciona um processo de tecnologia Replicar
Dados Remotos, que é servido por um serviço de tecnologia Replicação de Atualizações do
Banco de Dados. Este serviço de tecnologia é realizado por uma função de tecnologia
Replicação de Banco de Dados, que é composta por outras quatro funções de tecnologia:
Administração da Replicação, Tratamento de Atualizações Locais, Tratamento de Atualizações
Remotas e Monitoramento do Status da Replicação. Existem fluxos de informação a partir da
função de tecnologia Administração da Replicação para as outras três funções de tecnologia.
Exemplo 28: Elementos de Comportamento de Tecnologia
9.5.3 Elemento de Estrutura Passiva de Tecnologia: Artefato

Um artefato Arquivamento Web (que pode realizar um componente de aplicativo) é composto de
dois outros artefatos: Arquivamento Java de Acesso ao Banco de Dados e Arquivamento Java da
Lógica de Negócio. Duas Especializações do artefato Arquivamento Web são um Arquivamento
Web do Aplicativo de Compra e um Arquivamento Web do Aplicativo de Cotação. Um artefato
Banco de Dados de Seguro de Viagem (que pode realizar um objeto de dados) está associado
com o artefato Arquivamento Web.
Exemplo 29: Elemento de Estrutura Passiva de Tecnologia: Artefato
Capítulo 10 Elementos Físicos
Os elementos físicos são incluídos na Camada de Tecnologia para modelar o mundo físico.
10.1 Metamodelo dos Elementos Físicos

A Figura 39 dá uma visão geral dos elementos físicos e seus relacionamentos. Estes são
baseados na Camada de Tecnologia.
Figura 39: Metamodelo dos Elementos Físicos

O elemento equipamento é o principal elemento de estrutura ativa dentro dos elementos físicos.
Ele é usado para modelar quaisquer máquinas, ferramentas, instrumentos ou implementos
físicos.
Os inter-relacionamentos dos elementos físicos são formados, principalmente, pela infraestrutura

logística. O elemento caminho da Camada de Tecnologia modela o relacionamento entre dois ou
mais nós, por meio do qual estes nós podem trocar informações ou materiais. A realização física
de um caminho é modelada com uma rede de distribuição; ou seja, uma conexão física entre
duas ou mais peças de equipamento (ou outras redes físicas). Isto pode ser usado para modelar,
por exemplo, redes ferroviárias ou rodoviárias, redes de abastecimento de água, grades de
energia ou redes de gás.
Tabela 18: Elementos Físicos - Estrutura Ativa
Equipamento Uma ou mais máquinas, ferramentas ou

instrumentos físicos que podem criar,
armazenar, mover ou transformar materiais.
Equipamento engloba todos os elementos de
processamento ativos que realizam os processos
físicos nos quais materiais (que são um tipo
especial de objeto de tecnologia) são utilizados
ou transformados. Equipamento é uma
especialização do elemento nó da Camada de
Tecnologia. Assim sendo, é possível modelar
nós que são formados por uma combinação de
infraestrutura de TI (dispositivos, software de
sistema) e infraestrutura física (equipamentos);
por exemplo, um scanner de ressonância
magnética em um hospital, uma fábrica com os
seus sistemas de controle etc.
O nome de uma peça de equipamento deveria
Instalação Uma estrutura ou ambiente físico.

Uma instalação é uma especialização de um nó.
Ela representa um recurso físico que tem a
capacidade de facilitar (por exemplo, abrigar ou
sediar) o uso de equipamentos. Ele é
geralmente usado para modelar fábricas,
edifícios ou construções que têm um papel
importante em processos de produção ou
distribuição. Exemplos de instalações incluem
uma fábrica, um laboratório, um armazém, um
shopping, uma adega ou uma nave espacial.
Instalações podem ser compostas; ou seja,
consistirem em sub-instalações.
O nome de uma instalação deveria ser
ao tipo de instalação; por exemplo, “Refinaria
de petróleo de Rotterdam”.
Rede de Uma rede física usada para transportar

distribuição materiais ou energia.
Uma rede de distribuição representa a
infraestrutura física de distribuição e transporte.
Ela representa a realização física dos caminhos
lógicos entre os nós.
Nenhum elemento de comportamento físico separado está definido. Os elementos de
comportamento da Camada de Tecnologia (função, processo, interação, serviço e evento de
tecnologia) são utilizados para modelar o comportamento de todos os nós, incluindo equipamento
físico. Uma vez que equipamento será frequentemente controlado por computador, ou de alguma
forma tem uma relação próxima com a TI (por exemplo, Internet das Coisas), seu comportamento
pode ser descrito de forma integral usando os conceitos de comportamento de tecnologia
existentes.

Tabela 19: Elementos Físicos - Estrutura Passiva
Material Matéria física tangível ou energia.

Material é usado, geralmente, para modelar
matérias-primas e produtos físicos, e também
fontes de energia, tais como, combustível e
eletricidade. Material pode ser acessado por
processos físicos.
O nome de um material deveria ser
10.5 Exemplo de Elementos Físicos

Uma Linha de Montagem, modelada como equipamento e instalado em uma instalação Planta de
Manufatura, faz uso dos materiais Placa de Circuito Pré-montada, Antena Interna e Estojo de
Plástico, para produzir o material Aparelho de Telemática Veicular. O aparelho, inicialmente
localizado na instalação Planta de Manufatura, é em seguida transportado para as instalações
Centro de Distribuição Nacional e Centro de Distribuição Local, fazendo uso das redes de
distribuição Transporte Marítimo e Transportadora Local. Estas redes de distribuição, em
conjunto, realizam o caminho Frete Intermodal.
Exemplo 30: Elementos Físicos
Capítulo 11 Relacionamentos entre as
Camadas Centrais
Uma questão central em Arquitetura Corporativa é o alinhamento negócio-TI: como as Camadas
de Negócio, Aplicativo e Tecnologia podem ser combinadas? Este capítulo descreve os
relacionamentos que a linguagem ArchiMate oferece para modelar as ligações entre negócio,
aplicativos e tecnologia.
11.1 Alinhamento da Camada de Negócio e Camadas Inferiores

A Figura 40 mostra os relacionamentos entre os elementos da Camada de Negócio, Camada de
Aplicativo e Camada de Tecnologia. Existem dois tipos principais de relacionamentos entre
estas camadas:
1. Relacionamentos de servidão, entre serviço de aplicativo e os diferentes tipos de elementos
de comportamento de negócio, e entre interface de aplicativo e papel de negócio; vice-versa,
relacionamentos de servidão entre serviço de negócio e elementos de comportamento de
aplicativo, e entre interface de negócio e componente de aplicativo. Estes relacionamentos
representam os aspectos comportamentais e estruturais do suporte do negócio pelos
aplicativos.
2. Relacionamentos de realização, de um processo ou função de aplicativo para um processo
ou função de negócio, ou de um objeto de dados, ou objeto de tecnologia, para um objeto de
negócio, para indicar que o objeto de dados é uma representação digital do objeto de negócio
correspondente, ou que objeto de tecnologia é uma representação física do objeto de
negócio.
Além disso, pode haver um relacionamento de agregação entre um produto e um serviço de

aplicativo ou de tecnologia, e um objeto de dados ou de tecnologia, para indicar que estes
serviços ou objetos podem ser oferecidos diretamente para um cliente como parte do produto.
Figura 40: Relacionamentos entre Elementos da Camada de Negócio e da Camada de Aplicativo e
Tecnologia
11.2 Alinhamento das Camadas de Aplicativo e Tecnologia

A Figura 41 mostra os relacionamentos entre os elementos da Camada de Aplicativo e Camada
de Tecnologia. Existem dois tipos de relacionamentos entre estas camadas:
1. Relacionamentos de servidão, entre serviço de tecnologia e os diferentes tipos de elementos
de comportamento de aplicativo, e entre interface de tecnologia e componente de aplicativo;
vice-versa, relacionamentos de servidão entre serviço de aplicativo e elementos de
comportamento de tecnologia, e entre interface de aplicativo e nó. Estes relacionamentos
representam os aspectos comportamentais e estruturais do uso da infraestrutura tecnológica
pelos aplicativos.
2. Relacionamentos de realização a partir do processo ou função de tecnologia para processo
ou função de aplicativo, de objeto de tecnologia para objeto de dados, para indicar que o
objeto de dados é realizado por, por exemplo, um arquivo de dados físico, de objeto de
tecnologia para componente de aplicativo, para indicar que um arquivo de dados físico é um
executável que realiza um aplicativo ou parte de um aplicativo. (Observação: Neste caso, um
artefato representa um componente “físico” que é implantado em um nó; isto é modelado
por meio de um relacionamento de atribuição. Um componente de aplicativo (lógico) é
realizado por um artefato e, indiretamente, pelo nó no qual o artefato é implantado.)
Figura 41: Relacionamentos entre os Elementos da Camada de Aplicativo e Camada de Tecnologia
Devido às relações derivadas, também é possível desenhar relacionamentos diretamente entre as
Camadas de Negócio e Tecnologia. Por exemplo, se um objeto de negócio é realizado por um
objeto de dados, que por sua vez é realizado por um objeto de tecnologia, este objeto de
tecnologia indiretamente realiza o objeto de negócio.
11.3 Exemplo de Relacionamento Entre Camadas

O Exemplo 31 mostra como os relacionamentos entre camadas integram as diferentes camadas, e
como você pode representar isto em uma visão. Ele mostra também como a notação opcional,
com letras no canto superior esquerdo, é usada para distinguir entre as camadas.
Exemplo 31: Relacionamentos entre Camadas
Capítulo 12 Elementos de Implementação
e Migração
Elementos de implementação e migração suportam os aspectos de implementação e migração
das arquiteturas. Isso inclui modelar programas e projetos de implementação para suportar o
gerenciamento de programas, portfólios e projetos. Isto também inclui suporte para o
planejamento da migração.
12.1 Metamodelo de Elementos de Implementação e Migração

A Figura 42 dá uma visão geral dos elementos de implementação e migração e seus
relacionamentos.
Figura 42: Metamodelo de Implementação e Migração
12.2 Elementos de Implementação e Migração

O conceito central de comportamento é um pacote de trabalho. Um pacote de trabalho é um
elemento de comportamento que tem datas de início e de término claramente definidas, e realiza
um conjunto bem definido de metas ou resultados. O elemento pacote de trabalho pode ser usado
para modelar subprojetos ou tarefas dentro de um projeto, projetos completos, programas ou
carteiras de projetos.
Pacotes de trabalho produzem entregáveis. Estes entregáveis podem ser de qualquer tipo, tais
como, relatórios, documentos, serviços, software, produtos físicos etc., ou resultados intangíveis
tais como mudança organizacional. Um entregável também pode ser a implementação de (uma
parte de) uma arquitetura.
Pacotes de trabalho podem ser acionados ou interrompidos por um evento de implementação.

Além disso, pacotes de trabalho podem disparar eventos que acionam outros comportamentos. Ao
contrário de um pacote de trabalho, um evento é instantâneo: ele não tem duração.
O elemento platô está incluído para apoiar os diferentes estados de uma arquitetura no
framework TOGAF, nomeadamente os estados Arquitetura de Linha de Base, Alvo e de
Transição.
Uma lacuna é um resultado da técnica de análise de lacunas, e constitui uma entrada importante
para o planejamento da implementação e da migração. O elemento lacuna está associado a dois
platôs (por exemplo, Arquiteturas de Linha de Base e Alvo, ou duas Arquiteturas de Transição
subsequentes), e representa as diferenças entre estes platôs.
Tabela 20: Elementos de Implementação e Migração
Pacote de Um conjunto de ações identificadas e

trabalho desenhadas para atingir resultados específicos
dentro de restrições especificadas de tempo e
recursos.
Entregável Um resultado precisamente definido de um

pacote de trabalho.
Evento de Uma mudança de estado relacionada com a

implementação implementação ou migração.
O nome de um evento de implementação
deveria ser preferencialmente um verbo no
particípio passado; e.g., “fase de iniciação do
projeto completada”.
Platô Um estado relativamente estável da arquitetura

que existe durante um período limitado de
tempo.
Lacuna Uma declaração de diferença entre dois platôs.
12.3 Exemplos de Elementos de Implementação e Migração
O pacote de trabalho Programa de Serviços de Próxima Geração é composto por três outros
pacotes de trabalho. Um evento de implementação Programa Aprovado aciona o primeiro pacote
de trabalho, Arquitetura e Planejamento, que aciona o pacote de trabalho Desenvolvimento da
Camada de Serviços de Aplicativo, que aciona o pacote de trabalho Desenvolvimento de
Serviços de Negócio, o qual aciona o evento de implementação Programa Completado. O evento
de implementação Programa Aprovado também fornece um entregável Sumário do Programa,
como entrada para o primeiro trabalho do pacote. O pacote de trabalho Arquitetura e
Planejamento realiza três entregáveis: Plano de Negócios, Arquitetura e Roteiro (que é acessado
pelo pacote de trabalho Desenvolvimento da Camada de Serviços de Aplicativo), os quais
coletivamente realizam o platô Planejamento Estratégico Completo. Este platô segue o platô de
linha de base inicial, preenchendo a lacuna de Conhecimento sobre Como Atender às
Necessidades do Cliente. Da mesma forma, outros pacotes de trabalho realizam outros
entregáveis que realizam os platôs subsequentes.
Exemplo 32: Elementos de Implementação e Migração
12.4 Relacionamentos
Os elementos de implementação e migração usam os relacionamentos padrão do ArchiMate.
12.5 Relacionamentos com Outros Aspectos e Camadas

A Figura 43 mostra como os conceitos de implementação e migração podem ser relacionados
com os elementos centrais do ArchiMate.
Um platô está ligado a uma arquitetura que é válida por um determinado período de tempo. Para
indicar quais partes da arquitetura pertencem a um determinado platô, um platô pode agregar ou
compor qualquer dos conceitos da linguagem central do ArchiMate. Uma lacuna está associada
com os conceitos centrais que são únicos a um dos platôs ligados pela lacuna. Um entregável
pode realizar, entre outros, a implementação de uma arquitetura ou de uma parte de uma
arquitetura.
Figura 43: Relacionamentos dos Elementos de Implementação e Migração com Elementos Centrais
A Figura 44 sumariza os relacionamentos entre os elementos de implementação e migração e os

elementos de motivação. Metas, resultados, capacidades e requisitos podem ser agregados ou
compostos em platôs. Requisitos e capacidades podem ser realizados por entregáveis. Uma vez
que resultados e metas são realizados por capacidades e requisitos, eles podem obviamente ser
realizados indiretamente por entregáveis.
Figura 44: Relacionamentos dos Elementos de Implementação e Migração com os Elementos de

Motivação
Capítulo 13 Exemplos de Pontos de Vista
do ArchiMate
A linguagem ArchiMate fornece uma abordagem flexível na qual arquitetos e outras partes
interessadas podem usar suas próprias visões sobre a Arquitetura Corporativa. Nesta abordagem,
visões da arquitetura são especificadas por meio de pontos de vista da arquitetura. Pontos de
vista da arquitetura definem abstrações sobre o conjunto de modelos que representam a
Arquitetura Corporativa, cada um destinado a um tipo particular de parte interessada e
endereçando um determinado conjunto de preocupações. Pontos de vista da arquitetura podem
ser usados para ver certos aspectos em isolamento, e para relacionar dois ou mais aspectos.
13.1 Visões e Pontos de Vista da Arquitetura

Visões da arquitetura são um mecanismo ideal para transmitir propositadamente informações
sobre áreas da arquitetura. Em geral, uma visão da arquitetura é definida como uma parte de uma
Descrição da Arquitetura, que endereça um conjunto de interesses relacionados, e é direcionada
para partes interessadas específicas. Uma visão é especificada por meio de um ponto de vista da
arquitetura, o qual prescreve os conceitos, modelos, técnicas de análise e visualizações que são
fornecidos por essa visão. Dito simplesmente, uma visão da arquitetura é o que você vê e um
ponto de vista da arquitetura é de onde você está olhando.
Pontos de vista da arquitetura são um meio para se concentrar em determinados aspectos e

camadas da arquitetura. Estes aspectos e camadas são determinados pelas preocupações de uma
parte interessada com a qual a comunicação ocorre. O que deveria e não deveria ser visível a
partir de um ponto de vista da arquitetura específico é, portanto, inteiramente dependente da
argumentação em relação às preocupações da parte interessada.
13.2 Mecanismo de Ponto de Vista

Um arquiteto é confrontado com muitos tipos diferentes de partes interessadas e preocupações.
Para ajudar na seleção dos pontos de vista adequados para a tarefa em mãos, o padrão introduz
um framework para a definição e classificação de pontos de vista da arquitetura, o mecanismo de
ponto de vista. O framework é baseado em duas dimensões: propósito e conteúdo. A Figura 45
mostra como o mecanismo de ponto de vista é utilizado para criar visões que endereçam as
preocupações das partes interessadas.
O arquiteto se comunica com as partes interessadas para entender e documentar suas

preocupações. O mecanismo de ponto de vista é usado para identificar o propósito e o conteúdo,
e para ajudar a definir e classificar o ponto de vista da arquitetura. O ponto de vista da
arquitetura governa a construção e o desenho da visão da arquitetura. A visão é uma descrição da
arquitetura que endereça as preocupações da parte interessada e é governada pelo ponto de vista.
Um exemplo de conjunto de pontos de vista é fornecido na Especificação ArchiMate 3.1.
Figura 45: Enquadrando Preocupações das Partes Interessadas com o Mecanismo de Ponto de Vista
Apêndice A Mudanças da Versão 3.0.1
para a Versão 3.1
As principais mudanças entre a Versão 3.0.1 e a Versão 3.1 da Especificação ArchiMate são
listadas abaixo. Em adição a estas mudanças, foram feitas várias melhorias menores nas
definições e na redação
 Foi introduzido um novo elemento de estratégia: fluxo de valor
 Foi adicionada uma notação direcional para o relacionamento de associação
 A organização do metamodelo e das figuras associadas foi melhorada
 Derivação dos relacionamentos melhorada e mais bem formalizada
A formalização das regras de derivação, como mencionado acima, tem um pequeno impacto na
estrutura do metamodelo, uma vez que alguns relacionamentos que agora podem ser derivados
anteriormente tinham que ser especificados explicitamente no metamodelo. Isso também levou à
remoção de um pequeno número de relacionamentos espúrios. Para transformar um modelo
ArchiMate 3.0.1 para um modelo ArchiMate 3.1, quaisquer destes relacionamentos podem ser
substituídos por uma associação direcionada.
Glossário
Framework Central do ArchiMate
Uma estrutura de referência usada para classificar os elementos da linguagem central do

ArchiMate. Consiste em três camadas e três aspectos.
Linguagem Central do ArchiMate
A parte central da linguagem ArchiMate que define os conceitos para modelar Arquiteturas
Corporativas. Ela inclui conceitos de três camadas: Negócio, Aplicativo e Tecnologia (incluindo
Físico).
Visão da Arquitetura
Uma representação de um sistema a partir da perspectiva de um conjunto de preocupações

relacionadas.
Ponto de Vista da Arquitetura
Uma especificação das convenções para um tipo particular de visão da arquitetura.
Aspecto
Classificação dos elementos baseada em características independentes de camada, relacionadas

com as preocupações de diferentes partes interessadas. Usada para posicionar elementos no
metamodelo do ArchiMate.
Atributo
Uma propriedade associada com um elemento ou relacionamento da linguagem ArchiMate
Elemento Composto
Um elemento consistindo em outros elementos de múltiplos aspectos ou camadas da linguagem.
Conceito
Um elemento, um relacionamento ou um conector de relacionamento.
Conformidade
Atendimento dos requisitos especificados.
Implementação Conforme
Uma implementação que satisfaz os requisitos de conformidade definidos pela cláusula de

conformidade do padrão.
Elemento Central
Um elemento de estrutura ou comportamento de uma das camadas centrais da linguagem

ArchiMate
Elemento
Unidade básica do metamodelo do ArchiMate. Usado para definir e descrever as partes

constituintes das Arquiteturas Corporativas e seu conjunto único de características.
Camada
Uma abstração do framework do ArchiMate por meio da qual uma empresa pode ser modelada.
Modelo
Uma coleção de conceitos no contexto da estrutura da linguagem ArchiMate.
Para uma definição genérica de modelo, consulte o Framework TOGAF.
Relacionamento
Uma conexão entre um conceito fonte e um conceito alvo. Classificado como estrutural, de
dependência, dinâmico ou outro.
Índice
alinhamento da camada de especialização................................. 26
aplicativo .................................... 91 estratificação .................................. 18
alinhamento da camada de estrutura da linguagem ................... 17
negócio ....................................... 90 evento ............................................. 25
alinhamento da camada de Framework Central do ArchiMate . 19
tecnologia ................................... 91 Framework Completo do
Arquitetura Corporativa ........... 13, 15 ArchiMate .................................. 21
aspectos .......................................... 20 Framework TOGAF ....................... 94
BMM .............................................. 14 função ............................................. 26
BPMN............................................. 14 interação ......................................... 26
Camada de Aplicativo .............. 18, 68 interface.......................................... 24
Camada de Negócio........................ 18 lacuna ............................................. 94
Camada de Tecnologia ............. 18, 76 Linguagem Central do ArchiMate . 15
camadas .......................................... 20 localização ...................................... 28
colaboração..................................... 26 mecanismo de ponto de vista ......... 97
cor, uso de ...................................... 18 metamodelo da camada de
elemento ......................................... 17 aplicativo.................................... 68
elemento composto ......................... 27 metamodelo da camada de
Camada de Negócio .................... 63 negócio....................................... 56
elemento de agrupamento ............... 28 Metamodelo da Camada de
elemento de comportamento .... 22, 24 Tecnologia ................................. 76
Camada de Aplicativo .................. 70 metamodelo dos elementos de
Camada de Negócio .................... 59 estratégia .................................... 50
Camada de Tecnologia ................ 79 metamodelo dos elementos de
físico ............................................ 88 implementação e migração ........ 93
elemento de comportamento metamodelo dos elementos de
externo........................................ 24 motivação ................................... 41
elemento de estratégia .................... 50 metamodelo genérico ..................... 22
elemento de estrutura...................... 22 modelo ............................................ 17
elemento de estrutura ativa ............. 23 notação ........................................... 19
Camada de Aplicativo ................. 68 orientação a serviços ...................... 18
Camada de Negócio .................... 56 pacote de trabalho .......................... 93
Camada de Tecnologia ................ 76 Padrão TOGAF ........................ 13, 14
físico............................................ 86 parte interessada ............................. 20
elemento de estrutura passiva ......... 25 platô................................................ 94
Camada de Aplicativo ................. 74 ponto de vista ................................. 20
Camada de Negócio .................... 61 ponto de vista da arquitetura .......... 97
Camada de Tecnologia ................ 82 processo.......................................... 26
físico............................................ 88 regras de derivação......................... 39
elemento de motivação ............. 27, 41 relacionamentos ............................. 29
elemento físico ......................... 18, 86 serviço ............................................ 24
elementos de implementação e TOGAF ADM ................................ 15
migração ..................................... 93 UML ............................................... 14
entregáveis ...................................... 94 visão da arquitetura ........................ 97

A Pocket Guide To The ArchiMate® 3.1 Specification (Brazilian Translation)

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

A Pocket Guide To The ArchiMate® 3.1 Specification (Brazilian Translation)

Enviado por

Direitos autorais:

Formatos disponíveis

Um Guia de Bolso para a

Especificação ArchiMate® 3.1

Copyright © 2012-2019, The Open Group

Todos os direitos reservados.

Em caso de qualquer discrepância entre o texto do presente documento e a documentação oficial do

Um Guia de Bolso para a Especificação ArchiMate® 3.1

Número do Documento: G196BR

Publicado pelo The Open Group, novembro de 2020.

Atualizado em agosto de 2017 para alinhar com a Especificação ArchiMate 3.0.1.

The Open Group

ou por correio eletrônico para:

5.4 Relacionamentos com os Elementos Centrais ....................................................... 36

12.5 Relacionamentos com Outros Aspectos e Camadas .............................................. 81

O público para este documento é:

Convenções Utilizadas neste Documento

Usado para destacar termos específicos.

Usado para ênfase. Pode também se referir a outros documentos externos.

Uma caixa Nota é usada para realçar informações úteis ou interessantes.

Sobre o The Open Group

A missão do The Open Group é orientar a criação de um Boundaryless Information Flow™

Mais informações sobre o The Open Group estão disponíveis em www.opengroup.org.

Marc Lankhorst, BiZZdesign

Iver Band, Cambia Health Solutions

Henk Jonkers, BiZZdesign

Dick Quartel, BiZZdesign

Steve Else, EA Principals

Antonio Plais, Centus Consultoria (Tradução para o Português Brasileiro)

Antonio Plais é Proprietário e Consultor Sênior em Análise de Negócios, Arquitetura

Os tópicos abordados neste capítulo incluem:

1.1 Introdução à Especificação ArchiMate

Assim como um desenho arquitetônico na arquitetura clássica de edifícios descreve os vários

Desenvolvimento da Linguagem ArchiMate

O conteúdo da especificação inclui o seguinte:

A Especificação ArchiMate 3.1 é a versão mais recente da especificação, e é uma evolução a

O desenho da linguagem ArchiMate começou a partir de um conjunto de conceitos relativamente

1.3.1 A Linguagem ArchiMate e o TOGAF ADM

As camadas de Negócio, Aplicativo e Tecnologia suportam a descrição dos domínios da

Os elementos de estratégia e de motivação na linguagem ArchiMate podem ser usados para

Os elementos de implementação e migração da linguagem ArchiMate suportam a

Os tópicos abordados neste capítulo incluem:

2.1 Estrutura de Nível Superior da Linguagem

Figura 2: Hierarquia de Nível Superior dos Conceitos do ArchiMate

Em alinhamento com a orientação para serviços, o relacionamento mais importante entre as

2.3 Uso de Cores e Indicações Notacionais

Elas podem ser usadas também para ênfase visual.

2.4 O Framework Central do ArchiMate

A estrutura do framework permite a modelagem da empresa a partir de diferentes pontos de

As dimensões do framework são como segue:

Um elemento composto, como mostrado na Figura 2, é um elemento que não se encaixa

Figura 4: Framework Completo do ArchiMate

3.1 Elementos de Estrutura e de Comportamento

Figura 5: Hierarquia dos Elementos de Estrutura e Comportamento

Este fragmento de metamodelo genérico consiste em dois tipos principais de elementos:

Elementos de estrutura podem ser subdivididos em elementos de estrutura ativa e elementos de

Elementos de comportamento podem ser subdivididos em elementos de comportamento interno,

A Figura 6 especifica os principais relacionamentos entre os elementos de comportamento e de

Figura 6: Metamodelo dos Elementos de Estrutura e Comportamento

3.1.1 Elementos de Estrutura Ativa

Um elemento de estrutura ativa externo, chamado de interface, representa um ponto de acesso

Figura 8: Notação Genérica dos Elementos de Estrutura Ativa Externos (Interface)

3.1.2 Elementos de Comportamento

Figura 9: Notação Genérica dos Elementos de Comportamento Internos

Um elemento de comportamento externo, chamado de serviço, representa um comportamento