Modelos ArchiMate para Equipes Ágeis (Parte 1)
Postado em 27 de jul. de 2022 por Antonio Plais
Originalmente postado por Marc Lankhorst*, no blog da Bizzdesign – Adaptação e tradução autorizadas
Em uma postagem anterior nesta série sobre métodos ágeis e arquitetura, discutimos porque modelos de arquitetura são valiosos para organizações ágeis. Naquela postagem nos concentramos nas maneiras como você pode usar estes modelos para alimentar a agilidade no nível da empresa. Nesta postagem, gostaríamos de ir um pouco mais fundo e discutir como modelos de arquitetura e a linguagem ArchiMate podem suportar as equipes ágeis.
Equipes de Componentes, Equipes de Funcionalidades, e a Arquitetura
Lidar com sistemas grandes e complexos é difícil em qualquer metodologia, e é talvez o maior desafio para se adaptar a maneiras ágeis de trabalhar. Devido à sua própria natureza, estes grandes sistemas não são muito ágeis, por causa do grande número de dependências que eles possuem atrasa a mudança.
Alguns metodologistas ágeis diriam que você tem que “simplesmente” quebrar estes sistemas em partes menores que sejam gerenciáveis por uma única equipe. Microsserviços são um exemplo desta abordagem, mas qualquer um que já tenha visto isso em ação sabe que é comum que a complexidade que costumava estar oculta em um único grande sistema agora aparece nas conexões e nos padrões de comunicação entre estes microsserviços.
Como declara a Lei de Conway, as organizações desenham sistema que espelham suas estruturas de comunicação. Isso é bastante óbvio, pois se a sua arquitetura de sistemas atravessa essas estruturas de comunicação, o esforço extra de comunicação entre estas equipes geralmente as leva a redesenhar a estrutura do sistema de forma que cada equipe tenha a sua própria área de responsabilidade na arquitetura do sistema (e.g. microsserviço), ou a reestruturar as equipes para alinhar com a arquitetura dos componentes.
No entanto, de um ponto de vista de agilidade, estas equipes de componentes não são sempre ótimas. Se você tiver, digamos, uma arquitetura de três camadas com uma camada de apresentação Web, uma camada de lógica de negócio, e uma camada de acesso a dados, você pode ser tentado a ter três equipes correspondentes. No entanto, muitas funcionalidades irão requerer que as três equipes colaborem, uma vez que essas funcionalidades em geral precisam de alguma mudança na interface, alguma lógica de negócio, e algum armazenamento. Isso levará as equipes a ter que esperar umas as outras, e isso diminuirá a sua velocidade de mudança e a agilidade.
Assim, métodos ágeis tendem a favorecer equipes de funcionalidades multifuncionais e multicomponentes, formadas por especialistas nas partes da arquitetura que são potencialmente afetadas por uma funcionalidade, e também incluir, por exemplo, especialistas em experiência do usuário, teste e DevOps. Tais equipes de funcionalidades podem lidar com uma funcionalidade de ponta a ponta. Isso acontece as custas de alguma ineficiência. Mais ainda, se algum conhecimento especializado (digamos, segurança, tecnologia de banco de dados etc.) é escarça e necessária por várias equipes, você acaba tendo que lidar com sérias limitações de recursos.
Uma vez que ambas as abordagens possuem vantagens e desvantagens, a maioria das organizações tende a ter uma combinação de equipes de componentes e de funcionalidades com base nas especificidades das suas soluções. Decidir o que funciona melhor depende fortemente da sua arquitetura.
Modelando Funcionalidades e Componentes no ArchiMate
Com modelos ArchiMate você pode servir a ambas as abordagens. Na verdade, a subdivisão entre os aspectos de estrutura ativa e comportamento na linguagem ArchiMate é bastante similar àquela existente entre componentes e funcionalidades. No final, você precisa de ambos, mas você pode decidir começar por um ou por outro na organização do seu trabalho. Abaixo, você pode ver o framework completo do ArchiMate, com um exemplo da camada de aplicativos que ilustra estes aspectos.
Para uma nova solução a ser desenvolvida você normalmente começa a pensar a partir de uma perspectiva de funcionalidades. No ArchiMate, você começa com conceitos de motivação para capturar as metas, requisitos e resultados planejados para a empresa e para as partes interessadas.
Em seguida, você continua com os conceitos de comportamento do ArchiMate, como serviços, funções e processos. Como o padrão ArchiMate explica, um serviço de aplicativo é definido explicitamente como um comportamento de aplicativo exposto que é significativo a partir do ponto de vista do ambiente. Resumidamente, ele representa o que um aplicativo faz para os seus usuários. Esse é um conceito importante para a modelagem de funcionalidades de software no sentido ágil. Você não deveria confundir isso com o uso do termo “serviço” no sentido técnico, por exemplo, como um microsserviço sento realmente um tipo de componente de software. Ao invés disso, a notação de serviço do ArchiMate tem uma origem orientada para o negócio, onde um parceiro fornece um serviço para outro.
Funções e processos de aplicativo são usados em seguida, para modelar o comportamento interno que é necessário para fornecer estes serviços, ou seja, aquilo que acontece por trás das câmeras. Quais componentes de aplicativo (ou papéis e atores de negócio, no caso da parte não baseada em TI da solução) desempenham aquele comportamento, e através de quais interfaces você obtém estes serviço, são os passos finais nesse processo de desenho.
Quando criando modelos de soluções existentes, geralmente é mais fácil começar pelos componentes e suas interfaces, uma vez que estes são geralmente mais “visíveis” e concretos do que serviços e funções. Estes últimos são de alguma forma mais abstratos e podem exigir alguma análise profunda destes componentes. Dado que a maioria das soluções é um “campo marrom”, e vive em um panorama mais amplo de sistemas existentes, na prática você usa uma combinação de modelagem do comportamento para a estrutura e da estrutura para o comportamento.
Na próxima parte desta postagem, veremos com mais detalhes como a colaboração das equipes ágeis pode sere suportada pelos modelos ArchiMate. Fique ligado!
* Mark Lankhorst é Gerente de Consultoria & Evangelista-Chefe de Tecnologia da Bizzdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.
eBook
A Prática da Arquitetura Corporativa
Esta é uma versão eletrônica do livro A Prática da Arquitetura Corporativa, de Bas van Gils e Sven van Dijk, traduzido pela Centus Consultoria. Este livro não propõe um novo framework, teoria, ou abordagem para a Arquitetura Corporativa. Ao invés disto, os autores compartilham a experiência e as lições de vários projetos que conduziram ao […]