por Edgar Silva
O que são APIs? Eis a pergunta, e aí temos um leque gigantesco de respostas, mas dentre estas escolhemos:
Em uma analogia simples e fácil de entender: API's estão para o seu negócio como o painel e controle de um carro está para todas interligações internas que poucos de nós sabemos como funcionam internamente. Você sabe que ao acelerar o carro ele andará mais rápido, mas você não precisa saber sobre eixos, pistões e toda a parafernália mecânica por dentro da carroceria.
De forma direta: Suas APIs vão fazer soluções serem desenvolvidas em menos tempo, pois os desenvolvedores vão consumi-las mais rápido, além disso, você pode oferecer suas APIs para outras empresas ou parceiros e com isso ainda faturar para sua organização.
Figura 1
A busca por uma estratégia assertiva em expor essas funcionalidades internas nas organizações, de uma forma reutilizável, fácil de consumir por diversas aplicações e gerar receitas com este novo negócio é o que conhecemos como Estratégia de APIs e Economia das APIs. Uma colocação no mercado que conota bem este momento que vivemos é: "se na década de 90 era ruim uma empresa não ter um website, hoje dia é extremamente ruim uma empresa não ter uma API".
Vamos economizar um pouco de histórias e ir direto ao ponto: o que muitas empresas devem buscar em suas iniciativas de APIs?
Nós entendemos que uma iniciativa como esta seja composta minimamente das seguintes fases:
Figura 2
Neste documento, nossa intenção é explicar de forma abstrata e de maneira mais agnóstica possível como alcançar estes pontos de forma segura e com um alto grau de segurança, não só de retorno de investimento, mas também do ganho de credibilidade na sua organização.
Assim como já tivemos o Mobile First, o modelo API First consiste em começar e embasar seu negócio primeiramente em cima de APIs. Até aí, você pode pensar: isso é óbvio. Porém, vamos usar como exemplo um negócio do qual muitas pessoas possam entender o funcionamento, uma vez que faz parte de nosso dia-a-dia: um site de reserva de hotéis. Como nome fictício, vamos chamá-los de Hostelera, onde qualquer semelhança é mera coincidência.
Hostelera é uma spinoff de um tradicional grupo de turismo, que possui uma equipe de desenvolvimento própria e mantém um sistema desktop que está instalado em várias agências de turismo no país. Eles querem iniciar um processo de transformação digital saindo do B2B (Empresa x Empresa) para o B2C (Empresa x Consumidores direto). Eis então que o time de negócios da Hostelera acabou de definir seus planos de ação, entre eles, o desenvolvimento de um site.
Pois bem, desenvolver um site primeiramente lhe atenta a perguntas como:
Estas e várias outras questões são louváveis e válidas, porém, não estão tão próximas do negócio.
Para apoiar a Hostelera em sua iniciativa Digital, solicitamos uma reunião entre tecnologia e negócio. Nossas perguntas ao negócio foram as seguintes: O que mais vocês vendem? Como? Abaixo as respostas:
Nota: Não vamos nos ater a alguns detalhes mais técnicos, como a questão de usos de verbos, etc. Deixemos isto para um bate-papo mais técnico e mais focado na implementação das APIs.
Depois de analisar o que é importante para Hostelera, o pessoal de tecnologia expôs o que existe hoje na organização (as is), e depois de um brainstorming do pessoal de negócio com tecnologia, eis as APIs nós podemos elencar : (Figura 3) :
Figura 3: Resultado do Brainstorming
De posse destas informações, conseguimos modelar as APIs de forma muito simples usando o padrão de especificação de APIs mais popular de mercado: Swagger.
O Swagger permite que você defina o contrato de trabalho da API e posteriormente pode "rechear" cada função da API com a implementação tecnológica, que julgar mais importante. Mais uma vez, a equipe de negócio e tecnologia estão juntas, trabalhamos a quatro mãos para fazer com que a iniciativa possa sair com êxito.
Na figura 4: um exemplo do Swagger Editor que pode ser usado nas reuniões entre tecnologia e negócio para definir as APIs.
Figura 4: Swagger Editor - Criando o esqueleto/contrato de sua API ainda sem implementações.
Eles definiram todas estas APIs com Mocks (apenas de testes com dados hipotéticos, fixos e/ ou pré-populados) para poder testar minimamente as APIs.
Com as APIs prontas, eis que alguém pergunta: e o site?
A resposta é simples: com as APIs prontas, agora ter o site, ter o aplicativo móvel, ter o bot, poder integrar com parceiros ou até outros negócios, passou a ser algo fácil, dado o investimento na prática do API: First.
Vamos detalhar um pouco mais as fases que consideramos comuns em iniciativas de APIs que deram e dão certo.
Se você não sabe quais benefícios uma iniciativa de APIs trará à sua empresa e esta é uma tarefa complexa, pelo menos no curto prazo, vale muito a pena praticar diversas vezes o princípio de API First.
Quais são os impactos diretos de uma estratégia de APIs:
A questão chave é garantir que sua iniciativa terá engajamento na organização, pois se a empresa não abraçar sua idéia, baseado em nossa experiência, você poderá ter problemas. Muitas vezes, até mesmo o C-Level da sua empresa tem que saber que você está investindo tempo e dinheiro em uma iniciativa que vai impactar o negócio core da organização. Já vimos iniciativas morrer pela falta de estruturação e pelo fato de as pessoas não "comprarem" a idéia de uma iniciativa consistente de APIs.
No caso da Hostelera, eles estavam perdendo mercado e perceberam que uma interação B2C direta poderia maximizar sua receita, com aumento nas comissões, geração de novos canais de vendas, etc. Com toda esta análise, a iniciativa foi adotada como chave pela alta gestão da empresa, inclusive do seu presidente.
É muito importante levar em consideração os critérios fundamentais para escolha de sua solução de apoio, por exemplo, no caso da Hostelera, eles tinham os seguintes :
Definir “o norte” de sua estratégia é muito importante, por isso, com o apoio da organização, avalie o que é importante para o negócio e vá atrás da solução que possa satisfazer seu orçamento, busca de qualidade e claro, seus critérios chave.
É importante consultar seu parceiro tecnológico, como será seu processo de adesão. Geralmente recomendamos sprints baseados em metodologias ágeis, onde o mais importante é ter algo pronto num curto período de tempo. O ideal é que seja pelo menos 1 mês (não mais que isso, mas pode ser menos), pois se você estender este prazo, poderá trazer novas demandas para o escopo e isto atrapalhar seus entregáveis e quick wins. Não esqueça que a organização espera por um resultado rápido, então pense de forma interativa e incremental para ter uma adoção pragmática e objetiva.
Como proposta:
| Semana 1 | Semana 2 | Semana 3 | Semana 4 |
|
1. Treinamentos 2. Definição do alcance das MVA e MVP 3. Planejar o Marketplace (interno ou externo) |
Elencar 2 a 3 APIs: 1. Implementar de 2 a 3 APIs 2. Alinhar com negócio se são as APIs mais importantes 3. Como será tratamentos de segurança de suas APIs 4. Como serão consumidas |
1. Continuação da Implementação das APIs 2. Aderência de tecnologias acessórias e arquiteturas como Microserviços, Integrações, etc 3. Fechamento do modelo de negócio do MVP 4. Fechamento da MVA |
1. Customização do tema do Marketplace 2. Publicação das APIs 3. Testes de Carga |
Tabela 1 - Definição de um plano de Estratégia de Adoção
Um MVP é um minimum viable product (produto [entrega] mínimo viável) - Ou seja, o que é o mínimo do mínimo para você provar que seu produto funciona, e lançá-lo de forma incremental ao mercado. A idéia do MVP é que você tenha no período estipulado (ideal 1 mês ou menos), algo como: https://api.minhaempresa.com.br. Ligando o MVP na sua iniciativa de APIs isto significa:
O seu MVP/Iniciativa de API deve ser incremental, sempre agregando novas funcionalidades e reusando o que você já fez. Aqui uma idéia de MVP ilustrada na figura 5:
Figure 5: A Evolução de um MVP - Créditos: https://blog.engineyard.com/2015/actually-mvp
Uma MVA- minimum viable architecture (arquitetura mínima viável) - Será a arquitetura que você utilizará para construir os serviços que serão expostos como APIs. Algumas empresas tem como aproveitar esquemas de dados existentes, outras vão criar microserviços com .net, java, python, etc, e orquestrar ou seus containers. Estas são decisões importantes neste período, contar com uma solução aberta e resiliente suficientemente é fundamental para tornar sua iniciativa possível.
No papel de desenhar a solução, você se depara com algumas questões naturais como, por exemplo:
As respostas para estas e várias outras perguntas está no alinhamento da MVA com o MVP, ou seja, o que você pode fazer para acelerar seu MVP? Lembre-se, uma vez o MVP pronto, nunca esqueça dos princípios ágeis de iterativo e incremental, pois a qualquer momento você pode reavaliar sua arquitetura e promover/expor os serviços da maneira que lhe seja mais conveniente.
Algumas organizações, por exemplo, já possuem um Enterprise Service Bus, que muitas das vezes já expõe serviços e você pode partir desta premissa. Ou se a organização torce o nariz para este conceito e prefere ter seus serviços de forma "micro", "idempotentes", "independentes", "resilientes", "conteinerizados", etc, também você poderá trilhar esse caminho, desde que sua solução de APIs possa ter uma camada de gateway que entenda esses desafios arquiteturais e de decisões ágeis.
Figure 6:
É importante averiguar a cada final destes períodos: o que deu certo, o que não deu certo, e ajustar tudo de acordo com as necessidades da sua organização. Se você tiver esta disciplina, a cada nova interação seu processo estará mais maduro e mais confiável.
Este é um guia que tenta ser o mais objetivo e pragmático possível, que traz alguns insights para planejar as fases primordiais de uma iniciativa de APIs. Existem muitas visões mais complexas, mais academias e até mais completas, mas tentamos focar em atender o maior número de desafios e empresas. Existem vários pontos não cobertos neste paper, por exemplo:
Estes pontos vão variar de acordo com a solução e parceiro escolhidos, alguns vão permitir você usar o que já tem em casa, outros podem trazer práticas que começam do zero, o que é bom e ruim, nos levando a pergunta: o que é importante para sua empresa? Lembra dos critérios que mencionamos antes? Então, este é um grande ponto de reflexão.
E falando na Hostelera, qualquer semelhança com qualquer empresa de mercado é mera consciência.
For more details about our solutions or to discuss a specific requirement
