Padrões de Plataforma #1: Consolidação

Há muita literatura excelente sobre por que você deve construir uma plataforma e o que é uma platforma, mas não encontrei um recurso que ilustre situações específicas em que você possa querer construir uma. Com isso, comecei a pensar em padrões que poderiam ajudar a identificar a necessidade de uma plataforma e o que fazer quando você se encontra nessa situação como líder de engenharia.

Pretendo escrever alguns artigos sobre diferentes padrões que vi no passado. Se você pensar em outros exemplos, entre em contato no twitter e eu escreverei sobre ele e creditarei você como contribuidor.

§O que é uma plataforma?

Para pessoas menos familiarizados com plataformas técnicas, usarei a seguinte terminologia simplificada e um conjunto de princípios que podem ajudar a entender o básico. Se você quiser se aprofundar no assunto, os artigos na introdução lhe darão mais profundidade sobre o assunto.

Terminologia
  • Equipe de aplicação é uma equipe que aproveita a plataforma técnica para um caso de uso específico, por exemplo, uma equipe construindo cobrança recorrente por meio de uma plataforma de pagamentos;
  • Equipe da plataforma é a equipe que opera e mantém a plataforma técnica alavancada pelas equipes de aplicação, por exemplo, a equipe da plataforma de pagamentos;
  • Capability é um pedaço de software que fornece à empresa e ao usuário a capacidade de fazer algo, por exemplo, "cobrar um cartão de crédito" é um recurso da plataforma de pagamentos, assim como "reembolsar uma transação com cartão".
Princípios
  1. Uma plataforma é self-serve para a maioria dos casos de uso. Não apenas do ponto de vista técnico – o que significa excelente documentação, experiência do desenvolvedor etc. – mas também do ponto de vista de pessoas e processos. O modelo de coordenação de self-serve do Jade Rubick ilustra em detalhes o que quero dizer.
  2. Uma plataforma é extensível para casos de uso aos quais ela não oferece suporte. As equipes de aplicação podem aproveitar a plataforma como blocos de construção em vez de uma caixa preta para criar e dar suporte às suas próprias necessidades. Por exemplo, estender uma plataforma de pagamentos para suportar cobrança recorrente por uma equipe de aplicação pode ser fácil se ela tiver um recurso de "armazenar cartões" e suportar "cobrar um cartão de crédito".
  3. Uma plataforma opera de forma semelhante a um terceiro para os casos de uso. Toda a complexidade na manutenção do domínio da plataforma é abstraída da equipe do aplicativo. Prevenção de abuso, segurança, conformidade e fornecedores terceirizados são bons exemplos da complexidade que uma plataforma deve abstrair.

A seguinte citação que tirei deste artigo escrita por Evan Bottcher no blog de Martin Fowler ilustra muito bem o conceito:

"Uma plataforma digital é uma base de APIs self-serve, ferramentas, serviços, conhecimento e suporte que são organizados como um produto interno atraente. Equipes de entrega autônomas podem usar a plataforma para fornecer recursos do produto em um ritmo mais rápido, com coordenação reduzida."

Com esta cartilha rápida sobre plataformas técnicas, aqui está uma história fictícia que exemplifica o que quero dizer com o padrão de "consolidação".

§Uma história e o problema

A Acme corp iniciou seus negócios atendendo apenas clientes empresariais. Além de construir um ótimo produto, eles também tinham uma equipe de engenharia de software cujo objetivo era onboarding de empresas. Além de projetar a experiência, a equipe de onboarding de empresas desenvolveu algumas funcionalidades básicas para:

  • Verificações de autenticidade através de um número de identificação fiscal (CNPJ) para garantir que as empresas clientes estão legalmente registradas;
  • Verificações de compliance para prevenção de lavagem de dinheiro, por motivos de compliance, segurança e qualidade;
  • Verificação de informações de contato para garantir que qualquer empresa cliente possa ser contatada por qualquer motivo;
  • E, como parte do fluxo de onboarding, era necessário um cartão de crédito, que seria cobrado após o término do trial do produto.

Product-market fit veio muito rápido para a Acme, devido ao seu produto inovador. Consequentemente, suas ambições se ampliaram e a liderança da Acme anunciou uma nova estratégia para apoiar os consumidores sem um negócio jurídico, com um conjunto diferente de recursos. Para fazer isso, eles contrataram outra equipe para construir o onboarding de consumidores finais. Com a crescente pressão dos investidores para atingir as metas, fazia sentido que a equipe de onboarding de consumidores desenvolvesse seu próprio conjunto de sistemas. Nessa fase, para evitar contas falsas, bastava enviar um e-mail para confirmar o endereço de e-mail do consumidor.

Ao longo de alguns meses, o lado de consumidores finais do negócio também cresceu consideravelmente. A Acme viu outra oportunidade de cobrar um subconjunto de consumidores para um plano de seu produto comercial. A equipe de onboarding de consumidores implementou rapidamente o recurso, que foi uma excelente vitória. No entanto, alguns meses após o lançamento, alguns problemas vieram à tona:

  • Trials entre os perfis do consumidor e do negócio eram inconsistentes, e gerenciar diferentes durações de ciclos criava muita sobrecarga para a equipe financeira;
  • Dado que a integração do consumidor e da empresa usou fornecedores de pagamento diferentes, o mesmo cartão de crédito que funcionaria em uma conta comercial não funcionaria em uma conta de consumidor;
  • Como ambos os produtos foram construídos de forma independente, a linguagem para se referir ao domínio variou entre consumidores e empresas, e às vezes era até conflitante;
  • À medida que a Acme se expandiu para novos mercados, as equipes de consumidores e empresas tiveram que adicionar novos tipos de pagamento, novas verificações de conformidade e suporte para novas moedas.

§Sintomas

Normalmente, existem alguns sintomas que antecedem a necessidade de aplicar o padrão de consolidação:

  1. Tecnologia fragmentada para um recurso. Especialmente quando você está experimentando um novo produto, o excesso de indexação na coesão geralmente é uma má ideia, pois você mal sabe se o produto será bem-sucedido. Na anedota acima, quando a equipe de liderança de engenharia formou a equipe de onboarding de consumidores finais, receber um pagamento estava fora do escopo, então provavelmente foi a decisão certa construir um novo conjunto de sistemas. Embora, à medida que o escopo aumentou, a empresa acabou com sistemas duplicados para muitos recursos, como "receber um pagamento", "executar verificações de conformidade", "gerenciar trials".
  2. Duplicação de trabalho ou dependências indiretas similares. Na anedota, ao expandir para novos mercados, as equipes de integração de consumidores e empresas dependeriam de uma "equipe de gerenciamento de usuários" para adicionar um campo "país" ao modelo de usuário para selecionar qual moeda usar ao fazer um pagamento. Podemos abstrair isso como mais de uma equipe tendo que fazer uma implementação muito semelhante ou às vezes o mesmo trabalho, ou duas equipes tendo dependências indiretas pelas mesmas razões para as mesmas partes.
  3. Linguagem quebrada em toda a empresa. No exemplo acima, referir-se a "trial de produto" ou "verificações de conformidade" é muito ambíguo, pois você pode estar se referindo a coisas muito diferentes dependendo de com quem você fala. Para pessoas familiarizadas com o livro Domain-Driven Design, o capítulo Ubiquitous Language vem à mente aqui.

§Uma solução para o problema

Um exemplo de um caminho a seguir para equipes em tal situação é usar o modelo "aplicação/platforma" e dividir a responsabilidade em três áreas:

  • Onboarding de consumidores, que foca na experiência do onboarding do consumidor e qualquer coisa específica do lado do consumidor;
  • Onboarding de empresas, com foco na experiência do negócio e suas especificidades;
  • Plataforma de onboarding, que consolida em uma plataforma os recursos utilizadas por ambas as equipes de onboarding. Bons exemplos de recursos nesta equipe de plataforma podem ser "receber pagamentos", "gerenciar testes", "executar verificações de conformidade", que podem ser configurados ou estendidos a diferentes casos de uso;

E aqui está um detalhamento de um passo a passo para testar a mudança e ver se faz sentido para o seu caso:

  1. Forme uma equipe virtual com representação de ambas as equipes. Este grupo de pessoas será responsável por colocar juntos um plano de ação e testar a hipótese. Além de trabalhar em um roadmap compartilhado, recomendo analisar SLAs por caso de uso, nível de extensibilidade necessário por equipe e priorizar casos futuros na nova plataforma com a contribuição de ambas as equipes. Você pode descobrir que talvez possa viver com a duplicação por mais algum tempo, ou até mesmo concluir que uma plataforma não é o ajuste certo;
  2. Desenvolva capacidade para consolidar recursos Se esse for o caminho a seguir, em vez de fazer uma migração big bang ou reescrever tudo do zero, puxe um recurso de cada vez dos sistemas anteriores para a nova plataforma. Uma maneira de priorizar são os casos de uso que são os maiores pontos problemáticos tanto para as equipes quanto para o negócio, e também quais são os maiores gargalos para o negócio;
  3. Eventualmente, forme uma nova equipe, de preferência com alguma representatividade das equipes existentes, e adote o modelo de aplicação/plataforma.

E para encerrar, veja como fazer isso resolve os sintomas mencionados acima:

  1. A tecnologia fragmentada não é mais um problema, pois, por design, os recursos compartilhados estão em uma única equipe;
  2. Idealmente, a maior parte do trabalho deve ficar com a equipe da plataforma ao adicionar um novo tipo de pagamento, cumprir uma nova regra de compliance ou adicionar um novo tipo de trial;
  3. O novo limite organizacional na equipe da plataforma pode ser uma função forçante para a correção da linguagem, mesmo que ainda seja necessario um esforço consciente da equipe da plataforma.

Agradecimentos especiais a David Golden por seus comentários sobre uma versão anterior deste artigo.

Gostou deste post? Compartilhe: email/linkedin/twitter/whatsapp