TL;DR Deveríamos determinar que técnicas e métodos de arquitetura de software utilizar conforme o risco associado a execução ou aos resultados de cada projeto. Quanto maior o risco, maior o rigor necessário. Essa é a ideia central de uma aborgagem que vem crescendo em popularidade chamada Risk-driven Architecture. Esse é o primeiro post de uma série que detalha essa abordagem.

Em nossas consultorias, frequentemente somos requisitados a apoiar empresas na implantação de um “processo único para arquitetura de software”. Ou seja, um conjunto de atividades, papéis e artefatos padrões que deveriam ser observados e que “funcionassem” para todos os projetos. Entretanto, nossa experiência aponta em outro sentido.

Conhecemos cases de sucesso e fracasso adotando diferentes processos de arquitetura. Há projetos “ágeis” com arquitetura emergente, há projetos com detalhamento exaustivo up-front. Logo, parece mais adequado tentar determinar quando cada abordagem faz mais sentido.

O que é Risk-driven Architecture?

Entendemos e apoiamos a ideia de que o “rigor” das atividades relacionadas a arquitetura de software deveriam ser determinadas considerando os riscos de cada projeto. Quanto maiores os riscos envolvidos, maior deveria ser o rigor a ser observado. Essa, é a essência de uma abordagem que ficou conhecida como Risk-driven Architecture.

Para tangilibilizar o conceito, façamos uma breve analogia. Pensemos no caso de um engenheiro  envolvido na construção de um prédio com dezenas de andares. É coerente e responsável que esse engenheiro empregue todas as técnicas conhecidas para assegurar que o prédio não caia e cumpra seus objetivos funcionais. Por outro lado, seria um total desperdício de tempo e, provavelmente, dinheiro se este mesmo engenheiro usasse a mesma abordagem para projetar uma “casinha de cachorro”.

Por que Risk-driven Architecture é importante?

Arquitetura de Software ainda é uma atividade recente. Entretanto, já temos muitas técnicas disponíveis para modelar e analisar sistemas. Muitas dessas técnicas consomem tempo precioso que poderia ser investido “escrevendo código”.

Usar os riscos envolvidos com o fracasso de um projeto para determinar que técnicas e quanto de esforço devem ser empregados em atividades de arquitetura ajuda a economizar recursos.

Projetos diferentes tem riscos diferentes. É fato que não há uma maneira única de “fazer” arquitetura de software. Não são incomuns projetos onde nenhuma atividade de arquitetura seja especificamente necessária por ser “mais do mesmo”.

De forma enfática, entendemos que é função da arquitetura  mitigar riscos.

O que vem por aí…

Em posts futuros, iremos compartilhar critérios para explicitar riscos envolvidos com projetos de software. Além disso, vamos mostrar como relacionar técnicas e metodologias de arquitetura para mitigação desses riscos.

Compartilhe conosco como você determina que técnicas e metodologias de arquitetura utilizar em seus projetos.