Tag: Arquitetura de Software

10 Tipos de Plataformas Digitais

Destaque

Ao definir uma estratégia de negócio de plataforma ou criar uma plataforma digital, é essencial entender as entidades envolvidas no seu ecossistema e a sua forma de monetização. Nesse post veremos os tipos de plataformas e suas entidades. As formas de monetização ficaram para um próximo post.

Entidades envolvidas em um ecossistema de plataforma

Primeiramente entenda que vc é o fornecedor da plataforma dentro de um ecossistema que a plataforma está inserida. Existem dois tipos básicos de entidades que são usuários da plataforma e outras entidades complementares. Por exemplo, um designer que lança uma nova roupa é um produtor e a pessoa que compra as roupas é um consumidor. O motociclista que entrega a roupa e uma entidade complementar.

  • Fornecedor da plataforma
    • Orquestra a co-criação de valor
    • Gerência a governança da plataforma
  • Produtores
    • Dono dos ativos
    • Provedor de serviços
  • Consumidores
    • Usuários dos ativos e serviços da plataforma
  • Complementares
    • Fornecem serviços que agregam valor aos serviços principais
  • Outros atores, Incumbentes, Sociedade, Reguladores, Criadores de politicas

Parece bem óbvio, mas em alguns tipos de plataforma existe sobreposição de personas e papeis adicionais.

Exemplos dos dois tipos básicos de entidades

Para entender esse conceito em detalhes, vamos analisar os 10 tipos mais comuns de modelos de negócio de plataformas digitais e as entidades envolvidas:

10 tipos mais comuns de modelos de negócio de plataformas digitais

1. Marketplace

Este é o tipo de plataforma mais comum e fácil de entender. Aqui, compradores e vendedores (produtores e consumidores) são duas entidades diferentes e se conectam usando a plataforma. Os compradores podem explorar vários produtos, compará-los e tomar uma decisão sobre a compra. Os vendedores podem demonstrar seus produtos a todos os compradores potenciais e interessados. Magazine Luisa, Amazon, eBay, Alibaba, Walmart e assim por diante são algumas das plataformas bem conhecidas desse tipo.

2. Mídias sociais

Todo mundo está familiarizado com as plataformas de mídia social hoje em dia. Elas são onde as pessoas se conectam, compartilham ideias e socializam virtualmente. Facebook, Twitter e LinkedIn são alguns exemplos de plataformas populares de mídia social. As plataformas de mídia social são um tipo de plataforma em que produtores e consumidores são iguais. Nessas plataformas, um usuário alterna entre ser um produtor e um consumidor dentro da mesma sessão e em alguns minutos. Por exemplo, quando um usuário está escrevendo um tweet, ele é o produtor, mas é o consumidor quando está lendo o tweet de outra pessoa.

3. Busca

Quando digo plataformas de mecanismos de busca, não existem apenas o Google e o Bing do mundo, mas podem ser um mecanismo de busca para uma categoria muito específica. Por exemplo, o Zillow é um mecanismo de busca de imóveis para compra ou aluguel, onde os consumidores podem procurar por propriedades, e o Indeed é um mecanismo de busca onde os candidatos procuram vagas de emprego. Existem duas entidades na categoria de plataforma de pesquisa específica. No Zillow, há proprietários e locatários, e no Indeed, há recrutadores e candidatos a emprego. Mas os mecanismos de busca de informações que são independentes de categoria, como o Google e o Bing, só têm consumidores, não há produtores específicos dessas informações.

4. Conteúdo e entretenimento

Nas plataformas de entretenimento e conteúdo, os criadores de conteúdo são produtores, e os usuários que transmitem e assistem ao conteúdo são consumidores. Em algumas dessas plataformas, a criação de conteúdo é restrita a artistas e especialistas e é controlada pelos proprietários da plataforma—por exemplo, GloboPlay, Netflix e Spotify. Mas existem plataformas onde a criação de conteúdo está aberta a todos e a qualquer pessoa—por exemplo, no YouTube, que também pode ser categorizado como uma plataforma de mídia social.

5. Conhecimento

As plataformas de compartilhamento de conhecimento e informações são semelhantes às plataformas de mídia social, na medida em que os produtores e os consumidores são os mesmos. Alguns exemplos comuns de tais plataformas de compartilhamento de conhecimento e informações são Hotmart, Coursera, Stack Overflow, Quora e Yelp. Quando um usuário faz uma pergunta ou responde a uma pergunta no Stack Overflow, ele é um produtor, mas quando está navegando e lendo soluções, ele é um consumidor. Da mesma forma, no Yelp, quando um usuário está adicionando uma avaliação, ele é um produtor, mas quando está navegando e lendo avaliações, ele é um consumidor. Já nas plataformas de cursos como Hotmart e Coursera temos os produtores de cursos e os alunos, que são os consumidores.

6. Serviços

Plataformas orientadas a serviços são aquelas em que uma plataforma permite a agregação de Provedores de Serviços (SPs) e os conecta aos consumidores. SPs são os produtores neste cenário. Exemplos clássicos desse tipo de plataforma são Uber, Airbnb, iFood e assim por diante. Essas plataformas crowdsource os SPs e os conectam aos consumidores certos. Plataformas como o iFood têm uma camada adicional; elas conectam três entidades em vez de duas, como visto na maioria dos tipos de plataforma. Eles conectam restaurantes, motociclistas e consumidores para a conclusão perfeita da entrega de comida.

7. Pagamentos

Todas as plataformas financeiras, como o PayPal, se enquadram nesta categoria. Eles facilitam a conclusão de uma transação processando o pagamento. A maioria delas opera com uma comissão ou taxa de transação. Semelhante ao DoorDash, as plataformas de transação têm três camadas ou conectam três entidades—compradores, comerciantes e bancos.

8. Comunicação

Plataformas de mensagens diretas e bate-papo, como WhatsApp, Slack, Skype e assim por diante, são exemplos populares e familiares de plataformas de comunicação. As funções e responsabilidades do produtor e do consumidor nas plataformas de comunicação são semelhantes às das plataformas de mídia social. O mesmo usuário atua como produtor ou consumidor, dependendo de sua ação.

9. Infraestrutura

As plataformas de infraestrutura fornecem recursos de hardware e computação para as organizações. As plataformas de infraestrutura cuidam da hospedagem, armazenamento, rede e outros hardwares e softwares essenciais necessários para criar e implantar qualquer aplicativo. Plataformas de computação em nuvem, como Google Cloud Platform (GCP), Amazon Web Services (AWS) e Azure, são os players mais populares e dominantes desse tipo.

10. Desenvolvimento

Todos os sistemas operacionais são categorizados como plataformas de desenvolvimento. Alguns são controlados e fechados, como Windows e Apple App Store, enquanto outros são de código aberto, como Android e Linux. Além dos sistemas operacionais, plataformas construídas para acessar dados por meio de Interfaces de Programação de Aplicativos (APIs) ou plataformas que permitem diferentes aspectos de desenvolvimento de software também podem ser classificadas como plataformas de desenvolvimento. Criadas para acessar dados por meio de Interfaces de Programação de Aplicativos (APIs) ou plataformas que permitem diferentes aspectos de desenvolvimento de software também são classificadas como plataformas de desenvolvimento.

Conforme descrito nesses 10 tipos diferentes de modelos de negócio de plataforma, é necessário projetar com os dois tipos de usuários básicos em mente e considerar que pode existir plataformas onde os produtores também são consumidores. A abordagem e o design desses tipos de plataformas onde produtores e consumidores são os mesmos, se diferem dos de uma plataforma onde eles têm duas personas distintas.

Architecture Owner

Outro dia eu estava conversando com um desenvolvedor super bom de serviço. Ele me disse que acha “waste” essa diversidade de práticas e processos de desenvolvimento ágil. Ele tem muita dificuldade em reunir e visualizar todas as práticas e métodos funcionando juntos porque veio de um contexto muito técnico onde o que tinha de ser feito era apenas escrever código e entregar o software. Ele me disse que gostaria de saber, por exemplo, o que o arquiteto de software faz. 🙂 Eu achei sensacional a duvida dele e expliquei rapidamente o papel do arquiteto, mas isso ficou na minha cabeça e resolvi fazer esse post.

O papel de arquiteto de software ágil hoje está bem mais consolidado. O Disciplined Agile Delivery define o papel do Architecture Owner e as principais responsabilidades desse papel são:

  • Guiar a criação e evolução da arquitetura da solução.
  • Mentor e o Coach dos membros do time nas práticas e questões de arquitetura.
  • Entender a direção arquitetural, os padrões da organização e garantir que o time esteja aderente à eles.
  • Garantir que o sistema será suportado de maneira fácil encorajando um design adequado e tocando as refatorações necessárias para garantir um bom design.
  • Garantir que o sistema seja testado e integrado frequentemente.
  • Tem a palavra final sobre as decisões técnicas, mas deve engajar o time nas decisões e não dita-las.
  • Lidera o esforço de visualização inicial da arquitetura.
  • Trabalhar junto ao time de arquitetura corporativa (se ele existir).

No ciclo de vida básico do DAD existe um marco específico para provar a arquitetura o mais cedo possível na fase de construção. É uma forma do arquiteto mitigar os riscos técnicos e um checkpoint de governança para sinalizar a gerência sênior e outros stakeholders as decisões e questões técnicas.

Por que você deveria considerar Microservices em um próximo projeto?

Para responder essa pergunta vou assumir que você desenvolve aplicações monolíticas. Os “monolitos” são o padrão “de fato” para a construção de aplicações de negócio hoje em dia. Você vai argumentar que as aplicações que você cria tem um alto-nível de modularização com alta-coesão e baixo acoplamento e que você desenvolve serviços e tal. Tudo bem, mas você tem de concordar que não é comum quebrar a aplicação em diversos serviços, implantáveis separadamente e manter essa prática em produção. Isso é novidade. Concorda?

Bom, se você já passou pelo desenvolvimento de uma aplicação grande em Java EE ou .NET, em algum momento já passou pelos seguintes problemas:

  •  A produtividade caiu ao longo do projeto. Sua aplicação se tornou difícil de manter a medida que a aplicação cresceu. Isso resultou em ciclos longos de build para implantar novas funcionalidades ou mesmo novos serviços, e você não conseguiu fazer muito mais rápido.
  • O deploy  era “tudo ou nada”. Os pacotes grandes forçaram a construção, testes e deploy, mesmo em uma pequena mudança. Os CRUDs, as transações mais críticas e os relatórios ficaram todos no mesmo implantável e na mesma infraestrutura;
  • A escalabilidade também foi “tudo ou nada”. Não dava para escalar apenas parte da aplicação. Até dava mas nem foi cogitado isso;
  • O Onboarding de novos desenvolvedores foi difícil. Os novos integrantes do time tiveram de baixar todo o código e aprender a lidar com a aplicação inteira.
  • O gerenciamento de dependências de código ficou complexo.
  • O projeto ficou preso a uma única opção de tecnologia.

Para atacar estes problemas os caras pensaram em modularização e particionamento da aplicação em pequenas partes que chamaram de micro-serviços. Cada micro-serviço funciona como uma aplicação independente, implantável separadamente, com interface de serviço baseada em REST agnóstica em relação à tecnologia. Isso possibilita uma liberdade de escolha de tecnologia de implementação. Com essa liberdade você pode implantar serviços em plataformas diferentes e escalar de forma independente também.

Mas não existe almoço grátis… atenção ao desempenho. Você vai ter de monitorar o tempo de resposta e o uso de recursos e é importante ficar atento desde o início. Serviços distribuídos tendem a ter problemas em função da latência, por exemplo. Atenção ao design dos serviços. Evite as dependências entre serviços e a necessidade de orquestração para conseguir que o deploy fique realmente independente, senão vai acabar tendo deploy “tudo-ou-nada” do mesmo jeito. 🙂

Mas voltando aos benefícios… outra liberdade que você tem com esse modelo é “rampar” times diferentes para cada serviço. Isso te dá a possibilidade de paralelizar ou adiar a entrada de um novo time de acordo com o melhor momento para investimento. Lembrando que a métrica do time de “2 pizzas” vale aqui e também a abordagem DevOps onde o time que desenvolve também é responsável por manter e acompanhar o serviço em produção.

As vantagens dessa abordagem estão sendo experimentadas ainda, mas resultados positivos tem sido apresentados em conferências. Acho que você deveria considerar para tornar os times mais capazes de responder rapidamente às novas necessidades de negócio. A abordagem de desenvolvimento de aplicações monolíticas gera respostas mais lentas. Microservices promete entregas mais freqüentes e mais rápidas. Isso permite feedback mais rápido dos usuários e ajustes nos investimentos por parte do time de negócios.

Microservices

Enquanto estou criando uma massa de dados resolvi escrever sobre Microservices. 

Mas por que Microservices?

Porque é o estilo arquitetural mais falado do mercado no momento e porque eu acho bem interessante. Se você perguntar para aquele seu colega early adopter ele vai dizer que já aplicou no último projeto e que já está dominando o Node.js.:)

Brincadeiras a parte, segue uma definição de elevador:

Microservices é um estilo arquitetural no qual um sistema complexo de software é formado por um ou mais serviços pequenos, chamados de micro serviços. Estes serviços tem foco restrito a uma capacidade de negócio, são fracamente acoplados e agnósticos em relação à linguagem de implementação. Cada serviço é uma aplicação que tem uma API REST bem definida. Os serviços se comunicam uns com os outros através de suas APIs. Eles são desenvolvidos e mantidos por pequenas equipes. Essas equipes geralmente aplicam práticas ágeis e ao contrário da prática normal, onde uma equipe desenvolve e outra equipe mantém a aplicação, é comum que a equipe que desenvolve também seja responsável pela operação. Nesse contexto as equipes aplicam Continuous Delivery e práticas de DevOps.

Então é isso. A massa de dados está quase pronta. Fui…