Arquitetura Corporativa


Transformação Digital: Como Gerenciar e Governar um Ambiente de TI de Várias Velocidades - Parte 2

postado em 12 de jul de 2019 14:12 por Antonio Plais   [ atualizado‎(s)‎ ]

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.


Figura 2. Abordagem tri-modal

Em Direção à uma Estrutura Celular

Evoluir 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.


 
http://bizzdesign.centus.com.br/biblioteca/ebooks/apm
eBook Gerenciamento do Portfólio de Aplicativos

As organizações são desafiadas por uma crescente necessidade de mudanças em um ambiente em constante pressão. A TI desempenha um papel crucial nesta mudança. Para realizar a necessária transformação digital, as organizações precisam desenvolver e executar uma estratégia de aplicativos que racionalize seu portfólio de sistemas legados e, ao mesmo tempo, prepare para requisitos de negócio e novas tecnologias que estão surgindo rapidamente.  

Solicite sua cópia GRÁTIS aqui

Transformação Digital: Como Gerenciar e Governar um Ambiente de TI de Várias Velocidades - Parte 1

postado em 6 de jul de 2019 14:20 por Antonio Plais   [ 12 de jul de 2019 14:20 atualizado‎(s)‎ ]

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 Digital

A 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 à Mistura

Mas 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.


 
http://bizzdesign.centus.com.br/biblioteca/ebooks/apm
eBook Gerenciamento do Portfólio de Aplicativos

As organizações são desafiadas por uma crescente necessidade de mudanças em um ambiente em constante pressão. A TI desempenha um papel crucial nesta mudança. Para realizar a necessária transformação digital, as organizações precisam desenvolver e executar uma estratégia de aplicativos que racionalize seu portfólio de sistemas legados e, ao mesmo tempo, prepare para requisitos de negócio e novas tecnologias que estão surgindo rapidamente.  

Solicite sua cópia GRÁTIS aqui

Modelos de Arquitetura de Referência com o ArchiMate

postado em 23 de jun de 2019 16:04 por Antonio Plais   [ 23 de jun de 2019 16:11 atualizado‎(s)‎ ]

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:
  • Modelo de Referência de Negócio (BRM-Business Reference Model)
  • Modelo de Referência de Tecnologia (TRM-Technology Reference Model)
  • Modelo de Referência de Informação (IRM-Information Reference Model)
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ócio

Essencialmente, 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 Tecnologia

Similar 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ção

Até 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ão

Entã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

postado em 18 de jun de 2019 06:26 por Antonio Plais   [ 18 de jun de 2019 06:26 atualizado‎(s)‎ ]

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:
  • O panorama de serviços BIAN para a indústria bancária
  • O framework Energistics, para a indústria de petróleo e gás
  • O framework ACORD para a indústria de seguros
  • O framework de processos de negócio eTOM, do TMForum, para a indústria de telecomunicações
  • Várias arquiteturas de referência para governos, como o FACIN brasileiro, o NORA holandês, o FEAF americano ou o AGA australiano
  • Frameworks de arquitetura de defesa, tais como o NOAF, DODAF e MoDAF
  • Arquiteturas de referência para a indústria e a cadeia de suprimentos, como o ISA-95 e o SCOR
  • Arquitetura de referência para serviços de saúde, como o HERA
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ência

Antes 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

postado em 1 de jun de 2019 04:12 por Antonio Plais   [ 1 de jun de 2019 04:28 atualizado‎(s)‎ ]

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:
  • O APM vai muito além da racionalização de aplicativos; ele tem a ver com a tomada inteligente de decisões de investimento
  • O APM não diz respeito apenas à TI; ele tem a ver com a estratégia do negócio, com as decisões do negócio, e com os resultados do negócio
  • O APM não é apenas mais uma ferramenta; ele requer uma capacidade robusta, incluindo processos, pessoas e competências
No ambiente de negócios complexo de hoje, a Arquitetura Corporativa é essencial para fornecer as percepções necessárias para tomar as decisões corretas.

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.


 
http://bizzdesign.centus.com.br/biblioteca/ebooks/apm
eBook Gerenciamento do Portfólio de Aplicativos

As organizações são desafiadas por uma crescente necessidade de mudanças em um ambiente em constante pressão. A TI desempenha um papel crucial nesta mudança. Para realizar a necessária transformação digital, as organizações precisam desenvolver e executar uma estratégia de aplicativos que racionalize seu portfólio de sistemas legados e, ao mesmo tempo, prepare para requisitos de negócio e novas tecnologias que estão surgindo rapidamente.  

Solicite sua cópia GRÁTIS aqui

Arquitetura Corporativa para Tomadores de Decisão: Sete Conselhos

postado em 21 de mai de 2019 04:35 por Antonio Plais   [ 21 de mai de 2019 04:40 atualizado‎(s)‎ ]

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ção

Forneç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 investimentos

Nã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 concretos

Ilustre 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 si

Padrõ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 tempo

A 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 simples

Um 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-passo

Comece 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

postado em 16 de mai de 2019 04:49 por Antonio Plais   [ 16 de mai de 2019 04:50 atualizado‎(s)‎ ]

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 modelos

O 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.

Isso torna a modelagem ArchiMate baseada em repositório fundamentalmente diferente daquela usando ferramentas de desenho: a habilidade de reusar objetos resulta em um enorme aumento na produtividade.

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 modelos

A 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 modelos

Pessoas

Uma 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.

Processo

Processos 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.

Tecnologia

Como 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ão

Um 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.
 

Para saber mais e ver o Enterprise Studio em ação, entre em contato e solicite uma demonstração.


* 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

postado em 13 de mar de 2019 17:17 por Antonio Plais   [ 14 de mar de 2019 03:31 atualizado‎(s)‎ ]

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 LGPD

O 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:
  1. O GDPR se aplica a todas as empresas que processam dados de residentes na União Européia. A LGPD se aplica principalmente aos residentes no Brasil, além de alguns casos especiais
  2. O GDPR, assim como a LGPD, tem a ver com a demonstração da conformidade
  3. O GDPR e a LGPD esperam que você registre o propósito da coleta dos dados pessoais
  4. O GDPR e a LGPD requerem uma abordagem integrada de segurança-por-desenho
  5. O GDPR requer uma Avaliação de Impacto sobre a Proteção de Dados para qualquer alteração significativa nas condições de processamento dos dados pessoais, ao passo que na LGPD este requisito, embora existente, não seja tão claro
  6. O GDPR força a comunicação de vazamentos de informações dentro de 72 horas, enquanto a LGPD não estabelece explicitamente um prazo para comunicação
  7. A não conformidade com a regulação pode acarretar pesadas multas, de até 4% do faturamento, no caso do GDPR, e até 2% de faturamento limitado a R$50 milhões, no caso da 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.

Registros

Uma 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:
  1. Nome da atividades de processamento
  2. Porque você está processando estes dados
  3. As bases legais para este processamento
  4. Alguma explicação adicional
  5. Quem está envolvido (internamente)
  6. Quem é responsável internamente
  7. Qual dado é processado
  8. Categorias especiais de dados
  9. De onde este dado foi obtido
  10. Categorias de terceiros recebedores dos dados
  11. Outros terceiros recebedores dos dados
  12. Período de retenção
  13. Contrato de processamento
  14. Tipo de processamento
  15. Aplicativos envolvidos
  16. Avaliação de impacto de privacidade necessária
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 Studio

Para 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:

Figura 1. Passos para criar um registro no Enterprise Studio

Criar uma extensão do modelo

Use 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 dados

A 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.

Figura 3. Modelagem de um processamento de dados, incluindo os aplicativos, dados e atores envolvidos

Criar a exportação

Use 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.

Figura 4. Configuração da exportação do registro

Publicar o registro

Agora, 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ção

Nó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.


 
Webinar Don't let the GDPR be a loose cannon - Are you ready?

Joost Niedorf, Consultor de Sucesso do Cliente da BiZZdesign, e especialista em gerenciamento de riscos, segurança e conformidade, apresenta neste webinar os principais requisitos e dificuldades para o atendimento de regulações como o GDPR (e que também são válidos para a LGPD).

Veja como um repositório de arquitetura corporativa, flexível e baseado na linguagem ArchiMate, pode ajudá-lo a superar este desafio.

Nós somos diferentes! Mas, nós somos realmente diferentes?

postado em 11 de mar de 2019 04:17 por Antonio Plais   [ 11 de mar de 2019 04:52 atualizado‎(s)‎ ]

Baseado na postagem original por Remco Blom* no blog da BiZZdesign. Adaptação, tradução e reprodução autorizados.

"Muitas partes interessadas consideram suas organizações como únicas". Dependendo do nível de abstração que você toma como ponto de vista, você pode argumentar que esta afirmação tanto pode estar certa como pode estar errada. É interessante compreender, a partir de um ponto de vista da arquitetura corporativa, por que as partes interessadas reforçam esta unicidade e quais os benefícios de entender onde a sua organização realmente é diferente das outras. Esta postagem usa organizações de saúde como exemplo, mas as ideias apresentadas são válidas para qualquer organização, em qualquer indústria.

Genérico x Específico

Um arquiteto em uma organização tem dois desafios importantes (entre outros):
  1. Aplicar arquiteturas (e soluções) genéricas para problemas específicos
  2. Desenhar soluções e arquiteturas específicas de uma forma genérica, de forma que estas possam ser úteis em situações futuras. Isso é muito mais difícil, tanto conceitualmente como na prática. Estariam os executivos do projeto dispostos a investir recursos adicionais para tornar as soluções reusáveis?
Isso é explicado também no Contínuo Corporativo (Enterprise Continuum), que é parte do padrão TOGAF.


Quanto mais genéricos são os elementos da arquitetura, mais reusáveis eles serão no futuro. Mas, também, na maioria dos casos será muito mais fácil adquiri-los, mantê-los e integrá-los.

Então, por que nós não trabalhamos com aplicativos padrão, desenhado colaborativamente, selecionados e hospedados para atender a vários hospitais em conjunto?

Entendendo por que e onde você é único

É claro que um banco é diferente de um hospital. Alguém pode dizer que quando os produtos e serviços são diferentes, os processos, fluxos de informação e panorama de aplicativos são diferentes. Eventualmente, lá em baixo na pilha, tecnologia genérica, como bancos de dados e conectividade, poderia muito bem ser bastante similar.

Mesmo quando as organizações têm os mesmos produtos, os processos usados para criar estes produtos podem ser diferentes. Mesmo quando os processos são padronizados, os fluxos de informação diferem. E mesmo se um conjunto de organizações consegue harmonizar isto, o panorama de aplicativos difere. Isso não parece ser lógico, ou, pelo menos, não é barato... especialmente em ambientes não-competitivos como o Governo. Nós temos visto que arquiteturas de referência estão se tornando bastante populares, principalmente em países como Austrália, Holanda, EUA, Singapura, entre outros. No Brasil, o FACIN é a primeira tentativa de criação de um framework de arquitetura corporativa comum para as entidades da Administração Pública Direta (APD). Na industria da saúde, o The Open Group tem trabalhado no desenvolvimento de uma arquitetura de referência chamada HERA-Healthcare Enterprise Reference Architecture (veja uma discussão sobre o tema aqui)

Mas mesmo assim, a cultura, a ambição por independência, o histórico, a estrutura da organização e, principalmente, a estratégia, provocam diferenças entre as organizações, mesmo quando atuando em áreas similares. A combinação e interação únicas entre as capacidades da organização torna cada organização única, mas isso não ajuda nosso trabalho arquitetural.

Existem dois passos para tornar mais claro onde você deveria querer se diferenciar:
  1. Criar um modelo de capacidades no qual você apresenta em alto nível o que a sua organização faz.
  2. Decidir, para cada capacidade, se a sua organização quer 'inovar', 'diferenciar', ou considerar esta capacidade de uso comum.

Nós descrevemos esta abordagem em uma postagem anterior que tratava da "Arquitetura de Negócio no Novo Normal". Esta abordagem ajuda a fornecer percepções sobre as capacidades primárias e secundárias, e alimenta a discussão sobre a implementação da estratégia e seu eventual custeio.

Tire vantagem das similaridades

A maioria dos elementos arquiteturais abaixo do nível dos aplicativos serão relativamente genéricos. Alguns aspectos da arquitetura de aplicativos e de negócios podem ser inspirados por outras indústrias. Finanças, Recursos Humanos, Suprimentos, etc. são exemplos típicos, mas também o CRM, o planejamento e o armazenamento de imagens podem ser (parcialmente) inspirados em como outras organizações fazem isso.

Processos específicos da indústria - e seus respectivos modelos de dados - podem ser fornecidos por provedores de serviços. Dentro da indústria da saúde, fornecedores de equipamentos de ressonância magnética e de prontuários eletrônicos entregam arquiteturas de processo padronizadas, que podem ser um ponto de partida para a sua arquitetura futura.

O que torna um hospital diferente de outras organizações

Hospitais possuem um conjunto único de processos, quando comparados com negócios que têm um impacto menos direto sobre a vida e a morte. Alguns exemplos:
  • Pessoas são tanto "sujeitos" como "objetos" dos processos. Alguns dos comportamentos de negócio são desempenhados pelos pacientes/clientes e, ao mesmo tempo, os pacientes são afetados pelo comportamento de negócio. Isso é fundamentalmente diferente de um banco ou indústria.
  • Fechar o ciclo de medicação é um processo que é único para instituições de cuidados de saúde, com o seu próprio conjunto de requisitos únicos.
  • A estrutura de governança é diferente para cada instituição de cuidados de saúde. Algumas são formadas por médicos cooperados, em outras os médicos são empregados. Algumas são ligadas a instituições de ensino ou fazem parte de um grupo maior, outras são independentes. Os conceitos de 'cuidado' e 'cura' têm abordagens diferentes e 'pulsam' através do negócio.

Toda Arquitetura Corporativa é Personalizada

Você pode usar arquiteturas de referência para acelerar o trabalho arquitetural, mas a história e a cultura da organização em que você está deve ser levada em conta. O processo de criar conscientização e conseguir o apoio da alta direção para a arquitetura corporativa deve ser levado em consideração em todos os casos, e a arquitetura resultante deve ser personalizada para as necessidades e metas estratégicas da organização, para que possa efetivamente entregar o valor desejado e esperado.


Para falar mais sobre o tema da arquitetura corporativa e do uso de modelos de referência para acelerar a sua adoção, entre em contato conosco e saiba mais sobre os nossos produtos, serviços e experiência.



*Remco Blom é consultor sênior e especialista em melhoria de processos e segurança da informação na BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.

Arquitetura Ágil: Usando o ArchiMate com o Scaled Agile Framework (SAFe)

postado em 19 de fev de 2019 05:21 por Antonio Plais   [ 24 de fev de 2019 18:21 atualizado‎(s)‎ ]

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

Temos escrito várias postagens sobre arquitetura corporativa em um mundo ágil, como o suporte de ferramenta para os Métodos Ágeis e DevOps, e, anteriormente, sobre o uso do ArchiMate em um contexto ágil. Nesta postagem, revisitaremos este último assunto e adicionaremos novas percepções e ideias.

Mais uma vez, usaremos o Scaled Agile Framework (SAFe) como pano de fundo. Ele é o framework mais popular (mas, de forma alguma, o único) para aplicar métodos ágeis em larga escala, e nós o encontramos em muitos de nossos clientes. Ele fornece para as empresas a estrutura para coordenar os esforços de várias equipes ágeis em torno de metas compartilhadas e soluções comuns e em larga escala. Abaixo, você pode ver uma versão simplificada da encarnação completa, em quatro camadas, do SAFe.


Isso é mais relevante para organizações muito grandes, que precisam coordenar o trabalho de centenas ou milhares de desenvolvedores; digamos, um grande banco, uma seguradora, ou uma agência governamental. Organizações menores podem não precisar da camada Grandes Soluções, e as menores ainda, com apenas algumas equipes ágeis, podem precisar apenas das duas camadas inferiores. Um dos aspectos distintivos desta organização em camadas é que quanto mais alto você vai, mais o foco se move para a intenção, ao invés da construção, da solução.

Abaixo, você pode ver um exemplo de como isso pode ser refletido no uso dos conceitos do ArchiMate através destas camadas, neste caso, para a versão do SAFe de três camadas (sem a camada de Grandes Soluções).

Modelando a Intenção: Temas, Épicos, Funcionalidades e Histórias como Elementos de Motivação do ArchiMate

À esquerda, temas estratégicos de alto nível são modelados como metas no ArchiMate. Isso expressa a intenção de negócio da empresa. Estes temas são detalhados em épicos (modelados como resultados), os quais, por sua vez, são realizados por funcionalidades (modelados como requisitos), que são elas mesmas agregações de histórias individuais (também modeladas como requisitos). Note que todos estes podem, também, ser "habilitadores" em termos do SAFe, isso é, eles não são necessariamente usados diretamente pelos usuários, mas podem fornecer suporte para funcionalidades de negócio futuras, garantir a conformidade regulatória, melhorar a infraestrutura, habilitar a mantenabilidade, etc.

Épicos, funcionalidades e histórias são priorizadas por meio de backlogs nos seus níveis respectivos. Estes, por sua vez, são organizados em iterações, que são modeladas com o conceito ArchiMate de platô. No nível mais baixo nós temos os incrementos de produto (ou sprints, em termos Scrum), entregues pelas equipes ágeis individuais. Vários incrementos juntos constituem um release, entregue pelos ART-Agile Release Trains (Trens de Lançamento Ágil) do SAFe, uma equipe-de-equipes coordenada. No nível do portfólio, estes releases formam o roteiro do produto.

Modelando o que nós construímos: Elementos Centrais do ArchiMate

Platôs são usados no ArchiMate para agregar os elementos da arquitetura que são válidos durante um período de tempo específico. À direita, vemos os elementos constituintes destes vários platôs, expressos por meio de elementos centrais do ArchiMate. No nível mais baixo, eles são bastante concretos.

Primeiro, usamos o conceito de função de aplicativo. Isto descreve o (parte do) comportamento de um componente de aplicativo: o que esta coisa faz (ou deveria fazer)? De forma similar, você pode modelar, aqui, processos e funções das camadas de negócio ou de tecnologia. Isso também é ligado às histórias à esquerda, uma vez que o comportamento deve realizar aquela história.

Estas funções e processos precisam ser executados por elementos concretos do aspecto do ArchiMate chamado de "estrutura ativa". Neste caso, nós usamos componentes de aplicativo, ou seja, blocos de construção de software sendo usados ou criados. Existem, naturalmente, vários outros conceitos que você poderia usar aqui, para modelar, digamos, a infraestrutura de tecnologia, recursos da organização e outros elementos concretos da solução.

Note que este nível é governado pelas equipes ágeis; eles, e não algum arquiteto nos níveis superiores, são os responsáveis pelo desenho detalhado do produto que está sendo desenvolvido, e eles poderiam (ou não) usar especificações mais detalhadas em UML ou BPMN, conforme suas necessidades. Ligar modelos ArchiMate com estes modelos detalhados é bastante fácil, mas está além do escopo desta postagem; veja esta série de postagens para saber como combinar a linguagem ArchiMate com outros padrões.

Abstraindo dos detalhes do desenho: em direção à arquitetura intencional

Um nível acima, nós usamos o conceito de serviço de aplicativo. Serviços abstraem das estruturas e comportamentos internos, e descrevem somente o que alguma coisa faz para o seu ambiente. O conceito de serviço do ArchiMate (através das três camadas, Negócio, Aplicativo e Tecnologia) é, desta forma, um grande correspondente com a noção de "funcionalidade" no SAFe. Cada serviço, naturalmente, precisa se encaixar no seu ambiente, o que pode ser expresso por meio de vários outros conceitos do ArchiMate, não mostrados aqui.

É neste nível onde os arquitetos de solução desempenham seu papel, empregando conceitos como o Architectural Runway (Pista Arquitetural) do SAFe. Isso é desenvolvido de uma maneira oportuna e iterativa, e fornece para as equipes ágeis a arquitetura intencional que fornece os limites para garantir que os resultados do trabalho das várias equipes ágeis se encaixem bem juntos, se conformem com requisitos não-funcionais, demandas regulatórias e outras restrições.

Os conceitos do ArchiMate são uma ótima forma para expressar a arquitetura intencional, uma vez que o ArchiMate não é desenvolvido para o desenho detalhado de soluções. Seus conceitos objetivam expressar os aspectos estruturais e comportamentais essenciais das soluções e as motivações por trás disso. Mais ainda, o ArchiMate se expande através do negócio e da TI, e assim fornece para as equipes ágeis contexto e clareza além das preocupações com o desenvolvimento de software somente. Por exemplo, em quais processos de negócio isso será usado? Como ele se relaciona com outros produtos no nosso portfólio? Como isso contribui para as metas principais do negócio? Em qualquer organização (mas especialmente em um contexto ágil), todos deveriam entender o propósito dos seus esforços.

Isso, então, nos leva para a parte superior, onde vemos o conceito de capacidade. Uma capacidade é algo que uma organização é (ou quer ser) capaz de fazer, e aqui ela expressa que as soluções desenvolvidas fornecem certas capacidades novas ou melhoradas para a empresa. Estas capacidades, por sua vez, realizam épicos que foram definidos anteriormente. Mais ainda, elas contribuem para o curso de ação que a empresa adota para executar seus temas estratégicos e atingir suas metas.

Exemplo

Para dar um exemplo concreto, vamos pegar nossa empresa bancária, fictícia mas realista, BiZZbank. Um dos seus temas estratégicos é aumentar significativamente suas receitas de serviços bancários digitais, através do aumento do foco no segmento da Geração do Milênio (Millennials, ou Geração Y). Para isso, o BiZZbank objetiva desenvolver a melhor experiência de usuário de serviços bancários digitais. Isso, por sua vez, requer várias capacidades e recursos, tais como o gerenciamento do relacionamento com os clientes, análises analíticas dos clientes e um excelente aplicativo para dispositivos móveis. Abaixo, um modelo ArchiMate simplificado mostra isso, usando os conceitos de partes interessadas e valor para fornecer um pouco mais de contexto para o curso de ação ao centro.


A partir desta figura contextual de alto nível, poderíamos descer aos detalhes, por exemplos, dos serviços específicos que este aplicativo móvel precisa fornecer, como ele se encaixa na jornada do cliente, quais as suas funcionalidades e qual a sua arquitetura de software, sua integração com os sistemas de retaguarda do banco, etc. Muito mais coisas sobre o BiZZbank podem ser vistas no nosso webinar de demonstração.

No entanto, a principal mensagem que queremos passar é que fornecer este tipo de contexto e intenção de alto nível é essencial para o desenvolvimento ágil. Nos ambientes tradicionais em cascata, você poderia ter analistas de negócio, analistas de informação e outros papéis com tarefas específicas para traduzir a intenção estratégica em requisitos concretos. No desenvolvimento ágil, no entanto, muito desta responsabilidade recai sobre os ombros das equipes ágeis e dos donos de produto. Sem um claro entendimento do contexto, como você espera que eles tomem as decisões de desenho corretas?

A noção de arquitetura intencional corresponde muito bem com a nossa visão de Empresa Adaptativa, onde a visibilidade das informações necessárias para delegar a tomada de decisões para toda a empresa é fundamental. Se você quer conhecer mais sobre a nossa visão, entre em contato conosco.



* 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.


http://bizzdesign.centus.com.br/biblioteca/ebooks/empresa_adaptativa
Nós publicamos o eBook 'A Empresa Adaptativa - Prosperando em uma Era de Mudanças', no qual explicamos nossa visão dos desafios da mudança e do controle em empresas complexas, e descrevemos as capacidades necessárias para lidar com isso em maiores detalhes. 
Clique aqui para solicitar sua cópia grátis deste eBook.

1-10 of 104