Richards & Ford – Fundamentos da Arquitetura de Software (2024)

Página 271

19. Decisões da Arquitetura

CAPÍTULO 19 Decisões da Arquitetura Uma das expectativas essenciais de um arquiteto é tomar decisões de arquitetura. Em geral, essas decisões envolvem a estrutura da aplicação ou do sistema, mas podem envolver decisões de tecnologia também, em particular quando tais decisões impactam as características da arquitetura. Independentemente do contexto, uma boa decisão de arquitetura é aquela que ajuda a orientar as equipes de desenvolvimento ao fazer escolhas técnicas certas. Tomar decisões de arquitetura envolve reunir bastante informação relevante, justificar a decisão, documentá-la e comunicar a decisão com eficiência para os stakeholders apropriados.

Antipadrões da Decisão de Arquitetura

Há certa arte em tomar decisões de arquitetura. Sem nenhuma surpresa, surgem vários antipadrões da arquitetura ao tomar decisões como arquiteto. O programador Andrew Koenig define um antipadrão como algo que parece uma boa ideia no começo, mas leva a problemas.

Outra definição de antipadrão é um processo repetido que produz resultados negativos. Os três antipadrões maiores da arquitetura que podem surgir (e geralmente surgem) ao tomar decisões da arquitetura são Cobertura dos Ativos, Feitiço do Tempo e Arquitetura Baseada em E-mail.

Normalmente esses três antipadrões seguem um fluxo progressivo: dominar o antipadrão Cobertura dos Ativos leva ao Feitiço do Tempo, e dominar esse antipadrão leva à Arquitetura Baseada em E-mail. Tomar decisões da arquitetura com eficiência e precisão requer que um arquiteto domine todos os três antipadrões.

Antipadrão Cobertura dos Ativos

O primeiro antipadrão que surge ao tentar tomar decisões da arquitetura é a Cobertura dos Ativos. Esse antipadrão ocorre quando um arquiteto evita ou adia tomar uma decisão da arquitetura com o medo de fazer a escolha errada.

Existem meios de dominar esse antipadrão. O primeiro é esperar até o último momento responsável para tomar uma decisão importante da arquitetura. Esse último momento significa esperar até você tenha informação suficiente para justificar e validar sua decisão, mas não aguardar muito tempo a ponto de atrasar as equipes de desenvolvimento ou cair no antipadrão Paralisia de Análise. O segundo modo de evitar esse antipadrão é colaborar continuamente com as equipes de desenvolvimento e assegurar que a decisão tomada possa ser implementada como o esperado. Isso tem vital importância, porque não é viável, como arquiteto, saber cada detalhe sobre certa tecnologia e todas as questões associadas. Colaborando de perto com as equipes de desenvolvimento, o arquiteto pode responder rápido a uma mudança na decisão da arquitetura se ocorrem problemas.

Para ilustrar isso, suponha que um arquiteto tome a decisão de que todos os dados de referência relacionados ao produto (descrição, peso e dimensões do produto) sejam armazenados em

Página 272

cache em todas as instâncias do serviço que precisam dessa informação usando um cache replicado de somente leitura, com a réplica primária pertencendo ao serviço de catálogos. Um cache replicado significa que, se houvesse mudanças nas informações do produto (ou um novo produto fosse adicionado), o serviço de catálogo atualizaria seu cache, que então seria replicado em todos os outros serviços que requerem esses dados por meio de um produto em cache (na memória) replicado. Uma boa justificativa para essa decisão seria reduzir o acoplamento entre os serviços e compartilhar de modo efetivo os dados sem ter que fazer uma chamada entre os serviços. Contudo, as equipes de desenvolvimento que implementam essa decisão de arquitetura acham que, devido a certos requisitos de escalabilidade de alguns serviços, essa decisão exigiria mais memória no processo do que está disponível. Colaborando de perto com as equipes de desenvolvimento, o arquiteto toma conhecimento rapidamente sobre o problema e ajusta a decisão de arquitetura para incluir essas situações.

Antipadrão Feitiço do Tempo

Assim que um arquiteto domina o antipadrão Cobertura dos Ativos e começa a tomar decisões, surge um segundo antipadrão: Feitiço do Tempo. Esse antipadrão ocorre quando as pessoas não sabem por que uma decisão foi tomada, então continuam discutindo sem parar. O antipadrão Feitiço do Tempo tem esse nome por causa do filme Feitiço do Tempo, de Bill Murray, em que o dia 2 de fevereiro se repete todos os dias.

O Feitiço do Tempo ocorre porque, assim que um arquiteto toma uma decisão da arquitetura, ele não dá uma justificativa para a decisão (ou uma justificativa completa). Ao justificar as decisões da arquitetura, é importante dar uma explicação técnica e comercial. Por exemplo, um arquiteto pode tomar a decisão de dividir uma aplicação monolítica em serviços separados para desacoplar os aspectos funcionais da aplicação para que cada parte use menos recursos da VM e possa ser mantida e implementada separadamente. Embora seja um bom exemplo de justificativa técnica, falta a justificava comercial, ou seja, por que o negócio deve pagar por essa refatoração arquitetural? Uma boa explicação comercial para essa decisão pode ser entregar uma nova funcionalidade comercial mais rápido, melhorando a entrada no mercado. Outra pode ser reduzir os custos associados ao desenvolvimento e ao lançamento de novos recursos.

Fornecer valor comercial ao justificar as decisões é de vital importância para qualquer decisão da arquitetura. Também é um bom teste decisivo para determinar se a decisão deve ser tomada em primeiro lugar. Se certa decisão da arquitetura não fornece nenhum valor comercial, então talvez não seja boa e deva ser reconsiderada.

Quatro das justificativas comerciais mais comuns incluem custo, colocação no mercado, satisfação do usuário e posicionamento estratégico. Ao focar essas justificativas comuns, é importante levar em conta o que é importante para os acionistas da empresa. Justificar certa decisão apenas com base na economia dos custos pode não ser a decisão correta se os acionistas estão menos preocupados com o custo e mais com o tempo de entrada no mercado.

Antipadrão Arquitetura Baseada em E-mail

Assim que um arquiteto toma decisões e justifica por completo essas decisões, surge um terceiro antipadrão: Arquitetura Baseada em E-mail. Esse antipadrão é onde as pessoas se perdem, esquecem ou nem sabem que uma decisão de arquitetura foi tomada, portanto não podem implementar tal decisão. O antipadrão é sobre comunicar com eficiência suas decisões da

Página 273

arquitetura. O e-mail é uma ótima ferramenta de comunicação, mas cria um sistema ruim de repositório de documentos.

Existem muitos modos de aumentar a eficiência da comunicação das decisões da arquitetura, evitando o antipadrão Arquitetura Baseada em E-mail. A primeira regra para comunicar as decisões não é incluir a decisão no corpo de um e-mail. Incluir a decisão da arquitetura no corpo cria vários sistemas de registro dessa decisão. Muitas vezes detalhes importantes (inclusive a justificativa) são omitidos no e-mail, criando o antipadrão Feitiço do Tempo mais uma vez. Além disso, se essa decisão da arquitetura mudou ou foi substituída, como as pessoas podem receber a decisão revisada? Uma abordagem melhor seria simplesmente mencionar a natureza e o contexto da decisão no corpo do e-mail e fornecer um link para o sistema de registro para a decisão da arquitetura real e detalhes correspondentes (um link para uma página wiki ou um documento no sistema de arquivos).

A segunda regra para comunicar com eficiência as decisões da arquitetura é notificar apenas as pessoas realmente importantes. Uma boa técnica é escrever no corpo do e-mail algo como:

“Oi, Sandra. Tomei uma decisão importante em relação à comunicação entre os serviços que impacta você diretamente. Veja a decisão seguindo este link…”

Observe a frase na primeira parte: “decisão importante em relação à comunicação entre os serviços”. Aqui é mencionado o contexto da decisão, mas não a decisão em si. A segunda parte é ainda mais importante: “que impacta você diretamente”. Se uma decisão da arquitetura não impacta a pessoa diretamente, então por que incomodá-la com a decisão da arquitetura? É um ótimo teste decisivo para determinar quais stakeholders (inclusive os desenvolvedores) devem ser notificados diretamente sobre a decisão da arquitetura. A segunda frase fornece um link para o local da decisão da arquitetura para que ela fique em apenas um lugar e, por isso, um sistema de registro para a decisão.

Significante para a Arquitetura

Muitos arquitetos acreditam que se uma decisão da arquitetura envolve qualquer tecnologia específica, então não é uma decisão da arquitetura, mas uma decisão técnica. Nem sempre é assim. Se um arquiteto toma a decisão de usar certa tecnologia porque ela dá suporte direto a determinada característica da arquitetura (como desempenho ou escalabilidade), então é uma decisão da arquitetura.

Michael Nygard, um arquiteto de software conhecido e autor do livro Release It! (sem publicação no Brasil), abordou o problema de por quais decisões um arquiteto deve ser responsável (e, consequentemente, o que é uma decisão da arquitetura) criando o termo significativo para a arquitetura. Segundo Michael, as decisões significativas para a arquitetura são as que afetam a estrutura, as características não funcionais, as dependências, as interfaces ou as técnicas de construção.

Estrutura se refere às decisões que impactam os padrões ou os estilos da arquitetura sendo usada. Um exemplo é a decisão de compartilhar dados entre um conjunto de microsserviços.

Essa decisão impacta o contexto delimitado do microsserviço e, assim, afeta a estrutura da aplicação.

As características não funcionais são as características da arquitetura (“atributos”) que são importantes para a aplicação ou o sistema que está sendo desenvolvido ou mantido. Se uma

Página 274

escolha de tecnologia impacta o desempenho, e ele é um aspecto importante da aplicação, então ela se torna uma decisão da arquitetura.

Dependências se referem a acoplar pontos entre componentes e/ou serviços dentro do sistema, impactando a disponibilidade, a modularidade, a agilidade, o testabilidade, a confiabilidade gerais etc.

Interfaces se referem a como serviços e componentes são acessados e orquestrados, em geral por meio de um gateway, hub de integração, barramento de serviço ou proxy da API. Em geral, as interfaces envolvem definir contratos, inclusive a versão e a estratégia de descontinuação desses contratos. As interfaces impactam outros usos do sistema, por isso são significantes para a arquitetura.

Por fim, técnicas de construção se referem às decisões sobre plataformas, estruturas, ferramentas e até processos que, embora sejam técnicos por natureza, podem impactar algum aspecto da arquitetura.

Registros de Decisão da Arquitetura

Um dos modos mais eficientes de documentar as decisões da arquitetura é com ADRs (Registros de Decisão da Arquitetura). Os ADRs foram divulgados pela primeira vez por Michael Nygard em um blog e, mais tarde, marcados como “adotar” no periódico Technology Radar da ThoughtWorks. Um ADR consiste em um pequeno arquivo de texto (em geral uma ou duas páginas) descrevendo uma decisão de arquitetura específica. Embora possam ser escritos usando texto normal, eles costumam vir com um tipo de formato de documento de texto, como AsciiDoc ou Markdown. Uma alternativa seria um ADR também ser escrito usando um modelo de página wiki.

Há também ferramentas disponíveis para gerenciar os ADRs. Nat Pryce, coautor do livro Growing Object-Oriented Software Guided by Tests (sem publicação no Brasil), escreveu uma ferramenta de código aberto para ADRs chamada ADR-tools, que fornece uma interface da linha de comando para gerenciar os ADRs, inclusive os esquemas de numeração, os locais e a lógica substituída. Micha Kops, engenheiro de software alemão, escreveu um blog sobre como usar as ADR-tools com ótimos exemplos sobre como elas podem ser usadas para gerenciar os registros de decisão da arquitetura.

Estrutura Básica

A estrutura básica de um ADR consiste em cinco seções principais: Título, Status, Contexto, Decisão e Consequências. Em geral, adicionamos duas seções extras como parte da estrutura básica: Conformidade e Notas. Essa estrutura (como mostrado na Figura 19-1) pode ser estendida para incluir qualquer outra seção considerada necessária, contanto que o modelo fique consistente e conciso. Um bom exemplo poderia ser adicionar uma seção Alternativas se for preciso fornecer uma análise de todas as outras possíveis soluções alternativas.

Página 275

Figura 19-1. Estrutura básica do ADR Título O título de um ADR costuma ser numerado em sequência e contém uma pequena frase descrevendo as decisões da arquitetura. Por exemplo, a decisão é usar mensageria assíncrona entre o Serviço de Pedido e o Serviço de Pagamento, mostrando: “42. Uso de Mensageria Assíncrona Entre os Serviços de Pedido e Pagamento”. O título deve ser descritivo o bastante para não haver ambiguidades sobre a natureza e o contexto da decisão, mas, ao mesmo tempo, deve ser curto e conciso.

Status

Página 276

O status de um ADR pode ser marcado como Proposto, Aceito ou Substituído. O status Proposto significa que a decisão deve ser aprovada por um tomador de decisão de nível mais alto ou algum órgão de governança da arquitetura (como uma comissão de avaliação da arquitetura). O status Aceito significa que a decisão foi aprovada e está pronta para a implementação. Um status Substituído indica que a decisão mudou e foi substituída por outro ADR. O status Substituído sempre pressupõe que o status ADR anterior era aceito, ou seja, um ADR proposto nunca seria substituído por outro ADR, mas continuaria a ser modificado até ser aceito.

O status Substituído é um modo poderoso de manter um registro histórico das decisões tomadas, por que foram tomadas naquele momento, qual é a nova decisão e por que foi alterada. Em geral, quando um ADR é substituído, ele é marcado com a decisão que o substituiu. Do mesmo modo, a decisão que substitui outro ADR é marcada com o ADR que ela substituiu. Por exemplo, suponha que o ADR 42 (“Uso de Mensageria Assíncrona Entre os Serviços de Pedido e Pagamento”) tenha sido aprovado anteriormente, mas devido às últimas mudanças na implementação e localização do Serviço de Pagamento, agora REST deve ser usado entre os dois serviços (ADR 68). O status ficaria assim:

ADR 42. Uso de Mensageria Assíncrona Entre os Serviços de Pedido e Pagamento Status: Substituído por 68 ADR 68. Uso de REST entre os Serviços de Pedido e Pagamento Status: Aceito, substitui 42 O link e o caminho do histórico entre os ADRs 42 e 68 impedem a inevitável pergunta “e o uso da mensageria?” em relação ao ADR 68.

ADRs e RFC (Requisição de Comentários) Se um arquiteto deseja enviar um ADR preliminar para comentários (o que às vezes é uma boa ideia quando ele deseja validar várias suposições e afirmações com um público maior de stakeholders), recomendamos criar um novo status chamado RFC (Requisição de Comentários) e especificar um prazo de quando a revisão estaria concluída. Essa prática impede o inevitável antipadrão Paralisia de Análise, em que a decisão é discutida para sempre, mas nunca tomada de fato. Assim que a data é atingida, o arquiteto pode analisar todos os comentários feitos sobre o ADR, fazer qualquer ajuste necessário na decisão, tomar a decisão final e definir o status para Proposto (a menos que o arquiteto consiga aprovar ele mesmo a decisão e, nesse caso, o status seria definido para Aceito). Um exemplo de um status RFC para um ADR seria assim:

STATUS Requisição de Comentários, Prazo 09 jan 2010 Outro aspecto importante da seção Status de um ADR é que ela faz um arquiteto ter as conversas necessárias com seu chefe ou arquiteto responsável sobre os critérios com os quais ele mesmo pode aprovar uma decisão da arquitetura ou se deve ser aprovada por um arquiteto de nível mais alto, uma comissão de avaliação da arquitetura ou algum outro órgão de governança da arquitetura.

Os três critérios que formam um bom ponto de partida para essas conversas são custo, impacto entre as equipes e segurança. O custo pode incluir a compra do software e taxas de licença, custos adicionais com hardware, além do nível geral de esforço para implementar a decisão da arquitetura. O nível dos custos do esforço pode ser estimado multiplicando o número estimado

Página 277

de horas para implementar a decisão da arquitetura pela taxa FTE (equivalente em tempo integral) padrão da empresa. O proprietário ou o gerente do projeto normalmente tem a quantia de FTE. Se o custo da decisão da arquitetura excede certa quantia, então deve ser definida para o status Proposto e aprovada por outra pessoa. Se a decisão impacta outras equipes ou sistemas, ou tem alguma implicação na segurança, não pode ser autoaprovada pelo arquiteto, mas por um órgão de governança de nível mais alto ou arquiteto responsável.

Assim que os critérios e os limites correspondentes são estabelecidos e acordados (como “custos acima de €5 mil devem ser aprovados pela comissão de avaliação da arquitetura”), esse critério deve ser bem documentado para que todos os arquitetos que criam ADRs saibam quando podem ou não aprovar suas próprias decisões da arquitetura.

Contexto A seção Contexto de um ADR especifica as forças em ação, ou seja, “qual situação me faz tomar esta decisão?” Tal seção do ADR permite que o arquiteto descreva a situação ou o problema específico e colabore de modo conciso nas possíveis alternativas. Se um arquiteto precisa documentar a análise de cada alternativa em detalhes, então uma seção Alternativas extra pode ser adicionada ao ADR, em vez de a análise ser acrescentada à seção Contexto.

A seção Contexto também fornece um modo de documentar a arquitetura. Descrevendo o contexto, o arquiteto também descreve a arquitetura. É um modo eficiente de documentar uma área específica da arquitetura de um jeito claro e conciso. Continuando com o exemplo da seção anterior, o contexto pode ser o seguinte: “O serviço de pedido deve passar informações ao serviço de pagamento para pagar um pedido sendo feito atualmente. Isso poderia ser feito usando REST ou uma mensageria assíncrona.” Observe que essa declaração concisa não só especificou o cenário, como também as alternativas.

Decisão A seção Decisão do ADR contém a decisão da arquitetura, junto com uma justificativa completa para a decisão. Michael Nygard introduziu uma ótima maneira de declarar uma decisão da arquitetura usando uma voz muito afirmativa e de comando, ao invés de uma passiva. Por exemplo, a decisão de usar mensageria assíncrona entre os serviços mostraria “usaremos mensageria assíncrona entre os serviços”. Isso é um jeito muito melhor de declarar uma decisão do que “Acho que a mensageria assíncrona entre os serviços seria a melhor escolha.” Note aqui que não está claro qual é a decisão nem mesmo se uma decisão foi tomada, apenas a opinião do arquiteto é declarada.

Talvez um dos aspectos mais poderosos da seção Decisão dos ADRs seja que ela permite que um arquiteto enfatize mais o por que, em vez de como. Entender por que uma decisão foi tomada é muito mais importante do que entender como algo funciona. A maioria dos arquitetos e dos desenvolvedores pode identificar como as coisas funcionam vendo os diagramas do contexto, mas não por que uma decisão foi tomada. Saber por que ela foi tomada e a justificativa correspondente para a decisão ajuda as pessoas a entenderem melhor o contexto do problema e evita possíveis erros refatorando outra solução que pode gerar problemas.

Para mostrar isso, considere uma decisão da arquitetura original de anos atrás para usar a estrutura gRPC (Remote Procedure Call) do Google como um meio de se comunicar entre dois

Página 278

serviços. Sem entender por que a decisão foi tomada, outro arquiteto escolheu sobrescrever a decisão vários anos depois e usar a mensageria para desacoplar mais os serviços. Contudo, implementar esse refatoramento de repente causa um grande aumento na latência, que, por sua vez, causa limites de tempo nos sistemas uptream. Entender que o uso original do gRPC era para reduzir muito a latência (às custas de serviços muito acoplados) teria evitado a ocorrência do refatoramento em primeiro lugar.

Consequências A seção Consequências de um ADR também é muito importante. Ela documenta o impacto geral de uma decisão da arquitetura. Toda decisão que um arquiteto toma tem algum impacto, bom e ruim. Ter que especificar o impacto de uma decisão da arquitetura faz o arquiteto pensar se esses impactos pesam mais que os benefícios da decisão.

Outro bom uso dessa seção é documentar a análise de trade-off associada à decisão da arquitetura. Esses trade-offs poderiam se basear em custo ou trade-offs contrários a outras características da arquitetura (“atributos”). Por exemplo, considere a decisão de usar a mensageria assíncrona (disparar e esquecer) para postar uma avaliação em um site. A justificativa para essa decisão é aumentar muito a resposta da requisição de avaliação da postagem de 3.100 milissegundos para 25 milissegundos porque os usuários não precisariam aguardar que a avaliação real fosse postada (apenas que a mensageria fosse enviada para uma fila). Embora seja uma boa justificativa, outra pessoa pode argumentar que ela é ruim devido à complexidade do tratamento de erro associado a uma requisição assíncrona (“o que acontece se alguém posta uma avaliação com palavras impróprias?”). Desconhecida para a pessoa que contesta a decisão, essa questão já tinha sido discutida com os acionistas da empresa e outros arquitetos, e foi resolvida de uma perspectiva do trade-off de que era mais importante ter o aumento na resposta e lidar com o tratamento de erro complexo do que aguardar de modo síncrono para dar um feedback para o usuário, informando que a avaliação foi postada com sucesso. Utilizando ADRs, essa análise de trade-off pode ser incluída na seção Consequências, fornecendo uma imagem completa do contexto (e dos trade-offs) da decisão da arquitetura, assim evitando a situação.

Conformidade A seção Conformidade de um ADR não é uma das seções padrão nele, mas algo que recomendados. Ela faz o arquiteto pensar sobre como a decisão da arquitetura será medida e controlada de uma perspectiva da conformidade. O arquiteto deve decidir se a verificação da conformidade dessa decisão deve ser manual ou se pode ser automatizada usando uma função de aptidão. Se pode ser automatizada com uma função de aptidão, então o arquiteto pode especificar nessa seção como a função de aptidão seria escrita e se há outras alterações na base de código que são necessárias para mediar essa decisão da arquitetura quanto à conformidade.

Por exemplo, considere a seguinte decisão da arquitetura em uma arquitetura com n camadas tradicionais, como na Figura 19-2. Todos os objetos compartilhados usados pelos objetos comerciais na camada comercial residirão na camada de serviços compartilhados para isolar e conter a funcionalidade compartilhada.

Página 279

Página 280

Modificado por Última modificação Mesmo ao armazenar ADRs em um sistema de controle de versão (como Git), metainformações extras são úteis além do que o repositório pode suportar, portanto recomendados adicionar essa seção, independentemente de como e onde os ADRs estão armazenados.

Armazenando ADRs

Assim que um arquiteto cria um ADR, ele deve ser armazenado em algum lugar. A despeito de onde os ADRs estão armazenados, cada decisão da arquitetura deve ter seu próprio arquivo ou página wiki. Alguns arquitetos gostam de manter os ADRs em um repositório Git com o código-fonte. Mantê-los nesse repositório permite que o ADR tenha o controle de versão e seja rastreado também. Contudo, para as organizações maiores, não recomendamos essa prática por vários motivos. Primeiro, todos que precisam ver a decisão da arquitetura podem não ter acesso ao repositório Git. Segundo, esse não é um bom local para armazenar os ADRs com um contexto fora do repositório Git da aplicação (como decisões da arquitetura de integração, decisões da arquitetura corporativa ou decisões comuns a toda aplicação).

Por isso, recomendamos armazenar os ADRs em uma wiki (usando um modelo wiki) ou em um diretório compartilhado em um servidor de arquivos compartilhados que possa ser acessado facilmente por uma wiki ou outro software de apresentação de documentos. A Figura 19-3 mostra um exemplo dessa estrutura de diretórios (ou estrutura de navegação da página wiki).

Página 281

Figura 19-3. Estrutura de diretórios de exemplo para armazenar ADRs O diretório aplicacao contém as decisões da arquitetura específicas de algum tipo de contexto da aplicação. Esse diretório é subdividido em outros. O subdiretório common é para as decisões da arquitetura que se aplicam a todos as aplicações, como “Todas as classes relacionadas à estrutura conterão uma anotação (@Estrutura em Java) ou atributo ([Estrutura] em C#) identificando a classe como pertencendo ao código da estrutura subjacente”. Os subdiretórios no diretório aplicacao correspondem à aplicação ou ao contexto do sistema específico, e contêm decisões da arquitetura específicas dessa aplicação ou sistema (nesse exemplo, as aplicações ATP e PSTD). O diretório integraçao contém os ADRs que envolvem a comunicação entre aplicação, sistemas ou serviços. Os ADRs da arquitetura da empresa ficam no diretório

Página 282

empresa, indicando que são decisões da arquitetura globais e que impactam todos os sistemas e aplicações. Um exemplo de ADR da arquitetura da empresa seria “Todo acesso a um banco de dados do sistema será apenas a partir do sistema proprietário”, evitando o compartilhamento de bancos de dados em vários sistemas.

Ao armazenar ADRs em uma wiki (nossa recomendação), a mesma estrutura descrita antes se aplica, com cada estrutura do diretório representando uma página inicial de navegação. Cada ADR seria representado como uma única página wiki dentro de cada página inicial de navegação (Aplicaçao, Integraçao ou Empresa).

Os nomes do diretório ou da página inicial indicados nesta seção são apenas uma recomendação. Cada empresa pode escolher os nomes adequados à sua situação, contanto que sejam consistentes entre as equipes.

ADRs como Documentação

Documentar a arquitetura de software sempre foi um tópico difícil. Embora alguns padrões estejam surgindo para diagramar a arquitetura (como o Modelo C4 do arquiteto de software Simon Brown ou o padrão The Open Group ArchiMate), não existe tal padrão para documentar a arquitetura de software. É onde entram os ADRs.

Os ADRs podem ser usados de um modo eficiente para documentar uma arquitetura de software. A seção Contexto de um ADR é uma excelente oportunidade para descrever a área específica do sistema que requer que uma decisão da arquitetura seja tomada. Essa seção também é uma oportunidade para descrever as alternativas. Talvez o mais importante seja que a seção Decisão descreve os motivos para certa decisão ser tomada, que é de longe a melhor forma de documentação da arquitetura. A seção Consequências adiciona a parte final dessa documentação, descrevendo aspectos adicionais de determinada decisão, como a análise de trade-off, ao priorizar o desempenho e não a escalabilidade.

Usando ADRs para Padrões

Poucas pessoas gostam de padrões. Na maioria das vezes, eles parecem existir mais para controlar as pessoas e como elas fazem as coisas do que para serem úteis. Usar ADRs para os padrões pode mudar essa prática ruim. Por exemplo, a seção Contexto de um ADR descreve a situação que força certo padrão. A seção Decisão de um ADR pode ser usada não apenas para indicar apenas qual é o padrão, porém o mais importante é o motivo da necessidade de o padrão existir. É um modo maravilhoso de conseguir qualificar se certo padrão deve existir em primeiro lugar. Se um arquiteto não consegue justificar o padrão, então talvez ele não seja um bom padrão para criar e aplicar. Além disso, quanto mais os desenvolvedores entendem por que existe certo padrão, mais provável será segui-lo (e não desafiá-lo). A seção Consequências de um ADR é outro ótimo lugar para um arquiteto qualificar se um padrão é válido e deve ser criado. Nessa seção, o arquiteto deve considerar e documentar quais são as implicações e as consequências de certo padrão que está sendo criado. Analisando as consequências, o arquiteto pode decidir que o padrão não deve ser aplicado afinal.

Exemplo

Página 283

Existem muitas decisões da arquitetura em nosso “Caso de Estudo: Going, Going, Gone”, no Capítulo 7. O uso de microsserviços orientados a evento, a divisão das IUs do proponente e do leiloeiro, o uso do RTP (Protocolo de Transporte em Tempo Real) para a captura de vídeo, o uso de uma camada da API e o uso de mensageria para publicar e assinar são apenas algumas dezenas de decisões da arquitetura tomadas nesse sistema de leilão. Toda decisão da arquitetura tomada em um sistema, independentemente do quão óbvia possa ser, deve ser documentada e justificada.

A Figura 19-4 mostra uma das decisões da arquitetura no sistema de leilão Going, Going, Gone, que é o uso da mensageria para publicar e assinar (pub/sub) entre a captura do lance, o streamer do lance e os serviços de controle do lance.

Figura 19-4. Uso de pub/sub entre os serviços O ADR para essa decisão da arquitetura poderia ser similar à Figura 19-5:

Página 284

Figura 19-5. ADR 76. Mensageria Pub/Sub assíncrona entre os serviços do lance

Página 285

20. Analisando o Risco da Arquitetura

CAPÍTULO 20 Analisando o Risco da Arquitetura Toda arquitetura tem um risco associado, seja envolvendo disponibilidade, escalabilidade ou integridade de dados. Analisar esse risco é uma das principais atividades da arquitetura.

Analisando-o continuamente, o arquiteto pode lidar com as deficiências na arquitetura e tomar uma ação corretiva para mitigar o risco. Neste capítulo, apresentamos algumas das principais técnicas e práticas para qualificar o risco, criar avaliações de risco e identificá-lo como uma atividade chamada risk storming (refletir sobre os aspectos da qualidade).

Matriz de Risco

O primeiro problema que surge ao avaliar o risco da arquitetura é determinar se ele deve ser classificado como baixo, médio ou alto. Em geral, há muita subjetividade nessa classificação, criando confusão sobre quais partes da arquitetura são realmente de alto risco versus médio risco. Por sorte, existe uma matriz de risco que os arquitetos podem usar para ajudar a reduzir o nível de subjetividade e qualificar o risco associado a certa área da arquitetura.

A matriz de risco da arquitetura (mostrada na Figura 20-1) usa duas dimensões para qualificar o risco: o impacto geral do risco e a probabilidade de ele ocorrer. Cada dimensão tem uma classificação baixa (1), média (2) e alta (3). Esses números são multiplicados em cada grade da matriz, fornecendo um número objetivo que representa o risco. Os números 1 e 2 são considerados de baixo risco, os números 3 e 4 são de risco médio, já os números de 6 a 9 são de alto risco.

Página 286

Figura 20-1. Matriz para determinar o risco da arquitetura Para ver como a matriz de risco pode ser usada, suponha que exista uma preocupação com a disponibilidade em relação a certo banco de dados central primário usado na aplicação.

Primeiro, considere a dimensão do impacto, ou seja, qual é o impacto geral se o banco de dados cai ou fica indisponível? Aqui, um arquiteto pode julgar que é de alto risco, tornando isso um risco 3 (médio), 6 (alto) ou 9 (alto). Contudo, após aplicar a segunda dimensão (probabilidade do risco ocorrer), o arquiteto percebe que o BD está em servidores altamente disponíveis apenas em uma configuração de cluster e que, portanto, a probabilidade de que o BD fique indisponível é baixa. Assim, a interseção entre o alto impacto e a baixa probabilidade dá ao risco geral a classificação 3 (risco médio).

Ao utilizar a matriz de risco para qualificar o risco, considere primeiro a dimensão do impacto, depois a dimensão da probabilidade.

Avaliações do Risco

A matriz de risco descrita na seção anterior pode ser usada para criar o que se chama avaliação do risco. Essa avaliação é um relatório resumido do risco geral de uma arquitetura em relação a algum critério de avaliação contextual e significativo.

As avaliações do risco podem variar muito, mas, em geral, contêm o risco (qualificado com a matriz de risco) e algum critério de avaliação com base nos serviços ou nas áreas do domínio de uma aplicação. Esse formato do relatório de avaliação do risco básico é mostrado na Figura 20-

Página 287

2, em que um cinza claro (1-2) é de baixo risco, um cinza médio (3-4) é de médio risco e um cinza escuro (6-9) é de alto risco. Em geral essas cores são outras, como verde (baixo), amarelo (médio) e vermelho (alto), mas a tonalidade pode ser útil para a exibição em preto e branco e pessoas daltônicas.

Figura 20-2. Exemplo de uma avaliação do risco padrão O risco quantificado com a matriz de risco pode ser acumulado pelo critério de risco e também pelas áreas do serviço ou do domínio. Por exemplo, note, na Figura 20-2, que o risco acumulado para a integridade dos dados é a área de risco mais alta, totalizando 17, já o risco acumulado para a Disponibilidade é de apenas 10 (o menor risco). O risco relativo de cada área do domínio pode também ser determinado pelo exemplo da avaliação do risco. Aqui, o registro do cliente tem a maior área de risco, ao passo que realizar o pedido é o menor risco. Esses números relativos podem ser rastreados para demonstrar melhorias ou degradação do risco em certa categoria de risco ou área do domínio.

Embora o exemplo de avaliação do risco na Figura 20-2 contenha todos os resultados da análise, ela raramente é apresentada assim. Filtrar é essencial para indicar visualmente certa mensagem em determinado contexto. Por exemplo, suponha que um arquiteto esteja em uma reunião com a finalidade de apresentar as áreas do sistema que têm alto risco. Em vez de apresentar a avaliação de risco como ilustrada na Figura 20-2, o filtro pode ser usado para mostrar apenas as áreas de alto risco (como na Figura 20-3), melhorando a relação geral entre sinal/ruído e apresentando uma imagem clara do estado do sistema (bom ou ruim).

Página 288

Figura 20-3. Filtrando a avaliação de risco com apenas o alto risco Outro ponto na Figura 20-2 é que esse relatório de avaliação mostra apenas uma captura no tempo; ele não mostra se as coisas estão melhorando ou piorando, ou seja, a Figura 20-2 não mostra a direção do risco. Apresentar essa direção é um problema. Se uma seta para cima ou para baixo fosse usada para indicar a direção, o que significaria a seta para cima? As coisas estão melhorando ou piorando? Passamos anos perguntando às pessoas se uma seta para cima significava que as coisas melhoravam ou pioravam, e quase 50% delas disseram que a seta para cima significava que as coisas pioravam progressivamente, já quase 50% disseram que essa seta indicava melhoria. O mesmo acontece com as setas para a esquerda e a direita. Por isso, ao usar setas para indicar a direção, deve haver uma legenda. Porém, descobrimos que isso também não funciona. Assim que o usuário rola além da chave, ele fica confuso de novo.

Em geral usamos o símbolo de direção universal adição (+) e subtração (-) ao lado da classificação de risco para indicar a direção, como na Figura 20-4. Observe na Figura 20-4 que, embora a performance do registro do cliente seja média (4), a direção é um sinal de menos, indicando que está piorando progressivamente e indo para um alto risco. Por outro lado, note que a escalabilidade de fechar o catálogo é alta (6) com um sinal de mais, mostrando que está melhorando. As classificações de risco sem sinal de mais ou menos indicam que o risco é estável, não melhorando nem piorando.

Página 289

Figura 20-4. Mostrando a direção do risco com sinais de mais e menos Por vezes, até os sinais de adição e subtração podem ser confusos para algumas pessoas. Outra técnica para indicar a direção é utilizar uma seta junto com o número da classificação de risco.

Essa técnica, mostrada na Figura 20-5, não requer legenda porque a direção é clara. E mais, o uso de tons ou cores (seta vermelha para pior, verde para melhor) deixa ainda mais clara a direção do risco.

Figura 20-5. Mostrando a direção do risco com setas e números A direção do risco pode ser determinada usando medidas contínuas com as funções de aptidão descritas antes no livro. Analisando objetivamente cada critério de risco, podem ser observadas tendências, fornecendo a direção de cada critério de risco.

Risk Storming

Nenhum arquiteto consegue determinar sozinho o risco geral de um sistema. Há dois motivos para isso. Primeiro, um arquiteto pode não ver ou ignorar uma área de risco; segundo, bem É

Página 290

poucos arquitetos têm total conhecimento de cada parte do sistema. É onde o risk storming pode ajudar.

Risk storming é um exercício de colaboração usado para determinar o risco da arquitetura em certa dimensão. As dimensões comuns (áreas de risco) incluem tecnologia não comprovada, performance, escalabilidade, disponibilidade (inclusive dependências de transição), perda de dados, pontos únicos de falha e segurança. Embora grande parte dos esforços de risk storming envolva vários arquitetos, é inteligente incluir os principais desenvolvedores e os responsáveis técnicos também. Além de darem uma perspectiva da implementação para o risco da arquitetura, envolver desenvolvedores os ajuda a ter uma melhor compreensão da arquitetura.

O esforço de risk storming envolve uma parte individual e uma de colaboração. Na parte individual, todos os participantes atribuem individualmente (sem colaboração) um risco às áreas da arquitetura usando a matriz de risco descrita na seção anterior. Essa parte sem colaboração do risk storming é essencial para que os participantes não influenciem nem direcionem a atenção para certas áreas da arquitetura. Na parte de colaboração, todos trabalham juntos para chegar a um consenso nas áreas de risco, discutem sobre o risco e criam soluções para mitigá-lo.

Um diagrama da arquitetura é usado para as duas partes do esforço de risk storming. Para as avaliações de risco globais, em geral é usado um diagrama da arquitetura abrangente, já o risk storming em áreas específicas da aplicação usaria um diagrama da arquitetura contextual. É responsabilidade do arquiteto conduzir o esforço de risk storming para assegurar que esses diagramas fiquem atualizados e disponíveis para todos os participantes.

A Figura 20-6 mostra um exemplo de arquitetura que usaremos para mostrar o processo de risk storming. Nessa arquitetura, um Balanceador de Carga (Elastic Load Balancer) interage com cada instância EC2 que contém servidores web (Nginx) e serviços da aplicação. Os serviços da aplicação fazem chamadas para um banco de dados MySQL, um cache Redis e um banco de dados MongoDB para o gerenciamento de logs. Também fazem chamadas para Servidores de Expansão (Push Expansion Servers). Esses serviços, por sua vez, se comunicam com o banco de dados MySQL, o cache Redis e o gerenciamento de logs do MongoDB.

Página 291

Figura 20-6. Diagrama da arquitetura para o exemplo de risk storming O risk storming é dividido em três atividades básicas:

1. 1. Identificação
2. 2. Consenso
3. 3. Mitigação

A identificação é sempre uma atividade individual e sem colaboração, já o consenso e a mitigação são sempre em colaboração e envolvem todos os participantes trabalhando juntos no mesmo ambiente (pelo menos virtualmente). Cada atividade básica é detalhada nas próximas seções.

Identificação

A atividade de identificação do risk storming envolve cada participante identificar individualmente as áreas de risco na arquitetura. As etapas a seguir descrevem a parte da identificação no esforço de risk storming:

1. O arquiteto que realiza o risk storming envia um convite a todos os participantes um ou dois dias antes da colaboração do esforço. O convite contém o diagrama da arquitetura

(ou o local de onde encontrá-lo), a dimensão do risk storming (a área de risco sendo analisada nesse esforço), a data quando a colaboração ocorrerá e o local.

2. Usando a matriz de risco descrita na primeira seção deste capítulo, os participantes analisam individualmente a arquitetura e classificam o risco como baixo (1-2), médio (3-4)

Página 292

ou alto (6-9).

3. Os participantes preparam pequenas notas adesivas com cores correspondentes (verde, amarelo e vermelho) e escrevem o número de risco adequado (encontrado na matriz de risco).

A maioria dos esforços de risk storming envolve apenas analisar determinada dimensão (como performance), mas pode haver vezes, devido à disponibilidade da equipe ou a problemas de tempo, em que várias dimensões são analisadas em um único esforço (como performance, escalabilidade e perda de dados). Quando isso acontece, os participantes escrevem a dimensão ao lado do número do risco nas notas adesivas para que todos fiquem cientes da dimensão específica. Por exemplo, suponha que três participantes acharam risco em um BD central. Todos os três identificaram o risco como alto (6), mas um participante descobriu um risco relacionado à disponibilidade e dois descobriram um risco a respeito da performance. Essas duas dimensões seriam debatidas separadamente.

Sempre que possível, restrinja os esforços de risk storming a uma dimensão. Isso permite que os participantes foquem sua atenção nessa dimensão específica e evita confusão sobre várias áreas de risco sendo identificadas na mesma área da arquitetura.

Consenso

A atividade de consenso no esforço de risk storming é altamente colaborativa, com o objetivo de chegar a um acordo entre todos os participantes quanto ao risco na arquitetura. Essa atividade é mais eficiente quando uma versão grande e impressa do diagrama da arquitetura é disponibilidade e colocada na parede. No lugar de uma grande versão impressa, uma versão eletrônica pode ser exibida em uma grande tela.

No início da sessão de risk storming, os participantes começam colocando notas adesivas no diagrama da arquitetura na área onde eles descobriram um risco individualmente. Se for usada uma versão eletrônica, o arquiteto que faz a sessão consulta cada participante e coloca eletronicamente o risco no diagrama na área da arquitetura onde ele foi identificado (veja a Figura 20-7).

Página 293

Figura 20-7. Identificação inicial das áreas de risco Assim que todas as notas adesivas são colocadas, a parte de colaboração do risk storming pode iniciar. O objetivo dessa atividade é analisar as áreas de risco como uma equipe e chegar a um consenso em termos de qualificação do risco. Note que várias áreas de risco foram identificadas na arquitetura, como na Figura 20-7:

1. 1. Dois participantes identificaram individualmente o Balanceador de Carga como de risco médio (3), já um participante o identificou como de alto risco (6).
2. 2. Um participante identificou individualmente os Servidores de Expansão por Push como de alto risco (9).
3. 3. Três participantes identificaram individualmente o banco de dados MySQL como de médio risco (3).
4. 4. Um participante identificou individualmente o cache Redis como de alto risco (9).
5. 5. Três participantes identificaram o Gerenciamento de Logs do MongoDB como de baixo risco (2).
6. 6. Todas as outras áreas da arquitetura não foram consideradas como tendo risco e, por isso, não há notas adesivas em nenhuma outra área.

Os itens 3 e 5 na lista anterior não precisam de mais debate nessa atividade, uma vez que todos os participantes acordaram com o nível e a qualificação do risco. Porém observe que houve uma diferença de opinião no item 1 na lista, e os itens 2 e 4 tiveram apenas um participante identificando o risco. Esses itens precisam ser discutidos durante a atividade.

Página 294

O item 1 na lista mostrou que dois participantes identificaram individualmente o Balanceador de Carga como de médio risco (3), ao passo que um participante o identificou como de alto risco (6). Nesse caso, os outros dois participantes pedem que o terceiro participante explique por que ele identificou o risco como alto. Suponha que o terceiro participante diga que atribuiu o risco como sendo alto porque se o Balanceador de Carga ficar inativo, o sistema inteiro não poderá ser acessado. Embora seja verdade e realmente eleve a classificação do impacto geral para ser alta, os outros dois participantes convencem o terceiro de que há um baixo risco disso acontecer. Após um debate, o terceiro participante concorda, reduzindo o nível do risco para médio (3). Mas o primeiro e o segundo participantes podem não ter visto certo aspecto do risco no Balanceador, daí a necessidade de colaboração na atividade de risk storming.

Com isso, considere o item 2 na lista anterior em que um participante identificou individualmente os Servidores de Expansão por Push como de alto risco (9) e nenhum outro participante o identificou com risco. Nesse caso, todos os outros participantes perguntam ao participante que identificou o risco por que ele foi classificado como alto. Então o participante diz que teve experiências ruins com os Servidores de Expansão por Push ficando sempre inativos sob alta carga, algo que ocorre nessa arquitetura em particular. Esse exemplo mostra o valor do risk storming — sem o envolvimento desse participante, ninguém teria visto o alto risco (até estar em produção, claro!).

O item 4 na lista é um caso interessante. Um participante identificou o cache Redis como de alto risco (9), já nenhum outro viu risco na arquitetura. Os outros participantes perguntam qual é a razão do alto risco nessa área e um participante responde: “O que é cache Redis?” Nesse caso, Redis era desconhecido para o participante, daí o alto risco nessa área.

Para as tecnologias não comprovadas ou desconhecidas, sempre atribua uma classificação de risco mais alto (9), uma vez que a matriz de risco não pode ser usada para essa dimensão.

O exemplo do item 4 na lista mostra por que é inteligente (e importante) reunir os desenvolvedores nas sessões de risk storming. Não só os desenvolvedores podem aprender mais sobre a arquitetura, como o fato de que um participante (que, nesse caso, era um desenvolvedor na equipe) não conhecer certa tecnologia fornece ao arquiteto informações valiosas relacionadas ao risco geral.

Esse processo continua até todos os participantes acordarem nas áreas de risco identificadas.

Assim que as notas adesivas são consolidadas, a atividade termina e a próxima pode começar.

O resultado final dessa atividade é mostrado na Figura 20-8.

Página 295

Figura 20-8. Consenso das áreas de risco Mitigação Assim que todos os participantes acordam quanto à qualificação das áreas de risco da arquitetura, ocorre a atividade final e mais importante: a mitigação do risco. A mitigação do risco dentro de uma arquitetura costuma envolver mudanças ou melhorias em certas áreas dela que poderiam ser consideradas perfeitas como estavam.

Essa atividade, que também normalmente é de colaboração, busca meios de reduzir ou eliminar o risco identificado na primeira atividade. Pode haver casos em que a arquitetura original precisa ser totalmente alterada com base na identificação do risco, já outros podem ser um refatoramento simples da arquitetura, como adicionar uma fila para controle de carga para reduzir um problema de gargalo na taxa de transferência.

Independentemente das mudanças requeridas na arquitetura, em geral essa atividade gera um custo adicional. Por isso, os principais stakeholders costumam decidir se o custo compensa o risco. Por exemplo, suponha que, em uma sessão de risk storming, o banco de dados central foi identificado como sendo de risco médio (4) em relação à disponibilidade geral do sistema.

Nesse caso, os participantes concordaram que colocar o BD em cluster, combinado com a divisão em bancos de dados físicos separados, mitigaria o risco. Contudo, embora o risco fosse muito reduzido, a solução custaria US$20 mil. Então o arquiteto faria uma reunião com o principal acionista da empresa para discutir esse trade-off. Durante a negociação, o empresário decide que o preço é alto demais e o custo não compensa o risco. Em vez de desistir, o arquiteto sugere uma abordagem diferente. Que tal ignorar o cluster e dividir o banco de dados em duas

Página 296

partes? O custo nesse caso cai para US$8 mil, ainda mitigando grande parte do risco. Nesse caso, o acionista concorda com a solução.

O cenário anterior mostra o impacto que o risk storming pode ter não apenas na arquitetura geral, mas também nas negociações entre arquitetos e acionistas da empresa. O risk storming, combinado com as avaliações de risco descritas no início deste capítulo, fornece um excelente veículo para identificar e rastrear o risco, melhorando a arquitetura e lidando com as negociações entre os principais stakeholders.

Análise de Risco da História com a Metodologia Ágil

O risk storming pode ser usado para outros aspectos do desenvolvimento de software além de apenas a arquitetura. Por exemplo, utilizamos o risk storming para determinar o risco geral da conclusão da história do usuário em certa iteração Ágil (e, como consequência, a avaliação de risco geral dessa iteração) durante a preparação da história. Usando a matriz de risco, o risco da história do usuário pode ser identificado pela primeira dimensão (o impacto geral se a história não for concluída dentro da iteração) e pela segunda dimensão (a probabilidade de a história não ser concluída). Utilizando a mesma matriz de risco da arquitetura, as equipes conseguem identificar as histórias de alto risco, rastrear com cuidado e priorizar.

Exemplos de Risk Storming

Para mostrar o poder do risk storming e como ele pode melhorar a arquitetura geral de um sistema, considere o exemplo de um sistema de call center para dar suporte a enfermeiros que aconselham pacientes sobre várias condições de saúde. Os requisitos para tal sistema são os seguintes:

O sistema usará um mecanismo de diagnóstico de terceiros que apresenta perguntas e guia enfermeiros ou pacientes em relação a problemas médicos.

Os pacientes podem ligar usando o call center para falar com um enfermeiro ou escolher usar um site de autoatendimento que acessa diretamente o mecanismo de diagnóstico, pulando os enfermeiros.

O sistema deve suportar 250 enfermeiros simultâneos em todo o país e até centenas de milhares de pacientes simultâneos no autoatendimento em todo o país.

Os enfermeiros podem acessar os prontuários dos pacientes usando a troca de prontuários, mas os pacientes não podem acessar seus próprios prontuários.

O sistema deve cumprir a lei de portabilidade e responsabilidade de convênio médico (HIPAA nos EUA) em relação aos prontuários. Isso significa que é essencial que ninguém, exceto os enfermeiros, tenha acesso aos prontuários.

O sistema deve ser capaz de lidar com surtos e alto volume durante a época de gripe e resfriados.

O roteamento das chamadas para os enfermeiros se baseia no perfil do enfermeiro (como necessidades bilíngues).

O mecanismo de diagnóstico de terceiros pode lidar com cerca de 500 requisições por segundo.

Página 297

O arquiteto do sistema criou a arquitetura de alto nível mostrada na Figura 20-9. Nessa arquitetura, há três IUs separadas baseadas na web: uma para o autoatendimento, outra para os enfermeiros que recebem as chamadas e uma terceira para os funcionários administrativos adicionarem e manterem o perfil da enfermagem e as definições da configuração. A parte do call center do sistema consiste em um receptor de chamadas que as recebe e no roteador de chamadas, que as roteia para o próximo enfermeiro disponível com base no perfil dele (note como o roteador acessa o banco de dados central para obter informações sobre o perfil do enfermeiro). No centro dessa arquitetura está o gateway da API do sistema de diagnóstico, que faz verificações de segurança e direciona a requisição para o devido serviço de back-end.

Figura 20-9. Arquitetura de alto nível para o exemplo do sistema de diagnóstico dos enfermeiros Existem quatro serviços principais nesse sistema: serviço de gerenciamento de casos, serviço de gerenciamento do perfil do enfermeiro, interface para a troca de prontuários e mecanismo externo de diagnóstico de terceiros. Todas as comunicações usam REST, com exceção dos protocolos proprietários (patenteados) para os sistemas externos e os serviços do call center.

O arquiteto examinou essa arquitetura inúmeras vezes e acredita que ela esteja pronta para a implementação. Como uma autoavaliação, estude os requisitos e o diagrama da arquitetura na Figura 20-9, e tente determinar o nível de risco nela em termos de disponibilidade, elasticidade e segurança. Após determinar o nível de risco, determine quais mudanças seriam necessárias na arquitetura para mitigar o risco. As seções a seguir contêm cenários que podem ser usados como comparação.

Disponibilidade

Durante o primeiro exercício de risk storming, o arquiteto escolheu focar a disponibilidade primeiro, uma vez que a disponibilidade do sistema é essencial para o sucesso dele. Após a identificação no risk storming e das atividades de colaboração, os participantes propuseram as seguintes áreas de risco usando a matriz de risco (como na Figura 20-10):

O uso de um BD central foi identificado como de alto risco (6) devido ao alto impacto (3) e à probabilidade média (2).

Página 298

A disponibilidade do mecanismo de diagnóstico foi identificada como de alto risco (9) devido ao alto impacto (3) e à probabilidade desconhecida (3).

A disponibilidade da troca de prontuários foi identificada como de baixo risco (2), uma vez que não é um componente requerido para o sistema rodar.

Outras partes do sistema não foram consideradas como de risco para a disponibilidade devido a várias instâncias de cada serviço e do cluster do gateway da API.

Figura 20-10. Áreas de risco da disponibilidade Durante o esforço de risk storming, todos os participantes acordaram que embora os enfermeiros possam fazer anotações de casos manualmente se o banco de dados fica inativo, o roteador de chamadas não pode funcionar se o BD não está disponível. Para mitigar o risco do banco de dados, os participantes escolheram dividir o único BD físico em dois separados: um banco de dados em cluster contendo as informações do perfil do enfermeiro e outro banco de dados com uma instância para as notas dos casos. Essa mudança de arquitetura não só lida com as questões relacionadas à disponibilidade do BD, como também ajudou a proteger as notas dos casos contra o acesso do administrativo. Uma opção para mitigar esse risco seria colocar as informações do perfil do enfermeiro em cache no roteador de chamadas. Porém, como a implementação do roteador de chamadas era desconhecida e pode ser um produto de terceiros, os participantes seguiram com a abordagem do banco de dados.

Mitigar o risco da disponibilidade dos sistemas externos (mecanismo de diagnóstico e troca de prontuários) é muito mais difícil de gerenciar devido à falta de controle desses sistemas. Um modo de mitigar esse risco é pesquisar se há um SLA (Acordo de Nível de Serviço) ou um SLO (Objetivo de Nível de Serviço) publicado para cada sistema. Um SLA costuma ser um acordo contratual e tem valor legal, já um SLO não. Com base na pesquisa, o arquiteto descobriu que o SLA para o mecanismo de diagnóstico tem garantia de estar 99,99% disponível (52,60 minutos de tempo inativo por ano) e a troca de prontuários tem a garantia de 99,9% de disponibilidade (8,77 horas de inatividade por ano). Com base no risco relativo, essas informações são suficientes para remover o risco identificado.

As mudanças correspondentes na arquitetura após essa sessão de risk storming são mostradas na Figura 20-11. Observe que dois DBs são usados agora e também SLAs são publicados no diagrama da arquitetura.