Bostjan
Agree with you that this separation is valid and operationally important .
In the Open Digital Archtiecture
IG1167 ODA Functional Architecture v5.0.1 we separate Core Commerce from Production exactly for this reason.
The exposure from ODA Production is of Services.
In most cases these Services will be provided using the
TMF909 API Suite Specification for NaaS v3.0.1with appropriate Service Models usually based on the Information Framework Customer Facing Service (CFS) concept
There is a lot of interest in how to go between Product and Service based models and we are pulling together guidance in what we call vertical /blueprints in the ODA team.
We have explored the implementation of ODA Production in
GB999 ODA Production Implementation Guidelines v4.0.1 which covers both Service and Resource domains and where the general implementation model has been derived from the resuslts of six+ 5G related catalysts projects. This also links to modelling concepts of Reaource Fucntions to support virtualisation and modelling intent based interfaces using the Feature concept embedded in the TM Forum Information Fraweeok and OPEN APIS.
We are just publishing some example Service and Resource models for 5G NRM and Slices in
------------------------------
Dave Milham
TM Forum CHIEF ArchItect
------------------------------
Original Message:
Sent: Jul 16, 2020 08:55
From: Bostjan Keber
Subject: Product to Service mapping: From TMF 622 to TMF 641
I think the "SOM layer" should be managed by the OSS department as traditionally OSS deals with service management. Let me elaborate...
BSS manages commercial product catalog (product specifications, product offerings, prices) which drives core commerce components (e.g. commercial order management, shopping cart, commercial eligibility etc.) and customer experience layer. However, the commercial product catalog should keep information about the services and resources that comprise products and that are needed for product provisioning. This "information" is a technical description of product specifications and could be a simple label or unique service/resource specification identifier added to product specs. The BSS layer usually doesn't deal with technical service decomposition and doesn't need too many service details. So, the product spec. / service spec. mapping should be managed by the BSS department and service spec. design & management should be managed by the OSS department.
If we think about modern architectures (ODA) and OSS/BSS convergence ("digital BOSS"), I think this separation of concerns is still valid. Core commerce components are aware of services, but not of service details as they use end-to-end service management as an abstraction layer to communicate with various domain orchestrators that deal with technical service design & runtime.
------------------------------
Bostjan Keber
Marand d.o.o.
Original Message:
Sent: Jul 16, 2020 08:05
From: DANIEL SOEIRO SANTOS
Subject: Product to Service mapping: From TMF 622 to TMF 641
@Ludovic Robert @Bostjan Keber So, if we have 3 IT departments : BSS IT Department , Integration IT Department and OSS IT Deparment ...the SOM layer would be managed by BSS Department . Am I rigth ? Thanks in advance .
------------------------------
DANIEL SOEIRO SANTOS
Telefonica Brasil S.A.
Original Message:
Sent: Mar 14, 2019 02:56
From: Bostjan Keber
Subject: Product to Service mapping: From TMF 622 to TMF 641
Hi Thomas,
I agree with Dino Pellegrini and Ludovic Robert. Product to service mapping should be done by the unified product catalog as a part of the BSS system. At least this is how we did it at Marand. I wrote about this some time ago in a LinkedIn post: https://www.linkedin.com/pulse/telco-business-transformation-through-centralized-product-keber/
Hope it helps!
Bostjan
------------------------------
Bostjan Keber, Software Engineering Manager
Marand d.o.o.
Original Message:
Sent: Mar 12, 2019 09:19
From: Thomas Dupré
Subject: Product to Service mapping: From TMF 622 to TMF 641
Hi all,
I am wondering which component in TMF will be responsible for product-service mapping (on instance level, not specification level).
Assuming a customer wants to change a specific product of his subscription (e.g. the bandwidth of <g class="gr_ gr_47 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar only-del replaceWithoutSep" id="47" data-gr-id="47">a fixed</g> line access or the disk space of an e-Mail product). Typically this will be done via a product order.
Now I observe that
- TMF622 (Product Ordering) requires product <g class="gr_ gr_53 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del" id="53" data-gr-id="53">ids</g> in the product order (ProductOrder > OrderItem > Product) <g class="gr_ gr_62 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del" id="62" data-gr-id="62">where as</g> TMF641 (Service Ordering) requires service <g class="gr_ gr_55 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del" id="55" data-gr-id="55">ids</g> in the service order (ServiceOrder > ServiceOrderItem > Service)
- service ids are, however, typically not known to the BSS / <g class="gr_ gr_59 gr-alert gr_gramm gr_inline_cards gr_run_anim Style multiReplace" id="59" data-gr-id="59">customer / agent</g>
- in order to generate corresponding service order(s) out of the incoming product <g class="gr_ gr_56 gr-alert gr_gramm gr_inline_cards gr_run_anim Punctuation only-ins replaceWithoutSep" id="56" data-gr-id="56">order</g> we need a mapping from product ids to service ids (on instance level)
So there must be a component somewhere in Product Order that maps product <g class="gr_ gr_58 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del" id="58" data-gr-id="58">ids</g> to service <g class="gr_ gr_60 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del" id="60" data-gr-id="60">ids</g> using a certain "product-to-service instance inventory". Which component is it and is there some API for it?
Thinking further, for usage ticket pricing the <g class="gr_ gr_48 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling multiReplace" id="48" data-gr-id="48">above mentioned</g> inventory could be used vice versa in order to guide an incoming data record (usage ticket) with some technical OSS key to the relevant BSS <g class="gr_ gr_50 gr-alert gr_gramm gr_inline_cards gr_run_anim Style multiReplace" id="50" data-gr-id="50">product / contract</g> that should be charged for this usage.
Maybe @Jonathan Goldberg, @Ludovic Robert, do have valuable hints.
BR Thomas
------------------------------
Thomas Dupré
Deutsche Telekom AG
------------------------------