APIs
7
min de lectura
2 de enero de 2019

Modelo de madurez de la arquitectura de la API

Rafael Rocha
Head de Soluciones y Preventa
Tecnólogo en Tecnología de la Información de la UNESP y postgrado en MBA Business Management de la UNIMEP.
Más sobre el autor

¿Su empresa está lista para API Economy en 2021?

Esta reflexión es para tener en cuenta en las resoluciones de fin de año. Los arquitectos de TI y estrategas digitales deben tenerlo en cuenta para planificar. Claro, si desean que su empresa implemente API Economy. Sin embargo, esta reflexión inicial debe invitarlo a identificar las condiciones actuales y cuán madura es la arquitectura de TI de su empresa para apoyar las iniciativas de las APIs. Luego de evaluar su condición actual, Piense ¿En qué condición debe estar su Arquitectura de TI en el futuro? Usted se debe estar preguntando, ¿Qué tipo de arquitectura es crucial para este escenario?

Bueno, básicamente la arquitectura del sistema y en especial la arquitectura de integración. La arquitectura del sistema es vital para cumplir el propósito del negocio. Por ejemplo, Una aplicación puede escalar cuando la compañía hace que sus APIs sean OPEN. Pero, qué hay de las integraciones. Técnicamente las APIs son la interfaz de las integraciones, lo que requiere cierta estandarización y tecnología.

Para ayudarle a identificar la condición actual y la condición que desea en el futuro, podemos utilizar un modelo de madurez específico para el sistema y la arquitectura de integración que apoyará las iniciativas de las API.

Clasificación de madurez en la arquitectura de la API.

Este modelo de madurez se divide en 7 niveles. Estos están agrupados en 3 clasificaciones que son:

  • Arquitectura no basada en APIs En algunos casos el sistema de integración que no se basa en APIs, no tiene comunicación entre los distintos canales y en otros suelen compartir algunos archivos, utilizando colas, servicios web no estructurados o incluso hacen algunas tecnologías TCP/Socket para proporcionar la comunicación entre aplicaciones.

  • Arquitectura parcialmente basada en APIs La arquitectura parcialmente basada en APIs tiene una alta frecuencia de uso de los servicios web (SOAP y REST), utilizan recursos como el Repositorio de Servicios y el Portal del Desarrollador pero con un bajo nivel de gobernanza. Normalización y separación de preocupaciones entre las API y los Servicios.

  • Arquitectura totalmente basada en APIs Arquitectura de sistema y de integración totalmente basada en APIs. Esto significa que se dividen las preocupaciones en capas como API, Servicios y Aplicaciones. Desde el punto de vista empresarial, las API son la base de los nuevos modelos de negocio o en algunos casos el modelo de negocio depende completamente de las API. También se observan otras características y capacidades técnicas como fuertes mecanismos de seguridad, API governance, monitorización, analytics medida y mejora de la API Developer Experience.

¿En qué nivel de madurez se encuentra la arquitectura de su empresa?

Este modelo de madurez cuenta con 7 niveles para clasificar el estado de la arquitectura de TI las empresas:

Modelo de madurez de la arquitectura de la API - Sensedia

Nivel 1 - Aplicaciones aisladas (Isolated Applications)

La arquitectura del sistema en este caso se basa en aplicaciones aisladas con integraciones bajas o nulas. Los principales tipos de aplicaciones son: Aplicaciones monolíticas, aplicaciones estándares como ERP o CRM.

Nivel 2 - Integraciones no estructuradas (Unstructured Integrations)

Hay integraciones entre aplicaciones pero no están estructuradas, lo que significa que no hay normas para la estructura de los mensajes o incluso tecnologías a utilizar. Además, los canales de integración están descentralizados (punto a punto), no hay ningún hub o algún tipo de bus Las integraciones se crean de forma ad-hoc. Por lo general, las tecnologías de integración utilizadas aquí son:

  • Message Queues
  • Sockets connections
  • Réplicas de la base de datos
  • Compartir archivos (por ejemplo, XML, CSV o EDI)

Nivel 3 - Arquitectura basada en componentes (Component-Based architectures)

Este nivel hace referencia a la arquitectura del sistema se basa en componentes, los principales modelos de arquitectura utilizados aquí son:

  • EJB (Enterprise Java Beans)
  • CORBA
  • Microsoft COM/COM+/DCOM
  • Aplicaciones autónomas de servicios web

Además, las principales tecnologías de integración son:

  • TCP/Sockets (Por ejemplo: Java RMI, COM, EJB)
  • Conexiones de enchufe personalizadas
  • Puntos finales HTTP (Por ejemplo: SOAP, RPC sobre HTTP)

El principal problema de este nivel son las integraciones e interfaces no tiene o tiene una pobre interoperabilidad porque las tecnologías utilizadas aquí sólo se comunican con la misma tecnología. Excepto los servicios web, pero esos servicios web no suelen seguir estándares y algún tipo de gobernanza que hace que la interoperabilidad sea más difícil de mantener.

Nivel 4 - Arquitectura orientadas al servicio

En este nivel, la arquitectura del sistema utiliza los principios de la SOA, por ejemplo hay una separación de las preocupaciones entre la capa de servicios y la capa de aplicaciones. Cuando la capa de aplicación suele depender de las capacidades de negocio y almacenamiento de datos, la capa de servicios se refiere a la estandarización de contratos, la abstracción, la componibilidad, el descubrimiento, etc.

Las principales características de la arquitectura del sistema son:

  • Aplicaciones monolíticas (Para la capa de aplicación)
  • Uso de la Pila SOA (ESB, BPEL, Procesadores de Eventos Complejos, Registros de Servicios, etc.)
  • Infraestructura en el lugar

Y las tecnologías de integración lo son:

  • Servicios web de SOAP
  • RESTFul de los servicios de la web (Uso incipiente)
  • Mensajes (Por ejemplo: JMS, ActiveMQ, etc.)

Por último, la principal cuestión relacionada con este nivel es que no hay separación de preocupaciones entre la Capa de Servicio y la Capa de API (Vea la imagen a continuación), sólo tiene una Capa de Servicio en la que se incorporan algunas capacidades de la API.

Servicio y Capa API

Nivel 5 - APIs privadas basadas en arquitecturas de microservicios

En este nivel, la arquitectura del sistema utiliza el enfoque de microservicios. Suele tener dos tipos de capas Front-End Layer y Back-End Layer donde residen los microservicios, en este tipo de arquitectura el papel de API Gateway aparece en algunos casos para proporcionar la integración entre el Front-End y el Back-End. Las clasificamos como APIs privadas porque sólo las aplicaciones internas del front-end utilizan esas APIs.

Las principales características de la arquitectura del sistema son:

  • Uso del patrón de microservicio
  • Puertas de enlace API
  • En su mayoría basados en la infraestructura y los contenedores de la nube.
  • El uso incipiente de Mesh Architecture

Y las principales tecnologías de integración utilizadas son:

  • RESTful APIs (Exposición al front-end o incluso comunicación entre microservicios)
  • AMQP (Por ejemplo: Kafka, RabbitMQ, etc.)
  • Uso incipiente de nuevos protocolos de comunicación como gRPC, Thrift, etc.

El principal problema crucial relacionado con las APIs en este nivel es que las APIs no están totalmente gestionadas, lo que significa que sólo se utilizan algunas capacidades como la seguridad y el estrangulamiento que es proporcionado por un único API Gateway. Otra característica crucial es que las APIs de los microservicios tampoco están gestionadas, lo que significa que la comunicación es punto a punto sin un gobierno centralizado (Falta la capacidad de Mesh Architecture)

Otro punto a observar es que la arquitectura basada sólo en Gateways API únicos no es fácil de ser extensible para toda la empresa, recomendamos encarecidamente el uso de la Plataforma API para sostener la evolución de este tipo de arquitectura.

Para todos los temas relacionados con los anteriores, clasificamos este nivel como parcialmente basado en los API.

Nivel 6 - APIs abiertas

La empresa suele tener algunas características técnicas de otros niveles, pero la principal característica técnica es tener una Capa API encima de la Capa de Servicio, la Capa de Aplicación o incluso la Capa de Back-end (Microservicios).

En este caso, las API forman parte del negocio de la empresa una vez que su negocio se incrementa por las API. Esto significa que pueden crear un ecosistema de asociación y un entorno de innovación abierta, este escenario crea una nueva corriente de valor y servicios innovadores.

Bajo la perspectiva técnica se observan otras características:

  • Utilización de plataformas de API comerciales o de código abierto y sus módulos, como se indica a continuación
  • Uso del Portal del Desarrollador para aumentar Developer Experience de los socios y startups
  • Uso de Analytics Módulos para monitorear el comportamiento técnico y comercial
  • Fuertes restricciones de seguridad usando protección WAF y DDoS.
  • RESTful APIs como estándar para la integración externa.

Nivel 7 - APIs como negocio

Como el nombre sugiere, en este nivel el negocio de la compañía está totalmente basado y es totalmente dependiente de las API.

Desde el punto de vista técnico, algunas características son obligatorias:

  • Fuerte estrategia de API
  • Plena gobernanza de las API externas e internas (Incluso entre servicios y microservicios)
  • Uso de todas las capacidades de las plataformas de API (Como se describe en el nivel 6)
  • Fuerte compliance de regulaciones (PSD2 por ejemplo)
  • La arquitectura de microservicio madura usando service mesh
  • Infraestructura y fundamentos sólidos basados en la nube
  • Múltiples protocolos de comunicación administrados como RESTful, GraphQL, WebSockets, gRPC, etc.

La madurez del Roadmap

Una vez que haya evaluado su compañía y se haya dado cuenta del nivel en el que se encuentra y del nivel al que desea llevar a su compañía. Puedes crear un roadmap para la evolución, por supuesto los detalles de este plan dependen de varios factores como los business drivers de la empresa, las limitaciones técnicas y las perspectivas de futuro.

Sin embargo, al crear su plan, le recomendamos que considere algunos consejos.

  • En primer lugar, pasar del nivel 4 al nivel 5 en lugar del nivel 4 al nivel 7. Un nivel a la vez ¡Baby steps!
  • Elija un proyecto cree un MVP para validar algunos puntos. Empezar pequeño, probar, aprender y aplicar las recomendaciones.
  • Empieza con las APIs internas y controladas
  • Definir algunos patrones de API y establecer un mínimo de API governance.

Conclusiones

Para participar de alguna manera en API Economy su empresa necesita gestionar sus API para contextos internos o externos. Independientemente del nivel en el que se encuentre su empresa, ésta puede iniciar una estrategia de API, por ejemplo, crear ecosistemas de asociación basados en las API.

El enfoque principal de este artículo es señalar cuán madura es la arquitectura para que algunos escenarios comprendan cuál es la mejor solución técnica y la estrategia técnica que se debe utilizar para proporcionar una arquitectura API madura de acuerdo con los requisitos comerciales y técnicos.

Si quieres ayuda en este viaje, puedes contactarnos .


¿Desea saber más? Hable con uno de nuestros especialistas, basta colocar los datos en el formulario abajo y luego entraremos en contacto ;)

¡Gracias por leer!