TM Forum Open API – ein PoC für Orange Polen 

Das PoC von Hycom basiert auf entkoppelten, cloud-nativen Anwendungen und wurde in Zusammenarbeit mit Google und Orange Polen realisiert. Google teilt unser Verständnis des zukunftsorientierten Commerce-Marktes und hat eine Investition getätigt, um gemeinsam mit Hycom ein PoC einer solchen modernen Telco-Commerce-Lösung für Orange aufzubauen.

Ziel des Google Orange PoC war es, die Möglichkeiten sowie die Vor- und Nachteile der Ablösung des monolithischen E-Commerce durch eine auf Microservices basierende Lösung nach dem Vorbild der TM Forum Open Digital Architecture und deren Implementierung auf der Google Cloud Platform (GCP) zu überprüfen. 

Einerseits drehte sich die Arbeit um die Implementierung eines ausgewählten
Geschäftsprozesses, andererseits war sie sehr auf technische Bereiche ausgerichtet, wie z. B.: 

• die Untersuchung der Möglichkeiten der GCP-Plattform, 

• die Entwicklung einer CI/CD-Pipeline, 

• die Beobachtbarkeit und die Service Mesh, 

• und schließlich sollte die Implementierung der TM Forum Open API die Vor- und Nachteile des Standards aufzeigen. 

Unser Projekt wurde im Geiste von Cloud Native durchgeführt, unter Verwendung von Open-Source-Äquivalenten der von GCP bereitgestellten Services, wie Prometheus, Grafana, Grafana Loki, Jaeger und Kafka. Der gesamte Stack wurde auf unserer eigenen (lokalen) Kubernetes-Installation entwickelt und gewartet und später auf die Google Cloud Platform übertragen. 
Dieser Ansatz ermöglicht es uns, unseren zukünftigen Kunden solche Lösungen in Zusammenarbeit mit jedem anderen Cloud-Anbieter wie Azure oder AWS sowie in einem On-Premise Private Cloud-Modell anzubieten. 

Wir sind auf viele Herausforderungen gestoßen und hatten viele Diskussionen, insbesondere über die Einzelheiten der Nutzung des TM Forums in bestimmten Geschäftsfällen. TM Forum schafft großartige Lebensstandards, löst aber nicht alle kundenspezifischen Geschäftsfälle
von Telekommunikationsunternehmen auf Anhieb. Wir sind auf viele Bereiche gestoßen, in denen die TM Forum-API noch keine spezifischen Lösungen bietet, wie zum Beispiel die Beziehungen zwischen: 

• Datenschutzvereinbarungen 

• Warenkorb/Produktbestellung.   

Dank des guten TM Forum-Community-Supports konnten wir unsere Probleme mit Mitgliedern anderer Telekommunikationsunternehmen diskutieren, um einen gemeinsamen Weg zu finden, wie wir mit solchen fehlenden Lösungen umgehen können. Die APIs des TM-Forums und ihre Ressourcen befinden sich noch im Aufbau, sodass wir davon ausgehen, dass viele der Probleme, mit denen wir konfrontiert waren, in Zukunft durch eine Referenzimplementierung oder zumindest durch Einführungsleitfäden gelöst werden. Es wird jedoch immer einige branchenspezifische Lücken geben, die unter Berücksichtigung der Besonderheiten des Kunden mit der besten Erfahrung von Fachleuten, wie Hycom sie hat, gefüllt werden können. 

Alle unsere Entscheidungen und Schlussfolgerungen während des Projekts wurden nach bewährten Praktiken dokumentiert, darunter Architecture Decision Records, C4, UML und OpenAPI / Swagger. 

PoC Architecture für den universellen Einsatz 

In der Vision von Hycom ist die Customer Experience über alle Kanäle hinweg vereint. Egal, ob dieser Kanal Telefon, Tablet, Smartwatch, Chatbot, Kiosk oder Sprachassistent heißt, der Kunde muss den Kauf überall abschließen können. 

Wir haben unseren PoC als Beschleuniger für Composable Commerce aufgebaut, bei dem jedes zusätzliche Modul von Drittanbietern wie Customer Engagement, Headless Commerce, Headless CMS usw. auf Wunsch der Stakeholder einfach hinzugefügt oder gegen jede kundenspezifische Lösung ausgetauscht werden kann. 

Als Ergebnis können wir auf 10 automatisch einsetzbare und vollständig überwachte Services verweisen, die in Echtzeit Metriken und Warnmeldungen sammeln und gemeinsam den Prozess der Telekommunikationskundenakquise durchführen. Außerdem haben wir unser
Verständnis der TM Forum-APIs-Architektur und unsere Kompetenz bei der Cloud-Implementierung unter Beweis gestellt.

PoC-Schlussfolgerungen im Hinblick auf TM Forum Open APIs 

Unser Hauptziel des Proof of Concept war es, die Vor- und Nachteile der TM Forum Open API als eine der Komponenten der Open Digital Architecture zu validieren. TM Forum Open API wurde stark beworben, ein perfektes Mittel für alles zu sein. Wie üblich liegt die Wahrheit immer dazwischen. Es gibt technologieunabhängige REST-basierte APIs, die in jedem digitalen Dienstleistungsszenario verwendet werden können. Es gibt zwar Ressourcen und Beschreibungen, aber keine ausreichenden Leitlinien, wie sie zu verwenden sind. Es gibt keine Dokumente mit einer Referenzarchitektur, die alle Elemente in einem Stück für typische
Anwendungsfälle zusammenfasst. Das passendste Sprichwort, das wir erwähnen können, ist: „Je mehr wir uns damit beschäftigen, desto komplizierter wird es.“ Warum? Während unserer PoC-Implementierung gab es so viele Meinungen wie Leute, zum Beispiel ... Welche API-Anfrage sollte in welchem Fall verwendet werden? Sollten wir Zustimmungen im Warenkorb oder vielleicht in der Bestellung speichern? Welches Ressourcenobjekt sollte zu welchem Zeitpunkt aktualisiert werden? Sollten wir zuerst privacyAgreement oder privacyProfile aktualisieren? Und viele andere. 

TM Forum entwickelt derzeit High-Level-Konzepte, aber wir erwarten eine Referenzimplementierung oder zumindest ein Beispiel für den Flow von API-Aufrufen in Anwendungsfällen. TM-Forum spricht darüber, aber im Moment gibt es noch keine Referenzimplementierung. Es gibt nur wenige ausführliche Einführungsleitfäden, die die Verwendung von APIs erläutern, und jedes Jahr werden neue erstellt, die jedoch den größten
Teil des Anwendungsbereichs der vom TM Forum erstellten APIs nicht mehr abdecken. Wir gehen davon aus, dass es noch einige Jahre dauern wird, den Umfang des Telco-Commerce-Bereichs mit Beispielen abzudecken. Die gute Nachricht ist, dass das TM Forum im Dezember 2020 ein Projekt namens Open Digital Architecture Component Accelerator zur gemeinsamen Entwicklung einer Referenzimplementierung gestartet hat. 

Ein weiteres gutes Beispiel ist die Erstellung der Shopping Cart API (TMF663). Die Shopping Cart API wurde vor drei Jahren erstellt. Die Product Orderung API (TMF622) wurde im Jahr 2013 vor der Shopping Cart API erstellt, und die Mitglieder des TM-Forums nutzten die Product Ordering API, um Bestellungen aufzugeben, obwohl es keinen Shopping Cart gab, und viele Mitglieder fragten danach. Nach vier Jahren wurde dann 2017 die Shopping Cart API (TMF663) geschaffen. In unserem PoC arbeiteten wir mit dieser Shopping Cart API. Gemäß dieser API ist das Ende des Lebenszyklus des Warenkorbs und der Beginn des Lebenszyklus der Bestellung erreicht, wenn der Kunde zum Checkout-Prozess gelangt. Alle Kundendaten und sonstige Checkout-Informationen werden zum Bestellgegenstand erhoben. Aus unserer Sicht sollte der Warenkorb eine Sammlung von Punkten sein, die einfach an eine Bestellung übergeben werden können. Zu unserer Überraschung stellte sich heraus, dass das Warenkorbobjekt und das Bestellobjekt völlig unterschiedlich und nicht kompatibel sind. Wir mussten jedes Attribut des Warenkorbs manuell der Bestellung zuordnen. Es sieht so aus, als ob die Shopping Cart API von völlig anderen Leuten geschrieben wurde als die Product Order API, wobei die Kompatibilität zwischen diesen APIs nur wenig berücksichtigt wurde. 
Darüber hinaus ist diese Shopping Cart API nicht für Telekommunikationsunternehmen geeignet. Sie eignet sich für Standard-Einzelhandelsgeschäfte, bei denen der Kunde einfach zur Kasse geht. So können beispielsweise während des Checkout-Prozesses die Preise nicht geändert werden, der Kunde kann dem Warenkorb nichts hinzufügen, es gibt keine Rabattzustimmungen wie bei einer elektronischen Rechnung usw. Um solche Funktionalitäten zu erhalten, muss die Shopping Cart API an vielen Stellen angepasst werden. Zu Beginn des Projekts haben wir sogar darüber nachgedacht, die Product Order API anstelle der Shopping Cart API zu verwenden, sobald die Nutzer den Checkout starten, aber das bringt auch einige Einschränkungen mit sich, die durch Anpassung beseitigt werden müssen... 

Während der Implementierungsphase unserer APIs haben wir viel Zeit damit verbracht, darüber zu diskutieren, ob wir uns zu 100 % an die TM Forum-Spezifikation halten und die erforderlichen Attribute auf die bestehenden Attribute einer API abbilden sollten oder ob wir diese APIs anpassen und bei Bedarf neue Attribute und Ressourcen hinzufügen sollten. Nach eingehender Analyse sind wir zu dem Schluss gekommen, dass die Zuordnung von Attributen zu nicht zweckgebundenen Attributen nicht effektiv ist, einen hohen Aufwand in der Konzeptionsphase bedeutet und außerdem zu irreführenden Namen von Attributen führt, die für unterschiedliche Zwecke verwendet werden, als ursprünglich vorgesehen. Daher wurde beschlossen, jede API dort anzupassen, wo es erforderlich war, um die geschäftlichen Anforderungen auf zuverlässigere Weise zu erfüllen. 

Dennoch sehen wir die Zukunft in TM Forum als einer einheitlichen Architektur mit API-Beschleunigern für verschiedene Funktionsbereiche. Zum jetzigen Zeitpunkt erfordert die Implementierung TM Forum Open APIs jedoch noch viele Diskussionen und Untersuchungen hinsichtlich ihrer technischen Nutzung. Wir glauben, dass die auf Digital Architecture basierende TM Forum Open API die Zukunft in der Telekommunikationsbranche ist, da sie insgesamt einheitliche und durchdachte Standards bietet. Wir bei Hycom verstehen sie nicht nur, sondern wissen dank unserer Beteiligung auch, wie man sie zu einem funktionierenden Arbeitssystem zusammensetzt. 

Zusammenfassung 

Composable BSS-Lösungen in der Telekommunikationsbranche, basierend auf TM Forum Open Digital Architecture in Verbindung mit geeigneten Technologien, sind der Schlüssel zur Marktführerschaft. Beachten Sie jedoch, dass der Aufbau von Lösungen auf der Grundlage von Microservices auch einige entscheidende Nachteile im Zusammenhang mit der verteilten
Architektur und ihres Managements mit sich bringt. Die TM Forum APIs scheinen nicht ausgereift zu sein, um viele der Telco-Funktionen ohne jegliche Anpassung anzusprechen. Die Kenntnis der Standards des TM-Forums, das aktuelle Wissen um deren Änderungen und Herausforderungen sowie die aktive Beteiligung an der Zusammenarbeit versetzen Hycom in die Lage, Risiken zu erkennen und zu vermeiden. 

Empfehlungen für Telekommunikationsunternehmen 

• Konzentrieren Sie sich auf die TM Forum Open Digital Architecture und wandeln Sie monolithische Anwendungen in Microservices um, um Flexibilität bei der Entwicklung und Skalierbarkeit des Datenverkehrs zu erreichen und um sich von hohen Lizenzgebühren zu befreien. 

• Seien Sie vorsichtig mit der Implementierung von TM Forum APIs ohne Erfahrung, da sie möglicherweise nicht ausgereift genug sind. 

• Gestalten Sie ihre Apps so, dass Ihre Kunden ihre Einkäufe auf allen Kanälen abschließen können, sogar auf ihren Kühlschränken oder Uhren. 

• Entkoppeln Sie Geschäftsfunktionalitäten, trennen Sie Frontend vom Backend, evaluieren Sie einen Cloud-Native-Approach, um die Markteinführungszeit neuer Geschäftsfunktionen von Monaten auf Wochen zu beschleunigen. 

• Hören Sie auf globale Forschungs- und Beratungsunternehmen wie Gartner, aber
  berücksichtigen Sie auch die Empfehlungen von erfahrenen Fachleuten aus der Telekommunikationsberatung und -entwicklung.