Modelo de Maturidade da Arquitetura de API

Sua empresa está pronta para a Economia das APIs?

Esta é a reflexão que os arquitetos e estrategistas digitais devem fazer, caso desejem que sua empresa participe dessa nova API Economy. Mas esta reflexão inicial deve identificar as condições atuais e quão madura é a arquitetura da empresa, a fim de apoiar as iniciativas de APIs. Depois de avaliar a condição atual, deve-se refletir: qual é a condição futura desejada?

Mas que tipo de arquitetura é crucial nesse cenário? Basicamente a arquitetura do sistema e em especial sua arquitetura de integração. A arquitetura do sistema é essencial para fins comerciais, por exemplo, os aplicativos poderão escalar se a empresa decide abrir suas APIs? E suas integrações? Basicamente, as APIs são a interface das integrações, o que requer algumas padronizações e tecnologias.

Para ajudá-los a identificar a condição atual e a condição futura desejada, podemos usar um modelo de maturidade específico para a arquitetura de sistema e de integração para suportar as iniciativas de APIs.

‍

Classificações de maturidade da arquitetura API

Este modelo de maturidade é dividido em 7 níveis agrupados em 3 classificações gerais que são:

• Não baseado em APIs: a arquitetura de integração e de sistema não são baseadas em APIs, em alguns casos não há comunicação e outros geralmente compartilham arquivos, usam filas, serviços web não estruturados ou até mesmo criam algumas tecnologias TCP / Socket para fornecer comunicação entre aplicativos.

‍

• Parcialmente baseado em APIs: a arquitetura de integração e de sistema são parcialmente baseadas em APIs, ou seja, tem forte uso de serviços Web SOAP e RESTful, usando recursos como Repositório de Serviços e Portal de Desenvolvedores, mas com baixa governança, padronização e separação de interesses (entre APIs e serviços).

‍

• Totalmente baseado em APIs: o sistema e a arquitetura de integração é totalmente baseada em APIs, o que significa que há separação de preocupações entre camadas como API, Serviços e Aplicações. Em perspectiva empresarial, as APIs são a base de novos modelos de negócios ou o próprio negócio depende das APIs. Também são observadas outras características e capacidades técnicas como fortes mecanismos de segurança, API governance, monitoramento, analytics medir e melhorar as APIs Developer Experience .

‍

Níveis

Este modelo de maturidade apresenta 7 níveis nos quais as empresas podem ser classificadas, que são:

Nível 1: Aplicações Isoladas

A arquitetura do sistema, neste caso, é baseada em aplicativos isolados sem / com poucas integrações. Os principais tipos de aplicativos são: aplicativos monolíticos ou aplicativos prontos para uso, como ERPs ou CRMs.

Nível 2: Integrações não estruturadas

Existem integrações entre aplicativos, mas elas não são estruturadas, isso significa que não há padrões para estrutura de mensagens ou mesmo nas tecnologias a serem usadas. Além disso, os canais de integração são descentralizados (ponto-a-ponto), não há hub ou algum tipo de barramento – as integrações são criadas de maneira ad hoc. Normalmente, as tecnologias de integração usadas aqui são:

• Message Queues
• Sockets connections
• Database replications
• File sharing (eg XML, CSV or EDI)

‍

Nível 3: Arquiteturas baseadas em componentes

Este nível se refere a arquitetura do sistema são baseados em componentes , os principais modelos de arquitetura usados ​​aqui são:

• EJB (Enterprise Java Beans)
• CORBA
• Microsoft COM/COM+/DCOM
• Aplicações autônomas de serviços Web

Além disso, as principais tecnologias de integração são:

• TCP/Sockets (por exemplo, Java RMI, COM, EJB)
• Conexões de soquetes personalizadas
• HTTP Endpoints (por exemplo, SOAP, RPC sobre HTTP)

A principal questão deste nível são as integrações e interfaces não terem ou terem pouca interoperabilidade porque as tecnologias usadas aqui só se comunicam com a mesma tecnologia. Exceto para serviços Web, mas esses serviços Web geralmente não seguem padrões ou algum tipo de controle, o que dificulta a manutenção da interoperabilidade.

‍

Nível 4: Arquiteturas orientadas a serviços

Nesse nível, a arquitetura do sistema usa princípios de SOA , por exemplo, há separação de interesses entre Camada de Serviços e Camada de Aplicação. Quando a camada de aplicação geralmente depende dos recursos de negócios e armazenamento de dados, a camada de serviços refere-se à padronização de contrato, abstração, composibilidade, descoberta etc.

As principais características da arquitetura de sistema são:

• Monolith applications (Application Layer)
• Uso de um SOA Stack (ESB, BPEL, Complex Event Processors, Service Registers, etc)
• On-premise infrastructure

E as tecnologias de integração são:

• SOAP Web-Services
• RESTFul Web-Services (mas uso incipiente)
• Messaging (e.g JMS, ActiveMQ, etc)

Por fim, a principal questão relacionada a este nível é que não há separação de interesses entre as camadas de Serviços e de APIs (veja a figura abaixo), apenas uma camada de Serviços, na qual alguns recursos das APIs são incorporados.

‍

Nível 5: APIs privadas baseadas em arquitetura de microsserviços

Nesse nível, a arquitetura do sistema usa a abordagem do microserviço. Geralmente tem dois tipos de camadas Front-End Layer e Back-End Layer, onde o micro-serviço reside, neste tipo de arquitetura, o papel do API Gateway aparece em alguns casos para fornecer integração entre Front-End e Back-End. Classificamos como APIs privadas porque somente aplicativos front-end internos usam essas APIs.

As principais características da arquitetura de sistema são:

• Uso de um Microservice Pattern
• API Gateways
• Baseada na maior parte em infraestrutura cloud e containers.
• Uso incipiente de Mesh Architecture

E as principais tecnologias de integração utilizadas são:

• RESTful APIs (exposição para front-end ou mesmo comunicação entre microsserviços)
• AMQP (e.g Kafka, RabbitMQ, etc)
• Uso incipiente de novos protocolos de comunicação, como gRPC, Thrift, etc.

Mas a principal questão crucial relacionado às APIs nesse nível é que as APIs não são totalmente gerenciadas, o que significa que apenas alguns recursos são usados, como segurança e throttling, fornecidos por um único API gateway. Outra característica crucial é que as APIs de microsserviços também não são gerenciadas, o que significa que a comunicação é ponto-a-ponto e sem governança centralizada (falta da capacidade de mesh architecture)

Outro ponto a ser observado é que a arquitetura baseada apenas em API gateways não é fácil de ser extensível para toda a empresa, nós recomendamos fortemente o uso da API Platform para sustentar a evolução deste tipo de arquitetura.

Para todos os problemas relacionados acima, classificamos esse nível como parcialmente baseado em APIs.

Nível 6: APIs abertas

Nesse nível, a empresa geralmente tem algumas características técnicas de outros níveis, mas a principal característica técnica é ter uma Camada de APIs sobre as Camadas de Serviço, de Aplicação ou de Back-End (Microservices).

Nesse caso, as APIs fazem parte dos negócios da empresa, seus negócios são impulsionados pelas APIs. Isso significa que eles podem criar um ecossistema de parceiros e um ambiente de inovação aberto. Esse cenário cria novos fluxos de valor e serviços inovadores.

Sob a perspectiva técnica, outras características podem ser observadas:

• Utilização de plataformas API e seus módulos (listados abaixo)
• Uso do módulo Portal do Desenvolvedor para aumentar a Experiência dos Desenvolvedores parceiros e startups
• Uso de módulos de Analytics para monitorar o comportamento técnico e comercial
• Fortes restrições de segurança usando proteção WAF e DDoS.
• APIs RESTful como padrão para integração externa.

‍

Nível 7: APIs como Negócios

Como o nome sugere, neste nível o negócio da empresa é totalmente baseado e é totalmente dependente de APIs.

Do ponto de vista técnico, algumas características são obrigatórias:

• Estratégia API forte
• Governança completa das APIs externas e internas (inclusive entre serviços e Microsserviços)
• Utilização de todas as capacidades das Plataformas API (conforme descrito no nível 6)
• Forte compliance com regulamentos (por exemplo, PSD2)
• Arquitetura de micro-serviços maduros usando service mesh
• Forte infra-estrutura e fundação baseada em nuvens
• Múltiplos protocolos de comunicação gerenciados tais como RESTful, GraphQL, WebSockets, gRPC, etc.

‍

O Vencimento Roadmap

Uma vez que você tenha avaliado sua empresa e percebido qual é o nível e qual o nível que sua empresa deseja ser. Você pode criar um roadmap para a evolução, é claro que os detalhes deste plano dependem de vários fatores, tais como os motores do negócio, restrições técnicas e perspectivas futuras.

Entretanto, quando você estiver criando seu plano, recomendamos que você considere algumas dicas, por exemplo:

• Antes de mais nada, passe do nível 4 para o nível 5, em vez disso do nível 4 para o nível 7, passos de bebê!
• Escolher um projeto MVP para testar alguns pontos, começar pequeno, testar, aprender e aplicar recomendações
• Comece com APIs internas e controladas
• Definir alguns padrões API e estabelecer padrões mínimos API governance.

‍

Conclusões

De fato, para participar de alguma forma do API Economy , sua empresa precisa gerenciar suas APIs para contextos internos ou externos. Não importa em que nível sua empresa seja colocada, a empresa pode iniciar uma Estratégia API, por exemplo, criar ecossistemas de parceria construídos sobre APIs.

O foco principal deste artigo é apontar quão madura é a arquitetura para alguns cenários para entender qual é a melhor solução técnica e estratégia técnica a ser usada a fim de fornecer uma arquitetura API madura de acordo com os requisitos comerciais e técnicos.

Se você quiser alguma ajuda nesta viagem, pode entrar em contato conosco!

‍