Qu’est-ce qu’un NGOSS ? J’ai beaucoup utilisé le terme, relatif au « contrat NGOSS », mais pour ceux qui ne connaissent pas l’espace OSS / BSS ou le TMF, cela peut être mystérieux. Tata Consultancy Services, une grande entreprise de services professionnels active, a récemment publié un article sur la « réimagination » de l’OSS / BSS, un document TMF demandant s’il existe une vie au-delà des services de connectivité. Il existe des contrastes et des similitudes intéressants entre les deux documents, qui méritent d’être explorés.
NGOSS signifie « Système de soutien aux opérations de nouvelle génération ». C’est un terme largement utilisé depuis au moins 15 ans, et il est souvent utilisé par le TMF dans ses spécifications. Une grande partie du contenu de TMF est réservée aux membres, et je ne peux donc pas le citer (ou, si je ne suis pas membre à l’époque, je ne peux même pas y accéder), sauf en résumant. Le document TMF est particulièrement utile à cause de cela; c’est un résumé public de la façon dont le corps voit l’avenir de la « transformation ». Le document Tata est intéressant car il reflète une vision des services professionnels du même processus de transformation.
L’ouverture du papier Tata a les platitudes habituelles sur la bande passante. « Alors que les entreprises s’adaptent de plus en plus à un modèle principalement en ligne conforme à la nouvelle réalité, le besoin de bande passante élevée et de services réseau fiables augmente. Par conséquent, les fournisseurs de services de communication (CSP) connaissent une demande exponentielle de services et dépendent des progrès des technologies de virtualisation pour continuer à évoluer au rythme actuel. »
Le problème avec cela, en plus de son statut de platitude (une déclaration de demande « exponentielle » de plus et je vomirai), est que le vrai problème n’est pas la croissance de la demande, c’est le rétrécissement des bénéfices. Aucun opérateur ne serait mécontent de la croissance de la demande de bande passante s’il pouvait facturer progressivement la croissance. Ils ne peuvent pas, ils doivent donc trouver autre chose que de la bande passante à vendre, ou réduire le coût de production de bande passante pour compenser le fait que les services à bande passante plus élevée ne génèrent pas de prix proportionnellement plus élevés.
Ce même problème colore la section suivante, appelée « Repenser la fonction OSS ». Il cite les objectifs de TMF pour la modernisation des systèmes d’exploitation, dont aucun n’implique même de traiter ce problème de compression des bénéfices. En fait, cette section du document explique pourquoi de nombreux stratèges d’opérateurs sont en faveur de la suppression de tout le système OSS / BSS et de tout recommencer. Ce n’est pas qu’aucun objectif utile n’est fixé (l’automatisation est l’un des attributs d’un futur OSS / BSS), mais que rien n’est dit pour les atteindre.
Cela vient dans la section suivante, qui s’appelle « Piloter des fonctions OSS bien orchestrées ». Cette section fait enfin une recommandation qui est utile; OSS / BSS doit être axé sur les événements. J’avais de l’espoir ici, car le TMF était en fait la source du concept clé de l’OSS et de l’automatisation des opérations — ce contrat NGOSS que j’ai mentionné au début de ce blog. Malheureusement, ni le terme ni le concept ne sont évoqués dans le document Tata. Ce qu’il dit, c’est que « les futures fonctions OSS doivent être créées et proposées sous forme de services composés de microservices pour prendre en charge l’orchestration automatisée de bout en bout des ressources réseau hybrides (physiques, logiques et virtuelles). »
Le document TMF, en revanche, s’ouvre sur la déclaration que « la connectivité est à juste titre considérée comme une activité à faible marge et se banalise rapidement. »L’objectif des opérateurs est de « redresser leur monde intérieur avec une base technologique agile et un modèle d’exploitation. »Le TMF inclut évidemment sa cible principale OSS / BSS dans ce monde intérieur, mais il est tout aussi évident que la base technologique agile doit s’étendre aux infrastructures.
Le mécanisme pour mettre de l’ordre dans leur « monde intérieur » est, par implication, la 5G. Le TMF dit qu’il est essentiel pour « tirer le meilleur parti du passage extrêmement coûteux à la 5G ». Mais cela semble être contredit par le paragraphe suivant, où l’ancien PDG du forum dit « Pour les consommateurs et les particuliers de la maison intelligente, la « connectivité » a tendance à avoir une valeur intrinsèque et est une chose valable à acheter. Cependant, à mesure que vous progressez dans le domaine de la transformation de l’industrie, la connectivité n’est valorisée que dans la mesure où elle est liée à la solution: « Ils ne veulent pas vous acheter de connectivité, ils veulent acheter une solution. » La 5G est clairement une stratégie de connectivité pour les consommateurs, comme l’est toute l’infrastructure du marché de masse. Si nous supposons que pour « monter en gamme dans le domaine de la transformation de l’industrie », c’est-à-dire des services aux entreprises, la clé est de vendre des solutions.
Cela semble plaider pour que les opérateurs concentrent leur activité de « fournisseur de services numériques » sur les entreprises, et pour fournir des solutions, il doit y avoir un fournisseur SaaS. Est-ce vraiment une approche intelligente, étant donné qu’il existe une entreprise de cloud public hautement active et compétitive qui vend déjà des solutions à ces clients? Surtout lorsque la majorité des problèmes de profit par bit que rencontrent les opérateurs proviennent de services à la consommation à volonté?
La résolution, selon une citation de Vodafone et d’autres commentaires dans le document TMF, est que « ce que nous appelons maintenant les « services » n’impliquera pas uniquement les opérateurs de télécommunications, mais comprendra une gamme de partenaires, y compris les opérateurs de télécommunications. » Ainsi, les opérateurs de télécommunications ne sont pas vraiment des fournisseurs de services numériques, mais des intégrateurs ou des revendeurs de services numériques. Une entreprise qui envisage la transformation comme un moyen d’échapper à la compression des bénéfices peut-elle se permettre d’être un revendeur des services d’un autre acteur?
Il me semble que la vision de TMF ne vise vraiment pas du tout au-delà du système d’exploitation / BSS, mais suggère plutôt que les opérations et les services évoluent vers quelque chose de supérieur à la connectivité en s’associant avec ceux qui fournissent des services là-haut. Cela pourrait aller à l’encontre de l’objectif de la « transformation numérique », enfermant les opérateurs télécoms non seulement dans leur niveau actuel de désintermédiation et de marchandisation, mais aussi dans un tout autre niveau.
Les deux articles semblent suggérer que la transformation OSS / BSS est essentielle, et impliquent au moins qu’une approche axée sur les événements est la réponse. C’est en fait une bonne idée, mais il manque le défi de « comment? »Pour être axé sur les événements, un système doit reconnaître à la fois le concept d’événements (évidemment) et le concept d ‘ »état » ou de contexte. Quiconque a déjà regardé un gestionnaire de protocole sait que le même message, dans différents contextes / états, doit être traité différemment. Par exemple, obtenir un message « paquet de données » dans l’état « commandable » pour un service est clairement une erreur, alors que c’est bien dans l’état « transfert de données ». Pour qu’il y ait des états et des événements et des processus associés, vous avez besoin d’une table d’état / événement.
Les tables d’état/d’événement sont des descriptions des contextes collectifs d’un système coopératif, et penser à les construire est utile en ce sens qu’elle oblige les architectes logiciels à considérer toutes les possibilités, au lieu d’avoir quelque chose qui tombe entre les mailles du filet. Cependant, il existe un conflit potentiel entre la valeur des tables état / événement et le nombre d’états et d’événements possibles. Si vous considérez un réseau complexe comme un système énorme et plat, vous auriez une table bien trop grande pour être jamais mise en œuvre. Le TMF et mon propre travail sur l’ExpériaSphère ont traité de cela en divisant des systèmes complexes en « modèles d’intention » qui avaient chacun leurs propres relations état / événement. Composition hiérarchique, en somme. C’est ce que le contrat NGOSS décrit.
Le point ici est que les deux articles manquent ce qui devrait être son propre point fort, à savoir que le pilotage des événements vers les processus par des modèles de données via des tables d’état / événements alignées sur les composants est le moyen de créer à la fois un comportement piloté par les événements et une conception compatible avec les microservices. Si un modèle de données de service génère un événement vers un processus, celui-ci peut obtenir les informations dont il a besoin à partir du modèle de données de service seul, ce qui signifie qu’il est sans état et peut être déployé en tant que microservice ou même sous forme sans serveur.
Si vous retirez l’approche du contrat NGOSS de l’histoire de la modernisation OSS / BSS, vous vous retrouvez avec la chose qui a miné toute la notion de modernisation OSS / BSS dès les premières platitudes. Nous pouvons parler de bas en haut et de haut en bas tant que nous nous concentrons sur les méthodologies de projet, mais une méthodologie de projet pilote un projet, elle n’écrit pas de logiciel. Une architecture logicielle devrait émerger de la méthodologie. C’est un élément distinct, le résultat du bon processus, mais ce n’est pas la conséquence automatique d’agiter une baguette sur un tas de données et de scander « de haut en bas, de haut en bas! »
Cela résume mon problème avec le papier Tata. Les méthodologies de projet en informatique et en réseau conduisent à des architectures d’applications ou de services, qui encadrent ensuite les exigences des composants de la solution et la manière dont ils sont intégrés et gérés. Le projet n’est pas la sortie, c’est le chemin d’accès à la sortie. Le problème avec le papier Tata est qu’il s’agit d’une autre description d’une méthodologie de projet (une bonne, mais pas transformatrice), à un moment où nous cherchons depuis longtemps un chemin vers la modernisation des systèmes d’exploitation et que nous recherchons plutôt des produits spécifiques, ou du moins des architectures. Le TMF semble se diriger vers le même endroit par un chemin différent – transformez-vous en partenariat avec vos anciens ennemis.
Le document de Tata, dans la section intitulée « Le rôle des normes de l’industrie », souligne un problème important, si important qu’il pourrait en fait être l’obstacle à la progression vers l’objectif de modernisation des systèmes d’exploitation. Le document cite les modèles TMF et ONF pour la conception descendante, mais tout au long du document, il est clair que le système d’exploitation / BSS « modernisé » doit être plus étroitement intégré au reste de l’écosystème du réseau et des services. Nous avons des normes pour chaque élément possible de chaque stratégie de réseau possible, et dans certains cas, les normes sont même en concurrence. Nous avons récemment entendu des applaudissements pour l’unification de deux spécifications API d’opérations différentes, par exemple. Nous devrions nous demander comment nous en sommes arrivés à les avoir en premier lieu.
Le document TMF semble non seulement accepter cette fragmentation du futur, mais en dépendre. Cédez la mécanisation des choses au-delà des OS / BSS et concentrez-vous sur l’exploitation de ces choses « au-delà » pour créer des services en tant que pseudo-intégrateur. D’accord, ce n’est peut-être pas une vision déraisonnable pour le TMF (un organisme dominé par OSS / BSS), mais c’est une formule pour rester désorganisé tout en faisant face à ce qui doit presque être une initiative unifiée — la transformation.
Je pense que le TMF était l’organe logique pour moderniser l’OSS / BSS, et que le TMF a (avec un contrat NGOSS) conçu le paradigme central du pilotage des événements vers les processus via un modèle de données, qui est essentiel à cette modernisation. Tout le reste décrit dans les documents, chaque API développée ou harmonisée, chaque activité de normes visant n’importe quel aspect des opérations et de la gestion, devrait être intégrée dans ce cadre de contrat NGOSS. Si cela devait être fait, le résultat serait exactement ce que « NGOSS » représente.
Le modèle du contrat TMF NGOSS est tout aussi précieux, voire plus, si vous entrez dans le domaine du réseau. Un véritable processus d’état / événement « contractuel » pourrait tout gérer sur le cycle de vie du service, y compris la pièce réseau. Il s’ensuit qu’une solution centrée sur le réseau pourrait facilement être étendue au domaine du service, OSS/BSS. L’universalité de l’approche est bonne pour l’industrie, car l’automatisation du cycle de vie des services doit être universelle pour être utile.
Il devrait également être basé sur une réflexion cloud à la pointe de la technologie. Les deux documents semblent être d’accord avec cela, et pourtant, les deux contournent la question de savoir comment y parvenir. Si vous envisagez d’utiliser les outils actuels pour accomplir quelque chose, vous devez encadrer votre approche en termes de ces outils. Vous ne pouvez pas accepter l’idée que vous pouvez écrire des spécifications pour tout, ou simplement traduire des objectifs en haut en fonctionnalités arbitraires en bas. C’est particulièrement susceptible de vous mordre étant donné que les processus de normes prennent des années avant de parvenir à une conclusion. Nous déployons la 5G aujourd’hui et les normes ne sont pas terminées et ne le seront probablement pas avant 2022. Je me demande s’il y a du temps pour ce genre de choses, étant donné que les opérateurs sont déjà confrontés à la chute des ROI d’infrastructure qui approchent du point critique.
Le contrat NGOSS existe depuis environ 13 ans maintenant, et le TMF m’a dit un jour qu’il avait acquis une traction très limitée. Il ne semble pas être joué dans le matériel TMF actuel, bien que, comme je l’ai dit, je n’ai pas accès aux éléments réservés aux membres. La question est donc de savoir si le TMF est prêt à promouvoir sa propre vision (éblouissante et unique), d’abord dans le domaine étroit OSS / BSS, puis dans la mission d’automatisation du cycle de vie plus large. Si c’est le cas, le TMF assume son rôle légitime dans l’évolution du NGOSS et définit la base de l’automatisation globale du cycle de vie des services. Si ce n’est pas le cas, ce sera à un autre organisme de normalisation ou à un groupe open-source de reprendre le flambeau, et le TMF devra alors se battre pour sa pertinence dans son propre espace.
