Arquitetura Corporativa
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.
|
Nós somos diferentes! Mas, nós somos realmente diferentes?
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íficoUm arquiteto em uma organização tem dois desafios importantes (entre outros):
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:
 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 similaridadesA 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çõesHospitais 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:
Toda Arquitetura Corporativa é PersonalizadaVocê 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)
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).
 À 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 ArchiMatePlatô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 intencionalUm 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.
ExemploPara 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.
 Clique aqui para solicitar sua cópia grátis deste eBook.
|
1-10 of 104