Criando Modelos de Arquitetura de Forma Ágil

Originalmente postado por Marc Lankhorst*, no blog da Bizzdesign – Adaptação e tradução autorizadas

Em postagens anteriores do blog, falamos sobre o uso de modelos de arquitetura no contexto do desenvolvimento ágil e o nível ‘certo’ de detalhe para esses modelos. Mas como você cria modelos em um contexto ágil?

Modelos ágeis a partir de um processo de modelagem ágil

Primeiramente, o próprio processo de modelagem deve ser feito usando os mesmos princípios ágeis que você usa para desenvolver software. Isso significa que a criação de modelos é um processo iterativo que começa pequeno e gradualmente estende os modelos com o conteúdo necessário para propósitos específicos. Esse processo deve avançar em sincronia com a evolução do que esses modelos descrevem.

Definindo o futuro

Alguns modelos são usados como entrada para o desenho de algum software (ou processo de negócios, produto, etc.) e, portanto, precisam estar ‘um passo à frente’. Como sabemos das formas ágeis de trabalhar, você quer adiar a tomada de decisões até o último momento possível, quando você tem as melhores informações disponíveis. Isso também é válido para modelos em um contexto ágil. Eles são desenvolvidos com uma mentalidade ‘just in time’, por exemplo, para fornecer contexto para os desenvolvedores nas próximas sprints, ou para ajudar os gerentes de portfólio a decidir sobre prioridades para os próximos épicos, etc. Isso também significa que quanto mais longe um modelo pretende olhar, menos concreto ele será. Em termos de ArchiMate, isso se traduz em:

• modelos que fornecem apenas a intenção de longo prazo e alto nível nos elementos de Motivação e Estratégia;
• modelos de médio prazo e nível médio com detalhes mais concretos, por exemplo, para expressar as principais características como serviços e definir conceitos como uma Pista de Arquitetura;
• modelos detalhados de curto prazo que são usados, por exemplo, para descrever componentes de aplicativos e seus serviços e interfaces para desenvolvedores que precisam se conectar a eles.

Todos esses modelos devem ser criados por e com aqueles que estão diretamente envolvidos, para que a intenção e as ideias sejam capturadas na fonte.

Entendendo o presente

Uma segunda categoria de modelos são aqueles criados para compreender a situação atual preexistente. A maioria do desenvolvimento é ‘brownfield’ e você precisa entender esse contexto. Modelos são úteis para lidar com a complexidade de tal situação atual. Por exemplo, padrões de comunicação complicados entre microsserviços são muito difíceis de entender apenas olhando para o código. Um modelo pode esclarecer isso.

Agora, ter que criar esses modelos da situação atual do zero pode ser um esforço descomunal. Idealmente, esses modelos teriam sido criados e mantidos por equipes anteriores, mas isso muitas vezes não é o caso. A segunda melhor opção é automatizar parte dessa criação de modelos. Existem cada vez mais ferramentas para descobrir, por exemplo, como os componentes de software se comunicam na sua rede e essas informações podem ser usadas para construir uma visão de baixo para cima do estado atual. A criação automatizada de, por exemplo, modelos ArchiMate da infraestrutura de TI com base em informações dessas ferramentas de descoberta, muitas vezes vinculadas a algum software CMDB moderno, é como as equipes de ponta trabalham hoje em dia. No nível dos negócios, ferramentas de mineração de processos podem ser usadas para descobrir os processos de negócios de uma organização. E podemos esperar cada vez mais técnicas de análise de dados e baseadas em IA que ajudam a obter esses tipos de percepções e construir seus modelos.

No entanto, o que você não pode reconstruir apenas olhando para o mundo lá fora é a intenção por trás do que você vê. Quais foram as principais decisões de desenho e escolha entre alternativas? Quais alternativas foram rejeitadas e por quê? Quem eram os principais partes interessadas e quais eram suas motivações? Esta é a principal razão pela qual você precisa documentar o que você projeta e não apenas tentar reverter a engenharia disso depois. Este é novamente um argumento para modelar a arquitetura intencional em modelos (ArchiMate).

Modelando o que foi criado

Isso nos leva ao terceiro tipo de modelos, aqueles que são destinados a documentar o que foi criado depois do fato para que outros entendam. Esses modelos são tipicamente ‘um passo atrás’ no processo de desenvolvimento e realização. Métodos ágeis recomendam documentar tarde (mas não muito tarde!) para que você capture o que realmente foi realizado e possa incorporar experiências de aprendizado relevantes, como feedback de clientes, revisões por pares ou retrospectivas. Além disso, a solução como realizada pode ser diferente da solução como projetada, e essas diferenças são importantes para entender e discutir.

O ciclo de vida dos modelos

Todos esses três tipos de modelos são úteis, mas devem ser criados e tratados de maneiras diferentes. Quanto mais tempo um modelo precisa viver, mais rigoroso deve ser seu desenvolvimento e manutenção. Como argumentado em postagens anteriores, não modele mais do que você pode razoavelmente manter. Informações desatualizadas são muitas vezes mais perigosas do que nenhuma informação.

E há um quarto tipo de modelos não discutido aqui, de modelos temporários criados durante o processo criativo de desenho. Esses modelos geralmente têm uma vida útil curta e servem principalmente para inspirar, gerar novas ideias, explicar e deixar seus colegas validarem suas ideias. Estamos muito interessado em saber como você usa modelos nesse processo criativo. Por favor, entre em contato se você tiver exemplos interessantes para compartilhar!

 

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