Non-Telco- und Partnerprodukte: ein Vertrag, eine Rechnung, eine Integration

Platz in ODA

Enablement & Monetization Platform und WideCoup Convergent BSS liegen in den ODA-Blöcken Party Management, Core Commerce Management und Production. Das Marketplace-Muster folgt der TM Forum Software Marketplaces Reference Architecture, ihren Use Cases und den ODA for Ecosystems Use Cases.

Rollen in der Kette

• Partner Ein Cloud-Anbieter oder der Betreiber: erstellt Services in seiner Cloud und bietet sie in seinem Store an.
• ISV Veröffentlicht Services im Store des Partners; Provisioning beim ISV ist optional.
• Kunde Bestellt im Store und hat einen Vertrag und eine monatliche Rechnung.
• Enablement & Monetization Platform Der Store, ISVs, Umsatzbeteiligung, Tenants, Abonnements und Provisioning.
• WideCoup Convergent BSS Zentrales Billing für B2B, B2C und B2B2X nach Abonnement und nach Nutzung.

Komponenten

• Store Der kuratierte Katalog von API- und Anwendungsprodukten. Ein Produkt durchläuft Draft, Review, Approve und Store; ein Bundle, das die Prüfung nicht besteht, geht mit Kommentar zurück in Draft.
• Namespace-Produkt API, UI und Hintergrunddienste werden als ein Produkt veröffentlicht. Die Komponenten behalten ihre eigenen Versionen und eine gemeinsame Veröffentlichungs- und Abonnementgrenze.
• Organisation bzw. Tenant Jeder Partner oder Consumer ist isoliert: eigene Benutzer, Anwendungen, Konfiguration, Daten, Abonnements, Quoten und Anmeldedaten.
• Open API-Schicht Authentifiziert Consumer, wendet Richtlinien an und leitet Aufrufe an Betreibersysteme, Partnerplattformen oder BPMN-Prozesse weiter.

Verträge

• An TM Forum ausgerichtete Verträge für Telco-Funktionen und deklarative Mappings für externe APIs.
• Eine Partnerkomponente wird mit ihrem Vertrag, ihren Abhängigkeiten, ihrem Zugriffsmodell und ihrem Verantwortlichen registriert und vor der Veröffentlichung geprüft.
• Anmeldedaten externer Systeme bleiben außerhalb des Paketcodes, auf Ebene des Namespace und der konsumierenden Organisation.

Ablauf

1. Der Partner erstellt Services in seiner Cloud; ISVs veröffentlichen ihre im Store.
2. Die Verantwortlichen des Betreibers prüfen und genehmigen das Produkt, bevor es in den Store gelangt; der Workflow hält fest, wer entscheidet.
3. Der Kunde bestellt einen Service. Die Plattform legt Tenant, Konto und Abonnement an, stellt die Cloud-Ressourcen des Partners bereit und fordert bei Bedarf die des ISV an.
4. Die Nutzung wird an der Grenze von Produkt und Organisation erfasst und fließt in Billing und Reporting.
5. WideCoup Convergent BSS stellt eine monatliche Rechnung aus; die Umsatzbeteiligung mit jedem ISV wird im Billing-Zyklus in der Landeswährung abgerechnet.

Neben bestehenden Systemen

• Rechtliche Vereinbarungen, Kundenfinanzen und Unternehmensidentität bleiben in ihren Systemen und werden über explizite APIs und Workflow-Aufgaben angebunden.
• Komplexe Abrechnungen können im System des Betreibers für das Partner-Revenue-Management verbleiben.
• Eine neue Version erzwingt keine marketplaceweite Umstellung: Consumer wechseln in ihrem eigenen Tempo, und ein Rollback wählt die vorherige Version eines Service innerhalb des Bundles.

Dies ist ein Zielszenario; Domänenadapter, Integrationsaufwand und kommerzielle Regeln werden in der Discovery-Phase bestätigt.

Technische Details auf platform.mef.dev →