Upgrade to Pro — share decks privately, control downloads, hide ads and more …

O time, a comunicação e a arquitetura. É realm...

Marcelio Leal
September 15, 2020

O time, a comunicação e a arquitetura. É realmente você quem define sua arquitetura?

Arquiteturas modernas e microserviços têm ajudado empresas a mudarem mercados inteiros. É nesse contexto que cada vez mais organizações entendem que não há mais espaço para a escolha entre a otimização de estabilidade ou de velocidade. Como diz Matthew Skelton no livro Team Topologies: “Organizações modernas de tecnologia devem operar e entregar sistemas rapidamente e de forma segura, enquanto simultaneamente crescem e se adaptam as mudanças e pressões de negócio”. Porém, não são só os requisitos funcionais ou não-funcionais que definem a arquitetura, fatores como comunicação, estrutura e time têm tanto ou mais influência nessa definição, como a lei de Conway já postulava desde de 1967. Esta palestra passa por fatores teóricos e práticos que vão influênciar diretamente na construção de arquiteturas de alto nível, trazendo diferentes abordagens que podem enriquecer o conjunto de ferramentas de times técnicos.

Marcelio Leal

September 15, 2020
Tweet

Other Decks in Technology

Transcript

  1. O TIME, A COMUNICAÇÃO E A ARQUITETURA. É REALMENTE VOCÊ

    QUEM DEFINE SUA ARQUITETURA? MARCELIO LEAL MICROSERVIÇOS E MACRONEGÓCIOS: DESENVOLVIMENTO E INFRAESTRUTURA NA TRANSFORMAÇÃO DIGITAL HTTPS://MSMN.COM.BR/ 
 OUTUBRO 2020
  2. EMPRESAS VÊM MUDANDO MERCADOS INTEIROS COM TECNOLOGIA E TUDO ACONTECEU

    MUITO RÁPIDO... Microserviços AWS XP DevOps Lean Startups Apps "Modelo Spotify" OKR Scrum Kanban Docker Kubernetes
  3. •De 80 para 385 empregados em 14 meses (Fev 2016)

    •1.664 Empregados (Abril 2019)
  4. NÃO SÓ AS EMPRESAS DE TECNOLOGIA TÊM CRESCIDO RÁPIDO, MAS

    TAMBÉM A EXPECTATIVA É QUE ELAS SEJAM AINDA MAIS CONFIÁVEIS QUE OS DINOS. Não há mais espaço para o famoso: "O sistema tá foda do ar senhor. Posso estar colaborando com algo mais?"
  5. MATTHEW SKELTON & MANUEL PAIS - TEAM TOPOLOGIES "ORGANIZAÇÕES MODERNAS

    DE TECNOLOGIA DEVEM OPERAR E ENTREGAR SISTEMAS RAPIDAMENTE E DE FORMA SEGURA, ENQUANTO SIMULTANEAMENTE CRESCEM E SE ADAPTAM AS MUDANÇAS E PRESSÕES DE NEGÓCIO"
  6. ENFIM... • Não há mais espaço pra ser lento •

    O mercado e outros aspectos mudam muito rápido (instabilidade e incerteza) • A exigência de estabilidade e confiabilidade aumentou Essas mudanças levaram à uma mudança de valores também!
  7. METABOLISMO • Metabolismo é o conjunto de reações químicas que

    acontecem em organismos vivos para manter a vida. • Em organismos e startups, manter o metabolismo é um ato equilíbrio constante. • Se mover muito rapidamente pode resultar em instabilidade, afetando os usuários e o time. • Se mover muito lentamente você pode matar a boa vontade dos seus usuários e ser atropelado pela concorrência.
  8. ANTIFRAGILIDADE É A PROPRIEDADE DE UM SISTEMA QUE CRESCE EM

    CAPACIDADE DE PROSPERAR COMO UM RESULTADO DE ESTRESSORES, VOLATILIDADE, RUÍDOS, ERROS, FALHAS E ATAQUES, ENTRE OUTROS. — NASSIM TALEB
  9. ORGANIZAÇÕES QUE PROJETAM SISTEMAS ESTÃO LIMITADAS A PROJETAR ARQUITETURAS CUJA

    ESTRUTURA É A CÓPIA DE SUAS ESTRUTURAS DE COMUNICAÇÃO. — LEI DE CONWAY (MELVIN E. CONWAY)
  10. IMPACTOS • Ponto único de falha • Muita informação concentrada

    em um time (DBA) • Perda de accountability • DBAs assumem erros de outros times • Criação de gargalo Fica difícil ser robusto nesse contexto, e muito mais difícil ser antifrágil!
  11. PROJETE A ESTRUTURA DA ORGANIZAÇÃO PARA PRODUZIR A ARQUITETURA DE

    SOFTWARE ADEQUADA MANOBRA REVERSA DE CONWAY
  12. YOU BUILD IT, YOU RUN IT. “Giving developers operational responsibilities

    has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.” Werner Vogels, Amazon CTO, 2006
  13. IMPACTOS • Permite accountability (pele em jogo) • Você constrói,

    você mantem • Informação distribuída • Minimiza gargalos • Permite mais autonomia
  14. Spotinik Faisse SoundNuvem TiquiToqui 1. Na próxima release, nós vamos

    mudar a API e o modelo que retornamos 2. Nós iremos descontinuar o evento que geramos. Vamos substituir por um novo. 3. Nós iremos mudar para REST o Webservice na próxima semana COMUNICAÇÃO E RELAÇÃO ENTRE TIMES WS
  15. 1. Nós vamos mudar a API e o modelo que

    retornamos na próxima release 2. Nós iremos descontinuar o evento que geramos. Vamos substituir por um novo. 3. Nós iremos mudar para REST o Webservice na próxima semana 1. Beleza! Manda a documentação aí! 2. Meu patrão, não temos nem orçamento e nem capacidade pra realizar essa adaptação 3. Esses caras são malucos! COMUNICAÇÃO E RELAÇÃO ENTRE TIMES Spotinik Faisse SoundNuvem TiquiToqui WS
  16. DOMAIN-DRIVEN DESIGN CONTEM ASPECTOS SOCIOTÉCNICOS QUE PODEM HABILITAR QUE TIMES

    SEJAM AUTÔNOMOS E ENTREGUEM VALORES DE FORMA VELOZ A PARTIR DA DESCENTRALIZAÇÃO DA GOVERNANÇA. Michael Plöd
  17. MAPA DE CONTEXTOS • Ferramenta estratégica que mostra as relações

    de time e as relações de integrações. • Visão holística sobre o acoplamento dos contextos https://medium.com/@fabio.delgado2
  18. DEPENDÊNCIAS ENTRE TIMES 1. Mutualmente dependentes - Dois artefatos de

    software precisam ser entregues em conjunto para que se tenha sucesso. 2. Independentes - Mudanças em um contexto não influenciam para o sucesso ou falha em outros contextos. 3. Upstream/Downstream - O contexto de upstream influencia o de downstream. O inverso pode não ser verdadeiro.
  19. CLIENTE-FORNECEDOR (UPSTREAM-DOWNSTREAM) Um Cliente (Downstream) consome serviços de um Fornecedor

    (Upstream). • O Cliente pode solicitar mudanças para o Fornecedor • Normalmente, o fornecedor (Upstream) define quando e como as mudanças serão aplicadas Empréstimos Sistema Legado U D
  20. Sistema Legado (BBoM) BIG BALL OF MUD (MACARRONADA) Um sistema

    ou uma parte dele que é uma "bagunça" o qual tem modelos mal definidos e fronteiras inconsistentes. • Problemas com a carga cognitiva • Problemas com accountability
  21. Emprestimos CAMADA ANTICORRUPÇÃO (ANTICORRUPTION LAYER - ACL) O Anticorruption Layer

    traduz um modelo para outro. • Transforma um modelo externo em um outro que é usado internamente • Reduz o acoplamento à uma camada • O time que implementa o ACL é sempre o Downstream • Permite que os contextos usem linguagens diferentes ACL Sistema Legado (BBoM) U D
  22. OPEN-HOST SERVICE (OHS) Open-Host Service é uma API pública. •

    Uma API para vários consumidores • O time que provem o OHS é o Upstream Sistema Legado (BBoM) Emprestimos U D ACL Serasa U D OHS Alguel de Imóveis D ACL
  23. PARCERIA (PARTNERSHIP) Um objetivo em comum e você vai colaborar

    intensamente para entregar algo em conjunto. • É uma relação organizacional • É muito comum no início de um projeto • Envolve colaboração intensa • Deve ser descontinuada quando possível/fizer sentido • Recomendada para times que usam um kernel compartilhado Sistema Legado (BBoM) Emprestimos U D ACL Serasa U D Score de Crédito ACL OHS
  24. CONFORMISTA • Não há transformação do modelo • Replica a

    linguagem para o downstream • Simplicidade Sistema Legado (BBoM) Emprestimos U D ACL Serasa U D Score de Crédito CF OHS
  25. OS PADRÕES • Big Ball of Mud • Mutualmente Dependentes

    • Parceria • Shared Kernel • Upstream-downstream • Open-host Service • Cliente-fornecedor • Camada anticorrupção • Conformista • Independentes • Published Language • Separated ways
  26. CARGA COGNITIVA • Intrínseca - Por exemplo, como desenvolver as

    funções em Clojure. • Estranha/Extrínseca (Irrelevante) - Por exemplo, como fazer um deploy, ou como funciona o CI/CD. • Pertinente (Relevante) - Por exemplo, informações de negócio necessária para a solução. Quantidade total de esforço total sendo usada na memória de trabalho. Sweller, 1988
  27. FATORES QUE PODEM AUMENTAR A CARGA COGNITIVA DEMANDAS E INSTABILIDADES

    DO NEGÓCIO PADRÕES DE COMUNICAÇÃO E DEPENDÊNCIA ENTRE TIMES MUITA VONTADE, POUCA TÉCNICA CARGA COGNITIVA ALTA, DIMINUI O METABOLISMO
  28. RECOMENDAÇÕES https://teamtopologies.com/ https://leanpub.com/ddd-by-example Domain-Driven Design: uma visão geral - Eriksen

    Costa https://www.youtube.com/watch?v=QxRXB1B9m8E https://www.fooledbyrandomness.com/
  29. REFERÊNCIAS • Context Maps - a deep dive - Michael

    Plöd • Team Topologies • DevOps Topologies • Spring Cloud Event Sourcing Example • DDD (Domain Driven Design) aplicado ao e-commerce - Nelson Senna • DDD uma abordagem prática - Fábio Delgado • Why Product Metabolism Is Every Startup’s First KPI • Visualizing Context Maps • Why Product Metabolism Every Startups First KPI • Sprint Cloud Event Sourcing Example
  30. OUTRAS REFERÊNCIAS & IMAGENS • Mercedes - https://i2.wp.com/c.ndtvimg.com/2020-06/k0t5pv48_2020-mercedesamg-f1-car-old-colours_625x300_29_June_20.jpg?resize=1400%2C9999&ssl=1 • Go

    Horse - https://gohorseprocess.com.br/wp-content/uploads/2017/05/horse21.png • RUP - https://www.uberdan.com.br/wp-content/uploads/2017/11/rup.jpg • Jeep • Startups Valuated 1BI - https://cbi-blog.s3.amazonaws.com/blog/wp-content/uploads/2017/01/crowded-club-draft-2.png • Empregados das big techs - https://fntalk.com/tech/amazon-is-responsible-for-most-big-tech-job-growth-since-2000/ • Spotify Number of Emp - https://www.statista.com/statistics/245130/number-of-spotify-employees/ • https://www.macrumors.com/2020/07/10/facebook-sdk-ios-apps-crash/ • https://canaltech.com.br/apps/em-pleno-dia-dos-namorados-ifood-apresenta-instabilidades-166410/ • https://br.financas.yahoo.com/noticias/apps-transporte-e-entrega-sofrem-233000853.html • https://www.theverge.com/2020/5/7/21250689/facebook-sdk-bug-ios-app-crash-apple-spotify-venmo-tiktok-tinder • https://www.atlassian.com/incident-management/devops/you-built-it-you-run-it • https://www2.unifap.br/claudiomarcio/files/2014/09/Aula-sobre-Organograma.pdf • https://twitter.com/kennybastani/status/761022769265909760/photo/1 • https://i.pinimg.com/originals/ee/66/14/ee661497db2a4ccaa385396f898fb6bb.jpg • https://i.pinimg.com/originals/dc/14/15/dc14159ecb45fd2615b3de2646d3d6f3.png • https://medium.com/it-dead-inside/domain-driven-design-when-is-a-bounded-context-no-longer-a-bounded-context-80e941cde79f