Progresso na Transformação Arquitetural
Este artigo faz parte de uma série que explora a transformação na arquitetura de sistemas de software em uma empresa fictícia do setor financeiro. A organização, que busca se tornar mais ágil, enfrenta desafios devido à sua arquitetura de software, que limita seu progresso. Neste capítulo, a empresa avança em sua jornada de transformação.
Resultados e Expectativas
Com a evolução da transformação arquitetural, Carlos, o responsável pelo projeto, começou a ser questionado pelos diretores sobre os resultados. Durante as reuniões, as perguntas sobre o andamento do projeto e a expectativa de melhorias se tornaram frequentes. Carlos explicou que, naquele momento, as equipes estavam focadas em atividades fundamentais, como estruturar ambientes e automatizar processos, preparando o terreno para a nova arquitetura. No entanto, a impaciência dos colegas era evidente, pois esperavam resultados mais imediatos.
Em uma dessas reuniões, o diretor comercial, Fábio, expressou sua preocupação com a possibilidade de a transição piorar o sistema. Sob pressão de clientes corporativos, que representavam uma parte significativa das vendas, ele enfrentava reclamações sobre lentidão e falhas. Fábio buscava garantias de que a migração não agravaria a situação, uma palavra que ele temia devido a experiências passadas com equipes de tecnologia.
Carlos, confiante no plano elaborado com sua equipe, sabia que a nova arquitetura traria melhorias em confiabilidade, escalabilidade e desempenho. Contudo, ele percebeu que, para os não técnicos, essa convicção não era suficiente. Era necessário apresentar dados que comprovassem a evolução do trabalho e a manutenção da qualidade do sistema.
Métricas como Ferramenta de Avaliação
Decidido a medir e reportar a realidade em números, Carlos assegurou que as métricas do sistema legado capturassem a experiência do usuário final, incluindo tempo de resposta, disponibilidade e estabilidade. Ele também determinou que essas métricas fossem replicadas na nova plataforma, permitindo comparações diretas entre os dois sistemas.
Para não sobrecarregar a equipe, Carlos optou por um conjunto reduzido de indicadores, focando no que realmente importava para os diretores, especialmente Fábio. As métricas precisavam ser relevantes e acionáveis, evitando medições supérfluas. Cada indicador deveria ter o potencial de orientar decisões concretas.
Por fim, Carlos reuniu a equipe responsável pela implementação e compartilhou a nova prioridade: desenvolver uma plataforma de medição que serviria como base para acompanhar a transformação. Essa abordagem visava demonstrar claramente que a nova arquitetura representaria um avanço mensurável para o negócio.
Definindo Indicadores Eficazes
Após conquistar apoio para a revolução arquitetural, o próximo desafio é provar que a mudança está funcionando. Sem métricas claras, os resultados ficam sujeitos a impressões e opiniões conflitantes. Portanto, é essencial definir indicadores que permitam comparar o sistema legado com a nova arquitetura, avaliando se a qualidade dos serviços e a performance das equipes estão realmente melhorando.
A migração para um novo estilo arquitetural pode causar impactos iniciais, como implantações mais complexas e dificuldades de monitoramento. No entanto, os benefícios tendem a superar esses desafios no médio prazo, desde que as expectativas sejam validadas com dados concretos.
Princípios para Métricas Confiáveis
Para garantir que a transformação ocorra sem causar disrupções nos serviços, as métricas devem seguir alguns princípios:
- Perspectiva do usuário final: escolha indicadores que reflitam a experiência real do usuário, como tempo de resposta e frequência de falhas.
- Preocupações dos stakeholders: alinhe as métricas às críticas já identificadas, como disponibilidade e tempo de resposta.
- Esforço razoável: prefira métricas que possam ser coletadas automaticamente, evitando sobrecarga nas equipes.
- Ação concreta: acompanhe apenas métricas que possam gerar ajustes reais no escopo da transformação.
Classes de Métricas a Considerar
Um conjunto equilibrado de métricas deve incluir as principais dores que motivaram a revolução, como:
- Confiabilidade: disponibilidade, latência e escalabilidade.
- Desempenho DevOps: frequência de deploy e tempo médio de recuperação.
- Fluxo de entrega: lead time e throughput de novas funcionalidades.
- Qualidade de código: complexidade e acoplamento.
- Atividade do repositório: número de commits e uso da nova arquitetura.
- Escalabilidade e custo: resposta sob carga e custo por transação.
Comparações Cuidadosas
Ao avaliar métricas voltadas aos serviços externos, é crucial compará-las do ponto de vista do usuário. Uma nova arquitetura mais distribuída pode resultar em mais incidentes, mas com menor impacto e recuperação mais rápida. Comparações ingênuas podem não refletir a qualidade real dos serviços.
É importante isolar fatores externos e reconhecer o efeito da curva de aprendizado, onde a produtividade pode cair antes de melhorar. Além disso, evite comparar equipes diferentes, pois a complexidade varia. O ideal é comparar o mesmo time antes e depois da migração.
Benefícios e Desafios das Métricas
O principal benefício de adotar métricas é a visibilidade. Indicadores claros permitem que as equipes experimentem e ajustem suas abordagens com base em dados, oferecendo aos stakeholders evidências objetivas de progresso. No entanto, desafios como a definição de métricas relevantes e a infraestrutura necessária para coletá-las devem ser superados.
Métricas bem escolhidas tornam a revolução arquitetural mais transparente e sustentável, alinhando expectativas e fundamentando decisões. Elas ajudam a manter a organização motivada durante um processo que, por sua natureza, é longo e repleto de incertezas.
Fonte por: Its Show