APIs
7
min de leitura
2 de janeiro de 2019

Modelo de Maturidade da Arquitetura API

Rafael Rocha
Head of Solutions and Presales
Tecnólogo formado em Tecnologia da Informação pela UNESP e pós-graduado em MBA em Gestão Empresarial pela UNIMEP.
Mais sobre o autor

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:

modelo de maturidade da arquitetura api - Sensedia

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.

Serviço e camada API

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!


você quer saber mais? Fale com um de nossos especialistas, basta preencher o formulário abaixo e logo entraremos em contato;)

Obrigado pela leitura!