Produits non télécom et partenaires : un contrat, une facture, une intégration

Place dans l’ODA

Enablement & Monetization Platform et WideCoup Convergent BSS se situent dans les blocs ODA Party Management, Core Commerce Management et Production. Le modèle de marketplace suit la TM Forum Software Marketplaces Reference Architecture, ses use cases et les ODA for Ecosystems Use Cases.

Rôles dans la chaîne

• Partenaire Un fournisseur cloud ou l’opérateur : crée des services dans son cloud et les propose dans sa boutique.
• ISV Publie des services dans la boutique du partenaire ; le provisioning côté ISV est facultatif.
• Client Commande dans la boutique et dispose d’un contrat unique et d’une facture mensuelle unique.
• Enablement & Monetization Platform La boutique, les ISV, le partage de revenus, les tenants, les abonnements et le provisioning.
• WideCoup Convergent BSS Billing centralisé B2B, B2C et B2B2X, à l’abonnement et à l’usage.

Composants

• Store Le catalogue sélectionné de produits API et applicatifs. Un produit passe par les états Draft, Review, Approve et Store ; un bundle qui échoue à la revue revient en Draft avec un commentaire.
• Produit namespace Services API, UI et d’arrière-plan publiés comme un seul produit. Les composants conservent leurs propres versions et une frontière unique de publication et d’abonnement.
• Organisation, ou tenant Chaque partenaire ou consommateur est isolé : ses propres utilisateurs, applications, configuration, données, abonnements, quotas et identifiants.
• Couche Open API Authentifie les consommateurs, applique les politiques et route les appels vers les systèmes de l’opérateur, les plateformes partenaires ou les processus BPMN.

Contrats

• Des contrats alignés sur le TM Forum pour les fonctions télécom, et des mappings déclaratifs pour les API externes.
• Un composant partenaire est enregistré avec son contrat, ses dépendances, son modèle d’accès et son propriétaire, et revu avant publication.
• Les identifiants des systèmes externes restent hors du code des packages, au niveau du namespace et de l’organisation consommatrice.

Flux

1. Le partenaire crée des services dans son cloud ; les ISV publient les leurs dans la boutique.
2. Les responsables de l’opérateur examinent et approuvent le produit avant qu’il n’arrive dans la boutique ; le workflow trace qui décide.
3. Le client commande un service. La plateforme crée le tenant, le compte et l’abonnement, provisionne les ressources cloud du partenaire et, si nécessaire, sollicite celles de l’ISV.
4. L’usage est collecté à la frontière du produit et de l’organisation et alimente le billing et le reporting.
5. WideCoup Convergent BSS émet une facture mensuelle unique ; le partage de revenus avec chaque ISV est réglé en devise locale dans le cycle de billing.

Aux côtés des systèmes existants

• Les accords juridiques, la finance client et l’identité d’entreprise restent dans leurs systèmes et se connectent via des API explicites et des tâches de workflow.
• Un reversement complexe peut rester dans le système de gestion des revenus partenaires de l’opérateur.
• Une nouvelle version n’impose pas de bascule à l’échelle de toute la marketplace : les consommateurs migrent à leur rythme, et le rollback sélectionne la version précédente d’un service au sein du bundle.

Il s’agit d’un scénario cible ; les adaptateurs de domaine, l’effort d’intégration et les règles commerciales sont confirmés lors de la phase de discovery.

Détails techniques sur platform.mef.dev →