Este capítulo possui uma versão mais recente:

Nenhum homem é uma ilha isolada; …
John Done
Se nenhum homem é uma ilha, tampouco qualquer artefato de software relevante será! Afinal, todo software suporta a execução de uma ou mais atividades que são partes de um ou mais processos, sempre com etapas anteriores e posteriores que, provavelmente, por sua vez, também são suportadas por outros agentes (software ou não). De alguma forma, as informações de um software que suporta uma atividade precisam ser “levadas” para outro que suportará a próxima atividade.
1
Por favor, deixe seu feedback aquix

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.

Quanto mais relacionamentos um software possuir, maior será seu impacto e relevância no contexto onde funciona. Em termos simples, software com poucos relacionamentos costuma ser inútil ou ser importante apenas em períodos curtos e eventuais. Não é exagero dizer que qualidade “interna” de um software pouco importará se suas “integrações” falharem.
1
Você concorda com essa afirmação? Há algo a ponderar aqui?x

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)

Boa parte dos problemas em ambiente produtivo ocorrem por deficiências no tratamento de falhas de integração entre sistemas. Não raro, sistemas de e-commerce, por exemplo, apresentam instabilidades por falhas na integração com o sistema bancário que viabiliza a cobrança ou, ainda, devido a problemas para acessar o inventário.
1
Você concorda com essa afirmação? Há algo a ponderar aqui?x

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)

Por tudo isso, explicitar e tratar adequadamente a arquitetura é tarefa fundamental nas boas práticas de arquitetura de software. Aliás, o mapeamento precoce das integrações ajuda a identificar mais rapidamente os objetivos do negócio, restrições e atributos de qualidade.
0
Você concorda com essa afirmação? Há algo a ponderar aqui?x

Explicitando as relações de um software com outros

Em uma primeira análise da arquitetura de um software podemos assumir que este, em um contexto amplo, é um componente, com determinadas responsabilidades, que se relaciona com outros componentes, os demais agentes, também com responsabilidades mais ou menos delimitadas.
0
Você concorda com essa afirmação? Há algo a ponderar aqui?x


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.

Agentes externos podem operar como gatilhos para operações no software ou como fontes de dados. Outras vezes, serão “acionados” pelo sistemas que estamos analisando ou irão ser atualizados por este. Finalmente, podem ser utilitários realizando operações de alta especificidade ou complexidade tecnológica (como o envio massivo de e-mails).
0
Você concorda com essa afirmação? Há algo a ponderar aqui?x

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

Nos últimos anos, uma notação tem ganhado destaque para documentação de relacionamentos. Trata-se do modelo C4, idealizado por Simon Brown.
0
Que outras linguagens você utiliza?x

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

Ao longo dos anos, a integração entre sistemas é implementada utilizando uma das seguintes quatro abordagens:
0
Há alguma abordagem faltando?x

  1. 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.
  2. 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.
  3. 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.
  4. Mensageria, onde uma aplicação publica mensagens para um canal comum para serem processadas por outras aplicações que “escutam” ativamente o canal.

Muito embora todas as quatro abordagens resolvam essencialmente os mesmos problemas, cada uma delas tem vantagens e desvantagens. Não raro, aliás, mais de uma abordagem é empregada em um software.
0
Qual das abordagens (ou derivação) você usa com mais frequência?x

Desafios comuns em integrações

Todas as integrações tendem a enfrentar os seguintes desafios comuns:
0
Qual outro desafio você relacionax

  1. Rede não confiável e lenta – Como bem descrito pelas “oito falácias da computação distribuída”, a rede não pode ser assumida como confiável, tampouco livre de penalidades. Não é raro que aplicações que precisam ser integradas estão operando geograficamente distantes.
  2. Toda aplicação é diferente (e única) – Soluções de integração precisam transmitir informações entre sistemas escritos em linguagens de programação, plataformas operacionais e formatos diferentes. Nem sempre, essa passagem é fácil.
  3. Mudança é inevitável – Aplicações sempre mudam ao longo do tempo (aliás, esse é o grande desafio das disciplinas de engenharia). Qualquer solução de integração precisa permanecer alinhada com essas mudanças.

A lei de Hyrum

Interessante observar que, na prática, nem todas as integrações de um software nascem com a anuência do time que o desenvolve. Não raro, relacionamentos são estabelecidos com base em características não documentadas de aplicações ocasionando em dificuldades para a evolução. Essa realidade é retratada por Hyrum Wright, engenheiro da Google, em uma “lei” de engenharia de software que leva seu nome.
0
Você conhecia a lei de Hyum? Já foi 'vítima' dessa lei?x

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.

Quanto maior o número de usuários de um software, maiores são as possibilidades de clientes precisarem permanecer em versões antigas. Afinal, estes clientes poderão ter construído processos e ferramentas usando como base comportamentos do sistema que não foram preservados em versões mais novas. A consequência direta disso é o aumento dos custos da empresa desenvolvedora pela necessidade de manter suporte a versões legadas, mesmo sem gerar valor novo.
1
Você concorda com essa afirmação? Há algo a ponderar aqui?x

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?

Referências bibliográficas

BROWN, Simon. C4 Model. Disponível em: https://c4model.com/. Acesso em: 10 abr. 2021.

HOHPE, Gregor; WOOLF, Bobby. Enterprise Integration Patterns: designing, building, and deploying business solutions. Boston, Ma: Pearson Education, 2003.

MUNROE, Randall. Workflow. Disponível em: https://xkcd.com/1172/. Acesso em: 10 abr. 2021.

NYGARD, Michael T.. Release It!: design and deploy production-ready software. 2. ed. Gravenstein Highway North, Ca: Pragmatic Booksheld, 2018. 518 p.

WIKIPEDIA (org.). C4 Model. Disponível em: https://en.wikipedia.org/wiki/C4_model. Acesso em: 10 abr. 2021.

WIKIPEDIA (org.). Fallacies of distributed computing. Disponível em: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing. Acesso em: 12 abr. 2021.

WRIGHT, Hyrum. Hyrum’s Law. Disponível em: https://www.hyrumslaw.com/. Acesso em: 10 abr. 2021.

Compartilhe este capítulo:

Compartilhe:

Comentários

Participe da construção deste capítulo deixando seu comentário:

Inscrever-se
Notify of
guest
6 Comentários
Oldest
Newest Most Voted
Feedbacks interativos
Ver todos os comentários
Alexandre Junges
Alexandre Junges
2 anos atrás
Feedback no conteúdo deste capítulo Se nenhum homem é uma ilha, tampouco qualquer artefato de software relevante será! Afinal, todo software suporta a execução de…" Ler mais »

Neste ponto acho bastante relevante a questão do especialismo de certos sistemas. Assim como profissionais especialistas sabem cada vez mais sobre cada vez menos, há sistemas muito focados em determinados domínios, que acabam adicionando grande valor para os usuários.
Nosso produto, por exemplo, oferece um módulo gerencial com relatórios e painéis. Recentemente integramos com uma solução que é especialista em análise de processos e usa IA para identificar ineficiências e desvios dos processos estabelecidos. Esta integração adicionou valor ao produto, e chama atenção nas apresentações.

É um exemplo da importância de integração entre sistemas serviços como Zappier e IFTTT, que são bastante conhecidos e utilizados.

Publicamos recentemente um post relacionado a este assunto, falando da quantidade de soluções no mercado e a importância de integrar com diferentes players:
https://www.interprocess.com.br/blog/modulo-de-integracao/

Anderson Lima
Anderson Lima
2 anos atrás
Feedback no conteúdo deste capítulo Quanto mais relacionamentos um software possuir, maior será seu impacto e relevância no contexto onde funciona. Em termos simples, software…" Ler mais »

Softwares bazuca, como ERPs, não entram como contra-exemplos disso ao oferecer uma solução “completa”?

Matheus Bortolon
Matheus Bortolon
2 anos atrás
Responder para  Anderson Lima

Entendo o que quer dizer, houve um tempo onde se vendia soluções completas “de caixinha” onde um unico programa era responsável por controlar todas as operações de determinada empresa.

Diego Balduino
Diego Balduino
2 anos atrás
Feedback no conteúdo deste capítulo Quanto maior o número de usuários de um software, maiores são as possibilidades de clientes precisarem permanecer em versões antigas. Afinal,…" Ler mais »

Concordo, gostaria de complementar que a manutenção da feature é arquitetura das aplicações aumentam exponencialmente quanto maior o número de versões mantidas pelo time, chegando a ruptura de manutenção caso o número de versões seja muito grande, impossibilitando dar continuidade ao software legado

Matheus Bortolon
Matheus Bortolon
2 anos atrás

Software mais documentação deve ser mais barato que somente software.
Os artefatos de arquitetura têm responsabilidade de expressar a arquitetura e
mostrar informações que estão no código fonte bem como as que não estão no código fonte como atributos de qualidade e restrições, por exemplo.
Bons artefatos de arquitetura trazem benefícios durante a integração de novas pessoas no time, explicação de funcionalidades para outros times envolvidos e para o time de negócio também.

Tiago Ávila
Tiago Ávila
2 anos atrás
Feedback no conteúdo deste capítulo Boa parte dos problemas em ambiente produtivo ocorrem por deficiências no tratamento de falhas de integração entre sistemas. Não raro,…" Ler mais »

Com certeza! Ainda acrescento aqui documentação com poucos detalhes em relação as integrações. Já vi casos onde foi necessário entrar em contato com o suporte de empresas pra entender certos aspectos que estavam causando bugs. E há também os casos onde cenários de erro não são tratados corretamente

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mentoria

para arquitetos de software

Imersão, em grupo, supervisionada por Elemar Júnior, onde serão discutidos tópicos avançados de arquitetura de software, extraídos de cenários reais, com ênfase em systems design.

Consultoria e Assessoria em

Arquitetura de Software

EximiaCo oferece a alocação de um Arquiteto de Software em sua empresa para orientar seu time no uso das melhores práticas de arquitetura para projetar a evolução consistente de suas aplicações.

ElemarJúnior

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

+55 51 99942-0609 |  contato@eximia.co

+55 51 99942-0609  contato@eximia.co

6
0
Quero saber a sua opinião, deixe seu comentáriox
()
x