The Frugal Architect: Princípios e Práticas para Arquitetura de Software

The Frugal Architect: Princípios e Práticas para Arquitetura de Software

No ambiente dinâmico e complexo da tecnologia, especialmente no desenvolvimento de software, arquitetos e desenvolvedores navegam por um oceano azul repleto de oportunidades, mas também enfrentam muitos desafios. Esses profissionais estão em constante busca por soluções que atendam às necessidades técnicas — o que é fundamental — mas também procuram, ou pelo menos deveriam procurar, alinhar-se com as expectativas e realidades dos negócios. Com isso em mente, o papel do arquiteto de software é ir além da simples construção e design de software; trata-se de compreender as necessidades do negócio e oferecer soluções que solucionem problemas reais.

Nesse contexto, emerge o conceito do The Frugal Architect, uma jornada marcada por pensamento estratégico, análise cuidadosa e melhoria contínua no desenvolvimento de software. Esta abordagem vai além da mera construção de software; ela representa o estabelecimento de um caminho que harmoniza inovação, responsabilidade e, acima de tudo, sustentabilidade.

O que é o The Frugal Architect?

The Frugal Architect é um conceito que abrange um conjunto de princípios e práticas destinados a projetar, desenvolver e operar sistemas de software de maneira eficiente, sustentável e moderna. Este conceito enfatiza a consideração do custo como um requisito não funcional e busca alinhar este aspecto aos objetivos do negócio. O termo foi cunhado por Werner Vogels, CTO da Amazon, que definiu o conceito em três pilares fundamentais juntamente com as sete leis do The Frugal Architect.

Pilar I: Design

A abordagem enfatiza a importância de projetar sistemas que sejam não apenas funcionais e robustos, mas também conscientes em termos de recursos e custos. É o momento que os arquitetos e engenheiros de software precisam pensar de forma crítica sobre como cada escolha de design impacta o todo, desde a escalabilidade até a manutenção a longo prazo.

Faça do custo um requisito não funcional – Make cost a non-functional requirement

O custo deve ser encarado como uma característica intrínseca de um sistema, influenciada por múltiplos fatores como arquitetura, tecnologia, processo, qualidade e contexto. Ele deve ser especificado, medido, testado e otimizado durante todo o ciclo de vida do sistema, e não apenas tratado como uma preocupação secundária. É importante lembrar que o custo é como uma unha: quando cresce, precisa ser cortado.

• O custo é um elemento chave que influencia tanto a viabilidade quanto a competitividade de um sistema. Assim, deve ser tratado com a mesma importância que outros requisitos não funcionais, como disponibilidade, confiabilidade e segurança.
• A avaliação de custos deve ser feita em consonância com os objetivos e limitações do sistema, e não de forma isolada. Ele reflete diretamente nas decisões arquiteturais e tecnológicas, nos processos adotados, na qualidade alcançada e no contexto em que o sistema está inserido.

A primeira lei do The Frugal Architect

Um requisito não funcional especifica critérios que podem ser usados ​​para julgar a operação de um sistema, em vez de características ou funções específicas. Exemplos são acessibilidade, disponibilidade, escalabilidade, segurança, portabilidade, capacidade de manutenção e conformidade. O que muitas vezes passa despercebido é o custo.

As empresas podem falhar porque não consideram os custos em todas as fases do negócio – desde a concepção ao desenvolvimento e à operação – ou porque não os medem adequadamente. A matemática é simples: se os custos forem superiores à sua receita, o seu negócio está em risco.

Ao considerar as implicações de custos antecipadamente e continuamente, os sistemas podem ser projetados para equilibrar recursos, tempo de lançamento no mercado e eficiência. O desenvolvimento pode se concentrar na manutenção de um código enxuto e eficiente. E as operações podem ajustar o uso e os gastos de recursos para maximizar a lucratividade.

Sistemas que duram e alinham custo ao negócio – Systems that last align cost to business

Para sistemas de software serem bem-sucedidos e duradouros, é importante que estejam em harmonia com as estratégias de lucro das empresas. Isso significa entender e se alinhar com os elementos que impulsionam a geração de receita e a redução de custos. Uma das grandes vantagens desse alinhamento é a capacidade de aproveitar as economias de escala, onde o custo médio de produção cai à medida que a quantidade aumenta.

• Quando um sistema alinha seu custo às metas do negócio, ele não apenas se torna mais eficiente, mas também agrega valor tanto para os usuários quanto para a organização. Isso se reflete em uma redução de custos na produção e operação, e em uma oferta de benefícios mais significativos.
• Explorar as economias de escala também é parte integrante deste processo. Ao se alinhar com as metas do negócio, um sistema pode se beneficiar de reduções de custo associadas ao aumento da produção. Isso pode ser alcançado através de uma variedade de fatores, como melhoria na divisão de trabalho, especialização, padronização e inovação.
• Manter o crescimento sustentável do sistema é outro aspecto importante deste alinhamento. Isso significa equilibrar a receita e os custos, evitando um crescimento que não seja rentável. Um sistema adaptável às mudanças de tecnologias, regulamentos e ambientes é vital para manter a relevância e a eficiência ao longo do tempo.

A segunda lei do The Frugal Architect

A durabilidade de um sistema depende de quão bem seus custos estão alinhados ao modelo de negócios. Ao projetar e construir sistemas, devemos considerar as fontes de receita e as alavancas de lucro. É importante encontrar a dimensão pela qual você vai ganhar dinheiro e, em seguida, certificar-se de que a arquitetura acompanha o dinheiro.

Por exemplo, no comércio eletrônico, essa dimensão pode ser o número de encomendas. Quando os pedidos aumentam, os custos de infraestrutura e operação aumentam. E tudo bem, porque se o seu sistema for bem arquitetado, você poderá começar a explorar economias de escala. O importante é que os custos de infraestrutura tenham um impacto mensurável nos negócios.

Como construtores, precisamos de pensar nas receitas – e usar esse conhecimento para informar as nossas escolhas. Porque o crescimento a todo custo leva a um rastro de destruição.

Arquitetar é uma Série de Trade-offs – Architecting is a Series of Trade-offs

Cada decisão de design em arquitetura de software traz consigo trade-offs, ou seja, escolhas que acarretam em benefícios e compromissos. É importante revisitar regularmente esses trade-offs, tanto técnicos quanto de negócios, e direcionar recursos de maneira alinhada às necessidades do negócio.

• Trade-offs são uma parte natural e inevitável do processo de arquitetura de software. Eles surgem ao lidar com requisitos que muitas vezes são conflitantes, restrições limitadoras, incertezas e mudanças que ocorrem continuamente.
• É importante que esses trade-offs sejam claramente identificados e cuidadosamente avaliados. Isso envolve considerar os critérios e objetivos do sistema, assim como entender os impactos e consequências de cada escolha. As decisões devem ser fundamentadas em dados e evidências, ao invés de suposições ou preferências pessoais
• Revisar e ajustar os trade-offs é essencial, especialmente diante de mudanças nas demandas do mercado, avanços tecnológicos, novos regulamentos e alterações no ambiente operacional. Eles devem ser vistos como flexíveis e adaptáveis, ao invés de fixos e definitivos.

A terceita lei do The Frugal Architect

Na arquitetura, toda decisão traz uma compensação. Custo, resiliência e desempenho são requisitos não funcionais que muitas vezes estão em tensão entre si. Como diz o ditado: “Tudo falha o tempo todo”. Ser capaz de se defender contra o fracasso significa investir na resiliência, mas o desempenho pode pagar o preço.

É importante encontrar o equilíbrio certo entre as suas necessidades técnicas e comerciais – encontrar o ponto ideal que se alinhe com a sua tolerância ao risco e orçamento. Lembre-se de que frugalidade significa maximizar valor, não apenas minimizar gastos. E para fazer isso, você precisa determinar quanto está disposto a pagar.

Pilar II: Measure

Projetar software exige não só a medição, mas também uma avaliação contínua do desempenho. A abordagem do The Frugal Architect valoriza a análise rigorosa do desempenho do sistema, do consumo de recursos e do impacto econômico. Isso implica em coletar dados, interpretá-los e compreender em profundidade como as decisões arquiteturais afetam a realidade operacional.

Sistemas não observados levam a custos desconhecidos – Unobserved systems lead to unknown costs

Embora o monitoramento e a observabilidade de sistemas exijam um investimento inicial, eles permitem que as organizações identifiquem práticas ineficientes, otimizem fluxos de trabalho e aloquem recursos de forma estratégica.

• Monitorar sistemas fornece visibilidade e transparência sobre o uso e custo dos recursos, bem como informações sobre desempenho, saúde, segurança e eficiência dos sistemas.
• Através do monitoramento, é possível coletar, visualizar e ser alertado sobre métricas, logs e eventos, facilitando a análise e a identificação de problemas e oportunidades de melhoria.
• Decisões baseadas em dados coletados por meio do monitoramento tendem a ser mais confiáveis, precisas e objetivas do que aquelas baseadas apenas em intuição, opinião ou suposição.

A quarta lei do The Frugal Architect

Sem observação e medição cuidadosas, os verdadeiros custos de operação de um sistema permanecem invisíveis. Tal como um contador de serviços públicos escondido numa cave, a falta de visibilidade permite hábitos de desperdício. Tornar os medidores mais visíveis pode mudar profundamente os comportamentos.

Embora a observação exija investimento, não implementar uma monitorização adequada é uma atitude míope. O ditado alerta: “Se você não consegue medir, não consegue gerenciar”. Rastrear a utilização, gastos, erros e muito mais é crucial para o gerenciamento de custos.

Quando métricas críticas de custos são colocadas em primeiro plano diante dos engenheiros e seus parceiros de negócios, práticas mais sustentáveis ​​emergem organicamente. A inspeção contínua permite detectar gastos excessivos e ajustar as operações para reduzir despesas. O retorno do investimento em observabilidade normalmente supera em muito as despesas.

Mais importante ainda, manter os custos em primeiro plano incentiva práticas sustentáveis.

Arquiteturas conscientes de custo implementam controles de custo – Cost aware architectures implement cost controls

Com um sistema de monitoramento robusto, é possível agir proativamente nas áreas onde se identificam oportunidades de melhoria. Implementando controles de custo detalhados, otimiza-se tanto o aspecto financeiro quanto a experiência do usuário.

• Controles de custo são essenciais para gerenciar e limitar o consumo e gasto de recursos, prevenindo desperdícios, abusos e excessos desnecessários.
• Estes controles permitem um ajuste fino e um balanceamento dos recursos em resposta às demandas e prioridades atuais, assegurando qualidade, disponibilidade e escalabilidade dos sistemas.
• Além disso, os controles de custo abrem caminho para explorar e aproveitar as vantagens dos recursos disponíveis, incluindo descontos, créditos, incentivos e inovações tecnológicas.

A quinta lei do The Frugal Architect

A essência da arquitetura frugal é o monitoramento robusto combinado com a capacidade de otimizar custos. Sistemas bem projetados permitem que você tome medidas sobre oportunidades de melhoria. Para que isso funcione, decomponha os aplicativos em blocos de construção ajustáveis.

Uma abordagem comum é hierarquizar os componentes por criticidade. Os componentes do nível 1 são essenciais; otimizar independentemente do custo. Os componentes do Nível 2 são importantes, mas podem ser temporariamente reduzidos sem grande impacto. Os componentes do nível 3 são “agradáveis ​​de ter”; torná-los de baixo custo e facilmente controláveis.

A definição de níveis permite compensações entre custos e outros requisitos. O controle granular sobre os componentes otimiza o custo e a experiência. Infraestrutura, idiomas e bancos de dados devem ser ajustáveis. Arquitete e construa sistemas com receita e lucro em mente. A otimização de custos deve ser mensurável e vinculada ao impacto nos negócios.

Pilar III – Optimize

Otimizar é a arte de fazer ajustes e aprimoramentos de forma contínua. O objetivo é basear-se em insights obtidos durante a fase de medição para encontrar maneiras de aumentar a eficiência, diminuir custos e maximizar o valor entregue aos usuários e ao negócio.

A otimização de custo é incremental – Cost optimization is incremental

A busca pela eficiência de custo é um processo contínuo. Monitorar os sistemas para identificar padrões e eliminar ineficiências é essencial. Otimizar constantemente implica em revisitar os sistemas regularmente para descobrir novas áreas de melhoria.

• A otimização de custo é um processo iterativo que segue o ciclo PDCA (Plan, Do, Check, Act) ou o ciclo OODA (Observe, Orient, Decide, Act), envolvendo planejamento, execução, avaliação e aprendizado contínuos.
• Ela também é um processo adaptativo, que exige responder, antecipar e influenciar mudanças em demandas, tecnologias, regulamentos e ambientes, aplicando princípios de agilidade, resiliência e antifragilidade.
• Além disso, a otimização de custo é um processo criativo, que incentiva a experimentação, teste e validação de novas ideias, soluções e oportunidades, seguindo os princípios de inovação, experimentação e validação.

A sexta lei do The Frugal Architect

A busca pela eficiência de custos é uma jornada contínua. Mesmo após a implantação, devemos revisitar os sistemas para melhorar gradativamente a otimização. A chave é questionar continuamente e mergulhar mais fundo. As linguagens de programação fornecem ferramentas de criação de perfil para analisar o desempenho do código e, embora exijam configuração e conhecimento, permitem análises granulares que podem levar a alterações que economizam milissegundos. O que podem parecer pequenas otimizações se acumulam em grandes economias em escala.

Nas operações, a maior parte do tempo é gasta executando sistemas existentes. Existem oportunidades para traçar o perfil do uso de recursos e identificar a redução de resíduos. Na Amazon, monitoramos continuamente os serviços em produção para compreender padrões e eliminar ineficiências. A frugalidade exige persistência: ao reduzir gradativamente as latências e os custos de infraestrutura, podemos otimizar o custo do serviço.

Sempre há espaço para melhorias… se continuarmos procurando. As poupanças que colhemos hoje financiam a inovação para amanhã.

O sucesso não questionado leva a suposições – Unchallenged success leads to assumptions

É importante questionar constantemente aquilo que funcionou no passado. Métodos e ferramentas devem ser reavaliados, mesmo diante de sucessos anteriores. Como Grace Hopper famosamente disse, “uma das frases mais perigosas em inglês é: ‘nós sempre fizemos assim’”.

• Quando o sucesso não é questionado, pode-se cair na complacência, um estado de satisfação excessiva com os resultados atuais, ignorando a necessidade de melhoria contínua ou de adaptação a novas realidades.
• Além disso, o sucesso inquestionável pode levar à rigidez, uma resistência a mudanças e novidades, sem levar em conta os benefícios e oportunidades que elas podem oferecer.
• Por fim, o sucesso não desafiado pode resultar em obsolescência, ou seja, uma perda de relevância ou eficácia, por não acompanhar as tendências e inovações do mercado.

A sétima lei do The Frugal Architect

Quando as equipes de software alcançam um sucesso significativo sem enfrentar grandes falhas ou obstáculos, a complacência pode se instalar. Há uma tendência perigosa de se tornarem excessivamente confiantes nos métodos, ferramentas e práticas que levaram a essas vitórias.

As equipes de software muitas vezes caem na armadilha de presumir que suas tecnologias, arquiteturas ou linguagens atuais serão sempre a melhor escolha, simplesmente porque trabalharam no passado. Isto pode criar uma falsa sensação de segurança que desencoraja o questionamento do status quo ou a exploração de novas opções que poderiam ser mais eficientes, econômicas ou escaláveis.

Você vê isso com frequência quando se trata de linguagens de programação. “Somos uma loja Java” é uma frase que ouço com frequência – e que pode sufocar a inovação. O sucesso incontestado gera complacência por meio de suposições. Devemos sempre buscar formas de questionar, otimizar e melhorar.

Como Grace Hopper afirmou, uma das frases mais perigosas da língua inglesa é: “Sempre fizemos assim”.

Conclusão

Este artigo explorou o conceito de The Frugal Architect, uma abordagem que engloba princípios e práticas para projetar, desenvolver e operar sistemas de software de maneira eficiente, sustentável e alinhada aos objetivos de negócio. Esta abordagem destaca a importância de considerar o custo como um requisito não funcional e o influencia por diversos fatores, incluindo arquitetura, tecnologia, processo, qualidade e contexto.

Foi apresentado as sete leis do The Frugal Architect, cada uma ilustrada com exemplos práticos que mostram sua aplicabilidade na arquitetura e no desenvolvimento de software:

1. Faça do Custo um Requisito Não Funcional.
2. Sistemas que Duram Alinham Custo ao Negócio.
3. Arquitetar é uma Série de Trade-offs.
4. Sistemas Não Observados Levam a Custos Desconhecidos.
5. Arquiteturas Conscientes de Custo Implementam Controles de Custo.
6. A Otimização de Custo é Incremental.
7. O Sucesso Não Questionado Leva a Suposições.

Estas leis orientam arquitetos de software na otimização de sistemas em termos de custo, desempenho, segurança e escalabilidade. Também discutimos como desenvolvedores e arquitetos podem integrar esses princípios em seu trabalho diário, enfatizando as vantagens de adotá-los no desenvolvimento. Por fim, analisamos o impacto desses princípios na gestão de projetos de software e na tomada de decisões estratégicas, realçando os benefícios a longo prazo para as organizações, incluindo sustentabilidade, eficiência de custos e inovação.

Ilustrei cada uma dessas leis com exemplos práticos de sua aplicação na prática de arquitetura e desenvolvimento de software, mostrando como elas podem ajudar os arquitetos de software a otimizar seus sistemas em termos de custo, desempenho, segurança e escalabilidade. Nós também discutimos como os desenvolvedores e arquitetos de software podem aplicar esses princípios em seu trabalho, bem como as vantagens da adoção desses princípios no dia a dia do desenvolvimento. Por fim, nós analisamos o impacto desses princípios na gestão de projetos de software e na tomada de decisões estratégicas, destacando os benefícios a longo prazo para a organização, incluindo sustentabilidade, eficiência de custos e inovação.

FAQ: Perguntas Frequentes

1. O que é o The Frugal Architect?

O The Frugal Architect é um conceito que se refere a um conjunto de princípios e práticas para projetar, desenvolver e operar sistemas de software de forma eficiente, sustentável e moderna, considerando o custo como um requisito não funcional e alinhando-o ao negócio.

2. Quem criou o The Frugal Architect?

O termo The Frugal Architect foi cunhado pelo CTO da Amazon, Werner Vogels, em seu keynote na AWS re:Invent 2023, onde ele apresentou as sete leis do Frugal Architect, baseadas em sua experiência e na cultura da Amazon.

3. Quais são as vantagens de seguir o The Frugal Architect?

Aumentar a viabilidade e a competitividade dos sistemas, ao reduzir o seu custo de produção e operação, e ao aumentar o seu valor para os usuários e para o negócio. Aproveitar as economias de escala, ao alinhar o custo dos sistemas com as alavancas de lucro do modelo de negócio, e ao reduzir o custo médio de produção à medida que a quantidade produzida aumenta. Sustentar o crescimento dos sistemas, ao manter um equilíbrio entre a receita e o custo, e ao se adaptar às mudanças nas demandas, nas tecnologias, nos regulamentos e nos ambientes.