Was zum Teufel ist ein NGOSS? Ich habe den Begriff oft verwendet, in Bezug auf den „NGOSS-Vertrag“, aber für diejenigen, die nicht mit dem OSS / BSS-Raum oder dem TMF vertraut sind, kann es mysteriös sein. Tata Consultancy Services, ein großes und aktives Dienstleistungsunternehmen, hat kürzlich ein Papier über die „Neugestaltung“ des OSS / BSS verfasst, ein TMF-Papier, in dem gefragt wird, ob es ein Leben jenseits von Konnektivitätsdiensten gibt. Es gibt interessante Kontraste und Ähnlichkeiten zwischen den beiden Dokumenten, die es wert sind, erkundet zu werden.
NGOSS steht für „Next-Generation Operations Support System“. Es ist ein Begriff, der seit mindestens 15 Jahren weit verbreitet ist, und es wird oft von der TMF in ihren Spezifikationen verwendet. Ein Großteil des TMF-Materials ist jedoch nur für Mitglieder bestimmt, und daher kann ich es nur durch Zusammenfassung zitieren (oder, wenn ich zu diesem Zeitpunkt kein Mitglied bin, nicht einmal darauf zugreifen). Das TMF-Papier ist aus diesem Grund besonders hilfreich; Es ist eine öffentliche Zusammenfassung der Art und Weise, wie der Körper die Zukunft der „Transformation“ sieht. Das Tata-Papier ist interessant, weil es eine professionelle Sichtweise des gleichen Transformationsprozesses widerspiegelt.
Die Eröffnung des Tata-Papiers hat die üblichen Plattitüden über Bandbreite. „Da sich Unternehmen zunehmend an ein überwiegend Online-Modell anpassen, steigt der Bedarf an hoher Bandbreite und zuverlässigen Netzwerkdiensten. Folglich erleben Kommunikationsdienstleister (CSPs) eine exponentielle Nachfrage nach Diensten und sind auf Fortschritte bei Virtualisierungstechnologien angewiesen, um die Skalierung mit den aktuellen Raten fortzusetzen.“
Das Problem dabei ist neben dem Platitude-Status (eine weitere „exponentielle“ Nachfrageaussage und ich werde kotzen), dass das eigentliche Problem nicht das Nachfragewachstum ist, sondern der Gewinnschwund. Kein Betreiber wäre unzufrieden mit dem Wachstum der Nachfrage nach Bandbreite, wenn sie inkrementell für das Wachstum berechnen könnte. Sie können nicht, also müssen sie entweder etwas anderes als Bandbreite finden, um zu verkaufen, oder die Kosten für die Produktion von Bandbreite senken, um die Tatsache auszugleichen, dass Dienste mit höherer Bandbreite keine proportional höheren Preise generieren.
Das gleiche Problem färbt den nächsten Abschnitt, der als „Überdenken der OSS-Funktion“ bezeichnet wird. Es werden TMF-Ziele für die OSS-Modernisierung zitiert, von denen keines den Umgang mit diesem Gewinnkompressionsproblem impliziert. In der Tat ist dieser Abschnitt des Dokuments der Grund, warum viele Betreiberstrategen dafür sind, die ganze OSS / BSS-Sache zu verschrotten und von vorne zu beginnen. Es ist nicht so, dass keine nützlichen Ziele gesetzt werden (Automatisierung ist eines der Attribute eines zukünftigen OSS / BSS), sondern dass nicht viel darüber gesagt wird, sie zu erreichen.
Das kommt im nächsten Abschnitt, der „Driving Well-Orchestrated OSS Functions“ genannt wird. Dieser Abschnitt macht schließlich eine Empfehlung, die nützlich ist; OSS / BSS muss ereignisgesteuert gemacht werden. Ich hatte hier Hoffnungen, weil die TMF tatsächlich die Quelle des Schlüsselkonzepts in OSS und Operations Automation war — des NGOSS-Vertrags, den ich zu Beginn dieses Blogs erwähnt habe. Leider wird weder der Begriff noch das Konzept in der Tata-Zeitung angesprochen. „Zukünftige OSS-Funktionen müssen als Dienste erstellt und angeboten werden, die aus Microservices bestehen, um die automatisierte End-to-End-Orchestrierung hybrider (physischer, logischer und virtueller) Netzwerkressourcen zu unterstützen.“
Das TMF-Papier beginnt im Gegensatz dazu mit der Aussage, dass „Konnektivität zu Recht als margenschwaches Geschäft angesehen wird und sich rasch weiter kommerzialisiert.“ Das Ziel von Betreibern ist es, „ihre Innenwelt mit einer agilen Technologiefundament und einem agilen Betriebsmodell richtig zu machen.“ Die TMF bezieht offensichtlich ihr primäres OSS / BSS-Ziel in diese innere Welt ein, aber ebenso offensichtlich muss sich die agile Technologiefundament auf die Infrastruktur erstrecken.
Der Mechanismus, um ihre „innere Welt in Ordnung zu bringen“, ist implizit 5G. Die TMF sagt, dass es entscheidend ist, „das Beste aus der enorm teuren Umstellung auf 5G zu machen.“ Aber das scheint durch den nächsten Absatz widerlegt zu werden, wo der ehemalige CEO des Forums sagt: „Für Verbraucher und Smart-Home-Personen hat „Konnektivität“ tendenziell einen inneren Wert und ist eine gültige Sache, die gekauft werden muss. Wenn Sie jedoch in den Bereich der Branchentransformation vordringen, wird Konnektivität nur insoweit geschätzt, als sie an die Lösung gebunden ist: „Sie möchten keine Konnektivität von Ihnen kaufen, sie möchten eine Lösung kaufen.“ 5G ist eindeutig eine Konnektivitätsstrategie für Verbraucher, wie jede Massenmarktinfrastruktur. Wenn wir davon ausgehen, dass „der Maßstab in den Bereich der Branchentransformation steigt“, dh Business Services, Der Schlüssel ist, Lösungen zu verkaufen.
Dies scheint für die Betreiber zu sprechen, ihr „Digital Service Provider“ -Geschäft auf Unternehmen zu konzentrieren und Lösungen anzubieten, die ein SaaS-Anbieter bieten soll. Ist das wirklich ein kluger Ansatz, wenn man bedenkt, dass es ein sehr aktives und wettbewerbsfähiges Public-Cloud-Geschäft gibt, das bereits Lösungen an diese Kunden verkauft? Vor allem, wenn die Mehrheit der Profit-per-Bit-Probleme, die Betreiber haben, von All-you-can-eat-Verbraucherdiensten kommt?
Die Resolution, so ein Vodafone-Zitat und andere Kommentare im TMF-Papier, lautet: „Was wir jetzt „Dienste“ nennen, wird nicht nur die Telco betreffen, sondern eine Reihe von Partnern umfassen, einschließlich der Telcos.“ Die Telekommunikationsunternehmen sind also überhaupt keine Anbieter digitaler Dienste, sondern Integratoren oder Wiederverkäufer digitaler Dienste. Kann es sich ein Unternehmen, das Transformation als Mittel zur Vermeidung von Gewinnengpässen betrachtet, leisten, Wiederverkäufer der Dienste eines anderen Spielers zu sein?
Es scheint mir, dass die TMF-Vision überhaupt nicht über das OSS / BSS hinaus zielt, sondern vielmehr darauf hindeutet, dass sich Operationen und Dienste zu etwas entwickeln, das über die Konnektivität hinausgeht, indem sie mit denen zusammenarbeiten, die dort oben Dienstleistungen erbringen. Das könnte den ganzen Zweck der „digitalen Transformation“ zunichte machen und die Telekommunikationsunternehmen nicht nur in ihrem derzeitigen Niveau der Disintermediation und Kommodifizierung, sondern auch in einem ganz neuen Niveau einsperren.
Beide Arbeiten scheinen darauf hinzudeuten, dass die OSS / BSS-Transformation wesentlich ist, und implizieren zumindest, dass ein ereignisgesteuerter Ansatz die Antwort ist. Das ist eigentlich eine gute Idee, aber es vermisst die Herausforderung „Wie?“ Um ereignisgesteuert zu sein, muss ein System sowohl das Konzept von Ereignissen (offensichtlich) als auch das Konzept von „Zustand“ oder Kontext erkennen. Jeder, der sich jemals einen Protokollhandler angesehen hat, weiß, dass dieselbe Nachricht in verschiedenen Kontexten / Zuständen unterschiedlich verarbeitet werden muss. Beispielsweise ist das Abrufen einer „Datenpaket“ -Nachricht im Status „Bestellbar“ für einen Dienst eindeutig ein Fehler, während dies im Status „Datenübertragung“ in Ordnung ist. Damit es Zustände und Ereignisse und zugehörige Prozesse gibt, benötigen Sie eine Status- / Ereignistabelle.
Zustands- / Ereignistabellen sind Beschreibungen der kollektiven Kontexte eines kooperativen Systems, und das Nachdenken über deren Aufbau ist insofern nützlich, als es Softwarearchitekten zwingt, alle Möglichkeiten in Betracht zu ziehen, anstatt etwas passieren zu lassen, das durch die Risse fällt. Es besteht jedoch ein potenzieller Konflikt zwischen dem Wert von Status- / Ereignistabellen und der Anzahl möglicher Zustände und Ereignisse. Wenn Sie ein komplexes Netzwerk als ein riesiges, flaches System betrachten, haben Sie einen viel zu großen Tisch, um ihn jemals zu implementieren. Die TMF und meine eigene ExperiaSphere-Arbeit befassten sich damit, indem sie komplexe Systeme in „Absichtsmodelle“ aufteilten, die jeweils ihre eigenen Zustands- / Ereignisbeziehungen hatten. Hierarchische Zusammensetzung, kurz gesagt. Das ist, was NGOSS Vertrag beschrieben.
Der Punkt hier ist, dass beide Papiere vermissen, was seine eigene Stärke sein sollte, Das ist, dass datenmodellgesteuerte Steuerung von Ereignissen zu Prozessen über komponentenausgerichtete Zustands- / Ereignistabellen der Weg ist, sowohl ereignisgesteuertes Verhalten als auch Microservice-kompatibles Design zu erstellen. Wenn ein Servicedatenmodell ein Ereignis zu einem Prozess steuert, kann der Prozess die benötigten Informationen allein aus dem Servicedatenmodell abrufen, was bedeutet, dass er zustandslos ist und als Microservice oder sogar in serverloser Form bereitgestellt werden kann.
Wenn Sie den NGOSS-Contract—Ansatz aus der OSS / BSS-Modernisierungsgeschichte herausziehen, bleiben Sie bei dem, was den gesamten Begriff der OSS / BSS-Modernisierung von Anfang an geplagt hat – Plattitüden. Wir können über Bottom-up und Top-Down sprechen, solange wir uns auf Projektmethoden konzentrieren, aber eine Projektmethodik treibt ein Projekt an, es schreibt keine Software. Aus der Methodik sollte eine Softwarearchitektur entstehen. Das ist ein separates Element, ein Ergebnis des richtigen Prozesses, aber es ist nicht die automatische Konsequenz, einen Zauberstab über ein Bündel von Daten zu schwenken und „top-down, top-down!“
Das fasst mein Problem mit dem Tata-Papier zusammen. Projektmethoden in IT und Netzwerk führen zu Anwendungs- oder Servicearchitekturen, die dann die Anforderungen an die Komponenten der Lösung und die Art und Weise, wie sie integriert und verwaltet werden, festlegen. Das Projekt ist nicht die Ausgabe, sondern der Pfad zur Ausgabe. Das Problem mit dem Tata-Papier ist, dass es sich um eine weitere Beschreibung einer Projektmethodik handelt (eine gute, aber keine transformative), zu einer Zeit, in der wir längst nicht mehr nach einem Weg zur OSS-Modernisierung suchen und stattdessen nach bestimmten suchen Produkte oder zumindest Architekturen. Die TMF scheint auf einem anderen Weg an denselben Ort zu gelangen – verwandeln Sie sich durch Partnerschaft mit Ihren ehemaligen Feinden.
Das Tata-Papier weist im Abschnitt „Die Rolle von Industriestandards“ auf ein wichtiges Problem hin, das so wichtig ist, dass es tatsächlich das Hindernis für den Fortschritt in Richtung des OSS-Modernisierungsziels sein könnte. Das Papier zitiert die TMF- und ONF-Modelle für das Top-Down-Design, aber im gesamten Papier ist klar, dass das „modernisierte“ OSS / BSS enger in den Rest des Netzwerk- und Service-Ökosystems integriert werden muss. Wir haben Standards für jedes mögliche Stück jeder möglichen Netzwerkstrategie, und in einigen Fällen konkurrieren die Standards sogar. Wir hörten vor kurzem Applaus für die Vereinheitlichung von zwei verschiedenen Operationen API-Spezifikationen, zum Beispiel. Wir sollten uns fragen, wie wir dazu gekommen sind, sie überhaupt zu haben.
Das TMF-Papier scheint diese Fragmentierung der Zukunft nicht nur zu akzeptieren, sondern davon abhängig zu sein. Geben Sie die Mechanisierung von Dingen jenseits von OSS / BSS auf und konzentrieren Sie sich darauf, diese „Jenseits“ -Dinge zu nutzen, um Dienste als Pseudo-Integrator zu erstellen. OK, das ist vielleicht keine unvernünftige Sichtweise für die TMF (ein OSS / BSS-dominiertes Gremium), aber es ist eine Formel, um unorganisiert zu bleiben, während man sich dem gegenübersieht, was fast eine einheitliche Initiative sein muss — Transformation.
Ich bin der Ansicht, dass die TMF die logische Instanz zur Modernisierung des OSS / BSS war und dass die TMF (mit NGOSS-Vertrag) das zentrale Paradigma der Ereignissteuerung für Prozesse über ein Datenmodell entwickelt hat, das für diese Modernisierung entscheidend ist. Alles andere, was in den Papieren beschrieben wird, jede API, die jemand entwickelt oder harmonisiert, jede Standardaktivität, die auf jeden Aspekt von Betrieb und Management abzielt, sollte in diesen NGOSS-Vertragsrahmen passen. Wenn das gemacht würde, wäre das Ergebnis genau das, wofür „NGOSS“ steht.
Das Modell des TMF NGOSS-Vertrags ist genauso wertvoll oder sogar noch wertvoller, wenn Sie in die Netzwerkdomäne eintreten. Ein echter „Vertrags“ -Status- / Ereignisprozess könnte alles über den Service-Lebenszyklus verwalten, einschließlich des Netzwerkstücks. Daraus folgt, dass eine netzwerkzentrierte Lösung leicht in den Dienst, die OSS / BSS-Domäne, erweitert werden könnte. Die Universalität des Ansatzes ist gut für die Branche, da die Automatisierung des Service-Lebenszyklus universell sein sollte, um nützlich zu sein.
Es sollte auch auf modernstem Cloud-Computing basieren. Beide Papiere scheinen damit einverstanden zu sein, und doch umgehen beide die Frage, wie dies erreicht werden kann. Wenn Sie vorhaben, aktuelle Tools zu verwenden, um etwas zu erreichen, müssen Sie Ihren Ansatz in Bezug auf diese Tools festlegen. Sie können die Vorstellung nicht akzeptieren, dass Sie Spezifikationen für alles schreiben oder einfach Ziele oben in beliebige Funktionen unten übersetzen können. Das ist besonders wahrscheinlich, dass Sie beißen gegeben, dass die Standards Prozesse Jahre dauern, bis zu einem Abschluss zu kommen. Wir setzen 5G heute ein und die Standards sind noch nicht fertig und werden es wahrscheinlich erst 2022 sein. Ich frage mich, ob es Zeit für dieses Zeug gibt, da die Betreiber bereits mit sinkenden Infrastruktur-ROIs konfrontiert sind, die sich dem kritischen Punkt nähern.
NGOSS Contract gibt es seit ungefähr 13 Jahren, und die TMF sagte mir einmal, dass sie nur sehr begrenzte Zugkraft gewonnen habe. Es scheint nicht im aktuellen TMF-Material abgespielt zu werden, obwohl ich, wie gesagt, keinen Zugriff auf das Material nur für Mitglieder habe. Die Frage ist also, ob die TMF bereit ist, ihre eigenen (blendenden und einzigartigen) Erkenntnisse zuerst innerhalb der engen OSS / BSS-Domäne und dann in der breiteren Lifecycle Automation-Mission zu fördern. Wenn dies der Fall ist, übernimmt das TMF seine rechtmäßige Rolle in NGOSS Evolution und definiert die Grundlage für die Service Lifecycle Automation insgesamt. Wenn dies nicht der Fall ist, liegt es an einer anderen Normungsorganisation oder Open-Source-Gruppe, die Fackel aufzunehmen, und die TMF muss dann in ihrem eigenen Bereich um Relevanz kämpfen.
