Según una encuesta realizada por McKinsey Global, a consecuencia de la crisis del COVID-19 las empresas han acelerado su transformación digital el equivalente a 3 o 4 años en unos pocos meses [1]. Los proveedores de servicios de comunicaciones (CSP) son protagonistas de la transformación digital del resto de los sectores ya que los alimentan proporcionando un importante habilitador de la digitalización: los servicios de comunicaciones. Es por ello, que los CSP han tenido un incremento de volumen de negocio que ha desafiado los límites de las infraestructuras de comunicaciones.
Echemos un vistazo a los principales desafíos a los que se enfrentan los CSP actualmente:
El desafío fundamental de los CSP es hacer frente un mercado con una competición disruptiva y con una cambiante demanda de sus clientes. Esta demanda de servicios de comunicaciones está creciendo de forma exponencial, pero entre la fiera competencia, y la demanda de precios más económicos por parte de los clientes más las frecuentes inversiones necesarias para satisfacer la demanda, hacen que el margen de maniobra de los CSP para el crecimiento orgánico y la innovación sean limitadas.
Para hacer frente a la fuerte demanda y a la competencia cada vez más ágil, los CSP necesitan cambiar su modelo de negocio y sus procesos transformando la agilidad en la toma de decisiones, la cultura, forma de trabajar y sistemas que los soportan. Es decir, necesitan una transformación digital que les permita evolucionar desde proveedores de productos tradicionales de conectividad hacia un modelo de productos “as a service” que les permita ir más allá y convertirse en proveedores de servicios digitales (DSP).
Un ejemplo de servicio digital es el concepto de Connectivity as a service (CaaS). El poder obtener servicios de comunicaciones a medida a golpe de click es algo que cada vez está más cerca y será demandado por los clientes según tecnologías como 5G vayan ganando tracción. En un mundo hiperconectado como el que se avecina, la conectividad como servicio puede tener un carácter tan temporal como la retransmisión en directo de un partido de futbol en 8k con unas necesidades de calidad muy concretas y a medida del evento. ¿Cómo puede un CSP conseguir tal cosa?
¿Cómo la industria encara los desafíos de las OpenAPIs?
Gran parte de los actores de esta industria se agrupan a través de TM Forum, una alianza de más de 850 empresas que trabajan juntas para romper las barreras entre los principales “players” del sector. Sus miembros incluyen proveedores de servicios digitales y de comunicaciones, compañías telefónicas, operadores de cable, operadores de red, proveedores de nube, proveedores de infraestructura digital, proveedores de software, proveedores de equipos, integradores de sistemas y consultorías de gestión.
La clave es que TM Forum ayuda a construir un ecosistema entre CSP y proveedores de soluciones de forma que puedan trabajar y ser más eficientes en ayudar a la industria a plantar cara a sus desafíos. Entre otras cosas TM Forum ayuda a:
- Planificar y gestionar el camino hacia la transformación mediante herramientas, como el Modelo Digital de Madurez.
- Resolver problemas rápido mediante el uso de la inteligencia colectiva de telcos y proveedores para crear herramientas y marcos de trabajo ampliamente adoptados, tales como las Open API, que dirijan la ejecución de la transformación.
- Acelerando la innovación a través de pruebas de concepto rápidas como Catalyst Programs y sirviendo como punto de encuentro para el desarrollo colectivo implementaciones de referencia.
Las herramientas más destacables para este viaje transformador son las metodologías agiles, OpenAPI y cloud-native.
OpenAPI las habilitadoras de la interoperabilidad y la automatización
Las API (Application Program Interfaces) son herramientas clave para todo tipo de negocios e industrias. Desde un punto de vista técnico, permiten la interoperabilidad entre distintos sistemas o aplicaciones y, por ende, las organizaciones. Es por ello, por lo que las API están alimentando una nueva ola de innovación centrada en los servicios digitales que catalizan la colaboración y asociación de empresas para conformar verdaderos ecosistemas digitales.
El término OpenAPI es en realidad sinónimo de OpenAPI Specification. La OpenAPI Specification define un interfaz estándar y agnóstico del lenguaje para APIs HTTP, que permite tanto a humanos como a máquinas descubrir y comprender las capacidades de un servicio sin necesidad de acceder al código fuente, documentación o inspección del tráfico [3].
La OpenAPI Specification está definida y gobernada por el The OpenAPI Initiative (“OAI”), que es un consorcio de expertos de la industria que han sabido reconocer el inmenso valor que aporta estandarizar la forma en la que se describen las API. [4]
Siguiendo la OpenAPI Specification es posible describir un API REST incluyendo la siguiente información:
- Endpoints y sus operaciones (GET /user, POST /users)
- Parámetros de entrada salida para cada operación
- Métodos de autenticación
- Información de contacto, licencia, términos de uso, etc…
Una descripción OpenAPI puede ser utilizada entonces por herramientas automáticas (como Swagger [6]) para generar documentación, código para servidores y clientes, código para pruebas y otros muchos casos de uso más.
TM Forum OpenAPIs como habilitador de los ecosistemas digitales
En la era de los ecosistemas digitales, las TM Forum OpenAPI son una valiosa herramienta para romper las barreras de integración que bloquean la transformación digital de los CSP.
Las TM Forum OpenAPI son una suite de +50 API, desarrolladas colaborativamente por miembros de TM Forum, para habilitar los ecosistemas digitales. Estas permiten gestionar los servicios digitales desde el principio al final de su ciclo de vida en un entorno en el que hay múltiples socios envueltos en la prestación del servicio. Las API están basados en patrones de diseño fuertemente establecidos en la industria que permiten su rápida implementación.
La clave de su éxito es su clara orientación práctica aportando especificaciones, implementaciones de referencia y tests de conformidad. Esto facilita una rápida implementación de las API que contribuye a construir soluciones ágiles y efectivas en costes.
Resulta muy interesante explorar el TM Forum Ecosystem API Portal [8] que sirve como guía para la adopción e implementación de estas API. Particularmente valiosa, para todo el que quiera adoptar una iniciativa de estandarización similar en otros dominios, es la guía de diseño de API TMF630 [9]. También la documentación de cada API en la tabla de OpenAPI puede dar pie a adoptar una de estas API o servir como fuente de inspiración para otras de ámbitos similares.
Las TM Forum OpenAPI son un estándar de facto que cada vez más CSP adoptan y exigen a sus proveedores. Como se puede ver en la figura, hoy la industria está moviéndose linealmente hacia una adopción madura de las OpenAPI. Se puede tomar el pulso al compromiso de la industria por su adopción y uso echando la vista a los firmantes de los manifiestos de Nivel 1: “OpenAPI Manifesto” y Nivel 2: “OpenAPI & Open Digital Architecture”. Si observamos el dashboard de Open API para marzo de 2021 podemos sacar conclusiones sobre el interés que despiertan. Aparte de los múltiples beneficios que aporta la adopción de OpenAPIs, estas allanan el camino hacia una arquitectura de microservicios como primer paso para transformar los sistemas de los CSPs en cloud-native, y así facilitar la migración hacia un modelo basado en cloud.»Las tecnologías “Cloud Native” empoderan a las organizaciones para construir y correr aplicaciones escalables en ambientes dinámicos modernos, como lo son hoy las nubes públicas, privadas o híbridas. Temas como contenedores, mallas de servicios, microservicios, infraestructura inmutable y API declarativas son ejemplos de este enfoque. Estas técnicas permiten crear sistemas de bajo acoplamiento que son resilientes, administrables y observables. Combinado con técnicas de automatización robusta les permite a los ingenieros realizar cambios de alto impacto de manera frecuente y predecible con un mínimo esfuerzo» [12]. Como los CSP ofrecerán cada vez más productos y servicios basados en la cloud tiene mucho sentido que los sistemas que les permiten proporcionar dichos productos y servicios también estén basados en la cloud.El proceso de mejora continua para la migración incluye etapas donde refactorizar los sistemas de información a un modelo cloud-native a través del uso de OpenAPI es parte fundamental. Es más, las OpenAPI son habilitadoras para que los CSP puedan adquirir o gestionar sus sistemas de información en un modelo SaaS (Software as a Service).Open digital architecture para completar la transformación
Como ya hemos visto, la adopción de OpenAPI por parte de proveedores y CSP va a hacer posible la interoperabilidad entre distintos componentes software provenientes de múltiples proveedores u otros CSP. Esto va a transformar la manera de afrontar integraciones y customizaciones de un modelo rígido, con altos costes económicos y temporales, y muchas veces mono vendedor con una fuerte dependencia del proveedor de productos y servicios, que hace que no sea posible sustituirlo sin afrontar costos sustanciales “vendor lock-in” hacia un modelo multi proveedor flexible que permite el ensayo error y fomenta la innovación. Este modelo flexible combinado con el carácter cloud-native que cada vez más van adoptando las soluciones software desemboca en un modelo tipo Marketplace donde los CSP podrán adquirir soluciones según el modelo SaaS.
Para avanzar desde un conjunto de OpenAPI a un Marketpace de componentes en el que los CSP pueden adquirir y configurar de forma ágil y sencilla sus componentes, TM Forum dio el paso en 2018 al apostar por la definición de una arquitectura que dé forma a esos componentes. Esta arquitectura es la Open Digital Architecture (ODA).
La Open Digital Architecture define un marco de trabajo de arquitectura, lenguaje común y principios de diseño. Los cimientos de esta arquitectura son componentes software interoperables organizados en dominios que exponen servicios de negocio a través de OpenAPI. La anatomía de un componente ODA es la de la siguiente figura.
Como se puede observar los componentes ODA expone y consume servicios a través de OpenAPI exclusivamente. Las API de Security, Notification/Response, Management/Ops y Environment Depencence/Requirements serán idénticas en todos los componentes ODA, sin embargo, serán las API de Core Function las que variarán de componente a componente.Esta anotomía está diseñada para facilitar al máximo el modelo Marketplace, así un componente puede describirse así mismo indicando cuál es su función y cuáles son sus dependencias. De esta manera, un componente una vez configurado y desplegado puede exponer sus capacidades y descubrir otros componentes y empezar a interoperar de manera autónoma.ODA aún se encuentra en proceso de definición, pero el trabajo realizado desde 2018 ha permitido establecer los principios y visión de la arquitectura a la par de la definición de los componentes ODA. Actualmente los esfuerzos están centrados en definir un inventario de componentes ODA junto con sus Core Functions para soportar el ecosistema digital, así como en proporcionar una implementación de referencia para estos componentes. De esta manera se continua con el modelo TM Forum OpenAPI a nivel de componente proporcionando especificaciones implementaciones de referencia y herramientas para testear la conformidad de los componentes ODA frente a las especificaciones para asegurar su interoperabilidad.¿Dónde está SATEC?
Satec tiene una gran experiencia en integraciones y desarrollos de soluciones BSS/OSS para CSP como Orange o Telefónica entre otros. Durante los más de 30 años que llevamos haciendo proyectos donde seleccionamos e integramos las mejores soluciones del mercado para traer valor a los CSP, hemos visto como estos sufrían las dificultades expuestas al principio del artículo que impiden la innovación y la agilidad necesaria para su transformación digital. Por ello decidimos crear alvatross, una división de producto dentro de Satec que ofrece productos OSS. Los productos de alvatross nacieron siguiendo la estrella polar de las OpenAPI y con el modelo colaborativo de TM Forum en el ADN. Estos productos permitirán a los CSP lanzar al mercado productos y servicios mucho más rápido, cubriendo el ciclo completo de fulfillment de servicios a través de una plataforma cloud-native basada en microservicios y OpenAPIs.
Satec siempre utiliza los últimos paradigmas, tecnologías y metodologías en nuestras soluciones y productos. Somos especialmente innovadores en el uso de OpenAPI, AIOps, RPA y microservicios.
Para seguir a la vanguardia de la tecnología somos firmantes del manifiesto de Nivel 2de “Open API & Open Digital Architecture” de TM Forum, y además participamos activamente en las iniciativas de TM Forum para que ODA (Open Digital Architecture Component Accelerator) se convierta en una realidad.
“Si quieres saber más no dudes contáctarnos”
[1] McKinsey, «How COVID-19 has pushed companies over the technology tipping point,» [En línea]. Available: https://www.mckinsey.com/capabilities/strategy-and-corporate-finance/our-insights/how-covid-19-has-pushed-companies-over-the-technology-tipping-point-and-transformed-business-forever.
[2] S. LABS, «Open APIs will Drive Innovation in a Mobile World,» [En línea]. Available: https://labs.sogeti.com/open-apis-will-drive-innovation-in-a-mobile-world/.
[3] O. Initiative, «OpenAPI Initiative,» [En línea]. Available: https://spec.openapis.org/oas/v3.1.0.
[4] «OpenAPI initative,» [En línea]. Available: https://www.openapis.org/about.
[5] Swagger, «OpenAPI definiton basic structure,» [En línea]. Available: https://swagger.io/docs/specification/basic-structure/.
[6] Swagger, «Swagger,» [En línea]. Available: https://swagger.io/.
[7] K. Vasudevan, «The Benefits of OpenAPI-Driven API Development,» [En línea]. Available: https://swagger.io/blog/api-strategy/benefits-of-openapi-api-development/.
[8] T. Forum, «TM Forum Ecosystem API Portal,» [En línea]. Available: https://projects.tmforum.org/wiki/display/API/TM+Forum+Ecosystem+API+Portal.
[9] T. Forum, «TMF630 API Design Guidelines 4.0.1,» [En línea]. Available: TMF630 API Design Guidelines 4.0.1.
[10] T. Forum, «Open API & Open Digital Architecture Manifesto,» [En línea]. Available: https://www.tmforum.org/oda-interactive-map/open-digital-architecture-open-api-manifesto/.
[11] T. Forum, «Open API dashboard,» [En línea]. Available: https://www.tmforum.org/wp-content/uploads/2021/04/TM_Forum_Open_APIs_Dashboard_March_2021.pdf.
[12] T. Forum, «IG1221 BSS/OSS Cloudification Guide part 1,» 2020.
[13] T. Forum, «IG1171 ODA Component Definition,» 2019.