Como dissociar o fornecedor de API e os ciclos de vida do consumidor

Como dissociar o fornecedor de API e os ciclos de vida do consumidor

Como dissociar o fornecedor de API e os ciclos de vida do consumidor
cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


Como qualquer produto, as APIs e os aplicativos clientes que usam APIs têm seus próprios ciclos de vida. Cada um deles experimenta suas próprias fases de criação, publicação, realização, manutenção e desativação. Quando as coisas correm bem, os serviços experimentam uso (e reutilização) importante e crescem até a maturidade para fornecer contribuições significativas ao desempenho da sua empresa. E os aplicativos clientes usarão APIs que se conectam a um ou mais serviços e, a seu modo, criarão seu próprio ciclo de crescimento e maturidade para aumentar a receita e / ou o uso do cliente de maneiras que também signifiquem sucesso para sua organização.

Durante todos esses ciclos e fases, é importante também ter a estratégia de governança correta. E uma parte essencial dessa estratégia é reconhecer que a taxa de mudança e a curva de crescimento / maturidade para serviços e clientes são frequentemente diferentes. Isso significa que são necessárias diferentes táticas e técnicas para apoiar seu sucesso.

Por exemplo, as atualizações do cliente geralmente acontecem com mais frequência do que as atualizações de serviço. Isso é especialmente verdadeiro porque a API amadurece com o tempo. E as alterações no lado do serviço têm muito mais probabilidade de perturbar o ecossistema da API do que as alterações no lado do cliente. Além disso, em um ecossistema diversificado onde existem muitos fornecedores e consumidores, é raro que o aplicativo cliente e o componente de serviço sejam liberados de qualquer maneira coordenada.

As empresas que reconhecem essas diferenças têm uma vantagem sobre seus pares no setor. Eles podem ajustar seu modelo de governança para tirar o melhor proveito das variações entre os ciclos de serviço e o cliente, e que fornecem a vantagem competitiva necessária para obter e manter a liderança em seu mercado.

Provedores de serviços de API

Para serviços de back-end, o design inicial e as fases de liberação antecipada geralmente sofrem alterações significativas. Mesmo quando você tem uma cultura saudável de pensamento de design de pré-lançamento, há momentos em que seus primeiros protótipos não capturam bugs importantes ou necessidades de recursos até que o serviço já esteja recebendo uso constante na produção. Os bons modelos de governança levam isso em consideração.

Mudanças frequentes no início

Por exemplo, ao projetar e implementar o serviço de integração do cliente, você pode achar que sua versão inicial da produção não levou em consideração alguns casos extremos. Fazer essas alterações após o primeiro lançamento corre o risco de quebrar todas as implementações existentes. Isso adiciona novos custos e atrasos antes que você possa acelerar as fases de crescimento e maturidade de seu serviço.

Mas não precisa ser assim.

Reduzindo a interrupção por meio de recursos

Um elemento-chave em programas de API bem-sucedidos é o suporte a alterações na API do provedor sem causar interrupções no serviço para os consumidores existentes da API. Uma maneira confiável de fazer isso é focar os padrões de design e implementação de API nos recursos, e não nos modelos de dados. Exemplos de recursos sustentáveis ​​são a integração do cliente, a revisão do contrato e a aprovação da compra. Essas são funções no nível de negócios que têm uma vida útil longa, mesmo que os detalhes de como implementá-las mudem com o tempo.

Leia Também  O que há de novo no CE 20.2 para o Tableau Forensic Imager (TX1)

Exemplos de foco de design de API potencialmente problemático são a API de dados do cliente ou a API da lista de produtos. Essas são as "coisas" normalmente governadas pela localização física e pelo esquema lógico. Esses aspectos (localização e esquema) são muito mais propensos a mudar ao longo do tempo do que ações como clientes de embarque ou compras de aprovação. E as alterações no local e no esquema têm mais probabilidade de interromper os aplicativos de consumidor de API existentes já em produção.

A implementação do estilo de serviço GraphQL faz exatamente isso. Expõe propriedades e ações para permitir que os clientes tomem suas próprias decisões sobre o que o serviço retorna. E isso significa que os serviços podem mudar a maneira como coletam e armazenam dados, independentemente da maneira como os clientes desejam visualizar e consumir esses mesmos dados.

Outra maneira de conseguir isso é através da dependência dos formatos de implementação da API, como a linguagem de descrição da interface Application-Level Profile Semmantics (ALPS). Compartilhando apenas a lista de recursos e propriedades e deixando cada implementação decidir sobre seus próprios URLs e objetos, os serviços podem fazer alterações com segurança sem causar interrupções dispendiosas na produção.

Menos mudanças para serviços maduros

Quando um serviço passa da fase inicial de realização, onde as mudanças são mais comuns, pode passar para uma fase de crescimento e maturidade, onde apenas pequenas alterações são necessárias para manter uma experiência ideal do consumidor, maximizando a receita e / ou reduzindo os custos operacionais. Ironicamente, é durante a fase de “estabelecimento” que um serviço geralmente experimenta seu crescimento e reutilização mais significativos do consumidor. E, durante a crescente fase de reutilização, é ainda mais importante que o serviço não sofra grandes alterações em seus recursos compartilhados.

Embora a governança nos estágios iniciais de um serviço se concentre nos detalhes da implementação que facilitam a mudança de serviços sem prejudicar os consumidores, o modelo de controle para serviços maduros precisa se concentrar na redução do número de mudanças que podem causar impacto negativo no uso e no crescimento de serviços. esse serviço. Isso significa diminuir o ritmo da mudança e avaliar cuidadosamente o perfil de custo / benefício das modificações sugeridas. Geralmente, faz mais sentido simplesmente criar um novo serviço com os novos recursos sob demanda. Isso preserva a estabilidade dos serviços existentes e permite um novo crescimento no perfil de capacidade da sua organização.

Portanto, muitas alterações no início e menos alterações à medida que o serviço amadurece – todas gerenciadas com foco na publicação de um conjunto estável de recursos, em vez de um conjunto fixo de URLs, métodos e cargas úteis. Esse é um padrão de ciclo de vida comum para provedores do servidor.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

Isso é um pouco diferente dos aplicativos clientes que consomem essas APIs do servidor.

Clientes consumidores da API

Durante a prototipagem inicial e o teste beta de aplicativos de consumidor da API, os casos de uso são refinados, expandidos e, às vezes, até completamente descartados do sprint, o que leva a mudanças frequentes. No entanto, as coisas se acalmam relativamente em breve. O importante é ter em mente que os consumidores de API frequentemente passam por um período adicional de alta frequência de mudança, uma vez que as APIs subjacentes do provedor amadurecem e se instalam. Essa fase adicional de mudança rápida pode causar sérias interrupções para os consumidores e fornecedores de API, a menos que o design e práticas de implementação já estão em vigor. E, assim como no ciclo de vida dos provedores de API, a chave para o sucesso é se concentrar em um conjunto de recursos para os consumidores de API.

Leia Também  Descompactando o anúncio de colaboração estratégica da AWS

Mudanças frequentes no início

No início do ciclo de vida dos consumidores da API, muitas vezes ocorrem algumas alterações por vários motivos. Primeiro, os primeiros protótipos e edições beta dos consumidores de API geralmente resultam em novas descobertas. Os cenários de caso de uso assumidos são refinados. Alguns novos cenários surgem durante o teste e, às vezes, os casos de uso iniciais são descartados do sprint de design atual. Essas mudanças ocorrem rapidamente e é importante ter uma fase de design no ciclo de vida do consumidor da API voltada para responder a essas primeiras descobertas.

Eventualmente, o release de produção inicial é concluído e implantado. Após algumas pequenas correções, as coisas geralmente se acalmam por um tempo. No entanto, à medida que a API ganha mais uso, os consumidores inteligentes da API começam a encontrar novos usos (e, portanto, novos casos de uso) para a API do provedor. Isso significa que o consumidor da API (aplicativos clientes) pode passar por uma série de atualizações além do ciclo de vida do provedor da API. É aqui que o consumidor da API começa a perceber o valor pretendido.

Mas fica melhor (ou pior, dependendo do seu ponto de vista) porque novos usos não são todos que os consumidores da API começam a descobrir. Eles também começam a descobrir casos de uso em que o provedor de API existente pode precisar adicionar novos recursos ou fazer ajustes no suporte ao fluxo de trabalho para os consumidores da API. À medida que o consumo aumenta, o mesmo ocorre com a demanda do fornecedor.

Essa experiência de "voltar ao poço", na qual os consumidores da API continuam solicitando aos fornecedores mais recursos, pode resultar em reescritas caras para o provedor da API e começar a diminuir o ROI e a usabilidade do ecossistema da API. Conheço empresas que estão constantemente atualizando suas emocionantes APIs de back-end até o ponto em que resta muito pouca estabilidade ou confiabilidade no ecossistema da API – tudo está em constante estado de mudança, interrupção e instabilidade.

Mas, como você pode imaginar, não precisa ser assim.

Reduzindo o atrito através de recursos

Assim como discutimos acima ao falar sobre a interrupção do provedor de API – o uso de um modelo de recursos (em vez de um modelo de recursos) pode ajudar a manter a estabilidade da plataforma de API enquanto você faz as alterações necessárias no sistema. Você pode adotar opções de design de plataforma que ofereçam liberdade aos desenvolvedores de clientes sem adicionar encargos aos desenvolvedores de fornecedores. Crie opções como APIs baseadas em hipermídia para permitir que os clientes personalizem fluxos de trabalho ou interfaces no estilo de consulta como RDF (Resource Description Framework) ou GraphQL para fornecer aos consumidores de API controle sobre a "forma" do retorno dos provedores de resposta. Você também pode empregar linguagens de descrição em tempo de design, como semântica de perfil em nível de aplicativo (ALPS), para se concentrar nas descrições de recursos reais, em vez de focar objetos e recursos. Isso permite que você restrinja seu controle aos fatores que causam atrito – alterações nos casos de uso.

Leia Também  10 razões pelas quais você precisa de uma estratégia de marketing digital em 2020

Cenários crescentes para clientes maduros

Um dos motivos pelos quais os ecossistemas da API podem se tornar menos estáveis ​​ao longo do tempo é que as mudanças nos casos de uso causam muita interrupção para os consumidores e fornecedores da API. Idealmente, você deseja que o processo de suporte a novos casos de uso seja isolado para sua comunidade de consumidores de API. Este é um dos princípios fundamentais por trás do mantra de "reutilização". Para muitos, o valor da reutilização é quando você pode reutilizar os mesmos componentes do provedor para dar suporte a novos cenários do consumidor.

Outro motivo comum para o lado do consumidor sofrer mais alterações do que o lado do provedor é que, com o tempo, mais / melhores / diferentes aplicativos clientes surgem para tirar proveito das APIs do provedor existentes. Esse é outro tipo de reutilização – o tipo que permite que novos clientes sejam criados para dar suporte a novos cenários. Geralmente, esses são cenários nos quais os fornecedores de API não pensavam quando fizeram o trabalho. A capacidade de oferecer suporte a novos lançamentos de novos consumidores de API é uma habilidade essencial que pode aumentar o ROI do seu ecossistema de API.

Sumário

APIs de serviço bem projetadas e construídas durarão muito tempo. Eles precisam continuar funcionando de maneira saudável e feliz, mesmo quando os aplicativos de consumidor da API mudam ou quando novos aplicativos de consumo ainda não imaginados são criados. Para fazer isso, concentre-se nos principais recursos de suas APIs (clientes de integração, remessas de rastreamento, feedback de gerenciamento etc.) e permita que os detalhes da implementação, como URLs e modelos de objetos, sejam mais fluidos e menos quebradiços ao longo do tempo.

Você pode precisar reconhecer que, enquanto o ciclo de vida do provedor de API se acalma com o tempo, permitindo que você obtenha valor agregado por meio de alterações limitadas, os ciclos de vida do consumidor da API funcionam de maneira bastante diferente. Os consumidores da API aprendem constantemente novos casos de uso e procuram maneiras de acelerar as mudanças durante toda a vida útil da API do lado do cliente.

Se você precisar reescrever os aplicativos de front-end e back-end para adicionar suporte a um novo recurso ou caso de uso, o processo de design e implementação da API precisará de algum trabalho. O suporte à mudança no lado do cliente sem a necessidade de reimplementação no lado do provedor é a chave para melhorar seus ecossistemas de API, estabilidade, reutilização e ROI do seu negócio.

Para saber mais sobre como as APIs podem ajudar a estratégia digital da sua organização, consulte o MuleSoft API Strategy Hub.


cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Luiz Presso
Luiz Presso