Arquitetura Corporativa

Proteja sua Empresa: Analise sua Segurança com Modelos de Arquitetura

postado em 6 de jun de 2018 12:21 por Antonio Plais   [ 6 de jun de 2018 12:24 atualizado‎(s)‎ ]

Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign - Tradução autorizada

Em uma postagem anterior, falamos sobre os passos essenciais para manter sua organização segura em um ambiente digital cada vez mais perigoso:
  1. Garantir a conscientização por toda a organização
  2. Alinhar o gerenciamento de risco e segurança com a estratégia do negócio
  3. Analisar suas vulnerabilidades e riscos
  4. Adotar uma abordagem de segurança por desenho
  5. Assumir que você está comprometido
Nesta postagem, vamos olhar mais detalhadamente os instrumentos que podem ser usados para que você possa alcançar a segurança cibernética - em particular, nos passos 3 e 4.

Modelos para a segurança cibernética

Não vamos surpreendê-lo ao defender uma abordagem baseada em modelos para analisar e mitigar os riscos cibernéticos. Descrições claras e formais da sua organização ajudarão você a obter o entendimento necessário para fornecer soluções de segurança cibernética ótimas. Naturalmente, não é possível alcançar a segurança absoluta; ao invés disso, você deveria focar onde você precisa investir a partir da perspectiva 1) do valor dos ativos que você quer proteger e 2) das vulnerabilidades associadas a estes ativos.

Nossa abordagem para o gerenciamento de segurança e risco corporativo é baseada em vários padrões abertos, mais notadamente o padrão ArchiMate para a modelagem da arquitetura corporativa, bem como o padrão Open FAIR para o gerenciamento de risco da informação. Mais detalhes estão descritos neste artigo do The Open Group sobre modelagem de segurança e gerenciamento de risco corporativo.


Processo de gerenciamento de segurança e risco


A figura acima mostra os passos principais da nossa abordagem, os quais estão embutidos na funcionalidade de Gerenciamento de Conformidade, Risco e Segurança do BiZZdesign Enterprise Studio. Na parte inferior da figura, você vê os ativos que você quer proteger de riscos cibernéticos, enquanto na parte superior você vê as políticas, princípios e objetivos que orientam a organização. Entre estes extremos estão os passos que os conectam; no lado esquerdo (em vermelho), você vê a análise dos riscos cibernéticos na sua organização, e no lado direito (em verde) você vê a implementação dos controles para melhorar a sua segurança. Estas são as etapas para o gerenciamento de segurança e risco:

1. Revisar os ativos: Quais são os ativos mais importantes que são críticos para a sua organização? O que as regulações aplicáveis falam sobre estes ativos? Por exemplo, os dados pessoais dos seus clientes podem ser um destes ativos. Sua reputação como uma organização confiável pode ser outro. Você pode atribuir algum valor a estes elementos? Tudo isso ajudará você posteriormente quando decidir o que é mais importante proteger.

2. Analisar as vulnerabilidades: De que forma os ativos da sua organização estão vulneráveis? Em segurança cibernética, "vulnerabilidades do dia zero", que não são conhecidas por ninguém exceto pelo atacante, são naturalmente as mais perigosas, e não aparecerão nesta lista. Mas outras vulnerabilidades que você possa reconhecer deveriam ser investigadas e ligadas com os ativos que elas expõem. Você pode reusar os modelos da sua arquitetura de negócios e de TI, possivelmente estendendo-os com os aspectos relevantes de segurança.

3. Avaliar as ameaças: Depois que você avalia as vulnerabilidades específicas dos seus ativos, você precisa avaliar se estas vulnerabilidades podem ser exploradas efetivamente pelos chamados "eventos de ameaça" e "agentes de ameaça". Isto pode ir desde hackers maliciosos até governos hostis e concorrentes desonestos, bem como seu próprio pessoal, mal-funcionamento técnico, desastres naturais, e outros acidentes. Nós coletamos um extenso modelo contendo centenas de vulnerabilidades, agentes de ameaça e eventos de ameaça, que pode servir como um ponto de partida para as suas análises neste passo e no anterior.

4. Calcular riscos: Com base nas ameaças potenciais e no valor dos seus ativos, você pode avaliar os riscos que a sua organização enfrenta na realidade. Em uma fórmula simples, risco = valor x probabilidade; quanto maior o risco, mais você quererá investir para mitigá-lo. A figura abaixo mostra um exemplo de uma análise como esta, construída gradualmente através destes quatro primeiros passos:
A parte inferior, amarela, do modelo mostra os processos de negócio e os ativos a serem protegidos ('Informação do Cliente'). A parte superior mostra, da esquerda para a direita:
  • a vulnerabilidade ('Autenticação fraca')
  • o agente de ameaça (o hacker)
  • eventos de ameaça
  • eventos de perda potencial resultantes destas ameaças
  • os riscos resultantes
Os sinais de tráfego mostram os vários parâmetros, tais como valor do ativo, nível de vulnerabilidade e nível de risco resultante. Todos eles são interconectados, e o nosso algorítimo de análise de risco calcula os resultados, ou seja, aumentando o nível de risco se você aumenta o valor do ativo ou a capacidade da ameaça.

5. Criar políticas: Para lidar proativamente com riscos cibernéticos potenciais, você deveria definir princípios e políticas de segurança apropriadas que estejam em linha com a sua estratégia de negócio e que também siga as regulações aplicáveis. Isto pode incluir, por exemplo, princípios tais como segurança por desenho, separação de responsabilidades, acesso restrito a dados pessoais, e outras políticas comuns. Frameworks regulatórios, como o GDPR, requerem políticas de proteção de dados sólidas, com altas multas em casso de não-conformidade e até mesmo a responsabilização pessoal da gerência responsável. Isto, por sua vez, influencia o valor dos ativos que você quer proteger. Não é apenas o seu valor intrínseco que está em jogo; multas, danos à reputação e outros efeitos colaterais também deveriam ser levados em consideração.

6. Definir objetivos de controle: Com base nas políticas que você criou no passo anterior, você deveria definir objetivos de controle apropriados. Uma abordagem padrão é, por exemplo, classificar a confidencialidade, integridade, disponibilidade, sensitividade à privacidade, e outros atributos dos seus dados, de acordo com casos de uso comuns que você tenha. Por exemplo, os dados no seu website precisarão de baixa confidencialidade, mas alta disponibilidade, enquanto os dados do cliente terão requisitos de confidencialidade e privacidade muito mais altos, enquanto a disponibilidade poderia ser uma preocupação menor.

7. Criar medidas de controle: Estes objetivos de controle são traduzidos em medidas de controle aplicáveis, que dizem o que deve ser feito para atingir estes objetivos. Padrões relevantes, como a ISO/IEC 27001, NIST 800-53, CSA e outros, podem ajudar fornecendo um conjunto predefinido e organizado de medidas de controle. Abaixo, vemos um pequeno extrato de um modelo do padrão ISO/IEC 27001, mostrando um objetivo de controle específico e várias medidas de controle relacionadas, expressas através da sobreposição de risco e segurança do ArchiMate que está definida no artigo do The Open Group mencionado acima. 

A força destas medidas de controle também pode ser usada como entrada para os cálculos de risco mostrados na figura anterior. Quanto mais forte o seu controle, mais baixas as suas vulnerabilidades e, assim, mais baixos os riscos que você corre.

8. implementar: A etapa final é desenhar a implementação destas medidas de controle como parte da sua arquitetura, processos e sistemas. Por exemplo, você terá que descobrir como você realiza o registro de usuários (a primeira medida na figura acima). O custo da implementação destas medidas pode ser comparado aos riscos que você está correndo. Eles realmente valem isto, ou você está protegendo ativos de baixo valor com caros controles extensivos?

A análise de risco mostrada acima é, naturalmente, algo a ser feito por especialistas em avaliação de riscos e modeladores, e pode parecer complicado para os não iniciados. Os resultados podem, no entanto, ser apresentados através de mapas de calor amigáveis como o mostrado abaixo.


O mapa de calor acima mostra como a alta capacidade das ameaças (por exemplo, um hacker esperto) combinado com controles com pouca força resultam em um nível de vulnerabilidade muito alto. As outras duas vulnerabilidades neste mapa de calor são, provavelmente, menos urgentes.

Esta análise ajuda a gerência a priorizar investimentos na melhoria da segurança como, neste exemplo, implementar regras relacionadas com o tamanho das senhas, ou instituir a autenticação de múltiplos fatores. Assim, sua organização ganha espaço no orçamento para investir naquilo que realmente conta.

A arquitetura de segurança é uma preocupação contínua

O gerenciamento de risco é um processo iterativo e contínuo. O processo esboçado aqui deveria ser executado regularmente para avaliar novas vulnerabilidades e ameaças, e para manter suas política, princípios e controles atualizados com a estratégia da sua organização e com as demandas regulatórias. Mais ainda, o fato que você tenha um processo de gerenciamento de risco como este é, em si, demandado por vários frameworks regulatórios.

Embutir isto em seus processos regulares de arquitetura e desenho fornece para você uma abordagem de segurança por desenho - uma forma muito mais efetiva de melhorar a resiliência da sua organização do que simplesmente implementar algumas medidas de segurança após o evento de segurança cibernética.

Não existe garantia de que nada sairá errado. De qualquer forma, ter uma abordagem para análise e mitigação de risco baseada em modelo, como apresentado aqui, se provará ser um grande investimento na segurança cibernética, continuidade do negócio e resiliência da sua organização onde (e quando) isto realmente importa.

Interessado em saber mais? Entre em contato com a Centus Consultoria e solicite uma demonstração da funcionalidade de Gerenciamento de Risco, Segurança e Conformidade do BiZZdesign Enterprise Studio!



* Mark Lankhorst é Gerente de Consultoria & Evangelista-Chefe de Tecnologia da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.

Suportando Grandes Arquiteturas como uma Equipe

postado em 27 de abr de 2018 04:39 por Antonio Plais   [ 27 de abr de 2018 04:40 atualizado‎(s)‎ ]

Originalmente postado por Marc Lankhorst e Rob Kroese*, no blog da BiZZdesign - Tradução autorizada

As arquiteturas das grandes organizações podem se tornar bastante grandes e complicadas, representando um desafio para os arquitetos que as desenvolvem e mantém. Em discussões anteriores, nós endereçamos várias técnicas para organizar e controlar tais grandes modelos para manter as coisas gerenciáveis. Nesta postagem, olharemos para os processos e práticas que você pode usar para otimizar a colaboração entre as pessoas que trabalham nestas arquiteturas.

Equipes de arquitetura federadas

Uma dica importante para facilitar o trabalho em arquiteturas grandes e organizar seu repositório de modelos por domínios de negócio ou capacidades de negócio de alto nível. Esta subdivisão é facilmente reconhecida pelas pessoas envolvidas e alinhada com a hierarquia organizacional e divisão de responsabilidades típicas.

Da mesma forma, você pode definir uma estrutura de governança federada. Gerenciar tudo isso a partir de um grande departamento de arquitetura centralizado normalmente não é uma boa ideia por duas razões. Primeiro, o esforço necessário será substancial, criando uma sobrecarga que será vista como não razoável pelos administradores. Segundo, e mais importante, estes arquitetos centrais estarão, na maioria das vezes, muito distantes do negócio em questão para realmente saberem o que está acontecendo.

Assim sendo, é muito melhor ter arquitetos locais dentro dos diferentes domínios de negócio. Estes arquitetos coordenam seus trabalho com um grupo relativamente pequeno de arquitetos centrais, que garantem que estes esforços se encaixam e definem pontos comuns (i.e. arquiteturas de referência, padrões de arquitetura etc.). Este padrão também se encaixa bem com nossas recomendações anteriores para estabelecer um "comitê editorial" que garante que seus modelos de arquitetura se conformam com um conjunto de padrões comuns de modelagem.

Organize seus projetos de arquitetura

Em grandes arquiteturas, você normalmente não trabalha junto na arquitetura inteira com todos os arquitetos ao mesmo tempo. Ao invés disso, diferentes grupos trabalharão em diferentes partes da arquitetura e só compartilharão os resultados quando estiverem prontos para uma distribuição ampla.

Este processo de mudança típico em dois estágios é suportado pela plataforma de equipes do BiZZdesign Enterprise Studio. Equipes de projeto trabalham juntos em um ou mais modelos que são parte de um pacote de modelos. Dentro de um projeto, os arquitetos individuais daquela equipe podem atualizar suas mudanças nestes modelos, quando são, então, compartilhados apenas com os membros da equipe, e com mais ninguém.

Quando a equipe está pronta, alguém com o nível de permissão necessário ('líder de projeto') pode tornar suas contribuições disponíveis para todos que colaboram no mesmo pacote de modelos. Somente então os outros arquitetos verão estas mudanças. Tipicamente, haverá também alguma forma de revisão antes que este passo seja dado. Desta forma, uma equipe de projeto pode trabalhar nas suas próprias ideias sem confundir ou perturbar os outros usuários daquele mesmo pacote de modelos.


Use autoserviço e controle de qualidade automatizado

Quando você trabalha com um grande grupo de pessoas juntas em um repositório de modelos, o desafio para manter modelos com alta qualidade se torna ainda mais difícil. Uma boa prática é definir um conjunto de requisitos de qualidade que os arquitetos devem usar para todos os trabalhos de modelagem. Alguns exemplos são:
  • Nenhum elemento não-usado: elementos que não estão ligados a outros elementos e não estão presentes em nenhuma visão são, provavelmente, desnecessários
  • Nenhum elemento duplicado: garanta que, para cada elemento, apenas uma única instância está presente no seu repositório e não crie duplicatas
  • Relacionamentos entre objetos aninhados: garanta que, se você desenhou objetos aninhados em uma visão, que os relacionamentos também foram definidos (tipicamente, composição ou agregação) entre o pai e os filhos.
O BiZZdesign Enterprise Studio tem mecanismos para prevenir que estas situações aconteçam, e você pode, também, verificar estas situações posteriormente. Os arquitetos podem usar estes mecanismos por si mesmos, como auto-serviço, o que ajuda a criar modelos de alta qualidade. Os modeladores deveriam ser encorajados a usar este tipo de mecanismo. No entanto, em grandes repositórios, pode ser valioso, também, usar funcionalidades de controle de qualidade automatizadas. É possível definir scripts automatizados que verificam requisitos de qualidade mais detalhados, tais como:
  • Convenções de nomeação: defina convenções de nomeação (como discutido em '6 formas de organizar seus modelos de arquitetura (parte 2)') e crie um relatório com uma lista de elementos/visões que não aderem a estas convenções
  • Uso de elementos do ArchiMate: frequentemente, um subconjunto da linguagem ArchiMate completa é usado para manter os modelos de arquitetura fáceis de serem lidos. Uma verificação automática pode produzir um relatório que lista os elementos que não são parte do subconjunto do ArchiMate que foi acordado
  • Uso de relacionamentos do ArchiMate: Na linguagem ArchiMate completa, vários tipos de relacionamento são permitidos entre diferentes tipos de elementos. É uma boa prática padronizar, na sua organização, o uso dos relacionamentos. Por exemplo: sempre use o relacionamento de Realização entre um Componente de Aplicativo e um Serviço de Aplicativo. Uma verificação do uso dos tipos de relacionamento acordados entre todos os diferentes elementos produzirá um relatório com todos os relacionamentos que podem ser do tipo incorreto
Estes tipos de verificações automatizadas podem ser executados periodicamente e gerarão um relatório onde possíveis problemas são listados. Além disso, o número de problemas encontrados nos modelos podem ser mostrados em painéis de controle. Tudo isso ajuda a gerar uma conscientização mais forte sobre a qualidade dos modelos e promover melhorias, o que é essencial em grandes repositórios de arquitetura.


Você quer saber mais sobre as funcionalidades avançadas do BiZZdesign Enterprise Studio? Entre em contato com a Centus Consultoria e solicite uma demonstração personalizada, e fique ligado nas nossas postagens neste blog.


 
* Mark Lankhorst é Gerente de Consultoria & Evangelista-Chefe de Tecnologia, e Rob Kroese é consultor nas áreas de arquitetura e melhoria de processos da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.

Combinando os Padrões TOGAF e ArchiMate para Suportar a Mudança Digital

postado em 18 de abr de 2018 11:56 por Antonio Plais   [ 18 de abr de 2018 11:59 atualizado‎(s)‎ ]

Originalmente postado por Bernd Ihnen*, no blog da BiZZdesign - Tradução autorizada 

Na primeira postagem desta série, explicamos quão importante é elevar sua capacidade de mudança digital para se tornar uma empresa adaptativa. Também realçamos o papel da comunicação efetiva, bem como abordagens para categorizar e visualizar descrições da arquitetura corporativa com base nos padrões TOGAF e ArchiMate. Também apresentamos orientações sobre como selecionar uma abordagem para a modelagem de Blocos de Construção da Arquitetura e de Solução (ambos são tipos de componentes lógicos e físicos). Para finalizar esta série, discutiremos a conexão com as Soluções Implementadas.

Soluções implementadas

O TOGAF descreve o componente de aplicativo físico como um "componente implementável, por exemplo, uma instância implementada de um ERP" (TOGAF seção 34.5). Como explicado anteriormente, os Blocos de Construção da Arquitetura (ABBs) e de Solução (SBBs) se referem a tipos de objeto. Você pode usá-los para distinguir componentes de aplicativo físicos em tipos como SBBs, e instâncias como Soluções Implementadas. As Soluções Implementadas são interessantes quando estamos documentando soluções existentes, gerenciando-as (por exemplo, em um portfólio de aplicativos) ou reusando esta informação no desenvolvimento da arquitetura. Em termos da sua modelagem usando o ArchiMate, você pode usar os mesmos conceitos de níveis de soluções e soluções implementadas para diferenciar tipos e instâncias. Em geral, é útil adicionar um sufixo ao nome das instâncias como uma convenção de nomeação (por exemplo, "SAP ERP P123"). Se você quer relacionar tipos de solução e instâncias de soluções implementadas, recomendamos usar o relacionamento de especialização do ArchiMate. Desta forma, você pode descrever coisas de um mesmo tipo, mas com parâmetros/configurações diferentes. A figura abaixo mostra como você pode modelar o Continuum Corporativo no ArchiMate usando a primeira abordagem descrita aqui.


Adicionando as camadas de negócio e tecnologia

O Método de Desenvolvimento da Arquitetura (ADM-Architecture Development Method) do TOGAF nomeia fases dedicadas para o desenvolvimento das arquiteturas de negócio e tecnologia. Para efeito didático, o mapeamento acima é baseado na camada de aplicativo, mas você pode transferi-lo também para as camadas de negócio e tecnologia.

Em geral, as instâncias das tecnologias não são de interesse do desenvolvimento da arquitetura corporativa (e.g. Windows versão 20XX número de licença ABCXYZ), de forma que não as modelamos neste contexto. Um possível candidato para modelagem neste nível é um , compondo as diferentes soluções tecnológicas que deveriam ser implementadas em um projeto ou a importação de servidores existentes, por exemplo, em um CMDB. Uma vez que nós usamos o conceito de estrutura ativa interno do ArchiMate componente de aplicativo para o componente de aplicativo físico, esta abordagem usa os conceitos de software de sistema ou de dispositivo (de hardware) para modelar a tecnologia subjacente. O conceito de função também existe na camada de tecnologia, de modo que o mapeamento é direto.

A camada de negócio também pode ser descrita através da mesma abordagem. A arquitetura de negócio geralmente contém processos de negócio para descrever o comportamento atribuído aos departamentos (ou papéis), de forma que nós os incluímos explicitamente junto com as funções de negócio para descrever a camada de negócio. 

Um pequeno esclarecimento em relação ao ArchiMate: ambos, processos e funções de negócio, descrevem comportamento interno de negócio. A diferença é que os processos agrupam o comportamento de acordo com uma ordem específica de atividades, enquanto as funções agrupam o comportamento de acordo com um conjunto de características quaisquer (por exemplo, conhecimento, ou responsabilidade). 

Como você sabe, o termo "função de negócio" é, algumas vezes, também usado para entidades como departamentos, que representam os elementos de estrutura ativa no framework do ArchiMate que realizam os comportamentos (i.e. processos de negócio). Sendo aderentes à especificação do ArchiMate, departamentos são usualmente modelados como atores de negócio, que são correspondentes aos aplicativos físicos, enquanto as funções/processos são correspondentes aos aspectos funcionais/lógicos.

Resumo desta série

O que vocês podem levar desta série de postagens? Na primeira postagem, levantamos a necessidade de se tornar uma empresa adaptativa em um ambiente em rápida mudança e explicamos como a linguagem desempenha um papel crítico na comunicação. Suporte apropriado de ferramenta e metodologia é também um ingrediente importante na digitalização da sua capacidade de mudança. Ao mesmo tempo, a função de arquitetura corporativa fornece uma visão holística dos impactos das transformações estratégicas através das iniciativas de mudança. Quando falando a respeito de estratégia e de projetos de mudança, há também a necessidade de descrever diferentes tipos de arquiteturas. Nós vimos como classificar arquiteturas com base no padrão TOGAF e como visualizá-las usando o padrão ArchiMate. Nós vamos, agora, usar tudo isso que nós apresentamos nesta série para fornecer um exemplo prático do Continuum Corporativo do TOGAF inteiro.

https://sites.google.com/a/centus.com.br/comunidade/arquitetura-corporativa/togaf_archimate_mudancadigital/blog_entertrise%20continuum_003.png?attredirects=0
Exemplo completo da modelagem do Continuum Corporativo (clique para ampliar)

Como você pode ver, arquiteturas de fundação são modeladas principalmente na camada de tecnologia, enquanto as outras arquiteturas mais específicas são usualmente modeladas nas camadas de aplicativo e negócio. Isso faz sentido, uma vez que você, em geral, constrói sua arquitetura de aplicativo em cima de uma fundação/tecnologia que você não desenvolve internamente, mas, ao invés, compra e configura (e.g. MS SQL). O exemplo acima também reflete que o TOGAF e o ArchiMate possuem a habilidade de descrever o negócio e a TI para melhorar o alinhamento para suportar transformações estratégicas.

Esperamos que você tenha gostado de ler esta série, e encontrado utilidade na aplicação do framework ArchiMate ao Continuum Corporativo do TOGAF. Para uma discussão mais profunda, verifique nossa oferta de treinamentos e fique ligado na nossa Biblioteca. Quando tiver a necessidade, entre em contato com a Centus Consultoria para saber mais sobre como o BiZZdesign Enterprise Studio, em conjunto com nossa experiência e serviços pode ajudá-lo a tornar sua empresa uma verdadeira Empresa Adaptativa.





* Bernd Ihnen é Consultor e Instrutor da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.

Relacionamentos Diretos e Derivados na Linguagem ArchiMate

postado em 17 de abr de 2018 08:39 por Antonio Plais   [ 17 de abr de 2018 08:40 atualizado‎(s)‎ ]

A especificação ArchiMate, seção 5.4, trata de um conceito, em geral, pouco compreendido por quem não tem experiência na linguagem. Através dos Relacionamentos Derivados é possível abstrair certos elementos de um modelo, permitindo não só a sua simplificação, como também a descrição explícita dos relacionamentos implícitos na modelagem.

Abaixo alguns exemplos a partir desta modelagem (completa) de um aplicativo genérico:

Relacionamentos diretos

Através dos relacionamentos diretos acima, modelamos que:
- uma função de aplicativo realiza um serviço de aplicativo; 
- uma interface de aplicativo é parte de (compõe) um componente de aplicativo; 
- um componente de aplicativo é atribuído a (é responsável por) uma função de aplicativo; 
- uma interface de aplicativo é atribuída (possibilita o acesso) a um serviço de aplicativo;

Podemos, então, fazer uma modelagem (completa) de um (outro) aplicativo usando (sendo servido por) este aplicativo:


Os relacionamentos realçados em vermelho modelam que:
- um componente de aplicativo é servido por (usa) um serviço de aplicativo
- um componente de aplicativo é servido por (usa) uma interface de aplicativo (para ter acesso ao serviço de aplicativo)

Relacionamentos derivados

Usando o conceito de relacionamentos derivados do ArchiMate, várias modelagens simplificadas, ou alternativas, são possíveis:

- uma função de aplicativo serve (é usada por) um componente de aplicativo


- um componente de aplicativo é usado por (é servido por) um componente de aplicativo



- um componente de aplicativo usa um (outro) componente de aplicativo através de uma interface de aplicativo



- um componente de aplicativo realiza um serviço de aplicativo (através do caminho componente de aplicativo atribuído a função de aplicativo que realiza serviço de aplicativo)



- um componente de aplicativo é atribuído a (é responsável por) um serviço de aplicativo (através do caminho componente de aplicativo é composto de interface de aplicativo que é atribuída a serviço de aplicativo)



Conhecendo melhor o ArchiMate

O ArchiMate é uma linguagem muito poderosa para descrever arquiteturas mas, como toda linguagem, requer conhecimento e prática da sua sintaxe e semântica. A leitura atenta da especificação, assim como um treinamento adequado, são fundamentais para o bom uso da linguagem. Considere fazer um bom curso preparatório e busque a certificação oficial do The Open Group.

Usando o ArchiMate para Visualizar o Continuum Corporativo do TOGAF

postado em 12 de abr de 2018 19:46 por Antonio Plais   [ 12 de abr de 2018 19:50 atualizado‎(s)‎ ]

Originalmente postado por Bernd Ihnen*, no blog da BiZZdesign - Tradução autorizada 

Anteriormente, escrevemos sobre o uso de uma linguagem de modelagem e o uso prático do Continuum Corporativo do TOGAF para classificar descrições arquiteturais relativas a diferentes níveis de abstração. Enquanto o TOGAF 9.1 fornece o método de desenvolvimento da arquitetura (ADM-Architecture Development Method) padrão, o ArchiMate é um padrão mundial para modelar e visualizar o conteúdo das arquiteturas corporativas. Ambos são padrões abertos do The Open Group.

Nesta postagem, demonstraremos como o conteúdo destas descrições pode ser visualizado através de uma notação padrão, suportando a modelagem de diferentes níveis de abstração, que mapearemos para o Continuum Corporativo do TOGAF. 

Figura 1: Os vários níveis de abstração da arquitetura

Você já conhece a distinção entre Blocos de Construção da Arquitetura (ABB-Architecture Building Blocks), Blocos de Construção da Arquitetura (SBB-Solution Building Blocks) e Soluções Implementadas. Esta distinção é similar à distinção entre aplicativos lógicos (ABB) e aplicativos físicos (SBB) que é definida no Modelo de Conteúdo do TOGAF. "No nível de abstração da Arquitetura Corporativa, é mais comum modelar tipos e/ou exemplares, ao invés de instâncias" (ArchiMate 3.0, seção 3.6). Por essa razão, iremos focar nos ABBs e SBBs, e em como representá-los.

A especificação ArchiMate 3.0 fornece três abordagens para distinguir estes conceitos, as quais iremos apresentar com base na Camada de Aplicativos e na nossa experiência. Os conceitos e melhores práticas aqui apresentados são válidos, também, para as outras camadas do framework central do ArchiMate.

Primeira abordagem - aplicativos lógicos como funções de aplicativo

Figura 2 - Componentes lógicos como funções de aplicativo, componentes físicos como componentes de aplicativo

À direita, na figura acima, você vê o componente físico, ou SBB, modelado como um componente de aplicativo que é atribuído para um componente de aplicativo lógico, ou ABB, modelado como uma função de aplicativo. Esta é uma abordagem interessante por usar a coluna de comportamento do framework do ArchiMate, uma vez que ela inclui as funções (retângulos arredondados) que descrevem a arquitetura lógica/ABBs, que são modeladas como aspectos separados das soluções. Símbolos diferentes indicam diferentes coisas, tornando mais fácil a compreensão.

Esta abordagem é bem apropriada para desenvolver novas arquiteturas de soluções e projetos. Ela começa com a definiçãodos requisitos e dos comportamentos desejados da solução futura, e então atribui os SBBs/aplicativos físicos.

Esta abordagem pode, ainda, ser estendida através da adição dos serviços de aplicativo que refletem os requisitos de um contexto da arquitetura, e que podem ser entendidos como uma camada conceitual. Neste caso, as funções de aplicativo realizam os serviços de aplicativo, e podem ainda ser agrupados a um componente de aplicativo lógico através do relacionamento de composição (como mostrado na próxima figura). Este padrão é útil para descrever diferentes níveis de granularidade, mas o nível de detalhe poderia variar de projeto para projeto. Você deveria levar isto consideração, para evitar a sobrecarga de detalhes em projetos pequenos. O uso desta abordagem pode, também, ser visto no eBook ArchiMate - Da Teoria à Prática, de Bas van Gils e Sven van Djik (pagina 66).

Figura 3 - Estendendo a modelagem de aplicativos lógicos com serviços

Segunda abordagem - aplicativos lógicos como componentes de aplicativo


Figura 4 - Componentes lógicos como componentes de aplicativo, componentes físicos como artefatos

A segunda abordagem modela os componentes lógicos de aplicativo como componentes de aplicativo, realizados por componentes físicos de aplicativo, os quais são modelados como artefatos (os elementos verdes à direita). Esta abordagem mantém a camada de aplicativos reservada para a camada lógica, e a camada de tecnologia para a camada física. Não somos muito favoráveis a esta abordagem, uma vez que vemos com muita frequência os aplicativos serem modelados como componentes de aplicativos, e muitos dos exemplos disponíveis na Internet fazem o mesmo.

Além disso, os arquitetos geralmente precisam modelar e analisar o ambiente de um aplicativo específico e seus componentes sendo suportados pelas tecnologias. Isto não é muito conveniente quando usamos artefatos. O uso do conceito de artefato do ArchiMate geralmente se refere aos arquivos .exe, .jar e outros tipos executáveis. Assim, esta abordagem só funciona melhor que as duas outras listadas nesta postagem quando você realmente quer mostrar quais arquivos realizam os componentes de aplicativo que estão sendo descritos (e onde eles deveriam ser implementados).

Terceira abordagem - modelos separados

Figura 4 - Componentes lógicos e físicos como especializações de componente de aplicativo

A terceira abordagem modela os aplicativos lógicos e físicos como componentes de aplicativo, que podem ser entendidos como duas especializações do componente de aplicativo do ArchiMate. Esta abordagem é usada no modelo IT4IT do The Open Group, e, próximo da primeira abordagem acima, é uma das abordagens mais usadas (de acordo com a nossa percepção). Isto é útil quando você quer criar modelos ArchiMate completamente diferentes para a arquitetura lógica/ABBs e arquitetura física/SBBs.

Pense na criação de uma arquitetura de referência onde você não mostra os vários aplicativos de negócio usando os seus nomes, mas ao invés disso usa um único elemento que representa alguns ou todos eles sob um guarda-chuva de "aplicativo de negócio". Isto também é adequado para fins de documentação, para evitar trazer muitos novos conceitos para a mesa. Usando esta abordagem, toda a camada de aplicativos, com todos os conceitos, pode ser usada em ambos os níveis de abstração (ABBs e SBBs).

O que está faltando?

Agora, você viu três abordagens que o framework ArchiMate oferece para descrever suas arquiteturas, de acordo com os conceitos de Blocos de Construção de Arquitetura e de Solução do Continuum Corporativo do TOGAF, através de uma notação padrão. Uma vez que é um framework, você deveria usar aquilo que for útil para você. No artigo final desta série, completaremos o mapeamento do ArchiMate para o Continuum Corporativo do TOGAF através da conexão da primeira destas três abordagens com as Soluções Implementadas.



* Bernd Ihnen é Consultor e Instrutor da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.

Seis Maneiras de Organizar Seus Modelos de Arquitetura (Parte 2)

postado em 5 de abr de 2018 13:32 por Antonio Plais   [ 25 de abr de 2018 09:31 atualizado‎(s)‎ ]

Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign - Tradução autorizada

Na postagem anterior desta série, escrevemos sobre a organização do seu repositório de modelos de acordo com os domínio de negócios, aplicativos e tecnologia. Também explicamos a necessidade de criar modelos separados para os estados atual e futuro, e a separação entre conteúdo e visão dos modelos. Nesta postagem, temos mais algumas coisas a acrescentar nos tópicos de nomeação e convenções de modelagem, bem como aconselhar sobre como estabelecer uma estrutura de governança e garantia da qualidade em torno dos seus modelos.

4. Definindo nomeação e outras convenções de modelagem

Para ser capaz de encontrar qualquer coisa em um modelo de larga escala, você tem que saber o que você está procurando. Em linguagem simples, você precisa saber como as coisas são chamadas - e como elas são nomeadas - no seu modelo. Por isso é essencial definir convenções claras de nomeação. Organizações diferentes terão seus próprios esquemas específicos de nomeação, de forma que nenhuma convenção universal é aplicável.

De qualquer forma, existem dicas comuns que podem ajudá-lo a criar seu próprio processo de nomeação:
  • Deixe os especialistas de negócio "possuírem" os nomes e definições de capacidades, processos e funções de negócio, e coisas parecidas. Se o pessoal de TI inventa novos nomes para estas coisas, o pessoal de negócios provavelmente não será capaz de reconhecer "o seu negócio" neles, levando a falhas de interpretação e entendimento.
  • Defina convenções de nomeação específicas para tipos específicos de elementos. Por exemplo, use verbos no indicativo mais um nome para nomes de processos (por exemplo, "Tratar Sinistro"). Desta forma, o nome do elemento já lhe dá uma indicação do tipo de coisa que está sendo modelada.
  • Em grandes organizações, use prefixos ou sufixos para nomes, tais como o domínio de negócio do elemento. Isto é particularmente importante se estes domínios usam os mesmos nomes. Por exemplo, em uma seguradora, domínios diferentes para "saúde", "vida" e "propriedade" podem, cada um, ter um processo "Tratar Sinistro", mas estes processos podem ser diferentes. Chamando-os "Tratar Sinistro - Saúde" ou "tratar Sinistro - Propriedade" ajuda a distinguir entre eles.
  • Faça uma separação clara entre diferentes aspectos da mesma entidade do mundo real que está sendo modelada. Se você está modelando um cliente que toma parte em um processo como um ator, não use o mesmo nome para a informação que você captura sobre aquile cliente. Você deveria, também, ter nomes diferentes para o arquivo ou banco de dados de clientes onde você guarda aquela informação. Chamar todos estes elementos de "Cliente" com certeza irá confundir ao extremo qualquer um que venha a usar seu modelo.
  • Seja seletivo no seu uso de conceitos de modelagem. Linguagens como o ArchiMate são muito ricas e poderosas, mas você raramente precisará usar todos os seus conceitos. Escolher quais conceitos usar, e para qual propósito, e se limitar ao essencial é chave para manter suas arquiteturas fáceis de serem entendidas.
Figura 2. Visão geral da sua capacidade de arquitetura corporativa, forma de trabalho e melhores práticas

5. Estabeleça um "comitê editorial"

Para criar colaboração em organizações grandes e federadas, você não pode confiar em controles simples de cima para baixo, a partir de um departamento central. Deve haver espaço para variações locais simplesmente porque, em grandes organizações, nenhum padrão vai se ajustar a todas as situações.

De qualquer forma, você precisa de coordenação entre os diferentes departamentos e domínios, para garantir que suas formas de trabalhar são compatíveis, e para compartilhar e se beneficiar das experiências dos outros, de forma que você possa construir sua própria biblioteca das melhores práticas da sua empresa.

Trabalhando em empresas grandes e complexas, temos visto que é útil criar algum tipo de "comitê editorial", composto por especialistas em modelagem e arquitetura representativos das diferentes áreas da organização. Eles podem encontrar formas compartilhadas de trabalhar, além de outros pontos comuns entre suas arquiteturas (tais como as convenções de modelagem e estruturação mencionadas anteriormente), e podem treinar e orientar seus colegas menos experientes na aplicação destas práticas para promover modelos de alta qualidade.

No entanto, o "comitê editorial" não é o mesmo que o seu comitê de arquitetura, que decide em relação ao conteúdo arquitetural em si. Ao invés disso, este comitê editorial supervisiona a maneira como as arquiteturas são modeladas e descritas. Estas são duas competências distintas: uma boa arquitetura pode ser descrita de forma pobre, e uma arquitetura pobre pode ser bem documentada. Tenha a certeza que os dois são bem feitos.

6. Descreva responsabilidades claras, direitos de acesso, grupos de usuários e procedimentos

Em grandes organizações, você deve ter muito claro quem faz o que, e quem tem acesso a qual material. Se todo mundo pode editar qualquer coisa nos seus modelos de arquitetura, você pode adivinhar o que acontecerá! As coisas podem ser movidas, alteradas, e até mesmo modelos inteiros podem ser excluídos.

Em geral, não recomendamos esconder partes da arquitetura (a não ser que haja razões específicas de segurança e confidencialidade). Os arquitetos devem ser confiáveis para ver o trabalho de seus pares e fazer bom uso dele. No entanto, você provavelmente precisará limitar o acesso para gravação apenas para as pessoas que têm o papel definido de criação e atualização de modelos. De outra forma, seus modelos rapidamente se tornarão uma bagunça!

Uma maneira de fazer isso é organizar o trabalho nas arquiteturas de estado futuro em projetos, cada um com seus respectivos modelos, como descrito acima. Equipes de projeto têm o direito de mudar os modelos no projeto, mas os resultados só são publicados no repositório geral da arquitetura quando eles estão suficientemente prontos, de acordo com a decisão de um arquiteto líder ou tomador de decisão dentro da organização.

Figura 3 - Papéis comuns associados com a arquitetura

O Enterprise Studio Team Platform suporta os diferentes projetos, papéis e direitos para os desenhistas e líderes de desenhistas da sua organização, e oferece a funcionalidade de grupos de usuários que podem ser organizados em equipes de projetos. Mais ainda, a funcionalidade de fluxo de trabalho disponível no Portal HoriZZon permitem que você crie fluxos de trabalho de revisão e aprovação para organizar o processo de desenvolvimento da arquitetura.

Para saber mais sobre o Enterprise Studio, o Team Server e o Portal Horizon, entre em contato com a Centus Consultoria e peça uma demonstração.


* Mark Lankhorst é Gerente de Consultoria & Evangelista-Chefe de Tecnologia da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.

Usando o Continuum Corporativo do TOGAF para Classificar Descrições da Arquitetura

postado em 2 de abr de 2018 09:48 por Antonio Plais   [ 12 de abr de 2018 19:49 atualizado‎(s)‎ ]

Originalmente postado por Bernd Ihnen*, no blog da BiZZdesign - Tradução autorizada

Em postagens anteriores, escrevemos sobre a necessidade de digitalizar as capacidades de mudança e como a arquitetura corporativa pode suportar e fornecer valor para sua organização. Também discutimos como categorizar descrições da arquitetura ao longo de diferentes níveis de abstração. Mas há uma dimensão que nós ainda não exploramos em profundidade: Quão genérica ou específica é a descrição da arquitetura comparada com a sua organização?

Durante a última década, muitas arquiteturas de referência foram desenvolvidas e publicadas. Elas são um ponto de partida útil para descrever uma organização, e as arquiteturas podem ser mais ou menos específicas para a nossa empresa. Não vamos nos aprofundar em uma discussão acadêmica sobre o que deveria ser classificado como o que, de forma que iremos nos ater aos pontos principais do conceito mais amplo.

De arquiteturas genéricas para arquiteturas específicas da organização

O espectro mostrado na figura acima começa à esquerda com os tipos mais genéricos de arquiteturas, as Arquiteturas de Fundação. Arquiteturas de tecnologias ou infraestrutura genéricas em geral se encaixam nesta categoria, como o Modelo de Referência Técnica (TRM-Technical Reference Model) a que se refere a especificação TOGAF 9.1. Aqui, nós geralmente encontramos descrições da arquitetura de tecnologias ou plataformas tecnológicas.

Movendo-se para a direita, Arquiteturas Comuns podem ser construídas sobre as Arquiteturas de Fundação. Usualmente, estas arquiteturas são mais específicas para uma arquitetura da organização, mas, ainda assim, estes tipos de arquitetura poderiam, potencialmente, ser aplicados para organizações em várias indústrias. Podemos mencionar, como exemplo, uma arquitetura de referência de Planejamento de Recursos Corporativos (ERP-Enterprise Resource Planning) ou de um sistema ERP, que poderia ser usado por empresas de várias indústrias.

Se uma arquitetura é mais específica, mas ainda potencialmente reusável em várias organizações da mesma indústria, estes tipos de arquitetura podem ser classificados como Arquiteturas da Indústria, por exemplo, arquitetura de referência de ERP Automotivo. Outro exemplo é um sistema ERP que é desenvolvido para ser usado na indústria de água e energia, onde as empresas em geral enfrentam várias e constantes mudanças regulatórias.

Arquiteturas Específicas da Organização são aquelas arquiteturas que você descreve para a sua organização, principalmente para suportar programas e projetos. Assim sendo, elas são as descrições da arquitetura mais específicas para a sua organização.

O TOGAF chama as descrições da arquitetura de "artefatos", que são "um produto do trabalho arquitetural que descreve um aspecto da arquitetura", e pode ser expresso através de tabelas, matrizes ou diagramas (TOGAF 9.1, seção 2.5). A especificação TOGAF trás mais informações sobre como estas categorias do espectro se inter-relacionam umas com as outras, mas vamos focar na parte mais prática.

O que nós usamos na prática?

Na prática, nós geralmente vemos arquiteturas específicas da organização (nossas descrições da arquitetura) e arquiteturas específicas da indústria. Se você não pode achar uma arquitetura de referência para a sua indústria, você pode tentar encontrar uma arquitetura mais genérica - arquiteturas comuns ou de fundação. Estes modelos de referência existem para vários domínios da arquitetura, por exemplo, capacidades, processos de negócio (por exemplo, ITIL), funções, aplicativos, tecnologias, ou risco e segurança.

Agora, você pode classificar as descrições da arquitetura de acordo com descrições funcionais/de solução, e de acordo com a sua especificidade. O exemplo a seguir ajudará a aplicar esta categorização na prática.

Exemplo prático de classificação da arquitetura

Para tornar isto prático, você pode usar taxonomias de classificação de tecnologia fornecidas por companhias que oferecem serviços de tecnologia da informação. Uma destas empresas é a Flexera BDNA Technopedia, que fornece informações sobre ciclos de vida das tecnologias, e muito mais. Isto serve como um bom ponto de partida para classificar tecnologias e é uma alternativa para o TOGAF TRM, mais antigo. Além disso, se você sentir falta de alguma classificação, lembre-se que o TOGAF diz para você "personalizar o modelo de referência de acordo com a sua necessidade".

A tabela abaixo mostra exemplos através do continuum corporativo:

Arquiteturas de Fundação  Arquiteturas Comuns  Arquiteturas da Indústria  Arquiteturas Específicas da Organização
TOGAF TRM, incluindo S.O. e DBMS
BDNA
Open Infrastructure Architecture - OIAr 
TOGAF III-RM
IT4IT
Arquitetura de ERP
Mapa de capacidade BIAN
Arquitetura ERP para a Indústria Automotica
Mapa de Capacidade da Companhia XYZ
Arquitetura de ERP da Companhia XYZ
Linux, SAP Hana, MS SQL, Kafka SAP ERP SAP ERP Indústria Automotiva SAP ERP da Companhia XYZ

Agora, você tem os meios para classificar suas descrições da arquitetura. Para atingir as proposições de valor da Arquitetura Corporativa, na sua jornada para se tornar uma Empresa Adaptativa, você pode ter um olhar mais atento para os blocos de construção da arquitetura e de soluções, o que evita que você, como arquiteto corporativo, se perca no gerenciamento de todas as instâncias implementadas na sua organização.

Na próxima postagem desta série, vamos abordar como você pode usar a linguagem ArchiMate para descrever estas arquiteturas usando uma notação padronizada de uso mundial. Isto irá ajudá-lo a padronizar a sua comunicação em relação à descrições da arquitetura para suportar suas mudanças estratégicas!


* Bernd Ihnen é Consultor e Instrutor da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.

Linguagem: A Base para Transformações Estratégicas de Sucesso

postado em 31 de mar de 2018 11:28 por Antonio Plais   [ 2 de abr de 2018 09:52 atualizado‎(s)‎ ]

Originalmente postado por Bernd Ihnen*, no blog da BiZZdesign - Tradução autorizada

Estamos vivendo tempos interessantes. A digitalização de todas as capacidades de negócio atingiu um novo nível, e provoca um enorme impacto em todas as indústrias. Modelos de negócio estão sendo redefinidos e novas companhias emergem para se tornarem importantes empresas globais. Hoje, as empresas precisam ser mais ágeis do que nunca, e a velocidade da mudança só irá continuar aumentando.

Para encarar este desafio, a única opção é se tornar uma "Empresa Adaptativa". Depois de digitalizar as capacidade de negócio umas depois das outras, através de mudanças estratégicas, a maioria das operações são digitalizadas e os processos continuarão a serem estendidos para outras áreas operacionais. Ho entanto, uma importante capacidade está sendo esquecida:

Para se tornar verdadeiramente uma "Empresa Adaptativa", você deve digitalizar sua capacidade de mudança

Digitalizando a mudança

Mark Lankhorst e Peter Matthijssen explicam isso em profundidade em seu eBook A Empresa Adaptativa - Prosperando em uma Era de Mudanças. Ser capaz de descrever seu negócio e as tecnologias de suporte, em seus vários níveis de detalhe, é uma capacidade importante para acelerar transformações estratégicas. A Arquitetura Corporativa fornece métodos e técnicas para desenvolver e descrever a estratégia corporativa, o negócio, as tecnologias, os programas, e como tudo isso funciona em conjunto.

Falar a mesma linguagem para alinhar diferentes papéis, áreas de negócio, projetos e operações é um desafio constante para a mudança estratégica. Na prática e na web, vemos muitas descrições de arquiteturas. Algumas usam uma linguagem formal, algumas usam símbolos fornecidos por alguma ferramenta de desenho, e algumas usam simples matrazes ou descrições textuais.

Usar uma notação formal fornece a enorme vantagem da precisão e do alinhamento para os arquitetos, e permite que eles respondam a perguntas como:
  • Sobre o que esta descrição da arquitetura está falando? Todo mundo pensa a mesma coisa quando usa as mesmas palavras?
  • A descrição da arquitetura endereça uma descrição funcional?
  • a descrição da arquitetura endereça ativos reais, como os servidores instalados?
  • Ela descreve sistemas em produção, em instalação, sistemas de backup, sistemas em pré-produção?
  • O desenho da arquitetura descreve partes de uma arquitetura da indústria ou a arquitetura da empresa?
Onde começar para obter o controle sobre a enorme variedade de descrições da arquitetura nos diferentes programas e projetos?

Primeiro, deveríamos ser capazes de categorizar as descrições da arquitetura. Para manejar isso, o Continuum Corporativo do TOGAF é um framework bastante útil. Ele ajuda a realçar em que nível de abstração uma arquitetura está (neste momento) sendo analisada, e apresenta diferentes níveis para serem usados para diferentes propósitos: "O Continuum Corporativo fornece um método para a classificação de artefatos de arquitetura e de solução [...]" (TOGAF 9.1, seção 39.1), e a figura abaixo mostra uma ideia geral desta classificação:

Figura 1: Adaptado de TOGAF 9.1 Figura 39-1

Comecemos com o retângulo inferior. As soluções implementadas descrevem o que está realmente implementado - os ativos do mundo real. Ele reflete quais soluções são selecionadas e instanciadas através de uma implementação. Estas soluções implementadas podem ser as instalações em produção, tais como "ERP SAP P123", ou "Salesforve P123", e são, em geral, gerenciadas pelas Operações. Uma vez que as soluções implementadas são instâncias de soluções, o continuum de blocos de construção de soluções contém tipos ou mapas de soluções que são implementadas: "Blocos de Construção de Soluções (SBB-Solution Building Blocks) [...] podem ser comprados ou desenvolvidos" (TOGAF 9.1, seção 37.2.4). Eles são relacionados a produtos ou fornecedores, por exemplo, "ERP SAP" ou "Servidor Windows", como um tipo de produto que pode ser comprado ou desenvolvido.

O retângulo laranja do Continuum da Arquitetura reflete os blocos de construção da arquitetura. "Blocos de Construção da Arquitetura (ABB-Architecture Building Blocks) capturam os requisitos da arquitetura e direcionam e orientam o desenvolvimento dos SBBs. Eles consistem de, e descrevem, as funcionalidades fundamentais" (TOGAF 9.1, seção 37.2.3). Você pode, também, chamá-los de componentes conceituais ou lógicos, por exemplo, "Planejamento de Recursos Corporativos (ERP-Enterprise Resource Planning)" ou "Sistema Operacional".

Em resumo:
  • Blocos de Construção da Arquitetura são descrições funcionais (por exemplo, ERP, SO)
  • Blocos de Construção de Soluções são tipos de produtos (por exemplo, SAP ERP, Windows Server, software desenvolvido internamente)
  • Soluções Implementadas são instâncias implementadas dos produtos (por exemplo, SAP ERP P123)
Agora, você pode classificar suas descrições da arquitetura de acordo com estes três grupos. Se você atualmente só está gerenciando as soluções implementadas através de um CMDB, podem existir mais descrições de tipos diferentes que possam ajudá-lo a arquitetar o futuro de sua empresa!

Mais sobre a classificação de descrições da arquitetura

Além destes três grupos, o Continuum Corporativo fornece um espectro para os blocos de construção da arquitetura e das soluções, para classificar a descrição da arquitetura e responder "Quão específica da minha organização é esta descrição da arquitetura?" Esta informação vai ajudar a completar a discussão sobre a classificação de descrições da arquitetura, na próxima postagem.


* Bernd Ihnen é Consultor e Instrutor da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.

Seis Maneiras de Organizar Seus Modelos de Arquitetura (Parte 1)

postado em 29 de mar de 2018 04:08 por Antonio Plais   [ 5 de abr de 2018 13:34 atualizado‎(s)‎ ]

Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign - Tradução autorizada

Se você tem alguma experiência com a modelagem casos reais de arquiteturas completas para grandes organizações - preferivelmente usando a linguagem ArchiMate, é claro - você provavelmente se viu de frente para o desafio de organizar seus modelos de uma maneira lógica e gerenciável. Nesta série de postagens em duas partes, compartilharemos as seis maneiras mais comuns que usamos para organizar nossos modelos de arquitetura. Estes seis métodos deveriam ajudá-lo a manter seus modelos organizados e limpos, ao mesmo tempo em que suportam melhores resultados para suas iniciativas estratégicas.

1. Organize seu repositório de modelos por domínios de negócio, domínios de informação e pilhas de tecnologia

Para grandes organizações, você precisa de alguma subestrutura para o seu modelo integrado do estado atual. As capacidades, funções e processos de negócio podem ser organizados por domínios de negócio ou capacidades de negócio de alto nível. Isto é uma subdivisão natural no mundo dos negócios, facilmente reconhecida tanto pelo pessoal envolvido como pelas estruturas de autorização e responsabilidade típicas em sua organização. A parte de aplicativos e dados do seu repositório de modelos pode ser organizada de acordo com os domínios de informação, consistindo de:
  • Conjuntos de itens de informação que geralmente se mantém juntos
  • Aplicativos que processam estas informações
  • Funções de negócio que estes aplicativos suportam
Por exemplo, você poderia ter um domínio de informações para Dados do Cliente, compreendendo os dados pessoais relevantes que você captura dos seus clientes e os aplicativos usados para armazenar e processar estas informações. (por exemplo, sistemas CRM). Outro domínio de informação poderia ser a Interação com o Cliente, onde você poderia encontrar aplicativos de centrais de atendimento e de mídias sociais, por exemplo.

Para a parte de tecnologia da arquitetura, uma estrutura orientada para o negócio geralmente não faz muito sentido, uma vez que boa parte da infraestrutura técnica de uma empresa atravessa domínios de negócio e de informação. Ao invés disso, a organização por pilhas tecnológicas faz mais sentido na maioria dos casos. Estes modelos de pilhas podem ser gerenciadas por equipes separadas com a competência técnica necessária.

Configurar uma página de navegação para ajudar as pessoas a encontrar seus caminhos em torno desta estrutura é, também, muito útil. A figura abaixo mostra um exemplo disso:


Duas outras categorias de modelos são 1) modelos de referência externos e 2) padrões. Por exemplo, o padrão BIAN para a indústria bancária ou o padrão de segurança ISO/IEC 27001 mostrados na figura acima descrevem sua forma de trabalhar, incluindo:
  • seus processos de modelagem
  • suas convenções de nomeação
  • papéis e estrutura da equipe de arquitetura
  • e muito mais...
Ter isso acessível no mesmo repositório é muito conveniente. Naturalmente, existem muitos aspectos transversais e sobrepostos nestes domínios. Para resolver isto, você precisa estabelecer uma coordenação regular entre os especialistas envolvidos, de preferência suportados por uma plataforma colaborativa que permita que você defina direitos de acesso, crie fluxos de trabalho de revisão e de alguma forma organize o trabalho a ser feito. Nossos produtos, Enterprise Studio e HoriZZon, oferecem suporte para estes aspectos da modelagem da arquitetura.

2. Separe os modelos do estado atual e futuro

É importante fazer uma separação clara entre o que você descreve sobre o mundo como você o conhece hoje e o futuro que você está almejando. Fatos sobre o presente e ideias sobre o futuro deveriam ser claramente distinguíveis nos seus modelos da arquitetura.

Uma forma de fazer isso é criar um modelo de referência integrado, somente para leitura, do seu estado atual (possivelmente por domínio, como descrito acima) e separar modelos no nível dos projetos que descrevem os aspectos do futuro na medida em que eles estão sendo desenhados. A visibilidade destes modelos do estado futuro é limitada aos membros da equipe de projeto que estão trabalhando neles, de forma que as demais pessoas não sejam confundidas pelo trabalho que está sendo feito no desenho do estado futuro. Dentro destes modelos do estado futuro, elementos do estado atual que continuarão no futuro podem ser reusados. Quanto for chegada a hora de colocar os resultados do projeto em produção, os modelos do estado futuro se tornarão realidade e serão transferidos para o modelo integrado do estado atual.

É importante notar que o processo de criação destes modelos é bastante diferente. Quando eles descrevem o estado atual, muitas vezes é mais fácil começar por aquilo que chamamos de 'estrutura' na linguagem de modelagem ArchiMate: a organização, os aplicativos, as plataformas de software e os dispositivos que estão prontamente visíveis na sua empresa. A partir daí, você pode olhar para o seu comportamento: os processos, serviços e funções fornecidos por estes elementos de estrutura. Em seguida, você poderia olhar por similaridades e oportunidades para sinergias ou racionalizações, apenas como um exemplo.

Ao desenhar a arquitetura do estado futuro, no entanto, você geralmente trabalha da maneira contrária: você primeiro define os serviços que você necessita para resolver o seu problema de negócio, então você rascunha os processos e funções que precisam fornecer estes serviços. Uma vez que isto está completo, somente então você decide quais elementos de estrutura desempenharão este comportamento e entregarão estes serviços. Isto evita a armadilha comum de restringir suas soluções possíveis de desenho em função das estruturas (isto é, componentes, sistemas, produtos, etc.) que você conhece, especialmente no início do processo de desenho.

3. Separe o conteúdo dos modelos das visões daquele conteúdo

Na modelagem da arquitetura, é importante distinguir o conteúdo da sua arquitetura das visões deste conteúdo que endereçam preocupações específicas das várias partes interessadas, através da visualização de partes do conteúdo de uma maneira adequada. Os mesmos elementos do modelo podem aparecer em diferentes visões; da mesma forma, todas as visões compartilham o mesmo conteúdo subjacente.

Tipicamente, você organiza o conteúdo do modelo de acordo com os tipos de elementos que você modela, usando, por exemplo, as camadas da linguagem ArchiMate (motivação, estratégia, negócio, aplicativo, tecnologia, implementação & migração), ou mesmo de forma mais granular, definindo conjuntos separados de processos de negócio, componentes de aplicativo, etc.

As visões deste conteúdo são melhor organizadas de acordo com os tipos de partes interessadas que você endereça, com visões para grupos como gerentes de negócio, desenhistas de processos, donos de aplicativos, gestores de dados, gerentes de projetos, administradores de sistema, e assim por diante.

Mais ideias para a organização de modelos de arquitetura

Na segunda e última parte desta série endereçaremos as convenções de nomeação e modelagem, bem como discutiremos estruturas para a governança e a garantia de qualidade dos seus modelos. Fique ligado!



* Mark Lankhorst é Gerente de Consultoria & Evangelista-Chefe de Tecnologia da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.

Como Construir uma Empresa Adaptativa?

postado em 19 de mar de 2018 07:56 por Antonio Plais   [ 19 de mar de 2018 07:59 atualizado‎(s)‎ ]

Originalmente postado por Marc Lankhorst & Peter Matthijssen*, no blog da BiZZdesign - Tradução autorizada

No turbulento ambiente atual de negócios, as organizações precisam ser excelentes no desenho e implementação das mudanças. A 'Organização Digital' requer inovação contínua, o que significa que as organizações estão em um constante estado de fluxo. Ao mesmo tempo, elas precisam estar no controle das mudanças. Elas têm que lidar com a pressão regulatória, restrições financeiras, e com o risco de perturbação dos seus negócios correntes enquanto implementam as grandes mudanças.

Em uma postagem anterior, e no eBook 'A Empresa Adaptativa', argumentamos que, para sobreviver e vencer neste ambiente, as organizações precisam focar em seis capacidades para se tornarem adaptativas: Simplificar, Inovar, Colaborar, Acelerar, Decidir e Controlar.

Como melhorar sua capacidade de mudança?

No eBook indicado acima, demonstramos a necessidade de digitalizar estas capacidades usando uma plataforma colaborativa de desenho de negócios como o BiZZdesign Enterprise Studio. O livro explica como uma plataforma como esta ajuda você a alinhar estratégia, pessoas, processos e tecnologia, e como lidar com as enormes quantidades de dados envolvidos, realizar várias análises para suportar uma tomada de decisões baseada em fatos, e visualizar e comunicar a mudança. O que nós não discutimos, no entento, é como ir do ponto A para o ponto B: como você pode melhorar suas capacidades de mudança para endereçar os problemas da sua empresa, usando efetivamente o Enterprise Studio?

Para ajudá-lo com isso, criamos um método de avaliação e melhoria baseado em um modelo de capacidades detalhado. É um refinamento das seis principais capacidades da empresa adaptativa descritas acima, e é, naturalmente, implementada no próprio Enterprise Studio. A figura abaixo sumariza a abordagem:


Ela começa com a identificação das preocupações de negócio importantes que a sua organização quer endereçar, suportado por uma lista de mais de 100 questões. Para lhe dar uma ideia, aqui está uma amostra de algumas destas questões:
  • Quais capacidades são necessárias para o seu modelo de negócio?
  • Nós podemos rastrear a contribuição de cada projeto para resultados concretos de negócio?
  • Nosso uso de dados pessoais respeita as regulações de privacidade?
  • Qual o impacto da introdução de um novo produto?
  • Qual é o risco do término de vida de uma tecnologia para um aplicativo?
Para diferentes questões de negócio precisamos de capacidades de colaboração, análise e mudança diferentes. Selecionar as questões mais relevantes para você determina o que você precisa.


As funcionalidades do Enterprise Studio mostradas acima suportam estas capacidades. Nós avaliamos o seu uso atual (se houver) destas funcionalidades, usando um segundo conjunto de questões. Isto fornece percepções sobre as suas capacidades atuais. Nós criamos mapas de calor mostrando suas capacidades atuais, as capacidades alvo, e as diferenças entre elas.

Agora, implementar ou melhorar as capacidades para preencher as lacunas exige alguma reflexão. Para guiá-lo nesse processo, criamos um modelo de maturidade que mapeia estas capacidades para diferentes estágios de crescimento. Tipicamente, você começa com as capacidades mais básicas e implementa as capacidades mais avançadas em um estágio posterior.


Finalmente, para suportar as capacidades necessárias para responder às suas questões de negócio, nossa abordagem recomenda o uso de funcionalidades específicas do Enterprise Studio. Isto fecha o ciclo e permite que você use o máximo da nossa plataforma dentro do seu contexto de negócios.

Em resumo, para endereçar as seis capacidades principais mencionadas acima, nós fornecemos um conjunto detalhado de capacidades de suporte, nós avaliamos suas necessidades com base nas questões de negócio que se apresentam, e endereçamos o suporte a elas pelas funcionalidades do Enterprise Studio. Assim, você sabe o que usar, personalizado para as circunstâncias específicas da sua organização. Você sempre poderá mudar a maneira como você muda, e se tornar uma Empresa Adaptativa.



* Mark Lankhorst é Gerente de Consultoria & Evangelista-Chefe de Tecnologia, e Peter Matthijssen é Diretor de Tecnologia, da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.

1-10 of 57