Arquitetura Corporativa
Suportando Grandes Arquiteturas como uma Equipe
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 federadasUma 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 arquiteturaEm 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 automatizadoQuando 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:
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:
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
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 implementadasO 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 tecnologiaO 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 nó, 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érieO 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.
 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
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:  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 derivadosUsando 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 ArchiMateO 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
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 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).  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)
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 modelagemPara 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:
 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 procedimentosEm 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.
 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
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çãoO 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 arquiteturaPara 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:
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
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çaMark 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:
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:
 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:
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 arquiteturaAlé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)
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 tecnologiaPara 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:
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:
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údoNa 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 arquiteturaNa 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?
Originalmente postado por Marc Lankhorst & Peter Matthijssen*, no blog da BiZZdesign - Tradução autorizada 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. 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:
   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. |
Segurança Cibernética: 5 Passos para Estar Seguro em um Mundo Perigoso
Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign - Tradução autorizada As ameaças de segurança cibernética estão aumentando cada vez mais. É comum se dizer que existem dois tipos de organizações: aquelas que sabem que elas foram atacadas, e aquelas que não sabem disso ainda. Para mitigar o risco e o dano associado com a segurança cibernética, é importante saber como avaliar estes riscos e melhorar suas defesas através da segurança-por-desenho. É importante, também, planejar o que fazer se (e quando) as coisas saem dos trilhos. Garanta a conscientização por toda a organizaçãoNa maioria das organizações, a conscientização das gerencias de nível superior em relação às ameaças cibernéticas tem crescido em função dos numerosos incidentes com grande impacto ocorridos nos últimos tempos. O custo associado com ransomware, vazamento de informações e outros problemas pode facilmente char à casa das centenas de milhões de Reais. No entanto, a segurança cibernética ainda é vista apenas como um problema técnico, que deve ser lidado pela Diretor de TI e sua equipe. Uma forma garantida de acordar toda a Diretoria para a conscientização da segurança cibernética é a conformidade regulatória. Nestes casos, a Direção pode ser pessoalmente responsabilizada pela não-conformidade, de forma que existe uma forte motivação para tomar ações. Novas regulações sobre privacidade de dados, como o GDPR da Comunidade Européia, são apenas um exemplo onde preocupações de segurança e privacidade chegaram até a sala da Diretoria. Regulações regionais e específicas de um setor, como a Lei de Privacidade HIPAA, dos Estados Unidos, para o setor de cuidados de saúde, ou a regulação NYDFS para Segurança Cibernética, para o setor financeiro em Nova York, são outros exemplos. Na maioria das vezes, a gerência se sente como um animal sob a luz dos faróis quando o assunto é ameaça cibernética. Eles vêm o perigo, mas não sabem o que fazer frente a estas ameaças. A extensão e a profundidade destes problemas pode, realmente, parecer incompreensível e não solucionável. Para ajudar a gerência a superar esta paralisia, você deve apresentar soluções, não apenas problemas. Arquitetos corporativos estão posicionados de forma única para contribuir para estas soluções.  Enquanto os arquitetos corporativos tentam construir padrões e processos de segurança cibernética, você precisa envolver e informar não apenas a gerência, mas também todo o resto da organização. Nós temos publicado uma série de postagens relacionadas com a comunicação sobre segurança da informação, discussão sobre segurança da informação na Diretoria, fornecendo dicas sobre como envolver seu negócio e endereçar o que realmente funciona para construir a conscientização da segurança. Para mais informações sobre como mitigar apropriadamente os riscos cibernéticos e de informação, consulte-as. Alinhe o gerenciamento de risco e segurança com a estratégia do negócioPara gastar seu dinheiro de forma inteligente, você precisa investir na segurança onde ela realmente conta - ou seja, onde ela é estrategicamente importante. Você deveria, desta forma, classificar seus ativos a partir da perspectiva da sua estratégia, levando em consideração a conformidade regulatória e outras orientações. Qual o valor destes ativos, não somente em termos financeiros, mas em um sentido mais amplo? Por exemplo, proteger o valor da propriedade intelectual ou dados sensíveis à privacidade pode ser crucial para a continuidade do seu negócio ou essencial a partir de uma perspectiva de conformidade regulatória. Tal classificação ajuda você a decidir suas prioridades de investimento e evitar gastar demais em medidas relativamente pouco importantes ou ineficazes. Infelizmente, a maioria das organizações não tem uma conexão clara entre a sua estratégia e seus ativos. Uma sólida arquitetura corporativa, relacionada com a motivação e direção estratégicas, bem como com a implementação dentro da organização, fornece o "tecido conectivo" que você precisa. O BiZZdesign Enterprise Studio fornece o suporte integrado para descrever a estratégia, a arquitetura, os processos, os sistemas e os dados que você precisa para criar esta linha de visão. Analise suas vulnerabilidades e riscosAtaques cibernéticos estão se tornando cada vez mais sofisticados, usando uma combinação de técnicas digitais, físicas e de engenharia social. Um exemplo comum é o assim chamado "ataque da maçã na beira da estrada". Um possível invasor "acidentalmente" deixa um pen-drive USB em um logar público, tal como o estacionamento da empresa. Algum empregado pega o pen-drive, e grandes são as possibilidades que ele não resistirá à curiosidade e irá conectá-lo ao seu PC. Surpresa: o pen-drive está infectado com algum malware que infecta o PC e envia informações sensíveis para o invasor. Com o Enterprise Studio, você pode capturar e visualizar vários aspectos de risco e segurança da sua organização. Isto ajuda você a visualizar os perigos, riscos e medidas mitigatórias em relação à sua arquitetura, estratégia de negócio e ativos, como um todo, de forma que você possa realizar uma avaliação de conformidade e riscos verdadeiramente baseada na estratégia e no valor de negócio. Você pode medir e visualizar o impacto potencial destes riscos e usar estas percepções para priorizar os investimentos em medidas de mitigação como parte do seu próximo passo. Nós escrevemos anteriormente sobre análises de conformidade e segurança, caso você esteja procurando por orientações adicionais nesta área. Adote uma abordagem de segurança por desenhoAs vulnerabilidades não deveriam ser tratadas após o fato, especialmente não apenas aplicando alguma medida de segurança imediato não planejada, como colocar um novo firewall. Ao invés de definir uma arquitetura de segurança separada, você deveria desenvolver uma arquitetura segura e endereçar os riscos proativamente na arquitetura e no desenho através de todos os níveis da sua organização, desde as pessoas e responsabilidades até os processos e tecnologia. Você também precisa levar em consideração a posição da sua organização em um ecosistema mais amplo. Manter a sua casa em ordem pode não ser suficiente. Por exemplo, se você confia extensivamente em algum parceiro externo, a segurança deles pode ser crucial para as operações do seu próprio negócio. Algumas organizações tentam confiar em contratos e acordos para lidar com isso, mas isto pode ser insuficiente. Legalmente, você pode ser tornado responsável por um vazamento que aconteça, digamos, em um parceiro externo. Regulações como o GDPR explicitamente declaram que a sua organização continua responsabilizável pelo processamento de informações sensíveis e sigilosas, mesmo se você contratar alguém para fazê-lo para você. Em alguns casos, você pode, inclusive, precisar auditar seus parceiros para garantir a conformidade. Em uma abordagem de segurança por desenho, você prioriza os investimentos em segurança com base no valor dos seus ativos e nas vulnerabilidades que você tiver identificado nas etapas anteriores. Você calcula o valor de negócio e o impacto dos projetos de segurança e usa isso para fazer a priorização das medidas de TI. Você pode usar nossa funcionalidade de gerenciamento de portfólios para decidir onde gastar seu orçamento mais efetivamente.  Assuma que você está comprometidoNenhuma quantidade de medidas de segurança irá torná-lo 100% seguro, de forma que é melhor você estar preparado para agir quando as coisas saírem dos trilhos. Muitas organizações se desesperam para saber o que fazer quando eles são atacados, porque eles não sabem que partes da organização ou dos sistemas podem ter sido afetados. Criar planos de contingência baseados em percepções claras em relação à estrutura e às operações da sua organização é essencial. Modelos atualizados da sua arquitetura, processos, sistemas e dados pode ser uma enorme ajuda para a avaliação de quanto um problema pode se espalhar, e em que pontos você deveria agir rapidamente para limitar o impacto de uma falha de segurança. Mas lembre-se de um dito de Eisenhower:"Planos não são nada; planejamento é tudo". Nada vai sempre completamente de acordo com os planos, mas o desenvolvimento em si de tais planos tornará claro o que você precisa saber, o que é desconhecido, e onde você deve atualizar seu conhecimento sobre o funcionamento e estrutura da sua organização. Conectar o Enterprise Studio com ferramentas como CMDBs (Sistemas de Gerenciamento de Infraestrutura), que gerenciam e monitoram a realidade operacional, ajuda a garantir que você está usando os melhores e mais atualizados dados disponíveis. Finalmente, toda esta informação precisa estar rapidamente acessível para a "linha de frente" da sua organização. O portal BiZZdesign HoriZZon oferece uma ótima solução para isso, fornecendo visões e painéis de controle fáceis de usar para os vários tipos de usuários, desde os executivos tomadores de decisões até os gerentes operacionais e pessoas no chão-de-fábrica. Para saber mais sobre como o BiZZdesign Enterprise Studio pode ajudá-lo a tornar realidade a segurança por desenho, entre em contato com a Centus Consultoria e agende uma conversa com nossos especialistas. * 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. |
1-10 of 56