O Método Swift é um conjunto de técnicas de análise de sistemas legados complexos a fim de determinar o trabalho necessário para modernizar gradualmente os principais componentes ou o sistema como um todo. Shaun Anderson, principal arquiteto de soluções da Pivotal Software, apresentou o Método Swift aos participantes do Explore DDD 2019, dando exemplos de como as cinco ferramentas e técnicas foram usadas para atualizar com êxito sistemas de softwares enormes (com até cinco milhões de linhas de código) usados em missões com alto nível de complexidade.
Anderson acredita que a pergunta "O que é modernização?" possui respostas muito diferentes, dependendo para quem vamos perguntar. Os líderes técnicos se concentram no "como", definindo um sistema moderno em termos de ferramentas e tecnologias, como Kafka e containers. Por outro lado, os stakeholders do negócio analisam o "porquê" da modernização ser importante, observando os resultados dos negócios, pontos problemáticos e os custos. O Método Swift considera esses dois pontos de vista, usando exercícios que incorporam ambas as análises, do tipo top-down, que é não técnica e bottom-up, que é técnica.
Ao trabalhar com clientes, Anderson comenta que não era importante ter uma definição global de modernização, afinal, a equipe precisa definir o que isso significa para si própria. Isso requer boa comunicação e entendimento compartilhado do sistema e dos desafios. Para o Método Swift, o Event Storming é usado para entender o caos e a complexidade do software legado e dos processos de negócios associados, encontrando grupos de eventos de negócios que provavelmente são candidatos a serviços.
Os candidatos a serviço ideais são o ponto de partida para o exercício Boris, que usa a teoria dos grafos para determinar a maneira como "o sistema quer se comportar". Semelhante ao Event Storming, o exercício Boris usa muitos post-its, um para cada domínio, nó ou serviço, colocados numa cartolina bem grande. Uma fita fina é usada para conectar os post-its para indicar os caminhos de comunicação entre os nós, criando assim um mapa visual do sistema. Inicialmente, o exercício Boris deve ser usado para encontrar a arquitetura ideal, seguindo o "caminho agradável" e pensando em pequenos partes do sistema, a partir de uma perspectiva do processo. As iterações posteriores podem ser usadas para percorrer casos especiais, pois 80% dos casos nos fornecem a clareza desejada sem muita confusão.
Os resultados do Boris Exercise são capturados usando uma técnica de documentação rápida chamada SNAP-E. Para cada serviço, a SNAP-E correspondente consiste em uma documentação em cinco categorias: APIs, Dados, Sistemas Externos/UI, Histórias e Riscos. O objetivo é capturar as informações e evitar mau funcionamento da análise.
Após a análise e a documentação serem concluídas, o quarto passo é o início da identificação dos padrões técnicos que podem ser usados. Pensando novamente em "como o sistema quer ser projetado" e trabalhando para a modernização, geralmente incluímos camadas anticorrupção para decomposição de monolitos, CQRS e padrões de armazenamento de dados, mensagens assíncronas e/ou microservices.
A etapa final no método Swift é criar uma lista de pendências do trabalho a ser realizado. O conhecimento capturado no SNAP-Es é combinado com os padrões técnicos desejados, para criar um conjunto de histórias e, em seguida, priorizá-las.
Para evitar a análise excessiva do problema, a equipe deve pausar o método Swift assim que conseguir criar uma lista de pendências priorizada. Quando o trabalho de modernização começa, a equipe pode voltar e analisar novamente o processo periodicamente para trabalhar nas fases subsequentes.
O método Swift também é útil para aplicações greenfield. Os familiarizados com o DDD reconhecerão os objetivos de identificar um domínio principal, dividir um sistema complexo em contextos limitados e usar uma linguagem onipresente para melhorar a comunicação e a colaboração.
Anderson disse que o método Swift surgiu parcialmente devido à "preguiça construtiva". Quando foi incorporado em uma organização para ajudar a modernizar um sistema de mainframe, a base de código era tão grande que tentar entender o sistema legado lendo-o, era impraticável. O Event Storming fez com que todos na sala também evitassem se concentrar no código e pensassem no cenário geral.
Após a conferência, o InfoQ conversou com Anderson.
InfoQ: Por quanto tempo está usando o método Swift?
Shaun Anderson: Tudo começou há três anos. Desde então, o usamos com sucesso em várias empresas da Fortune 500.
InfoQ: Todos os clientes estavam tentando modernizar os sistemas de mainframe?
Anderson: Não. Alguns eram mainframes com muito COBOL. Outros eram grandes sistemas J2EE ou WebSphere. Também o usamos para cenários greenfields. Todo o processo é independente da linguagem de programação.
InfoQ: Que orientação pode dar para alguém que tenta facilitar uma sessão Swift?
Anderson: Às vezes, o facilitador verá a solução mais rapidamente do que as outras pessoas na sala. É muito importante deixar a equipe chegar no resultado por conta própria. Isso cria um melhor senso de propriedade da solução e evita a mentalidade de "o consultor nos disse para fazer isso".
InfoQ: E se perceber que o grupo está indo por um caminho, e do nada houve algumas surpresas ou consequências intencionais?
Anderson: Já vi equipes trazerem executivos e posteriormente mostrei a eles os diagramas resultantes na parede. É uma maneira muito útil de explicar como sistemas complexos funcionam e onde existem grandes dependências e pontos problemáticos.
InfoQ: O objetivo é encontrar os pontos problemáticos?
Anderson: Esse não é um objetivo explícito, certamente não na medida em que pode ser com outras sessões de Event Storming. No entanto, os pontos problemáticos geralmente aparecem e, às vezes, onde as pessoas não esperam. Se perguntar para qualquer pessoa, a opinião dele sempre será tendenciosa. O Boris Exercise pode mostrar a eles que o problema que enfrentam se deve a uma dependência que não perceberam que existia.
InfoQ: De onde vieram as idéias e os nomes dos exercícios?
Anderson: A idéia do Boris Exercise veio após ver três novelos de lã sobre a mesa de um programador de COBOL que gostava de tricotar. O resultado final é algo que se parece com uma teia de aranha. Acabamos substituindo o fio por uma fita fina. O nome vem da música "Boris the Spider", do The Who.
O Snap-E é um método rápido para criar documentação "num estalar de dedos". Algumas pessoas pensaram que havia um acrônimo, então decidimos que o SNAP, significa Sem Paralisia de Análise, Aprimorada (Not Analysis Paralysis, Enhanced).