Comunidade
  • Termo

  • Categoria

  • Período

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

Postado em 19 de fev. de 2019 por Antonio Plais

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.

blog SAFe 002

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

blog agile 004

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.

blog intentional architecture 002

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.

eBook
A Empresa Adaptativa

As organizações sempre tiveram que se adaptar a um mundo em mudança, mas o ambiente turbulento de hoje é mais demandante do que jamais foi. Sua organização precisa inovar mais rápido, em uma base contínua, enquanto mantém o controle sobre os riscos, orçamento e conformidade. Neste livreto, Marc Lankhorst e Peter Matthijssen explicam sua visão sobre […]

Solicite aqui sua cópia grátis
Voltar para a página inicial