Auftragsmanagement in konvergierenden Umgebungen

Letzte Woche war ich auf der TelemanagementWorld-Konferenz. Zusammen mit Andreas und John haben wir in einer Sitzung erklärt, warum die Order Management API perfekt für konvergierende Umgebungen wie Telco, Cable, ISP, Mobile ist. Die Präsentation können Sie von der TMForum-Website herunterladen (Sitzung SYS33). Da sie jedoch nur für TMForum-Mitglieder oder Besucher der Konferenz zugänglich ist, werde ich im Folgenden eine Zusammenfassung geben.

Die Konvergenz in der Branche der Kommunikationsdienstleister (Telco, Kabel, ISP, Mobilfunk) findet in 3 Dimensionen statt:

• Industrie: Telco-, Kabel-, ISP- und Mobilfunkbetreiber fusionieren oder erweitern ihr Angebot.
• Technologie: Festnetz, Mobilfunk, IP
• Dienstleistungen: Sprach-, Daten-, Video-, Präsenz- und Nachrichtendienste werden von allen Branchen angeboten

Aus diesen 3 Dimensionen haben wir eine Reihe von Anforderungen abgeleitet, die spezifisch für die Auftragsverwaltung sind, und geprüft/erläutert, ob die Auftragsverwaltungs-API diese Anforderungen erfüllt. Für die Branchendimension ist es wichtig, dass die API nicht auf branchenspezifische Produkte beschränkt ist und die Interoperabilität zwischen Systemen wichtig ist. Darüber hinaus müssen Auftragsverwaltungssysteme sehr skalierbar sein, da die steigende Zahl von Abonnenten, die wachsende Zahl von Angeboten, Marketingaktionen usw. zu einer steigenden Zahl von Aufträgen führen, die verarbeitet werden. Vor allem, wenn Sie berücksichtigen, dass eine Produktbestellung in mehrere Servicebestellungen aufgeteilt werden kann, die wiederum in mehrere Ressourcenbestellungen aufgeteilt werden können. Die Order Management API erfüllt diese Anforderungen, da sie auf Industriestandards wie JavaEE und einigen WS-Standards basiert. Mit Hilfe dieser Standards können Sie skalierbare und interoperable Systeme aufbauen.Die API definiert keine produktspezifischen Details, sondern nur das abstrakte Konzept eines Produkts und die Erweiterungsmöglichkeiten, um Ihre eigenen Produktdetails zu definieren. Auf diese Weise ist die API nicht auf eine bestimmte Gruppe von Produkten beschränkt. Für die Dimension Technologie ist es (genau wie bei den Produkten) wichtig, dass die API nicht auf eine bestimmte Technologie beschränkt ist. Und wie Sie wahrscheinlich erwarten, kann sie für Festnetz, Mobilfunk, IP und andere (derzeit vielleicht sogar unbekannte) Technologien verwendet werden. Es gibt keine Beschränkung in der API. Die Geschwindigkeit, mit der ein Auftrag bearbeitet werden kann, kann je nach Technologie sehr unterschiedlich sein. Bei einem Mobiltelefon können Sie zum Beispiel mit einem voll funktionsfähigen Gerät aus dem Geschäft gehen, bei einem IP-Anschluss kann es erforderlich sein, dass ein Modem an Sie geliefert wird, bevor der IP-Dienst bereitgestellt und die Bestellung abgeschlossen werden kann. Letzteres ist ein Prozess, der Tage oder Wochen dauern kann. Daher sollten langwierige Transaktionen für diese Aufträge unterstützt werden, und diese werden auch unterstützt. Die Auftragsverwaltungs-API kann auch als Abstraktionsschicht verwendet werden, um eine einheitliche Schnittstelle zu Legacy-/Silo-Auftragsverwaltungssystemen zu schaffen. Um dies zu erleichtern, ist das Modell für Aufträge und Auftragszustände erweiterbar und die API bietet Unterstützung bei der Abfrage von Metadaten (z.B. welche Aufträge oder Auftragszustände von dieser Implementierung unterstützt werden). Für die Service-Dimension kann es keine Beschränkung bei den Arten von Diensten geben. Genau wie bei den beiden vorangegangenen Dimensionen gibt es keine Beschränkung bei den unterstützten Arten von Serviceaufträgen, das Modell ist erweiterbar. Das Serviceangebot wird in der Regel in einem Katalog gespeichert. Um Bestellungen für einen bestimmten Service zu bearbeiten, benötigt das Auftragsverwaltungssystem die Details dieser Service-Definitionen und muss die Details der aktivierten Services in einem Inventar speichern. Zu diesem Zweck bietet die API eine einfache Integration mit der Inventory Management API. Diese API kann zur Verwaltung des Katalogs und des Inventars verwendet werden. Die Auftragsverwaltungs-API selbst definiert nicht, wie Katalog/Bestand verwaltet werden sollten. Die Geschwindigkeit, mit der sich Serviceangebote ändern, nimmt ständig zu. Daher ist es wichtig, dass die API neue Service-Definitionen ohne Änderungen an der API problemlos unterstützen kann. Dies wird von der Auftragsverwaltungs-API unterstützt, indem das Konzept der Merkmale verwendet wird, das in SID und OSS/J Common API definiert ist. Andere übergreifende Fähigkeiten, die für die Konvergenz relevant sind, sind:

• Da die API eine einheitliche Schnittstelle für verschiedene Arten von Aufträgen (Produkt, Dienstleistung, Ressource, Arbeit) bietet, lernen Sie die API einmal und können sie auf verschiedene Bereiche anwenden.
• Es lässt sich problemlos in eine SOA integrieren, siehe früheres Blogposting.
• Es gibt Unterstützung für eigenständige und zusammenhängende Bestellungen (z.B. für gebündelte Produkte).
• Und noch viel mehr, das aus Sicht der Konvergenz weniger relevant ist, siehe zum Beispiel diesen Blogbeitrag.

Zusammenfassend lässt sich also sagen, dass die Auftragsverwaltungs-API eine große Hilfe bei der Konvergenz Ihrer veralteten oder isolierten Auftragsverwaltungssysteme zu einem konsistenten, flexiblen, skalierbaren und auf Standards basierenden Auftragsverwaltungssystem sein kann.