Farewell to the Service Domain?

I certainly agree with what John stated above (since I was one of the "students" who brought up this topic :). I dont want to argue for or against a "Service"-Farewell but just to name some of the aspects an eTOM/SID implementer could focus on there is some interesting issues:

- RFS could be interpreted as kind of a logicalResource that CIM (DMTF Common INformatin Model) and even some Tools like BMC Atrium (that implement their own adaption to CIM) see as an "ApplicationService/SystemService" on the Resource-side. Of course, this technicalService could be to some extend customer-specific and could also implement means for Service impact analysis. The latter would acutally mean to follow a Service-dependency implementation that not only focusses on the Services a Customer will directly order by a Product but to take into consideration all "side-effects" that a Service activation/operation/termination will have (e.g. a Customer orders a UserPackage that includes an AD-Account that - of course - needs to be dependent on NW-infrastructure services not directly ordered). All this could be done on the Resource-side without explicitely implemtenting RFS.

- CFS is very close to Product or its parameters. Imaging you would order a VirtualServer-Product that results in a "primary" LogicalResource with the name "VirtualServer" to be created that - of course - will be dependent on some storage, NW-infrastructure and Admin-Services etc. Why would you explicitely need a Service-like decomposition of the VirtualServer-Product if you include all necessary Product-parameters within the ProductSpecification? So even on the CFS-side there could be scenarios where you could get rid of "Service"

- finally we have a BusinessService in the Integration Framework that is very close to what we could derive from L3/4 or even deeper eTOM processes. But BusinessService would still have another aspect included that focusses on the functionality as well as on the application domains. So to my mind, BusinessService would not be part of this discussion since it is more an integration issue between the frameworx than only a matter of processes and information.

One final remark to that: from our daily experience the most issues we have to solve are at the interfaces between Strategy/Marketing/Customer/Product and Service/Resource horizontals. To some extend you could also see this gap between SIP and OPS processes. "Service" seemed to be the "right" connection between them to map whats  being defined on the left to whats being implemented and operated on the right. But maybe it is an illusion to fill the gap just by introducing a "Service". Maybe after having defined "Service" tha gap remains and actually it is the gap between Product-definition and Product-implementation (as a LogicalReource). :)

Andre

I like this idea of simplification.

One other issue I have with the product and service debate, and particularly the fact that instantiated services are either CFS or RFS, is the whole issue of governance.

IMHO SP hold the governance decision on what they sell as a product, hence we are producing a meta model for Product ( and related entities Product Offering etc.) which SP’s use to create their model of a Product.

Now when we get to CFS and RFS these are also in the main decided by SPs, and in some cased vendors may decide the RFS. So the distinction between CFS and RFS is based on an SP choice / governance decision. So again what we are doing is creating a meta model for Service/CFS/RFS and the distinction is mostly who creates the models from these metamodels. Given we don’t have a governance model in the SID this seem an incomplete modelling situation.

So simplifying the CFS/ RFS  model  into Logical resource does seem to me to be very appealing. And would also remove the Product Service debate which is endless and a symptom that something is not quite right in this area of the model – either wrong or incompletely described as yet. However as this is a dramtic change we clearly need feedback on a range of opinions ans experiences as there may be some simple fix through the use of synonyms or soem outher modelling device.

Interesting discussion. It seems to me that there's one aspect that should be considered in that discussion (not necessarily disqualifying the idea altogether, of course, just as an additional input). To me, instance of a resource is something unique (should it be a logical or a physical resource). If I allocate a logical resource (let's say an IP address) for a particular customer, it is allocated until I free it. IMHO, this has implications on the processes and applications supporting those processes - I need to maintain the inventory of all resources in certain way, obtain new resources somehow (not directly depending on orders), etc. On the other hand, instance of a service is never directly related to a specific "pool". Obviously, I may still need to check capacity before creating a new service instance (actually already during order validation if appropriate), but the capacity is again dependent on the associated resources rather than some "service pool", right?

Just one note that was raised in a very long thread recently by Francis Anderson - basically Products and Services have different lifecycle than Resources. Resources lifecycle relates to the SP while Service/Product relates to the customer. During fulfilment we create new instances of Products and Services while we only allocate Resources which are created in different processes and are 'only' allocated in the fulfillment process. This is just another point to think about - things are not that simple.