Definindo e documentando uma arquitetura de software distribuída

Como definir, avaliar requisitos, decompor e documentar uma arquitetura de software com base em um problema?

Antes de começar, vale explicar que definição de framework ou definição de tecnologia não significa definição de arquitetura. Muito que se vê no mercado profissionais escolhendo de forma arbitrária frameworks ou linguagens enquanto dizem estar "definindo a arquitetura". Bom, na prática a arquitetura, mesmo que de forma arbitrária, está sendo definida, mas não significa que está correto.

Então, o que um arquiteto precisa fazer para afirmar que fez a definição de uma arquitetura? Bom, algumas coisas. Entre elas:

  • Avaliação da viabilidade do projeto - Antes de iniciar um projeto é importante avaliar a viabilidade de forma macro.
  • Cálculo de custo de projeto vs custo da solução - Não tem porque criar um projeto que terá um custo de manutenibilidade e sustentabilidade superior ao que se espera como retorno.
  • Capacidade - Tem um time para desenvolver a solução? O arquiteto precisa ter a capacidade de avaliar de forma macro, antes mesmo de decompor os requisitos e conseguir avaliar se tem um time com skills para seguir com o projeto, se terá de preparar a equipe para alguma possível tecnologia que venha a fazer sentido com base no contexto do projeto, ou até mesmo, se terá de contratar mais desenvolvedores e engenheiros para atender a solução.
  • Levantamento de premissas e funcionalidades esperadas.
  • Outro ponto importante é elaborar a documentação do projeto para trazer visibilidade mais precisa das etapas do projeto: Problema que queremos resolver, tecnologias que solucionam o problema de forma adequada e que esteja também dentro da capacidade da empresa, requisitos não funcionais, validação de requisito e claro, um diagrama de implantação (no mínimo) para conseguirmos visualizar a solução por completo. E é esse ponto que vamos tratar nesse artigo.

Então, por onde começar?

Primeiro precisamos do problema que queremos resolver. Vou usar um case que me foi passado à algum tempo e não vou mencionar a origem do case (por razões óbvias).
Desafio
Formalização dos contratos de financiamento de imóveis baseando-se em documentos disponibilizados pelo cliente, em modelos de regras de créditos conforme perfil do cliente.

Funcionalidades

  • Entrada de documentos pelos canais digitais;
  • Status do processo de análise reportado ao cliente através de canais digitais por push ou meios de comunicação como SMS e e-mail;
  • Modelo de regra de crédito mais inteligente reportando pendencias e/ou inconsistência de documentos de forma rápida ao cliente;
  • Uso de documentos digitais disponibilizado por órgãos externos.

Premissas

  • O sistema de imóveis se encontra em ambiente mainframe.
  • O sistema de financiamento de imóveis expõe webservices SOAP que suportam atualmente 10 TPS.
  • Como há dados sensíveis sendo trafegados é importante as camadas de segurança e fraude fazerem parte da jornada de captura.
  • Temos uma previsão de consumo de mais 1000 TPS
  • Se integrar a um Backoffice externo em Salesforce

Agora vamos começar a trabalhar no nosso documento

Vou criar alguns nomes para simplificar a elaboração do documento:
Nome da empresa: XptoBan
Nome do projeto: Xpto Digital
Nome dos arquitetos: Rodrigo Celebrone e Outro Alguém

Etapas do documento

  • Proposta
  • Modelo de implantação
  • Detalhamento dos componentes
  • Mecanismos arquiteturais
  • Requisitos não funcionais
  • Detalhamento dos requisitos não funcionais (estímulo/resposta)

Proposta

A etapa de proposta deve contar o problema que você deseja resolver, sem entrar em detalhes da solução. 

*Nesse exemplo do artigo tem um modelo bem simples, mas podemos entrar ainda mais nos detalhes da implantação, incluindo bancos de dados dos micro serviços, bancos de cache compartilhado, divisões internas de rede, balanceador de carga ou estruturas de redundância por exemplo.

Modelo de implantação 

Aqui podemos trabalhar com uma tabela descrevendo os componentes e a interação entre eles, ou como fiz, usando um diagrama de implantação (sempre prefiro a opção diagrama pois da uma rápida visibilidade das integrações entre os componentes).

Detalhamento dos componentes

Essa etapa podemos detalhar os componentes que estão no modelo de implantação para explicar qual a utilidade daquele componente.

Mecanismos arquiteturais

Essa etapa é bem interessante pois podemos incluir referência para tecnologias que utilizaremos nos componentes, ou até mesmo uma referência direta para o componente (caso esse já esteja implementado -por exemplo o gateway).

Requisitos não funcionais

Aqui descrevemos todos os requisitos não funcionais que pudermos extrair em entrevistas com o cliente. Obviamente o cliente não saberá te dizer que (por exemplo) o mainframe deve suportar processamento que ultrapasse o limite pré-estabelecido. O cliente saberá (no máximo) que o Mainframe tem suporte a 10 TPS e a partir do lançamento do novo projeto a ideia é atingir um número muito maior (nesse caso nos foi passado que teremos 1000 TPS (aqui já expliquei como calcular TPS a partir de um cenário desconhecido), o que facilita na análise da solução).
Esses requisitos são levantados com objetivo de ajudar na definição e apoiar o os engenheiros e desenvolvedores na implementação, mas também são importantes para que possamos valida-los e garantir que estamos atendendo as necessidades do projeto. E para isso, usaremos uma técnica chamada de Estímulo/Resposta.

Detalhamento dos requisitos não funcionais (estímulo/resposta)

Aqui vamos utilizar os requisitos não funcionais que levantamos para conseguir medir e evidenciar que atingimos o objetivo do Requisito. Algo importante é que cada um desses detalhamentos deve possuir a capacidade de ser medido e para isso eu recomendo utilizar técnicas como o SMART (que já falei aqui). 
Primeiro descrevemos qual será o estímulo que gostaríamos de provocar e em seguida detalhamos dizendo qual a fonte do estímulo (o que vai provocar a situação que queremos validar). 
A terceira etapa do estímulo/resposta descreve como está o ambiente no momento do teste (coloquei no documento acima apenas uma configuração de ambiente por estímulo, mas em uma situação real, podemos criar estímulos para validar os requisitos em cargas normais, baixas e elevadas). É importante entender o porque validar o estímulo em baixo/normal e carga elevada, pois podemos, por exemplo, querer aumentar a quantidade de instâncias de nossa aplicação em ambiente de carga elevada, mas também podemos querer validar em baixa utilização para reduzir custos.
Descrevemos também o Artefato envolvido na validação do estímulo/resposta e em seguida a resposta que esperamos. Mas para conseguir validar, chegamos ao ponto mais importante: A medida da resposta (por isso o SMART é importante). Dessa forma podemos validar que atingimos o que se pede no requisito que está sendo validado.

E o que mais?

Bom, também é possível incluir resultado de POCs, referência para projetos modelos ou até mesmo custo do projeto e da infraestrutura do projeto. Lembre-se, quanto mais conseguirmos extrair do nosso cliente, maiores as chances de atingirmos a previsão e evitarmos complicações ao longo do projeto.