X

Easy Access to WSO2's Online Resources During COVID-19 Lockdown.   Read More

White Paper

WHITE PAPER

04/2017

Uma visão pragmática para sua iniciativa de APIs

por Edgar Silva

1. Princípios da API First

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

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:

  • Validar o impacto no negócio
  • Elencar os critérios chave
  • Definir a estratégia de adoção : MVP e MVA
Figura 2

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.

2. API: First

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:

  • Usamos PHP, Ruby ou Django?
  • Usamos HTML5 com Bootstrap ou Material?
  • Será que consigo um tema interessante no Themeforest?

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.

3. Aplicando API: First

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:

  • Negócio: "Temos um ótimo contato com algumas redes de hotéis, em alguns destinos e épocas do ano, nosso preço é o mais atrativo. Com isso, muitas agências reservam bastante no nosso sistema."
  • Nós: Quais são as principais informações que vocês tratam nesta operação da venda de hotéis?
  • Negócio: Precisamos saber informações da reserva: destino, período, configuração do quarto desejada e de preferência já saber como será feito o pagamento. Se o pagamento ocorrer diretamente com o hotel, às vezes, temos problemas em garantir nossas comissões.

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

Figura 3: Resultado do Brainstorming

  • Reserva
    • período (data inicio, data fim)
    • destino (cidade, de repente uma geolocalização de evento, etc)
    • quarto (casal, solteiro, 2 camas, andar baixo, etc)
    • hotel escolhido
    • valor da reserva
  • Hotel
    • disponibilidade
    • valores
    • termos e negociações
  • Pagamento
    • método de pagamento
  • Cliente
    • registro
    • monitoração
    • preferências

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

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.

3.1 Validação de Impacto no Negócio

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:

  • Agilidade para comunicar e expandir com novos canais tendo a possibilidade de gerar novas fontes de receitas
  • Monetização através de novos canais
  • Entrega mais ágil e rápida de novas aplicações e serviços
  • Economia baseada no reuso de serviços, microserviços e 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.

3.2 Elencar Critérios Chave

É 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 :

  • Capacidade de Modelar as APIs antes de implementá-las ( API First)
  • Solução na nuvem, mas que dependendo dos cenários pode ser usado no datacenter da Hostelera
  • Definir um customizável marketplace (API Store) de suas APIs, com recursos sociais, de avaliação e comentários para gerar uma comunidade de usuários
  • Um bom API Gateway incluso é importante para promover integrações com diversos sistemas, especialmente nas questões de pagamento e reaproveitamento do legado dos sistemas para atuarem como base das novas APIs.
  • Treinar sua equipe rapidamente

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.

3.3 Estratégia de Adoção

É 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

3.1.1 O que seria MVP e MVA?

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: http://api.minhaempresa.com.br. Ligando o MVP na sua iniciativa de APIs isto significa:

  • Que problemas você quer resolver inicialmente e/ou que oportunidades quer executar para provar que sua iniciativa é digna de investimento e atenção.
  • O que é o mínimo do mínimo para provar que sua iniciativa irá trazer o valor que você espera.

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

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:

  • Reutilizo minhas Stored Procedures e Packages como Serviços REST/SOAP?
  • Faço com que uma fila existente possa receber a transação de uma de minhas APIs?
  • A integração de arquivos que resulta em inserções e atualizações nas tabelas de banco de dados já estão prontas para ser expostas como serviços e consequentemente APIs?

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.

4. Observe: Reavalie: Repita

Figure 6

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.

5. Conclusão

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:

  • Como ficará sua Arquitetura de Integrações? Vai usar Microserviços? Ou uma plataforma de Integração que exponha serviços HTTP?
  • Como ficará sua entrega contínua?
  • Como ficarão os ambientes de desenvolvimento, homologação e produção?

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.

Para mais detalhes de nossas soluções ou discutir algum requisito especifico, entre em contato conosco.

x

Interessado em um conteúdo similar?