Produtos de plataforma: API é apenas uma interface!
A minha principal motivação por trás desse texto é elucidar um pouco melhor uma das possíveis visões sobre como construir plataformas de tecnologias internas, que é uma das minhas principais missões hoje aqui na RD Station.
Vou passar por alguns conceitos sobre plataformas e termino o artigo trazendo exemplos com os quais pretendo tornar o assunto um pouco mais prático e tangível.
Plataforma como modelo de negócio vs plataformas de tecnologia
O que é uma plataforma como modelo de negócios? Segundo a definição encontrada no livro Modern Monopolies (Alex Moazed e Nicholas L. Johnson), uma plataforma é um modelo de negócios que facilita a troca de valor entre dois ou mais grupos de usuários: consumidores e produtores. Para permitir que estas trocas ocorram, as plataformas criam enormes redes de usuários e recursos que podem ser acessados sob demanda. Plataformas criam comunidades e mercados que permite usuários interagir e efetuarem transações uns com os outros (tradução livre).
O livro cita como exemplos plataformas o Airbnb para aluguel de temporada, o Uber para locomoção, a Apple para aplicativos através da AppStore e o YouTube para vídeos, dentre outras.
Pensando desta maneira, podemos encontrar alguns exemplos do mundo físico como a Junta Local que, antes da pandemia, reunia pequenos produtores locais de comida para que pudessem vender direto ao público através de feiras itinerantes aqui no Rio de Janeiro (saudades das feiras, inclusive). Obviamente a Junta precisou se adaptar ao momento que estamos vivendo e lançaram a Sacola Virtual, que funciona exatamente como os marketplaces que já conhecemos. Quer dizer, a tradução de marketplace é literalmente feira… então Junta já era de fato marketplace e agora virou e-commerce 🤔 (interessante pensar sobre essa apropriação dos termos).
Eu, particularmente, não gosto do uso do termo plataforma como proposto no Modern Monopolies. Me parece que marketplace é mais apropriado, apesar de não me parecer aberto o suficiente para contemplar os modelos de negócio do Google e Facebook, por exemplo. Como não tenho uma palavra melhor, não vou me alongar na discussão. Para ser mais produtivo, vou me ater a discutir por aqui apenas os produtos considerados plataformas de tecnologia. Para quem quiser se aprofundar um pouco mais nessa discussão pode dar uma lida aqui.
Gosto de tratar as plataformas de tecnologia como um conjunto de serviços e ferramentas desenvolvidas e empacotadas com o intuito de permitir a criação de novas experiências para o usuário, novos modelos de negócio ou, até mesmo, melhoria/automação de processos. Considero bem-sucedidas as plataformas geram aquela sensação de alívio do tipo: "que bom que alguém já pensou em como resolver esse problema tecnicamente e 'só' preciso olhar para o negócio". Alguém aqui imagina ainda ter que gerenciar seus servidores em data centers a não ser que seu negócio seja esse?
Pois bem… Podemos encontrar facilmente por aí produtos com grande adoção que foram construídos para resolver um problema do mercado em geral como a AWS, Google Cloud ou Azure fizeram com IaaS (Infraestrutura como serviço), o Algolia fez com busca, a Zendesk com relacionamento com cliente dentre muitos outros. Os exemplos que citei são plataformas comerciais e que geram receita de forma direta para uma determinada empresa. No entanto, é possível replicar a mesma lógica de gerenciamento de produto utilizada no desenvolvimento de plataformas de tecnologia para mercado com o intuito de se resolver determinados problemas internos. A Netflix e o Airbnb, por exemplo, não monetizam suas plataformas de tecnologia mas as desenvolvem com a intenção de aumentar o engajamento de seus clientes ou facilitar a aquisição de novos usuários.
Mas, afinal, o que são essas plataformas? Estou falando sobre a construção de APIs internas? Não necessariamente… uma API é apenas uma das muitas possibilidades. Vamos lá…
API é apenas uma interface
Na primeira vez que ouvi falar da separação dos times de tecnologia entre aplicação e plataforma, senti algum desconforto com relação ao assunto. Investigando o que estava por trás desse estranhamento, percebi que a ideia me havia sido apresentada quase que como uma separação entre o desenvolvimento back-end e front-end. Como se um time construísse as APIs e o outro time implementasse o cliente das aplicações. Tal dissociação me pareceu na contramão do que vem sendo pregado por todo o mercado: times multifuncionais com capacidade de entregar valor para o usuário por cuidarem de um determinado tema de ponta a ponta.
Resolvi destrinchar um pouco mais o tema. Plataformas de tecnologia são, necessariamente, APIs? Não. Vamos ao significado de API: Application Programming Interface. Interface é o termo que gostaria de explorar.
API não é plataforma, API é apenas uma interface. Alguns outros tipos de interface que vieram instantaneamente na minha cabeça foram UI (User Interface) e CLI (Command Line Interface). A última certamente influenciada pela minha formação técnica 😬.
Para facilitar a vida, vou dar alguns exemplos usando referências de plataformas de tecnologia do mercado que muita gente aqui pode já estar familiarizado. Além disso, todos os formatos apresentados, são possibilidades para a construção de uma plataforma interna dependendo do problema que buscamos resolver.
Exemplos de UI (User Interface) para produtos de plataforma
O principal exemplo que gostaria de trazer (e que é um tema recorrente na minha carreira inclusive) são os whitelabels.
Whitelabels são soluções feitas para resolver um problema de ponta a ponta, desenvolvidos de forma a serem customizados visualmente para atender a mais de uma empresa. Exemplos clássicos de whitelabels são as plataformas de e-commerce como a VTEX, Shopify, Magento (código aberto). Essas soluções costumam tratar desde a camada de apresentação e usabilidade para o usuário final até a operação interna. Alguns outros exemplos de whitelabel são:
- Zendesk Guide para central de ajuda e que é apenas uma parte de toda a suíte Zendesk;
- Eventify para eventos;
- Crowdfundhq para financiamento coletivo
CMS (Content Management System) também são possíveis formatos de plataformas e podem ser whitelabel, quando resolvem a camada para o usuário final, mas também pode ser headless quando possuem a camada de administração mas entregam os dados apenas através de API para ser intepretado por outra aplicação.
Exemplos de CMS whitelabel:
- Wordpress (código aberto);
- RD Station Marketing: Landing Pages;
- Ghost CMS (código aberto).
Exemplos de CMS headless:
- Strapi (código aberto);
- Contentful.
Ainda sobre UI, podemos pensar em pedacinhos de interface muito menores do que os que citei acima. Um tema que pode iluminar um pouco a mente nesse sentido é o estudo de design atômico (ou esse vídeo aqui). Outra excelente referência é o esse conteúdo sobre micro front-end. Para entregar esses pedacinhos de plataforma, podemos pensar desde SDK (software development kit), bibliotecas ou scripts. Vamos a alguns exemplos:
Widget através SDK (software development kit) é uma das formas de entregar componentes visuais. Um passeio pela documentação do Instant Search do Algolia dá para ter uma boa noção de como eles fazem isso com busca. O Algolia também possui um SDKs para Android, iOS, além de outras linguagens e frameworks.
Embed via iframe também é uma possibilidade para entregar componentes visuais. Exemplos muito utilizados são os players do YouTube ou do Spotify como esse aqui de baixo 👇.
Tag Manager via Javascript para parecer mágica também são um clássico da web. No RD Station Marketing temos alguns exemplos no produto como o botão de WhatsApp ou os Pop-ups de saída. Esse tipo de técnica nos permite injetar funcionalidades no produto sem requerer nenhuma ação de outro time de desenvolvimento e facilitam bastante a adesão.
Exemplos de API para produtos de plataforma
As APIs podem vir acompanhadas ou não de SDKs para os clientes. Não vou me alongar muito no tema API pois é a solução mais difundida e diria até que é base para todas as outras soluções. Mesmo assim vale citar que APIs podem ter muitas formas e arquiteturas com graphQL, REST e por aí vai. Cabe um artigo (ou muito mais) só sobre design de APIs e todas as possibilidades.
A API do Twilio é uma ótima referência para mim e vale aquela pesquisa.
Exemplos de CLI para produtos de plataforma
Uma forma bem menos convencional de interface para quem não tem formação técnica são as CLIs (Command Line Interface). Uma plataforma que eu considero genial nesse sentido é o Heroku pois eles entenderam perfeitamente a persona para quem estavam construindo a solução e disponibilizaram muitas possibilidades de interfaces.
A genialidade do Heroku não está somente na sua própria CLI mas sim na apropriação de uma CLI amplamente adotada pela comunidade desenvolvedor para servir ao processo de deploy da pltaforma: a CLI do git!
A AWS também tem seu CLI que vale ficar de olho mas, na minha humilde opinião, não tem o borogodó da CLI do Heroku.
Outros exemplos
Consigo pensar em algumas outras formas de entregar uma solução de plataforma que pode ir desde scripts no Docker até Gradle/Maven Archetypes para os javeiros de plantão.
Acho que a ideia é ser criativo e pensar sempre na adesão da plataforma. Qual é a melhor forma de garantirmos que nosso cliente vá conseguir se integrar e utilizar a plataforma tecnológica que construímos? Para isso, vamos precisar entender com quem estamos falando, qual é a capacidade técnica de sua equipe, dentro outras variáveis. No próximo tópico vou enumerar algumas possíveis personas para exemplificar alguns usos.
Diferentes tipos de personas
Ao gerenciar produtos de plataforma, precisamos dar suporte a muitos tipos de personas que variam desde o desenvolvedor ao usuário final. Se nosso produto entrega um widget que pode ser customizado por outro time qualquer, precisamos ter a noção que nosso trabalho impacta diretamente no resultado para o usuário final do nosso cliente. Sendo assim, se propusermos uma solução que carrega um javascript em um site B2C do seu cliente, precisamos ter a noção que cada milissegundo no tempo de carregamento pode impactar em sua taxa de conversão e garantir que isso não acontecerá.
Nesse espectro entre desenvolvedores e usuário final, podemos encontrar pessoas de operação, marketing, comercial e até mesmo outros times de produto. Algumas perguntas que podem ajudar a garantir uma melhor adesão e engajamento com a plataforma são:
- Qual é a capacidade de implantação da minha solução pelo time técnico do meu cliente? Como consigo facilitar esse processo?
- O que é necessário para que meu cliente opere a plataforma? Se eu entregar só uma API é realmente suficiente ou preciso de algum complemento como uma área de administração/operação?
- Se eu precisar fazer alguma alteração na minha plataforma, qual é o nível de envolvimento que meu cliente vai precisar ter? Ele tem esse tipo de disponibilidade?
- Quais são os riscos que uma possível falha no meu produto trazem para o meu cliente? Como mitigar tais riscos?
- Em que ponteiros as minha plataforma ajuda a mexer do lado do meu cliente e como ele comprova isso para seus stakeholders? (Métricas de melhoria no tempo de entrega também são bem-vindas como o leadtime, por exemplo);
Elaborando boas perguntas, você pode chegar a personas de marketing super letrados em tecnologia até times de engenharia bem júniores com baixa habilidade técnica ainda. Ter esse tipo de mapeamento é fundamental para conseguir entregar uma solução eficaz para o problema que você pretende resolver.
Conclusão
Um resumão para o texto aqui pode ser:
- APIs internas ou externas não são necessariamente plataformas;
- Uma API até pode ser sim a base para a grande maioria dos produtos de plataforma mas são apenas uma das possíveis interfaces;
- Tenha em mente quem é o seu cliente e qual é seu nível de aprofundamento técnico ou disponibilidade;
- Considere os riscos, operação e manutenção na hora de pensar na solução;
Espero que o artigo seja útil de alguma forma e qualquer coisa é só chamar ;)
Deixo ainda algumas referências e outros links úteis para enriquecer mais o papo, além daquele jabá maroto: Habemus vagas!! Quer vir trabalhar com a gente? Clica aqui!
Referências e outros links:
Tem uma referência maneirona da Accenture aqui tb mas estava ficando um PDF gigante no meio do texto.
