Arquitetura Corporativa
Especificação ArchiMate® 3.1: A Nova Versão do Padrão
Originalmente postado por Marc Lankhorst*, no blog do The Open Group. - Tradução e adaptação autorizados
No evento do The Open Group em Amsterdan, em 05 de novembro de 2019, foi lançada a mais recente versão da linguagem ArchiMate® para a modelagem da Arquitetura Corporativa. A Versão 3.1 é uma atualização da versão anterior 3.0 (lançada em 2016). Embora seja "apenas" uma pequena atualização, ela trás várias adições e melhorias importantes para os praticantes da Arquitetura Corporativa.
As três melhorias mais importantes são:
Fluxo de ValorA mais importante e visível destas mudanças na Versão 3.1 é a adição de um novo elemento de Fluxo de Valor na camada de Estratégia. O padrão define isso como:
Um Fluxo de Valor descreve como uma empresa organiza suas atividades para criar valor. Como descrito no TOGAF® Series Guide to Value Streams, um importante princípio dos fluxos de valor é que o valor é sempre definido a partir da perspectiva da parte interessada - o cliente, usuário final ou recebedor do produto, serviço ou entregável produzido pelo trabalho. A noção de Fluxo de Valor também aparece em outros lugares, como em métodos de Arquitetura de Negócio, como o Guide to the BIZBOK®, e em métodos ágeis como o Scaled Agile Framework (SAFe®). A definição do ArchiMate é genérica o suficiente para cobrir estas noções.
Fluxos de Valor são diferentes de processos de negócio. Este último está preocupado com o 'como', as tarefas realizadas por uma organização para produzir algum produto ou serviço concreto, enquanto fluxos de valor dizem respeito ao 'o que', o valor que é criado. O valor está no olhar do espectador; ele depende mais da percepção de valor da parte interessada sobre o valor do produto, serviço, resultado, ou entregável, do que do seu valor intrínseco (isso é, o custo do produto). Isso é modelado na linguagem ArchiMate usando o elemento de Valor (que já existia desde a especificação do ArchiMate versão 1.0).
Fluxos de valor são normalmente realizados por processos de negócio. Os estágios em um fluxo de valor fornecem uma estrutura para organizar e definir estes processos, mas diferentes partes da organização podem ter suas próprias implementações dos processos para realizar o mesmo estágio do fluxo de valor. Da mesma forma, um processo de negócio pode realizar vários estágios em um fluxo de valor.
Recursos podem ser atribuídos a fluxos de valor e capacidades podem servir (isso é, habilitar) um fluxo de valor. Isso suporta a técnica comum de mapeamento cruzado entre fluxos de valor e capacidades, onde você identifica quais capacidades e empresa precisa ou usa para suportar os estágios de um fluxo de valor. Um exemplo disso é mostrado na figura abaixo. Ela mostra um modelo do fluxo de valor de uma análise de dados para um estudo de caso de inteligência de negócio. Entre os estágios do fluxo de valor, vemos os fluxos de valor com o valor adicionado associado por cada estágio, e ao final o resultado de negócio de 'tomada de decisão bem fundamentada' que este fluxo de valor realiza para uma parte interessada em particular. Cada estágio no fluxo de valor requer várias capacidades, mostradas abaixo dos estágios e também mostrando como você pode usar o conceito de agrupamento melhorado para modelar eficientemente este mapeamento cruzado.
 Exemplo de Fluxo de Valor
Adicionar este conceito de fluxo de valor criou uma perfeita simetria na linguagem. Fluxos de valor e capacidades refletem o modelo de negócio da empresa e a criação de valor de uma forma independente da sua organização, enquanto os processos de negócio e as funções de negócio refletem seu modelo operacional e são mais dependentes da organização. Nos seus respectivos níveis de abstração, fluxos de valor e processos de negócio representam a 'empresa em movimento', enquanto que as capacidades e funções de negócio descrevem a 'empresa em descanso'.
Associação DirecionadaA adição de um relacionamento de Associação direcionada é uma pequena melhoria com um grande potencial. Um caso de uso comum é para expressar a navegabilidade, por exemplo, que uma apólice de seguro se refere a um ativo segurado, e não o contrário.
Especialmente quando combinado com a noção de relacionamentos especializados do ArchiMate, e a notação de estereótipo relacionada (veja o capítulo sobre Mecanismos de Personalização no padrão), ela permite que você forneça mais significado para uma associação 'sem significado'. A figura abaixo mostra o relacionamento entre o sono de um aplicativo e o aplicativo que ele possui, usando uma associação direcionada estereotipada como essa.
 Associação Direcionada com Estereótipo
Agora, você precisa exercitar alguma cautela ao usar esta funcionalidade. Ela não seria muito útil, por exemplo, para definir seus próprios relacionamentos se alguma coisa bastante próxima já é oferecida nativamente pelo padrão.
Derivação de RelacionamentosAlém das adições e melhorias mencionadas acima, a nova especificação também introduz regras refinadas para a derivação de relacionamentos. Este é um assunto mais especializado, que para a maiorias das pessoas fica escondido por trás das ferramentas de modelagem ArchiMate.
Estas regras de derivação permitem que você tire conclusões ou sumários sobre relacionamentos que podem (ou devem) existir entre dois pontos em uma cadeia de elementos conectados por vários tipos de relacionamentos. Por exemplo, se o seu Departamento de Serviço ao Cliente desempenha (é atribuído a, em termos ArchiMate) um processo de negócio Tratar Solicitação do Cliente, que por sua vez fornece (isso é, realiza) um Serviço de Helpdesk, você pode concluir que o Departamento de Serviço ao Cliente realiza o Serviço de Helpdesk.
Na nova versão do padrão, nós formalizamos estas regras (e as restrições que se aplicam a elas) para garantir que elas sejam bem entendidas e implementadas consistentemente. Isso agora se parece mais com uma especificação 'matemática', mas não entraremos em detalhes sobre isso aqui.
Nós também refinamos estas regras para fazer uma distinção entre derivações que devem ou podem ser verdadeiras. O primeiro tipo, chamado derivação 'válida', são necessariamente verdadeiras. Por exemplo, se A contém B, e B contém C, A por definição contém C (usando um relacionamento de composição). Esta derivação é sempre válida.
 Derivação válida (em azul)
Também é possível tirar conclusões sobre relacionamentos que são apenas 'potenciais'; se eles existem ou não na realidade depende de fatores específicos da sua arquitetura. Por exemplo, se um serviço de aplicativo S serve um processo de negócio P, que consiste dos sub-processos Q e R, qualquer um destes sub-processos poderia (potencialmente) ser servido (ou seja, usar) o serviço S. Somente uma decisão do arquiteto, ou um exame detalhado de Q e R, poderia dizer qual é realmente o caso, mas os dois relacionamentos de servidão são corretos.
 Derivações Potenciais (em vermelho)
Note que todos estes relacionamentos derivados são também permitidos na linguagem ArchiMate. Adicionar esta noção de relacionamentos 'válidos' e 'potenciais' aumentou a força analítica da linguagem e expandiu os relacionamentos possíveis, dando aos modeladores mais liberdade e opções.
Expectativas para o FuturoAlém das principais melhorias mencionadas acima, várias mudanças grandes e pequenas foram feitas nas definições dos conceitos na linguagem, tanto para torná-las mais claras como para melhorar o alinhamento com outros padrões como o TOGAF. A notação de ícone é agora permitida para todos os elementos que possuem uma notação 'caixa com ícone', e não apenas para um pequeno sub-conjunto aleatório. Finalmente, a exibição e a estrutura do metamodelo do ArchiMate foi melhorada em vários lugares. Isso não é algo que o usuário médio da linguagem notará, mas isso ajuda a compreender melhor o padrão.
Com estas recentes melhorias e adições, a cobertura da disciplina da Arquitetura Corporativa pela linguagem ArchiMate está bastante completa, pelo menos em termos dos domínios que ela pode descrever. assim sendo, não esperamos maiores extensões para o escopo da linguagem no futuro próximo. Existem, no entanto, alguns outros aspectos que poderiam ser objeto de melhorias. Por exemplo alternativas de notação que pareçam mais agradáveis para as partes interessadas de negócio, ou formas de usar a linguagem nos estágios iniciais do desenho arquitetural, quando as ideias ainda não estão cristalizadas. Mais ainda, podemos querer procurar formas de simplificar a estrutura da linguagem (naturalmente, sem reduzir a sua força expressiva). Estas são, no entanto, ideias de longo prazo. Por enquanto, a Especificação ArchiMate 3.1 está pronta para uso e sem nenhum concorrente sério, enquanto sua base de usuários cresce continuamente. Se você tem ideias sobre o padrão e quiser contribuir para a sua evolução, ou simplesmente quer conhecer mais sobre ela, junte-se ao Fórum ArchiMate do The Open Group ou ao grupo ArchiMate (ou ArchiMate Brazil) no LinkedIn, onde acontecem discussões acaloradas sobre todos os aspectos da linguagem. Você pode encontrar a Especificação ArchiMate 3.1 aqui (em breve, também em Português Brasileiro).
* 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.
|
Gerenciamento do Portfólio de Aplicativos: Em Direção à Arquitetura Orientada para o Valor
Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign - Tradução e adaptação autorizados Muitas organizações com grandes panoramas de aplicativos legados não podem mais adiar uma reforma geral na sua TI. Mas como você evita criar de novo, hoje, os legados de amanhã? E como você emprega o seu orçamento de TI da forma mais sensata? Além de um desenho e de práticas de desenvolvimento apropriadas (por exemplo, com arquitetura corporativa, métodos ágeis e DevOps, como mostramos anteriormente), você precisa gerenciar seu portfólio de aplicativos como um todo, para decidir onde é mais importante investir.
Gerenciamento de Portfólios Fraco vs ForteO Gerenciamento de Portfólios é um processo de tomada de decisão dinâmico no qual um conjunto coordenado de aplicativos, projetos, programas ou produtos é rotineiramente monitorado, analisado e gerenciado para maximizar sua efetividade. A avaliação e priorização de projetos e atividades associadas com o inventário fornece a oportunidade para priorizar, acelerar, terminar ou "despriorizar" partes do portfólio e alocar ou realocar os recursos associados.
Quando as organizações não têm um gerenciamento de portfólios forte, elas são relutantes para terminar projetos ou executar a retirada de aplicativos ou produtos ao final do seu ciclo de vida. Além disso, os critérios para decidir de um projeto continua ou não (Go/No Go) são inefetivos ou inexistentes. Ativos com baixo desempenho não são avaliados ou eliminados. Alguns projetos desenvolvem vida própria, enquanto outros são adicionados com pouca ou nenhuma consideração pelos seus requisitos de recursos, atenção da gerência ou impacto em outros projetos. Recursos podem ser realocados para o último projeto "urgente", sem uma consideração exaustiva dos efeitos disruptivos que isso pode ter sobre os esforços "importantes" que já estão em andamento.
Como resultado, uma verdadeira falta de foco se instala - resultando em muito mais itens no inventário do que os recursos disponíveis são capazes de gerenciar. Listas de pendências de tarefas começam a se acumular, os tempos de ciclo começam a crescer, e os processos em uso se tornam inefetivos. Os esforços se tornam cada vez mais reativos e a qualidade sofre, resultando em uma taxa de falhas crescente. O impacto mais significativo de um gerenciamento de portfólio fraco é o impacto na direção estratégica - projetos que não estão alinhados com a estratégia do negócio ou que não possuem importância estratégica competem por e consomem recursos valiosos que deveriam estar focados nos esforços mais estratégicos. Muitas organizações sofrem do chamado "estrangulamento da inovação": todos os recursos e orçamentos disponíveis são usados para manter o panorama de legados em funcionamento, espremendo para fora inovações estratégicas importantes.
Existem vários desafios para atingir um gerenciamento de portfólios forte:
Como Fazer um APM da Maneira Correta?Falando genericamente, o Gerenciamento do Portfólio de Aplicativos (APM-Application Portfolio Management) é o processo de gerenciar uma coleção de aplicativos para tomar decisões efetivas sobre oportunidades de investimento. Assim como um portfólio de investimentos, que contém uma coleção de ativos selecionados para suportar objetivos de lucratividade ou crescimento específicos, portfólios de aplicativos deveriam ser gerenciados para efetivamente suportar as principais estratégias e metas de negócio da organização. Em geral, portfólios de ativos podem incluir produtos e serviços; capacidades e processos de negócio; software, como aplicativos de negócio, middleware e bancos de dados; infraestrutura, como servidores, redes, estações de trabalho, dispositivos móveis; e, finalmente, recursos para suportar tudo isso. No APM, nós focamos nos ativos de software.
Infelizmente, muitas organizações abordam o APM como uma simples racionalização de aplicativos pontual, na maioria das vezes focada no custo ou em problemas técnicos de curto prazo. Isso trás alguns problemas significativos. Em primeiro lugar, limpar o seu panorama de aplicativos apenas uma vez e esquecer disso de novo resultará nos mesmos problemas que você tem hoje reaparecendo em um futuro próximo. Ao invés disso, é necessário de uma abordagem de ciclo de vida para o portfólio de aplicativos. O monitoramento e governança regulares, incluindo critérios de valor de negócio claramente definidos da saúde (de negócio e técnica) dos aplicativos e opções de avaliação para o seu futuro, são necessários para gerenciar o portfólio de aplicativos em direção às necessidades do negócio.
 Figura 1. Avaliação de aplicativos usando Análise TIME
Mais ainda, os aplicativos são, em geral, julgados caso-a-caso, mas o panorama como um todo é mais importante, considerando as dependências entre os aplicativos e com os processos de negócio que eles suportam, e a complexidade, os riscos e o valor de negócio do panorama de aplicativos como um todo. Simplesmente substituir ou desligar um aplicativo isolado geralmente não é uma opção.
É essencial saber o valor de negócio dos aplicativos e como eles suportam o negócio, seus processos e capacidades. Mas como você determina isso de uma forma objetiva (isso é, não apenas perguntando para os usuários)? Para isso, você precisa usar modelos de arquitetura corporativa através de todos os domínios da arquitetura para mostrar a rastreabilidade para os processos de negócio, capacidades de negócio, produtos e serviços, e para as estratégias e metas do negócio. Isso também inclui mostrar casos de uso, cadeias de valor e fluxos de trabalho, e como eles são suportados pelos aplicativos, suas funcionalidades e objetos de dados, por exemplo, para um produto ou cliente. Isso ajuda a avaliar os aplicativos em seu contexto, ao invés de isoladamente, e isso pode também melhorar o valor dos aplicativos ao revelar novos usos potenciais. Mais ainda, diferentes categorias de aplicativos são julgadas de acordo com diferentes aspectos. Aplicativos de linha de frente inovativos precisam atender a critérios diferentes dos sistemas de registro estáveis. Portfólios adequados deveriam ser definidos para tais categorias. Você quer garantir uma distribuição balanceada dos investimentos, tanto dentro como através dos portfólios, e tanto para os seus ativos como para seus projetos e programas. É importante escolher critérios baseados nos objetivos de negócio. Tipicamente, um gerenciamento do portfólio de aplicativos forte se apóia em cinco medidas de desempenho:
 Como relacionar o APM com outras disciplinasComo nós indicamos acima, um APM forte depende criticamente de uma linha clara e visão com a estratégia de negócio e uma fundação forte na arquitetura corporativa. Uma forma útil de relacionar seus portfólios de aplicativos com a estratégia é através das capacidades de negócio. Capacidades de negócio definem o que uma organização precisa ser capaz de fazer para atingir os resultados que estão definidos na estratégia corporativa. Elas são os principais blocos de construção do negócio, únicos e independentes uns dos outros, e tendem a ser estáveis ao longo do tempo. Assim sendo, elas são uma fundação muito útil para estruturar portfólios de aplicativos e determinar a importância estratégica dos aplicativos nestes portfólios. Isso pavimenta o caminho para uma arquitetura verdadeiramente orientada para o valor. Mais ainda, um APM forte precisa ser parte dos processos do dia-a-dia que mantém e melhoram o seu panorama de aplicativos. Sua abordagem baseada em valor o torna bem adequado para abordagens como o Scaled Agile Framework (SAFe), discutido na nossa postagem anterior. Ligar o APM com os fluxos de valor no nível de portfólio do SAFe e orçamentar tais fluxos com base em (entre outros) resultados do APM é relativamente simples. ConclusãoEm resumo, um gerenciamento de portfólio de aplicativos forte leva a abordagem de ciclo de vida para o panorama de aplicativos completo, relaciona-o com a estratégia de negócio e é fundamentada sobre uma sólida prática de arquitetura corporativa. Isso pode parecer simples, mas ainda é uma disciplina difícil: desligar os aplicativos machuca, e racionalizar a tomada de decisões pode não ser do interesse de todos... Mas, através do foco nos resultados de negócio, decisões melhores podem ser tomadas e maior valor de negócio pode ser obtido, algo que todas as organizações estão lutando para conseguir.
* 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.
|
Transformação Digital: Como Gerenciar e Governar um Ambiente de TI de Várias Velocidades - Parte 2
Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign - Tradução e adaptação autorizados Na nossa postagem anterior, falamos sobre o impacto da TI de várias velocidades na organização de TI e da Arquitetura Corporativa. Vamos falar, agora, sobre as diferentes opções para gerenciar uma abordagem de TI de várias velocidades. O gerenciamento e a governança da arquitetura ágil de alta velocidade e da arquitetura de linha de base estável e robusta que nós discutimos anteriormente pode ser feita através de várias opções, como mostrado na Figura 1. Você poderia assumir que nós estamos falando apenas sobre uma simples abordagem de TI de duas velocidades, como mencionado em alguns lugares, mas isso não é tão simples como parece.
 Figura 1. Abordagem Bimodal
Por que a TI Bimodal não funciona?Muitas organizações tendem a estabelecer uma função de Escritório Digital que inclui a governança das novas iniciativas digitais suportadas por uma equipe dedicada. Isso soa um pouco parecido com a abordagem bimodal, como defendido pelo Gartner. Assim como qualquer outra abordagem, esta tem seus pontos positivos e pontos negativos. Equipes separadas trabalhando em problemas separados parece ser uma boa ideia, uma vez que cada equipe pode se concentrar nas suas tarefas específicas na caminhada em direção ao seu alvo.
No entanto, isso também resulta em uma desconexão entre as duas equipes. Ao estabelecer duas equipes diferentes para trabalhar em duas tarefas diferentes, a comunicação entre elas sofrerá, independentemente da qualidade da estratégia de comunicação. Mais ainda, a equipe da linha de base estável poderia se sentir com a reputação prejudicada (sendo percebida como 'lenta' e 'antiquada' em comparação com as iniciativas digitais), no acesso aos recursos e ao orçamento, e no poder e influência na organização. Esta circunstância leva a graves conflitos entre as duas equipes, e a qualidade do trabalho pode sofrer dramaticamente.
Mais ainda, a abordagem bimodal, infelizmente, não parece oferecer uma solução sustentável a longo prazo. Ela, inclusive, tem sido acusada de ser incapaz de oferecer uma solução potencial para o problema mais simples da estabilidade vs agilidade. E ainda mais, as organizações que efetivamente implementaram uma abordagem bimodal tiveram que encarar consequências desastrosas, tais como a formação de silos artificiais para produtos, processos e pessoas, e a institucionalização da estagnação em detrimento da inovação nas plataformas tradicionais, com a desculpa que "se não está quebrado, não conserte".
Junto com isso tudo, existe um desafio arquitetural e tecnológico muito maior: os sistemas estáveis de linha de base precisam ser conectados aos sistemas inovadores em rápida mutação do novo domínio dos negócios digitais, uma vez que eles em geral contém os dados de negócio mais importantes. Tais sistemas de registro são indispensáveis, mas são também difíceis de integrar. Colocar o peso desta transformação e integração nas costas da equipe de transformação digital pode diminuir o seu ritmo até um nível inaceitável, enquanto a equipe de linha de base já está ocupada o suficiente apenas para manter as luzes acesas e os sistemas legados funcionando, lidando com novas regras e regulações. Desta forma, parece que nós precisamos de alguma coisa entre estas equipes, para ultrapassar tanto as diferenças culturais como técnicas entre o mundo estável da linha de base e o mundo em constante movimento da transformação digital.
Seria uma Abordagem Trimodal a Solução?Uma abordagem trimodal, como mostrado na Figura 2, oferece um método mais sofisticado e flexível que um cenário simples de duas velocidades. Esta abordagem considera três equipes diferentes: Os Pioneiros, os Colonos e os Urbanistas. Os Pioneiros desenvolvem a organização digital alvo habilitando a inovação e a co-criação, usando métodos e técnicas ágeis. Na outra ponta do espectro, os Urbanistas representam a linha de base, fornecendo serviços estáveis e robustos para os Pioneiros e os Colonos. Simultaneamente, eles gerenciam provedores de serviços externos através de uma função de gerenciamento e integração de serviços, e adicionam valor para as outras equipes. Os Colonos estão posicionados no meio e lidam com transições ou, melhor dizendo, com arquiteturas de transição, ajudando a organização a industrializar e personalizar os serviços, sistemas e aplicativos para que se ajustem na arquitetura de linha de base, e para gradualmente transformar a arquitetura de linha de base para acomodar as novas necessidades de negócio digitais. Eles também garantem um melhor gerenciamento do fluxo de trabalho e da comunicação na medida em que se movem de um nível para o próximo.
 Em Direção à uma Estrutura CelularEvoluir a abordagem trimodal resulta em uma estrutura celular (Figura 3), onde cada equipe (ou ainda, cada membro de uma equipe) suporta a equipe acima dele, preenchendo seus objetivos e assim sendo envolvido nos negócios diários da sua equipe. Várias equipes são responsáveis pelas várias partes da TI, algumas focadas em funcionalidade de linha de base estável, algumas em capacidades digitais avançadas, e algumas em alguma coisa no meio. Aplicar práticas DevOps implica que cada equipe é totalmente responsável por construir e operar sua parte da TI. A comunicação entre as equipes acontece diariamente no 'chão-de-fábrica', e as decisões necessárias entre as equipes podem ser tomadas de forma rápida e eficiente. Mais ainda, partes interessadas relevantes do negócio e da TI podem ser integradas suavemente na equipe de trabalho, contribuindo com as suas visões e fornecendo orientação estratégica e tática quando necessário.
 Figura 3. Abordagem Celular
Arquitetos corporativos são um destes grupos de partes interessadas, focados em garantir que os esforços e os resultados das equipes estão alinhados com a estratégia digital da organização e com as suas metas de médio e de longo prazo. Seu escopo amplo e conhecimento da organização torna-os um fator central neste processo. Se você está nesta posição, tire vantagem deste conhecimento e facilite sua organização em suas jornadas de transformação digital que estão por vir.
* 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.
|
Transformação Digital: Como Gerenciar e Governar um Ambiente de TI de Várias Velocidades - Parte 1
Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign - Tradução e adaptação autorizados Analisando várias discussões que temos tido com muitas organizações a respeito de Estratégia Digital, a maioria delas tem o desafio de balancear suas ações no dia-a-dia. Primeiro, uma Organização Orientada para o Digital precisa aceitar que os papéis e responsabilidades do Negócio e da TI irão se fundir, enquanto precisam habilitar as inovações do negócio e da TI em direção às necessidades do negócio digital. Simultaneamente, eles precisam configurar uma abordagem ágil através de toda a organização para desenvolver e gerenciar modelos de negócio digitais inovadores, lidando com novos momentos de negócio, e realizando os serviços e a tecnologia associada. Finalmente, o controle dos custos da TI e dos seus serviços se mantém no alto das preocupações da organização.
Tais mudanças são especialmente difíceis em organizações com uma grande base de sistemas legados, tanto em termos da TI como em termos dos processos e da cultura organizacional. No setor bancário, por exemplo, nós vemos que bancos e seguradoras estão sob ataque das ágeis empresas FinTech, e lutam para responder de uma maneira adequada. Elas carregam o peso de panoramas de TI complicados, uma cultura de aversão ao risco, e uma sempre crescente demanda por conformidade regulatória. Em termos arquiteturais, eles têm uma arquitetura de linha de base obsoleta em funcionamento, e precisam desenvolver uma nova arquitetura alvo para permitir modelos de negócio digitais e inovadores, que são melhor realizados através de uma abordagem ágil.
Mas, ao mesmo tempo, eles não podem simplesmente substituir os velhos sistemas que rodam os seus processos de negócio centrais, ou mudar radicalmente a forma como estes sistemas e seus processos de negócio associados são mantidos. Os riscos operacionais, as demandas regulatórias e a cultura da organização de desenvolvimento impedem uma abordagem tão radical. É aqui que a chamada abordagem de TI bimodal entra no jogo; as equipes de TI e de Arquitetura Corporativa precisam gerenciar a complexidade nos dois mundos: o ambiente estável e avesso ao risco dos sistemas legados, e os negócios digitais ágeis e inovadores.
Da Linha de Base Tradicional para o Alvo DigitalA arquitetura de linha de base forte e estável é refletida no lado direito da figura abaixo. Isto é gerenciado totalmente através do gerenciamento apropriado de portfólios, arquitetura e liberações, com base em métodos, padrões e frameworks estabelecidos e definidos. Esta arquitetura normalmente é bastante estável e suportada por robustos serviços internos e externos, os quais raramente mudam ao longo do ano. O foco está na redução dos custos e do risco, mantendo a atenção no negócio, e não no desenvolvimento de soluções de negócio e de TI inovadores.
No contexto da Arquitetura Corporativa, a arquitetura alvo representa o estado futuro imaginado da organização, que parcialmente substitui e transforma a arquitetura de linha de base. Atualmente, o desenvolvimento de uma arquitetura alvo é principalmente um projeto de transformação de médio prazo, levando de 1 a 2 anos para implementar um panorama de arquitetura e de soluções complexo através de vários negócios e/ou domínios. Mas, será que isso é realmente sustentável no futuro próximo? A velocidade das mudanças e as pressões competitivas de novos entrantes inovadores requer uma resposta muito mais rápida. Na nossa visão esta abordagem mudará dramaticamente, ou já está mudando em muitas organizações.
Mesmo no futuro próximo, estaremos falando sobre desenvolver e integrar microsserviços no panorama de arquitetura existente, e seremos confrontados com o gerenciamento destes serviços e seus provedores de serviço relacionados, criando um papel completamente novo para os arquitetos.
Por exemplo, vamos assumir que uma seguradora planeje desenvolver uma plataforma colaborativa para permitir a co-criação do desenho e desenvolvimento de novos produtos de seguro. Simultaneamente, eles querem melhorar a experiência do cliente através de um gerenciamento omnicanal. A partir da perspectiva atual, isso parece ser um projeto de transformação de médio prazo, daqueles que nós vemos o tempo todo. Para ser honesto, eles estão na realidade demorando muito para começar a colher os frutos dos galhos mais baixos.
Adicionando Agilidade à MisturaMas o que acontece se você quebrar este projeto em um punhado de serviços menores, ou melhor, microsserviços, que possam ser desenvolvidos por vários fornecedores e outros parceiros usando uma abordagem ágil? Usando métodos e conceitos como produto mínimo viável (MVP-minimal viable product), desenvolvimento ágil e DevOps, cada um destes serviços menores pode ser rapidamente desenvolvido e implementado através de protótipos, e terminar como produtos funcionais em 2 a 4 semanas. Ao fazer isso, é crucial entender que esta abordagem implica em experimentação rápida e ágil que pode, eventualmente, falhar.
Consequentemente, uma cultura de aceitar as falhas, aprender com elas, e fazer certo da próxima vez, é essencial para o sucesso no longo prazo. Você também pode experimentar os chamados testes A/B, testando variações diferentes dos serviços com os clientes para identificar qual variante funciona melhor na prática. Ninguém possui todas as respostas certas desde o início, então você apenas tem que testar o que se encaixa melhor com os seus clientes. Naturalmente, esta abordagem implica em um processo de desenvolvimento rápido e ágil com liberação frequente de novas versões dos serviços, coordenado com conceitos como ART-Agile Release Trains (Trens de Lançamento Ágil), do Scaled Agile Framework (SAFe). Estes trens de lançamento ágil, combinados com o desenvolvimento e publicação frequentes da arquitetura de linha de base estável, são considerados em conjunto como parte da função de Gerenciamento de Portfólio Corporativo sobre a qual escrevemos anteriormente.  Figura 1: Portfólio Corporativo e de TI de 2 Velocidades
Então, a equipe de arquitetura corporativa tem que gerenciar e governar os dois mundos em direção a uma estratégia e visão de arquitetura digital comuns. Mas a questão crucial, aqui, é como gerenciar e governar este mundo digital? Com muita frequência você escuta a respeito de abordagens como TI bi-modal ou tri-modal. Mas elas realmente ajudam você a lidar com a complexidade da transformação digital? Vamos falar sobre isso na nossa próxima postagem.
* 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.
|
Modelos de Arquitetura de Referência com o ArchiMate
Originalmente postado por George Pang*, no blog da BiZZdesign - Tradução e adaptação autorizadas Em uma postagem anterior, realçamos o valor das arquiteturas de referência, incluindo o por quê e o como utilizá-las. Nesta postagem, vamos nos aprofundar um pouco mais, focando no 'produto' que nós (ou alguns de nós) vemos com alguma familiaridade - modelos de referência construídos usando a linguagem ArchiMate.
O que são Modelos de Referência?Primeiro, vamos dar um passo atrás e olhar novamente para as arquiteturas de referência, descritas como "arquiteturas padronizadas que fornecem uma estrutura de referência para um domínio, setor ou campo de interesse específico". O que um modelo de referência trás para a mesa é uma visão muito clara (usualmente em uma página) de um domínio de interesse - algo que é reusável e que, naturalmente, pode ser adaptado para atender às necessidades da organização.
Os exemplos de tipos de modelos de referência incluem:
Existe uma infinidade de modelos de referência da indústria disponíveis para uso por todos, mas a verdadeira força dos modelos de referência é pegá-los e transformá-los em modelos de referência específicos da organização - modelos que possam provocar a discussão, promover o reuso e fornecer rastreabilidade para outras áreas da arquitetura.
Como eu represento isso usando o ArchiMate?Modelos de referência geralmente nascem como um simples slide em uma apresentação PowerPoint, um diagrama no Visio, ou mesmo algumas células preenchidas em uma planilha Excel. Isso é ótimo para a comunicação, e transmite a mensagem rapidamente de forma pontual.
No entanto, quando estamos falando sobre Arquitetura Corporativa, muito raramente os modelos de referência são usados em isolamento - nós precisamos 'ligá-los' às outras áreas e disciplinas, de forma que é necessário usar um padrão para unir os elementos dos modelos de referência - por exemplo, a linguagem ArchiMate.
A questão que aparece continuamente é: "qual o conceito que nós deveríamos usar para representar os 'blocos de construção' neste modelo de referência em particular?"
Esta é um assunto que pode, muitas vezes, gerar dias, e até mesmo semanas, de discussão - e brigar sobre isso na realidade apenas invalida o objetivo de usar modelos de referência como, bem, referência - nós apenas precisamos concordar com a representação e, então, simplesmente usá-la de forma consistente! Para aconselhar ou responder a esta pergunta, nós realmente precisamos observar mais de perto o modelo de referência em questão. Vamos voltar aos três exemplos mencionados acima.
O Modelo de Referência de NegócioEssencialmente, para descrever o 'Negócio em uma página' nós quebramos as áreas principais (pais) em áreas menores (filhos), e então mais uma vez (netos), e assim por diante. Isto deveria descrever 'o que a organização faz', e isso geralmente fornece uma pista sobre o elemento a ser usado. Para aqueles que possuem um conhecimento razoável da linguagem ArchiMate, algum tipo de 'comportamento' está sendo descrito, e ele deveria ser naturalmente de negócio. Isso nos leva a alguma coisa como uma Função de Negócio!
 Figura 1. Arquitetura de Referência da Indústria Bancária da Microsoft
O Modelo de Referência de TecnologiaSimilar ao Modelo de Referência de Negócio, o TRM tipicamente descreve a 'Infraestrutura em uma página', mas, novamente, em uma perspectiva mais funcional - ele não deveria chegar ao nível de detalhamento fino, por exemplo, de "servidor x, y ou z", nem de processadores, memória, ou outras informações deste tipo.
Tendo estes pontos em mente, nós estaremos olhando para Serviços de Tecnologia e Funções de Tecnologia (ou seja, comportamento de tecnologia).
 Figura 2. Modelo de Referência do Ecossistema em Nuvem
O Modelo de Referência de InformaçãoAté aqui, nos dois exemplos acima, nós vimos que foram usados os conceitos de 'comportamento' do ArchiMate - o que é comum para vários modelos de referência. Os conceitos 'estruturais', em geral, acabam sendo mais próximos da implementação. O IRM é uma descrição das informações 'comuns' disponíveis dentro de uma organização (alguma coisa como o SID, do TM Forum, é uma boa inspiração). Colocando isso em perspectiva, o uso de conceitos de comportamento não se encaixa aqui - assim, nós logicamente olhamos para a coluna 'estrutura passiva' (que descreve os 'objetos' de algum tipo). Como os modeladores ArchiMate experientes estão conscientes, deve ser tomada a decisão sobre usar Objetos de Negócio ou Objetos de Dados para representar os elementos do IRM. Isso, mais uma vez, está sujeito à interpretação, mas, em geral, algo tão alto-nível como 'informação' é melhor representado por um Objeto de Negócio.
 Figura 3. O Modelo de Informação SID, do TM Forum ConclusãoEntão é isso! Estas são algumas sugestões para trabalhar com Modelos de Referência usando a linguagem ArchiMate. Você poderia, potencialmente, usar vários conceitos do ArchiMate para representar elementos nos modelos; no entanto, os pontos mais importantes são concordar com um padrão (e segui-lo), ser consistente no seu uso, e compartilhar os resultados! Uma última conclusão foca na apresentação para partes interessadas "não-técnicas" - lembre-se, embora o ArchiMate possa criar modelos de referência usando uma notação padronizada (para criar relacionamentos válidos que permitam a análise de impacto e outras), não existe nenhuma razão para não formatar a saída de uma outra forma (usando um ponto de vista de 'informação', por exemplo).
Uma ferramenta de arquitetura pode facilitar de forma significativa a documentação deste tipo de modelos e ajustar sua visualização para atender às necessidades (visuais) da sua audiência. Então, dê uma olhada nas funcionalidades da nossa ferramenta BiZZdesign Enterprise Studio e entre em contato para uma demonstração.
* George Pang é Consultor Líder da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria. |
O Valor das Arquiteturas de Referência
Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign - Tradução e adaptação autorizados Arquiteturas de referência são arquiteturas padronizadas que fornecem uma estrutura de referência para um domínio, setor ou área de interesse em particular. Modelos ou arquiteturas de referência fornecem um vocabulário comum, desenhos reusáveis e melhores práticas da indústria. Elas não são arquiteturas de solução, ou seja, elas não são diretamente implementáveis. Ao invés disso, elas são usadas como uma restrição para arquiteturas mais concretas. Tipicamente, uma arquitetura de referência inclui princípios, padrões, blocos de construção e padrões de arquitetura comuns. Muitos domínios têm definido sua próprias arquiteturas de referência. Exemplos bem conhecidos incluem:
A maioria destas arquiteturas de referência incluem capacidades/funções de negócio e processos de negócio comuns em um domínio. Além disso, elas podem incluir, por exemplo, modelos de dados, padrões de comunicação e formatos de troca comuns, e algumas vezes até blocos de construção de software comuns e ativos reusáveis.  O framework eTOM no ArchiMate Por que usar arquiteturas de referência?Então, qual é o valor de usar tais arquiteturas de referência, e por que e quando você deveria usá-las? Em primeiro lugar, arquiteturas de referência fornecem uma estrutura de referência que ajudam você a obter uma visão geral de um domínio particular, e elas fornecem um ponto de partida para o seu próprio esforço de arquitetura corporativa. Elas fornecem estruturas básicas que você pode usar, evitando que você tenha que reinventar a roda. Arquiteturas de referência são mais valiosas para aqueles aspectos e elementos da sua organização nos quais você não compete com outras empresas. Por exemplo, as funções de negócio de uma seguradora típica são, em grande medida, similares àquelas dos seus concorrentes, assim como boa parte dos seus processos. As diferenças competitivas, muito provavelmente, estarão nos produtos que elas oferecem, nos preços que praticam, nos segmentos de clientes que elas atendem, nos relacionamentos com os seus clientes. Reusar as melhores práticas da indústria fornecidas por arquiteturas de referência garante que você não está ficando para trás nestes aspectos não-competitivos. Nós vemos isso, inclusive, na implementação de vários sistemas de TI, onde fornecedores como a SAP fornecem processos de referência para uma grande parte da organização. Seu processo de contabilização, por exemplo, raramente será uma fonte de vantagem competitiva. Uma segunda razão para usar arquiteturas de referência é a interoperabilidade. Em um mundo cada vez mais conectado, as empresas precisam se conectar e cooperar de todas as formas com outras partes. Os padrões e blocos de construção melhoram a flexibilidade, porque é mais fácil trocar blocos de construção que se conectam através de interfaces padronizadas (veja o esforço do BIAN para a criação de um padrão de APIs para um sistema bancário aberto); por outro lado, é muito mais fácil desenvolver padrões se os blocos de construção em si são padronizados. Isso nos trás para a terceira razão para usar arquiteturas de referência: fusões & aquisições, e terceirização. Se as duas partes falam a mesma linguagem, usam os mesmos padrões, e reconhecem as mesmas fronteiras entre as funções, processos e/ou sistemas, será muito mais fácil recombinar seus elementos em novas configurações. A quarta razão para usar arquiteturas de referência é facilitar a comparação dentro da sua indústria (benchmarking). Em geral, as diferenças entre duas empresas não está no desenho, por exemplo, dos seus processos de negócio, mas na sua execução. Usar desenhos de referência torna muito mais fácil comparar aqueles resultados da execução. Benchmarking nos leva à quinta razão pela qual arquiteturas de referência são importantes: conformidade regulatória. Em geral, arquiteturas de referência são prescritas (ou, pelo menos, fortemente recomendadas) por órgãos reguladores. Princípios, práticas e processos contábeis, por exemplo, são cada vez mais padronizados e mandatórios. Isso leva a padrões de reporte do negócio, incluindo até mesmo o nível de padrões de troca de informações, como o XBRL. Como usar arquiteturas de referênciaAntes que você decida usar uma arquitetura de referência, algumas condições devem ser satisfeitas. Primeiro, uma arquitetura de referência deveria ser baseada em comunidade. Os usuários, não os fornecedores, deveriam decidir a respeito de melhores práticas, e a arquitetura deveria ser mantida ativamente pela comunidade de usuários. O mundo está mudando, e a sua arquitetura de referência deveria mudar também. Um processo ativo e aberto para a comunidade como esse é, idealmente, complementado pelo uso de padrões abertos para descrever as arquiteturas. A BiZZdesign pode fornecer muitos destes modelos de padrões de referência diretamente no produto. O uso de arquiteturas de referência em uma organização também requer governança; a organização deveria realmente se comprometer com o seu uso e isso deveria ser "obrigado" de alguma forma. Arquiteturas de referência só possuem valor se as pessoas estão realmente usando-as como pretendido e realmente seguindo a sua orientação, se não toda a ideia de reusar as melhores práticas da indústria vai por água a baixo. Finalmente, sua escolha de arquitetura de referência deveria fornecer orientação acionável e verdadeira. Princípios gerais de arquitetura não são suficientes. A estrutura concreta, por exemplo, em termos de funções ou processos de negócio, blocos de construção e padrões, deve fornecer para você um referencial útil para o seu próprio esforço de arquitetura. Usar arquiteturas de referência não implica que você perde a sua liberdade de desenho. Ao contrário, você foca esta liberdade naqueles aspectos da sua empresa onde você pode fazer uma diferença real. É aqui que você, como um arquiteto, pode adicionar o máximo de valor para a sua organizaçã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. |
A Casa do Gerenciamento de Portfólios da BiZZdesign
Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign - Tradução e adaptação autorizados Como nós descrevemos em uma postagem anterior, poucas organizações possuem uma forma sistemática e confiável para traduzir uma estratégia de negócio em ação. Isso requer alinhar as várias disciplinas em direção aos mesmos resultados de negócio esperados. Isto é o que está no coração da abordagem da BiZZdesign e da Centus para a mudança do negócio. Como foi uma vez declarado pelo Gartner (em uma palestra na ITExpo 2013): "Em 2017, toda empresa será uma empresa digital. As capacidades para mudar rapidamente e permanecer ágil serão imperativas." Embora possamos questionar o marco de tempo indicado nessa declaração, não podemos negar que gerenciar seu panorama de TI efetivamente e eficazmente é uma parte primordial da sua capacidade de mudança, na qual o gerenciamento do portfólio de aplicativos (APM-Application Portfólio Management) desempenha um papel muito importante. Com frequência, as organizações lidam com centenas de aplicativos, e cada um destes aplicativos pode, por sua vez, gerar uma infinidade de projetos e outras iniciativas de mudança. Como você pode, então, decidir onde você deseja racionalizar (Racionalização de Aplicativos) e onde você precisa investir seu orçamento de TI? É necessário uma visão geral estruturada, através do agrupamento destes investimentos em categorias: os portfólios. Deveria haver um investimento balanceado nos vários tipos de projetos (e.g. de longo prazo vs de curto prazo, de alto risco/alto ganho vs baixo risco/baixo ganho) e nas várias categorias de ativos (e.g. aplicativos estáveis de retaguarda vs aplicativos inovadores de atendimento). A tomada de decisões é facilitada pelo agrupamento destes investimentos em portfólios de acordo com estas características, como, por exemplo, portfólios de "inovação", "introdução de novo produto", "manutenção" ou "desativação". Por exemplo, isso ajuda a evitar a "restrição da inovação", onde um orçamento de manutenção sempre crescente acaba por consumir todos os investimentos. Desta forma, a alta direção pode decidir sobre a alocação de investimentos através de todos os portfólios, ao invés de focar em cada investimento individual. A autoridade para a tomada de decisões sobre as prioridades dentro de cada portfólio pode, então, ser delegada para os níveis abaixo na organização. Com o APM você pode tomar decisões de investimento mais bem informadas e coerentes, melhorar o alinhamento com as metas estratégicas, e monitorar o progresso das mudanças. A Arquitetura Corporativa fornece esta visão holística sobre todas as partes relevantes da empresa, e sobre o seu desenvolvimento através dos vários estágios do processo de transformação. A combinação do APM com a Arquitetura Corporativa oferece informação acionável: além de estabelecer o impacto de uma mudança proposta no panorama de negócio e de TI, uma organização pode agora quantificar o seu impacto e obter uma visão integral através de várias mudanças ao mesmo tempo.  A Casa do Gerenciamento de Portfólios da BiZZdesign
A figura acima resume a visão da Centus e da BiZZdesign sobre o gerenciamento do portfólio de aplicativos, visualizada no formato de uma casa. Os resultados do negócio são, naturalmente, a meta final; o "teto" que precisa ser sustentado. A estratégia fornece a direção para o APM; seus objetivos são derivados diretamente dela. Dados financeiros e de outras fontes são usados como entradas. O desenho dos portfólios consiste do seu conteúdo, das métricas para avaliar isto contra os objetivos, e dos painéis de controle para apresentar os resultados de uma forma amigável. Isso suporta várias as várias análises e decisões de negócio que são consequência disso tudo. Uma sólida fundação de arquitetura corporativa para os seus portfólios garante a coerência por toda a empresa e uma visão clara sobre as várias dependências envolvidas. Finalmente, a base é formada por uma forte capacidade para o gerenciamento de portfólios, com processos, pessoas capacitadas com as competências necessárias, e um bom suporte de ferramentas para garantir uma operação eficiente e efetiva. A "Casa do APM" resume estes vários elementos, necessários para realizar um Gerenciamento do Portfólio de Aplicativos de uma forma efetiva. Algumas lições importantes são:
Boa sorte com o Gerenciamento do Portfólio de Aplicativos na sua organizaçã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.
|
Arquitetura Corporativa para Tomadores de Decisão: Sete Conselhos
Originalmente postado por Remco Blom* no blog da BiZZdesign. Tradução, adaptação e reprodução autorizados. A maioria dos arquitetos corporativos acredita que a Arquitetura Corporativa é uma disciplina relevante para os membros da Diretoria. No entanto, os CxO's geralmente não compartilham desta mesma opinião. Nós acreditamos que isso acontece porque eles normalmente não experimentam o verdadeiro valor da arquitetura. O que os arquitetos podem fazer para melhorar isto? Abaixo, nós apresentamos sete conselhos úteis. 1. Construa ativamente a conscientizaçãoForneça algum contexto para a sua audiência: conecte as questões arquiteturais com o mundo real. Pessoas, aplicativos, problemas aqui e agora, são mais fáceis de ser compreendidos e mais vívidos do que caixas e linhas abstratas. Os tomadores de decisão dificilmente tomam decisões por si só. Considere-os como uma Unidade de Tomada de Decisão (UTD), e influencie outras UTD's em torno do principal decisor usando mensagens da arquitetura corporativa. Torne isso pessoal. Encontre os executivos em entrevistas, encontros do departamento e em ambientes informais para conhecê-los e investir no relacionamento. 2. Arquitetura Corporativa tem a ver com investimentosNão foque demais na construção da solução, mas, ao invés disso, posicione a Arquitetura Corporativa próximo do portfólio de investimentos. Seja ativo e ajude no início dos projetos, considere problemas (amplos) de integração e construa a confiança. Você pode trazer o aspecto da qualidade e da agenda de longo prazo para as discussões do portfólio. 3. Apresente problemas concretos e resultados concretosIlustre os problemas e as opções com casos de uso reais. "Este é o paciente João, que foi internado devido a um ataque do coração. Nós não conhecemos João, nós não sabemos qual é o seu uso de medicamentos, nós não temos seu eletrocardiograma mais recente. Naturalmente, faremos o que for possível, mas isso é o ideal?". Associe histórias como essa com os problemas que a empresa enfrenta e como a falta de informação (que poderia ser fornecida pela arquitetura) pode prejudicar a sua evolução. 4. Foque nos efeitos da arquitetura, não nos métodos ou na arquitetura em siPadrões importantes de Arquitetura Corporativa, como TOGAF, ArchiMate, e mesmo BPMN, são realmente importantes para amadurecer a sua prática de arquitetura corporativa. Mas eles não são nem um pouco interessantes para os tomadores de decisão... Apresente cenários, forneça aconselhamento, e deixe os tomadores de decisão fazer o que eles fazer de melhor: tomar decisões. 5. Mostre o dinheiro, o risco e o tempoA construção da solução atrai muito pouco o interesse dos executivos. A maioria gosta de falar sobre dinheiro (tanto o custo como as receitas potenciais), riscos e velocidade. Você pode mostrar isso como uma camada acima dos seus modelos? 6. Use diagramas simplesUm diagrama complexo, também conhecido como teia de aranha, é muito útil para mostrar como o seu panorama é complexo. Mas não espere que o seu gerente vá se interessar muito por ele. Rascunhos simples, atrativos, começando com uma perspectiva de negócio, têm se provado funcionar muito bem na Diretoria. Nós temos muitos bons exemplos de Modelos de Negócio como pontos iniciais de uma (efetiva) discussão sobre arquitetura corporativa. 7. Faça isso passo-a-passoComece sendo orientado para a solução (dos projetos), então evolua para ser orientado para os problemas/resultados (em programas como "racionalização de aplicativos", por exemplo), e mova para ser orientado para a estratégia. Mereça a sua posição, não reclame por ela! Esperamos que estas dicas possam ajudá-lo a ter mais sucesso para criar a compreensão e o comprometimento da sua organização com a Arquitetura Corporativa. Se sentir necessidade, entre em contato conosco para compartilhar suas dores e conversar sobre como enfrentá-las com sucesso. *Remco Blom é consultor sênior e especialista em melhoria de processos e segurança da informação na BiZZdesign |
Modelagem ArchiMate na Prática: Usando um Repositório de Modelos
Originalmente postado por Sven van Dijk*, no blog da BiZZdesign - Tradução e adaptação autorizadas Em teoria, um modelo ArchiMate pode ser criado usando apenas papel e caneta, ou um quadro branco e marcadores. Também existem plataformas de software que fornecem um ambiente de modelagem ArchiMate, e que fornecem várias capacidades automatizadas e funções de análise. No entanto, nesta postagem focaremos em um elemento importante para o amadurecimento da sua capacidade de modelagem avançada e de missão crítica: o repositório de modelos. O repositório de modelosO ArchiMate é usado para descrever e analisar múltiplas perspectivas da empresa, incluindo os estados atual (as-is) e futuro (to-be) da arquitetura, e para planejar os passos possíveis entre eles. Isso é muito útil, uma vez que o foco principal da Arquitetura Corporativa é suportar iniciativas de mudança. Embora existam vários métodos, técnicas e melhores práticas para serem seguidas, isso ainda não é uma tarefa simples de executar. Isso acontece porque ela geralmente envolve várias pessoas trabalhando em equipes diferentes para atingir o mesmo objetivo: construir um modelo integrado da arquitetura corporativa. Um repositório centralizado para suportar e organizar os esforços de modelagem é indispensável. O repositório em si pode tomar a forma de um banco de dados, mas não necessariamente. Muitas organizações usam sistemas de gerenciamento de documentos para implementar um (parte do) repositório para artefatos de arquitetura corporativa. Um aspecto central do conceito de repositório é o reuso de modelos e de informações. No repositório de modelos ArchiMate os objetos são armazenadas uma única vez, e podem ser reutilizados em outros diagramas nos quais o objeto seja relevante. O repositório atua como um local central de armazenamento de todos os objetos, relacionamentos e atributos de informação, onde o modelo é mantido atualizado.
Uma vez que o repositório reúne informações de diferentes áreas, perspectivas e estados da empresa, a análise integrada pode ser realizada. A inclusão de dados quantitativos e/ou qualitativos como atributos dos objetos resulta em análises de alto nível muito interessantes. Os exemplos incluem informações de segurança para objetos de infraestrutura, ou indicadores de desempenho (KPIs) para componentes de aplicativo ou processos de negócio. Usando as extensões do ArchiMate, as informações sobre os requisitos e o planejamento dos projetos podem também ser incluídas no repositório, relacionadas com a arquitetura, e fazer parte das suas análises. Desta forma, os modelos ArchiMate se tornam muito mais do que uma coleção coerente de objetos, relacionamentos e visões; ele se torna um "Corpo de Conhecimento Corporativo" integrado. Configurando um repositório de modelosA melhor abordagem para configurar um repositório de modelos é "pensar grande, começar pequeno". Configurar um repositório centralizado se torna uma necessidade assim que os níveis iniciais de maturidade na modelagem ArchiMate é alcançado, tipicamente em dois ou mais "domínios" (e.g. informação, aplicativos, negócio e/ou tecnologia). Isto não é apenas um exercício técnico; os fatores pessoas e processos também precisam ser considerados. Principais considerações quando configurando um repositório de modelosPessoasUma imagem clara deveria ser estabelecida em torno de quem modela o que, e os problemas em torno da propriedade do conteúdo dos modelos deveria ser endereçada. Isso deveria estar claramente definido e documentado, por exemplo, usando matrizes RACI. Se você estiver usando uma solução de repositório automatizada, a estrutura organizacional para a modelagem ArchiMate pode ser implementada como níveis de acesso baseados em papéis. Outra questão importante é fornecer orientação sobre o uso específico da linguagem ArchiMate na organização. Introduzir um Guia de Estilo de Modelagem evita o surgimento de "dialetos" e o uso de níveis incompatíveis de modelagem através dos vários domínios. A mesmo tempo, o Guia de Estilo promove o uso de padrões de modelos reusáveis específicos da organização como parte (dos domínios) das arquiteturas. ProcessoProcessos de governança, papéis e responsabilidades deveriam ser identificados e documentados. Isso pode ser feito usando formatos tradicionais, incluindo fluxogramas e organogramas. O processo de governança deveria indicar a sequência de atividades usada pela organização para configurar e manter o repositório de arquitetura. É necessário definir, também, processos de revisão para manter um alto nível de qualidade, tanto em termos de consistência como de acurácia do conteúdo dos modelos, bem como dos dados nos atributos. TecnologiaComo mencionado anteriormente, um repositório de modelos ArchiMate pode ser implementado por meio do uso de vários tipos de tecnologia. O BiZZdesign Enterprise Studio oferece um repositório de modelos central e integrado, que fornece funcionalidade sofisticada. O repositório é flexível e configurável, permitindo implementar v´rias estruturas organizacionais e de governança para a modelagem ArchiMate. Um bom repositório tem várias capacidades para gerenciar e publicar o conteúdo dos modelos, incluindo o gerenciamento de versões, funcionalidade de check-in/check-out, e autorizações baseadas em papéis. No repositório de modelos, diferentes estados (as-is, to-be), bem como versões (rascunho, em revisão, publicado, etc.) podem ser descritas. ConclusãoUm repositório de modelos ArchiMate é indispensável para o gerenciamento e a governança efetivos das atividades de modelagem das equipes de arquitetura. A adoção e implementação de um repositório de modelos ArchiMate deveria ser encarado como um projeto em si, dando atenção não somente à tecnologia, mas também às pessoas e aos processos envolvidos. Uma estratégia baseada em "pense grande, comece pequeno" tem se provado muito bem-sucedida, pelo menos na nossa experiência. * Sven van Dijk é consultor, da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria. |
Crie seus Registros GDPR e LGPD com o BiZZdesign Enterprise Studio
Baseado na postagem original por Joost Niehof* no blog da BiZZdesign. Adaptação, tradução e reprodução autorizados. As empresas precisam criar e manter registros do porquê, onde e como eles estão processando dados pessoais dos seus clientes, parceiros, funcionários ou, no fundo, de qualquer pessoa, de acordo com regulações como o General Data Protection Regulation-GDPR, da União Europeia, ou com a Lei Geral de Proteção de Dados Pessoais-LGPD, no Brasil. Criar e manter estes registradores no BiZZdesign Enterprise Studio ajuda a garantir que você está criando registros coerentes e consistentes que se conformam com o desenho da arquitetura da sua empresa. Nesta postagem, gostaríamos de mostrar como usar o BiZZdesign Enterprise Studio para suportar este caso de uso específico da proteção de dados pessoais: a criação e manutenção de registros de todos os dados pessoais mantidos e processados pela empresa.
GDPR e LGPDO General Data Protection Regulation (GDPR) é uma regulação bastante restritiva da União Europeia sobre a proteção da privacidade, que entrou em efetividade em maio de 2018. A LGPD é a regulação brasileira correspondente, em vigor desde agosto de 2018 e com efetividade marcada para agosto de 2020. Em uma postagem anterior, nós destacamos os seguintes pontos sobre o GDPR, e que são também válidos para a LGPD:
Alguns destes pontos terão impacto principalmente nos (desenhos dos) processos (itens 4, 5 e 6), enquanto outros mais impacto sobre o que e como você registra dados pessoais, e onde, como e porque você processa estes dados (itens 1,2 e 3).
Como muitas empresas estão lutando para implementar e se conformar com a LGPD e o GDPR, a Centus e a BiZZdesign desenvolveram uma solução prática para endereçar alguns dos problemas mencionados acima.
RegistrosUma forma prática para implementar alguns dos requisitos da LGPD e do GDPR é criar um registro de todos os processamentos de dados pessoais dentro da sua empresa. Tal registro poderia facilmente ser uma planilha, contendo todos os dados necessários. Tal registro poderia conter os seguintes itens, por exemplo:
Você poderia escolher manter este registro completo disponível apenas internamente e criar um registro com menos itens para divulgação pública, se necessário.
Como criar um registro como esse com o BiZZdesign Enterprise StudioPara criar e manter um registro como esse, nós aconselhamos fortemente não criar um registro separado, mas integrar as informações necessárias nos seus modelos de arquitetura corporativa no Enterprise Studio. Em geral, você precisa dar os seguintes passos:
 Criar uma extensão do modeloUse o metamodelador do Enterprise Studio para estender seu metamodelo atual com os atributos mencionados acima. Nós escolhemos adicionar um perfil (profile) especial com os atributos necessários ao conceito Componente de Aplicativo do ArchiMate. Depois, nós precisamos criar estereótipos para os Objetos de Dados e Atores de negócio para distinguir as categorias de dados, dados especiais e terceiros. Após aplicar o novo metamodelo ao repositório o perfil se parecerá com isso:
 Figura 2. Perfil GDPR para o conceito ArchiMate Processo de Aplicativo
Modelar e adicionar os dadosA coleta de todos os dados sobre o processamento de dados pessoais na sua empresa é a parte mais difícil. Talvez você possa alavancar avaliações que você já tenha feito. Na próxima figura você pode ver um exemplo de um cenário de processamento de dados modelado.
 Criar a exportaçãoUse a poderosa funcionalidade de exportação do Enterprise Studio para criar uma exportação dos dados para uma planilha Excel. Os princípios para criar uma importação (veja aqui) também podem ser usados para criar uma exportação. Você pode escolher desenvolver dois tipos de exportação, uma com o registro completo e outra apenas com as informações públicas.
 Publicar o registroAgora, você pode publicar o seu registro. Uma parte da planilha resultante pode ser vista abaixo. Se você implementou um processo de gestão de mudança adequado, você só tem que atualizar o modelo e publicar um registro atualizado de vez em quando (ou quando solicitado pelas autoridades).
 Figura 5. Registro exportado para uma planilha Excel (clique para ampliar)
Veja isso em açãoNós esperamos haver inspirado você a alavancar os seus modelos de arquitetura existentes (ou iniciar aquele tão adiado projeto de modelagem!) e adicionar ao seu repositório as informações necessárias para atender aos requisitos do GDPR e da LGPD sobre o processamento de dados pessoais. Se você ainda não viu o Enterprise Studio em ação, entre em contato e solicite uma demonstração.
*Joost Niehof é consultor de sucesso do cliente com foco em melhoria de processos, gestão de riscos e segurança da informação na BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.
|
1-10 of 106