A relação de um software com artefatos externos é, ao mesmo tempo, a expressão de sua utilidade e a principal fonte de problemas em ambiente produtivo.
Aplicativos interessantes raramente operam isolados. Quer seu aplicativo de vendas deva interagir com seu aplicativo de estoque, seu aplicativo de compras deva se conectar a um site de leilão ou seu PDA precise sincronizar com o servidor de calendário corporativo, parece que qualquer aplicativo pode ser melhor integrando-o com outros aplicativos. (HOHPE; WOOLF, 2003)
O acoplamento forte permite que as “rachaduras” em uma parte do sistema se propaguem – ou se multipliquem – através das camadas ou limites do subsistema. Uma falha em um componente faz com que a carga seja redistribuída para seus pares e introduz atrasos e estresse para seus chamadores. Esse aumento de estresse torna extremamente provável que outro componente do sistema falhe. Isso, por sua vez, torna a próxima falha mais provável, resultando eventualmente em colapso total. (Nygard)
Explicitando as relações de um software com outros
O propósito dessa análise é revelar quem são as “pessoas” (usuários, agentes, papéis ou personas) e outros artefatos de software (dependências externas) que estão diretamente conectadas com o software que estamos analisando. Geralmente, estes outros sistemas estão fora do escopo primário.
Embora esta seja seja uma análise muito simples, na prática, sua execução tem se relevando útil e desafiadora. Por incrível que pareça, é difícil para as organizações relacionar quais são os principais “acionadores” e “acionados” para os diversos sistemas. Também costuma ser bem difícil criar uma descrição sucinta sobre o que um sistema faz ou deveria fazer.
Representando relacionamentos usando o modelo C4
O modelo C4 é uma técnica de notação gráfica enxuta para modelar a arquitetura de sistemas de software. É baseado em uma decomposição estrutural de um sistema em contêineres e componentes e depende de técnicas de modelagem existentes, como a Unified Modeling Language (UML) ou Entity Relation Diagrams (ERD) para a decomposição mais detalhada dos blocos de construção arquitetônicos. (Wikipedia)
O nível mais alto de abstração proposto pelo modelo C4 propõe a elaboração de diagramas de contexto, muito semelhantes ao que indicamos aqui. Já no segundo nível, o diagrama de contêineres, “explode” o sistema que sendo analisado para revelar sua estrutura.
Depois de entender como seu sistema se encaixa no ambiente geral de TI, uma próxima etapa realmente útil é ampliar o limite do sistema com um diagrama de contêiner. Um “contêiner” é algo como um aplicativo da web do lado do servidor, aplicativo de página única, aplicativo de desktop, aplicativo móvel, esquema de banco de dados, sistema de arquivos, etc. Essencialmente, um contêiner é uma unidade executável/implementável separadamente (por exemplo, um espaço de processo separado) que executa código ou armazena dados.
O diagrama do contêineres mostra a forma de alto nível da arquitetura do software e como as responsabilidades são distribuídas por ela. Também mostra as principais opções de tecnologia e como os contêineres se comunicam. É um diagrama simples e focado em tecnologia de alto nível, útil para desenvolvedores de software e equipes de suporte/operações. (Simon Brown)
A elaboração do diagrama de contêineres não é tarefa trivial.
Em sistemas muito grandes, ou legados, é comum que não seja evidente a responsabilidade de cada contêiner (indicando claro acoplamento). Em sistemas novos ou em desenvolvimento, há uma tendência de simplificar em demasia os contêineres.
O maior ganho que tenho percebido na elaboração desse diagrama está na explicitação da complexidade dos sistemas, geralmente causada por um projeto descuidado ou pela evolução descontrolada. Para sistemas novos, esse diagrama antecipa discussões que ficariam relegadas a momentos posteriores e que, se feitas no momento certo, poderiam evitar dores de cabeça.
Principais abordagens para integração entre aplicações
- Troca de arquivos – Onde uma ou mais aplicações escrevem arquivos em um determinado formato que serão, posteriormente, processados por outra. Além do formato, é necessário estabelecer regras para como nomear os arquivos e onde estes devem ser salvos.
- Banco de dados compartilhado – com múltiplas aplicações compartilhando um mesmo esquema, localizado em um único banco. Não há, de fato, duplicação de dados e tampouco transferências.
- RPC, onde uma aplicação expõe algumas de suas funcionalidades, geralmente através de serviços e protocolos abertos, de forma que estas possam ser acessadas por outra aplicação. A comunicação é geralmente síncrona.
- Mensageria, onde uma aplicação publica mensagens para um canal comum para serem processadas por outras aplicações que “escutam” ativamente o canal.
A lei de Hyrum
Com um número suficiente de usuários, não importa o que estiver acertado em contrato: todos os comportamentos observáveis de um sistema serão premissas para funcionamento de outros artefatos. (Hyrum Wright)
Tal realidade é tão frequente que foi “piada” no xkcd.
Detalhes técnicos de implementação como tempos de resposta, ordenação em resultados, esquemas de bancos de dados, mecanismos de persistência e, até mesmo, detalhes de infraestrutura de uma aplicação servem, invariavelmente, como fundamento para desenvolvimento de processos e outros sistemas.
Esquemas de banco de dados, por exemplo, mesmo que oficialmente privados e restritos aos times técnicos da organização desenvolvedora, são frequentemente utilizados para desenvolvimento de mecanismos de integração.
Toda grande jornada tem um primeiro passo…
As decisões de design que se relacionam com a arquitetura garantem o atendimento dos objetivos do negócio, respeitando restrições e atingindo atributos de qualidade. Não raro, todos estes elementos tem relação direta com os relacionamentos do software que está sendo arquitetado no ambiente que irá operar.
Quanto antes os responsáveis pela elaboração da arquitetura desenvolverem familiaridade com as integrações que irão ser suportadas, maiores as chances de sucesso! Por isso, a recomendação é explicitar essas integrações no início do esforço de desenvolvimento. Além disso, garantir que os artefatos de documentação gerados se mantenham atualizados.
Explicitar as integrações do software são uma boa forma de integrar novos desenvolvedores ao time de trabalho.
// TODO
Antes de avançar para o próximo capítulo recomendo as seguintes atividades:
- Utilizando o modelo C4, desenvolva representações do software que está desenvolvendo nos níveis de contexto e contêiner.
- Pondere sobre quais abordagens de integração estão sendo utilizadas atualmente. Quais as “dores” percebidas nas escolhas feitas?
- Reflita sobre a lei de Hyrum e o software que está desenvolvendo. Há indícios de integrações desenvolvidas “apesar” das especificações?
Não é incomun quando processos manuais passam a fazer parte da “integração automatica” por deficiêcnias no tratamento de falhas, onde alguém fica olhando a tela para clicar em um botão “Tentar novamente”.
Particularmente, gosto muito do modelo C4 e tenho utilizado.
Principalmente pelos niveis de visão, auxilia muito no entendimento e alinhamento da equipe. Quando novas pessoas entram no time começo explicando o contexto por esses diagramas, rapidamente é possivel diferenciar as fronteiras importantes da solução, relacionamentos e funcionalidades.
Pessoas de negócio também conseguem entender de forma geral os 2 primeiros níveis do diagrama.
Se a empresa cliente possui um setor de TI, integrações não oficiais serão feitas.
Para quem fornece o software deve-se tomar cuidado para que cada cliente não acabe tendo uma versão ramificada diferente, com customizações específicas solicitadas. Já presenciei senários que a manutenção ao longo do tempo passa a ser muito dolorosa, pois seu sistema agora passou a ser 34(?) sistemas diferentes. Podendo chegar ao absurdo de haver diferentes formas de integrações (não propositais) entre sistemas iguais, porém em ambientes(clientes) diferentes.