Continuando na nossa série de artigos sobre APIs, vamos analisar as quatro primeiras perguntas que foram feitas no primeiro artigo da série APIs.

Qual é o público alvo das APIs a serem planejadas e implementadas?

Qual o modelo de negócio para monetização que vai ser utilizado?

Quanto vamos cobrar pelo acesso?

Como vamos cobrar pelo acesso?

Apenas uma observação, para os mais estressados, essa coleção de artigos sobre APIs tem como objetivo mostrar os bastidores na construção de APIs, que nem sempre são conhecidos. Eu falo isso pois, muitos unicamente esperam ver alguma coisa do tipo: microserviços, containers, REST, serveless, cloud, Open API, Swagger, Kubernetes e mais uma quantidade enorme de ferramentas, tecnologias e métodos que estão inseridas no universo das APIs.

Para o pessoal que só pensa na tecnologia, eu temo dizer que você só deveria escolher a tecnologia A, B ou C com base nas respostas das perguntas acima. Escolher tecnologia A unicamente porque todo mundo está usando ou está migrando para ela, é falta de noção muito grande sobre em que você está trabalhando. Eu vejo muitos colegas que conhecem muito de uma tecnologia, mas muito pouco do negócio, e por isso na hora de planejar uma arquitetura para APIs usa somente os conhecimentos de TI sem saber se isso vai atender o negócio.

Nesta situação o que se vê, na maioria dos casos, e o pessoal aumentando consideravelmente o custo do projeto por estar mensurando de forma incorreta a estrutura necessária para as APIs estarem disponíveis para os usuários, é como na frase: matando formigas com bomba nuclear. Existe o outro lado também, que vou resumir nesta outra frase: acertar a lua com um tiro de revólver calibre .22; São os extremos!

Por isso, antes de tudo, todos os envolvidos no planejamento e construção das APIs, devem saber quem é o público alvo das APIs.

· Quem vai consumir os serviços expostos pelas APIs?

· É uma empresa(B2B) ou uma pessoa(B2C)?

· Essa empresa ou pessoa pode ser dezenas, milhares ou milhões?

· O segmento de negócio desta empresa é escalável?

· Se o cliente crescer rapidamente, ele pode fazer o volume de requisições das APIs também crescer de forma rápida?

· É possível que os clientes das APIs aumentem o consumo das APIs devido as questões de períodos de sazonalidade, exemplos: natal, páscoa, etc.?

Observem bem cada uma dessas perguntas, agora me digam; tem impacto ou não tem impacto sobre a arquitetura das APIs essas questões?

Uma vez que saber quem é o cliente, é um fato superado; agora vamos para o modelo de negócio que está inserido essas APIs. Todas as empresas têm um modelo de negócio, mesmo que ele não esteja escrito em lugar nenhum. Mas não estou falando desse modelo de negócio, o da empresa, eu estou mais interessado em saber o modelo de negócio do projeto das APIs. Lógico que ele tem vínculo com o da empresa, mas eu estou mais para saber dentro do contexto das APIs os seguintes itens:

· Parcerias chaves?

· Atividades chaves?

· Recursos chaves?

· Proposta de valor?

· Relações com clientes?

· Canais de distribuição?

· Segmentos de mercado? Item discutido anteriormente — clientes.

· Estrutura de custos?

· Fontes de renda?

Quem conhece o modelo de negócio CANVAS sabe que esses itens são de lá. Cada item deste, tem influência nos outros dentro do modelo, é um jogo interessante montar um modelo de negócio CANVAS. Um jogo importante no sistema, que infelizmente não é feito no processo de planejamento de APIs, na maioria dos projetos.

Temos aquela conversa antiga, que a maioria dos projetos de TI falham e gastam mais recursos que o planejado, mas na verdade eu acredito que muitos deles não deveriam nem ter começado, falhar já era a sina de algo que não tinha proposta de valor, estrutura de custos e fontes de renda.

O pessoal se confundi facilmente entre fazer software de forma ágil, empoderamento de equipe e ter a flexibilidade de mudança, com o a questão de saber qual é o objetivo do software, quem é o seu cliente e etc. Quando se tem mudança no mercado, obviamente os itens no modelo de negócio serão mudados, por isso que a agilidade e adaptabilidade no desenvolvimento das APIs são importantes. Se eu tenho que mudar rápido as minhas APIs é porque algo no modelo de negócio também mudou rápido.

Agora pensam no fato que você não tem esse modelo de negócio; como você sabe que os clientes das suas APIs têm critérios de segurança e normas regulamentatórias que você nem sequer sabia que existiam? Na hora de construir as APIs isso não foi planejado e não foram feitos, agora para incluir essas novas features o custo da mudança vai ser gigantesco.

Por isso eu afirmo, se eu não sei o meu cliente e qual o modelo de negócio que eu devo atender, qualquer coisa que for construído nas APIs está correto. Não existe certo ou errado, o que existe é um monte de gente construindo alguma coisa porque alguém mandou e usando as tecnologias que estão na vibe do mercado.

Voltando nas questões técnicas novamente; Por que eu estou usando Java? Por que eu estou usando microsserviços? Por que eu estou usando Apigee? Por que estou usando container? Se as respostas forem para o lado que não tem nenhum critério que se origina de um modelo de negócio, sinto em te dizer, mas está tudo errado.

O que estou colocando vocês para refletir aqui, não é algo fora da realidade, o modelo startup tem justamente esse propósito, construir soluções que são aderentes ao modelo de negócio que está resolvendo/minimizando uma dor de alguém. Esse alguém é um cliente muito bem definido, que a equipe o conhece e está apta a mudar projeto, método e tecnologias para atender a este cliente, tem poder e fazem uso deste poder para que o modelo, clientes e as APIs sempre fiquem em sintonia.

Vamos comentar sobre o artigo pessoal, indiquem aos seus colegas essa leitura, precisamos de mais pessoas no mercado que tenham um mindset diferente do que estamos habituados a ver.

Espero vocês no próximo artigo da série, até mais!

Cleison Melo.