Arquitetura de soluções é também sobre contexto

Para os arquitetos que desenham soluções complexas, um conjunto de requisitos bem documentado nunca deve servir como base exclusiva de uma arquitetura. Arquitetos precisam entender por que alguns requisitos específicos são relevantes para as partes interessadas e provavelmente terão que perguntar "por que?" mais de uma vez para entender as necessidades reais das partes interessadas, de modo a projetar uma arquitetura que melhor atenda às necessidades e aos objetivos por trás deles. Ao conversar com arquitetos sobre suas atribuições, muitas vezes sintetizo esse princípio como "Arquitetura de soluções também é sobre contexto".

A importância do contexto

Por que é tão importante que os arquitetos entendam o contexto, da forma mais ampla possível, de uma solução?

Ao considerarmos a arquitetura como um conjunto de decisões de design, uma boa medida do significado arquitetural de uma decisão é o impacto econômico dessa decisão sobre as partes interessadas que serão afetadas por ela (ver RCDA: Arquitetura como disciplina de Gerenciamento de Riscos e Custos). Desta forma, para que os arquitetos entendam o significado de suas decisões, eles precisam ter uma compreensão firme do contexto econômico da solução que estão arquitetando.

Um segundo motivo pelo qual arquitetos precisam entender o contexto e os antecedentes é porque os requisitos (especialmente os requisitos não funcionais ou requisitos de qualidade) geralmente causam conflitos nas decisões de design: por exemplo, disponibilizar determinados dados da empresa em um aplicativo móvel pode ser bom para produtividade, mas ruim para segurança. Arquitetos só podem fazer esses tipos de trade-offs se eles não só conhecerem adequadamente os requisitos, mas também se compreenderem completamente as diretivas de negócios e tecnologia por trás deles. Pedir às partes interessadas priorizar os requisitos não funcionais, não necessariamente ajuda, uma vez que esta ação rapidamente se torna um exercício sem sentido se for feito separado do design - leia mais em Problemas relacionados com requisitos não funcionais por meio de divisão contratual.

Os interesses em um contexto

Soluções complexas possuem muitos tipos de partes interessadas, cada um com os seus próprios interesses e necessidades, que contribuem com o contexto total de uma solução. Quando focamos nos impactos econômicos, a primeira coisa que vem a mente é o contexto do negócio definido segundo a visão das partes interessadas, que são quem pagam pelos benefícios tangíveis da solução. O significado arquitetural, no geral, é determinado por um amplo conjunto de interesses das partes interessadas. Como exemplo, temos as entregas operacionais das partes interessadas, para os quais precisamos entender a tecnologia que será utilizada assim como o contexto do projeto ou versão e o público que será afetado em termos de proteção, segurança e privacidade da solução.

Compreendendo o contexto

O que arquitetos podem fazer para melhorar a sua compreensão com relação ao contexto de uma solução, assim como o que podem melhorar no design de arquiteturas que atendam aos anseios e necessidades subjacentes das partes interessadas?

• Converse com as partes interessadas: Arquitetos que conversam com as partes interessadas têm um melhor entendimento do contexto de um problema - não tenha medo de bater em uma porta que já esteja aberta. Vá em frente e converse. Ainda me deparo com arquitetos que são tão focados na documentação, ou em um grupo específico de partes interessadas, que eles simplesmente esquecem de interagir com o restante dos interessados no projeto. Isso ocorre em ambos os sentidos: estar exclusivamente focado apenas nas partes interessadas que possuem conhecimento técnico ("Arquitetos devem codificar!") é tão ruim quanto apenas estar interessado apenas no lado do "negócio" das coisas. Certifique-se de falar a linguagem de suas partes interessadas - assista a apresentação de Jochem Schulenklopper na conferência SATURN 2015 Por que eles simplesmente não entendem, caso queira aprender mais sobre este assunto. Sem realmente conversar com as partes interessadas, minhas outras duas dicas: modelagem de contexto e rastreamento de decisões para um determinado contexto, perdem a maior parte do seu valor.
• Modelagem de contexto: A modelagem do contexto de um sistema faz parte das metodologias de projetos de software desde os primórdios. Nos anos 70, o método de design estruturado de Yourdon envolvia um diagrama de contexto, o qual mostrava os sistemas externos, assim como os usuários que interagiam com um sistema - uma das muitas técnicas ainda consideradas essenciais (incluindo por mim) para esclarecer e identificar as fronteiras de uma solução assim como suas dependências externas. Na verdade, o primeiro C no modelo C4 de Simon Brown significa Contexto, representado apenas por um diagrama de contexto. Diagramas de caso de uso em UML desempenham um papel similar (de forma um pouco menos autoexplicativa). Michael A. Jackson em seu livro Problem Frames dá um passo a frente modelando não apenas os contextos físicos e lógicos de um sistema, mas também o contexto mais amplo necessário para entender o problema de design a ser resolvido.
• Rastreie as decisões para um determinado contexto: Uma vez que compreendemos todo o contexto da solução para o problema que estamos arquitetando, é fundamental que registremos o impacto desse entendimento na arquitetura. O lugar perfeito para fazer esta ação é em uma seção "racional" do registro de decisão arquitetural. Nesta seção mostramos que as decisões são baseadas em algo do mundo real, que há preocupações reais, objetivos ou outros fatores elencados pelas partes interessadas e que foram considerados. Esta ação não só ajuda a conseguir o comprometimento das partes interessadas para a decisão, mas também traz grandes benefícios caso o contexto seja alterado (ou devo dizer "quando o contexto muda", porque geralmente é isso que acontece). Caso seja necessário revisar uma decisão arquitetural, conhecer o contexto completo e a lógica utilizada para a decisão inicial faz com que a reapreciação dos trade-offs seja muito mais fácil. Colocando esta ação em termos econômicos, o rastreamento das decisões arquiteturais e seu contexto reduz o custo da mudança - tornando sua arquitetura mais ágil.

A figura a abaixo ilustra um exemplo de um diagrama de contexto para um sistema.

Exemplo de um diagrama de contexto para um sistema.

Conclusão

O contexto é fundamental em uma decisão arquitetural, e existem várias maneiras pelas quais arquitetos podem melhorar sua compreensão a respeito de um contexto e seu impacto. A dica mais importante é conversar com as partes interessadas e continuar perguntando "por quê?" até que todas as suas dúvidas sejam esclarecidas.

Qual é a sua opinião sobre este tema? Você sempre desenha um diagrama de contexto? Qual o contexto que você coloca em seus registros de decisão arquitetural?

Sobre o Autor