¿Qué diablos es un NGOSS? He usado mucho el término, relacionado con el «Contrato NGOSS», pero para aquellos que no están familiarizados con el espacio OSS/BSS o el TMF, puede ser misterioso. Tata Consultancy Services, una firma de servicios profesionales grande y activa, recientemente hizo un documento sobre «reimaginar» el OSS/BSS, un documento de TMF que pregunta si hay vida más allá de los servicios de conectividad. Hay interesantes contrastes y similitudes entre los dos documentos, que vale la pena explorar.
NGOSS significa «Sistema de Soporte de Operaciones de Próxima Generación». Es un término que se ha utilizado ampliamente durante al menos 15 años, y a menudo es utilizado por TMF en sus especificaciones. Sin embargo, muchas de las cosas de TMF son solo para miembros, por lo que no puedo citarlas (o, si no soy miembro en ese momento, ni siquiera puedo acceder a ellas), excepto resumiendo. El documento de TMF es particularmente útil debido a esto; es un resumen público de la forma en que el cuerpo ve el futuro de la «transformación». El artículo de Tata es interesante porque refleja una visión de servicios profesionales del mismo proceso de transformación.
La apertura del papel Tata tiene los tópicos habituales sobre el ancho de banda. «A medida que las empresas se adaptan cada vez más a un modelo predominantemente en línea en línea con la nueva realidad, la necesidad de un alto ancho de banda y servicios de red confiables está aumentando. En consecuencia, los proveedores de servicios de comunicaciones (CSP) están experimentando una demanda exponencial de servicios y dependen de los avances en las tecnologías de virtualización para seguir escalando al ritmo actual.»
El problema con esto, además de su estado de trivialidad (una declaración de demanda «exponencial» más y vomito), es que el problema real no es el crecimiento de la demanda, es la contracción de las ganancias. Ningún operador estaría descontento con el crecimiento de la demanda de ancho de banda si pudiera cobrar de forma incremental por el crecimiento. No pueden, por lo que necesitan encontrar algo que no sea ancho de banda para vender, o reducir el costo de producir ancho de banda para compensar el hecho de que los servicios de mayor ancho de banda no generan precios proporcionalmente más altos.
Este mismo problema colorea la siguiente sección, que se llama «Repensar la función OSS». Cita los objetivos de TMF para la modernización del OSS, ninguno de los cuales implica siquiera abordar ese problema de compresión de beneficios. De hecho, esa sección del documento es la razón por la que muchos estrategas de operadores están a favor de desechar todo el asunto de OSS/BSS y comenzar de nuevo. No es que no se establezcan objetivos útiles (la automatización es uno de los atributos de un futuro OSS/BSS), sino que no se dice mucho sobre alcanzarlos.
Que viene en la siguiente sección, que se llama «Conducción de funciones OSS bien orquestadas». Esta sección finalmente hace una recomendación que es útil; OSS / BSS tiene que estar basado en eventos. Tenía esperanzas aquí, porque el TMF fue de hecho la fuente del concepto clave en OSS y automatización de operaciones, ese Contrato NGOSS que mencioné al comienzo de este blog. Lamentablemente, ni el término ni el concepto se plantean en el documento de Tata. Lo que dice es que «las futuras funciones de OSS deben crearse y ofrecerse como servicios compuestos de microservicios para admitir la orquestación automatizada de extremo a extremo de recursos de red híbridos (físicos, lógicos y virtuales).»
El documento de TMF, por el contrario, comienza con la declaración de que » la conectividad se ve con razón como un negocio de bajo margen y se está mercantilizando rápidamente.»El objetivo de los operadores es» hacer que su mundo interior sea el correcto con una base tecnológica ágil y un modelo operativo.»El TMF obviamente incluye su objetivo principal de OSS / BSS en este mundo interior, pero del mismo modo, obviamente, la base de tecnología ágil tiene que extenderse a la infraestructura.
El mecanismo para poner su «mundo interior en orden» es, por implicación, 5G. El TMF dice que es crítico para «aprovechar al máximo el cambio enormemente costoso a 5G». Pero eso parece contradicho en el siguiente párrafo, donde el ex CEO del foro dice «Para los consumidores y las personas de hogares inteligentes, la ‘conectividad’ tiende a tener un valor intrínseco y es una cosa válida para comprar. Sin embargo, a medida que subes de escala en el ámbito de la transformación de la industria, la conectividad solo se valora en la medida en que está vinculada a la solución: «No quieren comprarte conectividad, quieren comprar una solución.»La 5G es claramente una estrategia de conectividad para los consumidores, como lo es toda la infraestructura del mercado masivo. Si suponemos que «subimos la escala en el ámbito de la transformación de la industria», es decir, los servicios empresariales, la clave está en vender soluciones.
Esto parece argumentar que los operadores deben centrar su negocio de «proveedor de servicios digitales» en las empresas, y para proporcionar soluciones debe haber un proveedor SaaS. ¿Es realmente un enfoque inteligente, dado que hay un negocio de nube pública altamente activo y competitivo que ya vende soluciones a esos clientes? ¿Especialmente cuando la mayoría de los problemas de beneficio por bit que tienen los operadores provienen de los servicios al consumidor de todo lo que pueda comer?
La resolución, dice una cita de Vodafone y otros comentarios en el documento de TMF, es que «lo que ahora llamamos ‘servicios’ no involucrará solo a las empresas de telecomunicaciones, sino que comprenderá una gama de socios, incluidas las empresas de telecomunicaciones.»Por lo tanto, las empresas de telecomunicaciones no son en realidad proveedores de servicios digitales, sino integradores de servicios digitales o revendedores. ¿Puede una empresa que está considerando la transformación como un medio para escapar de la presión de los beneficios permitirse ser revendedor de los servicios de otro jugador?
Me parece que la visión de TMF realmente no apunta más allá del OSS/BSS en absoluto, sino que sugiere que las operaciones y los servicios evolucionan a algo por encima de la conectividad al asociarse con aquellos que suministran servicios allí. Eso podría estar frustrando todo el propósito de la» transformación digital», encerrando a las empresas de telecomunicaciones no solo en su nivel actual de desintermediación y mercantilización, sino también en un nivel completamente nuevo.
Ambos documentos parecen sugerir que la transformación OSS/BSS es esencial, y al menos implican que un enfoque basado en eventos es la respuesta. En realidad, es una buena idea, pero se pierde el desafío de «¿cómo?»Para ser impulsado por eventos, un sistema tiene que reconocer tanto el concepto de eventos (obviamente) como el concepto de «estado» o contexto. Cualquiera que haya visto un manejador de protocolo sabe que el mismo mensaje, en diferentes contextos / estados, debe procesarse de manera diferente. Por ejemplo, obtener un mensaje de » paquete de datos «en el estado» ordenable «para un servicio es claramente un error, mientras que está bien en el estado de» transferencia de datos». Para que haya estados y eventos y procesos relacionados, necesita una tabla de estado / evento.
Las tablas de estado / evento son descripciones de los contextos colectivos de un sistema cooperativo, y pensar en construirlas es útil ya que obliga a los arquitectos de software a considerar todas las posibilidades, en lugar de que suceda algo que se caiga por las grietas. Sin embargo, existe un conflicto potencial entre el valor de las tablas de estado/evento y el número de posibles estados y eventos. Si nos fijamos en una red compleja como un sistema enorme y plano, tendríamos una mesa demasiado grande para implementarla. El TMF y mi propio trabajo de ExperiaSphere trataron con esto dividiendo sistemas complejos en «modelos de intención» que cada uno tenía sus propias relaciones estado/evento. Composición jerárquica, en resumen. Eso es lo que el contrato de NGOSS describió.
El punto aquí es que ambos documentos pierden lo que debería ser su propio punto fuerte, que es que la dirección de eventos a procesos basada en modelos de datos a través de tablas de estado/eventos alineadas con componentes es la forma de crear un comportamiento basado en eventos y un diseño compatible con microservicios. Si un modelo de datos de servicio dirige un evento a un proceso, el proceso puede obtener la información que necesita solo del modelo de datos de servicio, lo que significa que no tiene estado y se puede implementar como un microservicio o incluso en forma sin servidor.
Si elimina el enfoque de contrato NGOSS de la historia de modernización de OSS / BSS, se quedará con lo que ha plagado toda la noción de modernización de OSS/BSS desde los primeros lugares: lugares comunes. Podemos hablar de abajo hacia arriba y de arriba hacia abajo, siempre y cuando nos centremos en metodologías de proyectos, pero una metodología de proyecto impulsa un proyecto, no escribe software. De la metodología debe surgir una arquitectura de software. Ese es un elemento separado, un resultado del proceso correcto, pero no es la consecuencia automática de agitar una varita sobre un montón de datos y cantar » ¡de arriba hacia abajo, de arriba hacia abajo!»
Que resume mi problema con el papel Tata. Las metodologías de proyecto en TI y redes conducen a arquitecturas de aplicaciones o servicios, que luego enmarcan los requisitos para los componentes de la solución y la forma en que se integran y administran. El proyecto no es la salida, es la ruta a la salida. El problema con el documento de Tata es que es otra descripción de una metodología de proyecto (buena, pero no transformadora), en un momento en que hace mucho que no buscamos un camino hacia la modernización de OSS y, en cambio, estamos buscando productos específicos, o al menos arquitecturas. El TMF parece dirigirse al mismo lugar por un camino diferente: transfórmate en asociación con tus antiguos enemigos.
El documento de Tata, en la sección llamada «El papel de los estándares de la industria», señala un problema importante, uno tan importante que en realidad podría ser la barrera para avanzar hacia el objetivo de modernización de OSS. El documento cita los modelos TMF y ONF para el diseño de arriba hacia abajo, pero en todo el documento está claro que el OSS/BSS «modernizado» tiene que estar más estrechamente integrado con el resto del ecosistema de redes y servicios. Tenemos estándares para cada pieza posible de cada estrategia de red posible, y en algunos casos los estándares incluso compiten. Recientemente escuchamos aplausos por la unificación de dos especificaciones de API de operaciones diferentes, por ejemplo. Deberíamos preguntarnos cómo llegamos a tenerlos en primer lugar.
El documento de TMF parece no solo aceptar esta fragmentación del futuro, sino depender de ella. Ceda la mecanización de cosas más allá de OSS/BSS, y enfócate en aprovechar esas cosas «más allá» para crear servicios como un pseudo-integrador. OK, puede que no sea una visión irrazonable para el TMF (un organismo dominado por OSS/BSS), pero es una fórmula para mantenerse desorganizado mientras enfrenta lo que casi tiene que ser una iniciativa unificada: la transformación.
En mi opinión, el TMF fue el cuerpo lógico para modernizar el OSS/BSS, y que el TMF (con el Contrato NGOSS) ideó el paradigma central de la dirección de eventos a los procesos a través de un modelo de datos, que es crítico para esta modernización. Todo lo demás que describen los documentos, cada API que alguien está desarrollando o armonizando, cada actividad de estándares dirigida a cualquier aspecto de las operaciones y la gestión, debe encajar en ese marco contractual NGOSS. Si eso se hiciera, el resultado sería exactamente lo que significa «NGOSS».
El modelo del contrato TMF NGOSS es igual de valioso, o incluso más valioso, si entras en el dominio de red. Un verdadero proceso de estado / evento de «contrato» podría administrar todo lo relacionado con el ciclo de vida del servicio, incluida la pieza de red. De ello se desprende que una solución centrada en la red podría extenderse fácilmente al dominio de servicio, OSS / BSS. La universalidad del enfoque es buena para la industria, porque la automatización del ciclo de vida del servicio debe ser universal para ser útil.
También debería basarse en el pensamiento en la nube de última generación. Ambos documentos parecen estar de acuerdo con eso, y sin embargo, ambos eluden la cuestión de cómo lograrlo. Si está planeando usar herramientas actuales para lograr algo, tiene que enmarcar su enfoque en términos de esas herramientas. No puede aceptar la idea de que puede escribir especificaciones para todo, o simplemente traducir los objetivos en la parte superior a características arbitrarias en la parte inferior. Eso es especialmente probable que te afecte, dado que los procesos de estándares tardan años en llegar a una conclusión. Estamos implementando 5G hoy y los estándares no están terminados, y probablemente no lo estarán hasta 2022. Me pregunto si hay tiempo para eso, dado que los operadores ya se enfrentan a la caída de los ROI de infraestructura que se acercan al punto crítico.
El contrato NGOSS ha existido durante aproximadamente 13 años, y la TMF me dijo una vez que había ganado una tracción muy limitada. No parece que se juegue en el material actual de TMF, aunque como he dicho, no tengo acceso a las cosas solo para miembros. La pregunta, entonces, es si el TMF está preparado para promover su propia (deslumbrante y única) visión, primero dentro del estrecho dominio OSS/BSS y luego en la misión de automatización del ciclo de vida más amplio. Si lo hace, TMF asume el papel que le corresponde en NGOSS evolution y define la base para la automatización del ciclo de vida del servicio en general. Si no lo hace, dependerá de algún otro organismo de estándares o grupo de código abierto recoger la antorcha, y la TMF tendrá que luchar por la relevancia en su propio espacio.
