@Dave WhitfieldVery happy to have the conversation.
Agree that supplementary Word and Excel documents to explain rulesets is a pain.
Explicit statements of how an installation should be executed along with the appropriate characteristics definitely helps here.
There does then remain the question as to whether the client organisation knows which installation services are then available to achieve what they want and this might spill over into qualification (especially where not all downstream suppliers have the same geographic coverage).
On the matter of "if these are 'fake' services (the installation service) then I dont see how the 641 API can honour the contract and return an id for the installation service as it doesnt really feel like something that would make it into the inventory at all"
I am showing my ignorance of the API spec here. But (!) I am not sure that an installation service having an ID means it ends up in inventory. I agree the spec implies that an ID is required for the service associated with the service order item but I am wondering whether that is to deal with the notion of linking service order items to services together with bundling related services etc. during the execution of the order as much as anything else.
It seems to me that in general (not just your case) not everything someone orders will end up with a tangible physical asset with an ID in the inventory. But that just means the ID remains in the order and never makes it to the inventory.
One example is a "self-install" consumer-grade broadband service where one has the option to add something value-added as part of a bundle (that is an associated but separate and optional second service for selected propositions). An example often quoted is to pay extra for a field tech to come out and move or install some wiring to correctly position the network termination point, install the CPE, and perhaps set up the customer's WiFi and demonstrate the features of the service. I choose this example because
The main service results in a working broadband service with associated RFS and an ID in inventory.
The optional installation service is definitely linked to the main service and its sole rationale is to enhance the main service but usually will not end up in inventory alongside the main service.
In catalogue and order terms, the optional installation service could be only loosely related to the "main" service as any old access service and not care whether it is xDSL or "fibre to the home" or even "Ethernet in the first mile" and therefore is available to be bundled with many types of connectivity services at order time.
You could also have more than one flavour of the installation service for various types of customer (home, SME, corporate) or contracted supplier which might have different characteristics to add value in different ways.
Such an installation service is definitely something I have seen people do and I believe has by comparison with what you want to achieve many of the broad properties I think you might be seeking.
------------------------------
Derrick Evans
------------------------------
Original Message:
Sent: Sep 15, 2021 07:39
From: David Whitfield
Subject: TMF641 & TMF633 characteristic modelling
yes agree with you @Ludovic Robert installation specific characteristics that are irellevant later can be added to the 'dummy' installation service. This was in mind already. I think that keeping the inventory clean is definately at the front of my mind.
However my thoughts were that i cant have a single installation service because this would mean that i would have to associate every possible characteristic relevant to every kind of installation to it and then have backend logic to determin if the correct ones were passed. If i have an installation service spec per install type then this allows me to link the relevant characteristics to the specific installation type which means better informed clients. Would you agree?
One final question on the 'requires' link for these specifications.
In 633 i concieve this as being modeled as a 'ServiceSpecRelationship'
In 641 i wondered whether this was one of two and didnt really understand the difference between them?...
serviceOrderItem | A list of service order items (ServiceOrderItem [*]). A list of order items embedded to this order item. |
serviceOrderItemRelationship | A list of service order item relationships (ServiceOrderItemRelationship [*]). A list of order items related to this order item. |
------------------------------
David Whitfield
TalkTalk Group
Original Message:
Sent: Sep 15, 2021 07:10
From: Ludovic Robert
Subject: TMF641 & TMF633 characteristic modelling
Hello David,
If I have to manage this, in order to split the characteristic between the Fiber Service and the Installation Service, I will ask myself: Do I care about this characteristic in one month from now when the service will be live and running?
If yes, the characteristic should be defined for the Fiber service.
If no, the characteristic should be defined for the Installation service.
So no problem for me to have the Characteristic A on the fiber and the characteristic B - C - D on the installation.
I want to get my inventory as clean as I can with only relevant information.
If for some reason I have to go back to the installation characteristic pattern, then I will look to the order.
Hope it helps
Ludovic
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
Original Message:
Sent: Sep 15, 2021 06:38
From: David Whitfield
Subject: TMF641 & TMF633 characteristic modelling
Hi @Ludovic Robert, thanks for going into this detail, this is really helpful! (a picture always helps i find!)
Whilst i do you follow you thinking here i'd question that if we were to model the 'Method' as a characteristic of a single service spec created for the installation then how would we drive the onward dependency of the other characteristics?
i.e. 'newLine' requires the client to pass CharacterisitcA and CharacteristicB
'siwtch' requires the client to pass CharacteristicC and CharacteristicD
------------------------------
David Whitfield
TalkTalk Group
Original Message:
Sent: Sep 14, 2021 09:23
From: Ludovic Robert
Subject: TMF641 & TMF633 characteristic modelling
David,
I was more imagining something like this:
Of course, we could imagine other approach but here my thought was to split the installation itself to the fiber but leverage relationship (present in the service order) to tie them. With this approach, you could also 'sell' some installation offer (I've also illustrated them).
Hope it helps,
Ludovic
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
Original Message:
Sent: Sep 14, 2021 07:42
From: David Whitfield
Subject: TMF641 & TMF633 characteristic modelling
Hi @Ludovic Robert,
thanks for getting back to me, really helpful thoughts, I've interpreted this as: -
- fibre access service specs per supplier in the catalog
- a single 'installation method' specification in the catalog
- 'dependent on' links between these mentions specs
- single characterisitc in the 'installation method' spec to capture which method is needed.
Couple of questions off the back of this
- As we only have a single specification for the 'install method' how would we drive the behaviour of the client to send different groups of characteristics based on which method they picked in the special 'installation type' characteristics?
- Given that this 'installation method' service wont actually be a service (its just a means to get a service installed) it doesnt feel right for it to be added to the service inventory? but that feels strange?
------------------------------
David Whitfield
TalkTalk Group
Original Message:
Sent: Sep 14, 2021 02:57
From: Ludovic Robert
Subject: TMF641 & TMF633 characteristic modelling
Hello David
Have you explored the option to dedicate a specific product and then a corresponding service to manage this installation option?
It will allow you to keep your fiber service 'clean' from the installation process.
This "installation choice" service (and the corresponding) product will have a relationship to the fiber access. We can have for this service (and product) the characteristic to pick the choice. And depending on this you trigger a specific installation process.
Hope it helps
Ludovic
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
Original Message:
Sent: Sep 13, 2021 12:33
From: David Whitfield
Subject: TMF641 & TMF633 characteristic modelling
Hi All,
Within our business there is a requirement for a client to specify the 'method' by which a service will be provisioned.
This is mainly for a focus around fibre access services that are onwardly provisioned with supplier networks. Some of these methods might be: -
- installation of a new line
- switching ownership of a line from an existing CSP to ourselves
- activation of an existing inactive line
The understanding is that variable data accross service specifications is stored within characterisitcss. Each of the 'methods' above would have different data requirements as below: -
What this is suggesting for us is that in the catalog model the follow relationships would be true (which conflicts with TMF): -
- ServiceSpecification -> 'Method' --> ServiceCharacteristics.
I'm reaching out here because it feels like to me that the problem of different provisioning methods driving different data requirements is very likely to have been faced into by others and some steer of how they achieved this would really help us.
thanks in advance for any help
------------------------------
David Whitfield
TalkTalk Group
------------------------------