Recent postings on the TMForum Community pages about the lifecycle of a modem a discussion on the difference between a logical resource and a service made me think it was time for me to describe to the wider world my thoughts and interpretation of the SID in these areas.
First of all, what is a Resource?
For physical resources it is pretty obvious because you can see them, hold them in your hand, put them in your pocket, or as I always say in my training course, put a ribbon round it if it is too big to hold. The really big resources are usually the Telecom’s Service Provider’s own equipment, be it a base station, the DP, or the switch, but of course PhysicalResources include things like the phone, the modem, the mobile, the SIM card, the memory card and the copper pair in the DP that belong to a Customer’s Product (subscription)1 Additionally a physical resource will always be located somewhere, at an address, a geographic location, or perhaps in a local location (e.g. a room in a building).
A logical resource is therefore something that cannot be touched. Generally LogicalResources are numbers, like the phone number, MSISDN, IMSI, IMEI, PIN, PUK etc. One realisation I made a few years ago is that anything that is a number is a LogicalResource, from π (which is an instance of the LogicalResouceSpecification of “Irrational Number”) through to a binary string. Really large binary strings are often programs, or perhaps a JPG picture or a MP3 music clip. So programs, images, and music files are all LogicalResources too. This realisation is useful in many ways; not least in understanding how a LogicalResource can have a location. For example, Firefox. The ResouceSpecifcation for Firefox belongs to Mozilla. I have an instance installed on my p.c. ( a PhysicalResouce), so a LogicalResource can installed in a PhysicalResource. But consider an MSISDN it is installed in the HLR (a logical resource itself) which in turn is installed in the Switch. So a LogicalResource must either be installed in (located in) another LogicalResource or a PhysicalResource and the PhysicalResource has a location. My p.c. is on my desk in my study in my apartment in Ankara.
Another thing about Resources is that they have lifecycles outside a Product (subscription) and this is where the question about the lifecycle of a modem came in. The TMForum Community member posted a question about a home internet product (specification) that could deliver a free modem, or a modem that is rented to the Customer or be used by a Customer who already owned a modem (as different ProductOfferings) The complex validation rules about what happened if a Customer subscribes to the ProductOffering that delivers the free modem and then cancels the subscription only to come back later to take out the ProductOffering that could use the Customer’s own modem.
Consider it from the modem’s point of view. It was born (manufactured) in a factory in Taiwan or PRC and shipped through a number of warehouses and Suppliers until it ended up in a box on a shelf in a Supplier’s shop together with a CD-ROM that had its driver software, a cable to connect the modem to the telephone point, another cable to connect the modem to a p.c., an instruction manual and a piece of paper with an activation code on it. All of these are Resources, and each will have had its own life to get to this point. The box all these Resources are in represents (as near as damn it) the ProductOffering. The ProductOffering also includes a number of Services which are (usually) the reason the Customer purchases the ProductOffering. These services are not to be found in the box, directly, but ultimately are delivered by software, either running on the Customer’s computer, in the modem, or in the Service Provider’s network... but I am getting distracted, I was talking about the modem’s life.
One day someone (a Customer) buys the box and takes it home (the new location for the modem). He follows the instructions and plugs in the modem correctly to the wall socket and his p.c., loads the software and activates the service through entering the activation code and establishing a username and password (again logical resources) with the Service Provider to set up the Product (subscription). Each of these Resources have a ResourceRoleProductInvolvement (a type of ProductInvolvementRole) that link and show the role of the Resource in the Product.
The Customer uses the modem and the Services provided by his Product (subscription) for a year or so and then cancels the Product (subscription) for some reason. He can no longer use the Services provided to him by the Product (internet access, email etc) and he gives up the username and password 2. However the modem and cables, CD-ROM and even the software on his p.c. are still all at his house, but not associated with an active Product. This seems to scare a lot of people. A suggestion was that the Modem should be associated with a bundled Product so that when the Internet Product was cancelled the relationship between the Customer, the Resource and the Service Provider could be maintained, just in case the Customer ever came back. You could do that, but if you do that then you should also do that for things like Phone Numbers, MSISDNs and anything else the Customer can purchase from the Service Provider and carry away.
In my mind the Resource still exists; it hasn’t disappeared just because the Product has been cancelled. Just like the Person playing the role of Customer still exists even after the Product (subscription) is cancelled and the Party is no longer playing that role. It is no co-incidence that Parties play PartyRoles that in turn play PartyRoleProductInvolvement (roles) and Resources play ResourceRoleProductInvolvement (I think SID has got the name wrong it should be ResourceProductInvolvementRole).
Once this is accepted then the whole problem that the TMForum poster was struggling with disappears.
And now to the difference between a Service and a Resource. In Telecoms at least, a Service is provided by a Resource, and as I have explained earlier, the Services are nowadays delivered by software, or LogicalResources (old-fashioned Strowger switches delivered the service of connecting a call mechanically). OK there are service delivered by the telco that may involve Human Resources, like an installation service, but this is not directly modelled in SID (I wonder why?) but is considered something covered by the likes of a WorkOrder or ServiceOrder.
I will cover how Services differ from Resources in Part 2 of this post.
Footnotes:
1. I put subscription in brackets because in SID the subscription is referred to by the word Product. Product is an instance of a ProductSpecification
2. The username and password seem to be, interestingly, Resources that don’t have a lifecycle outside the Product.
Subscribe to:
Post Comments (Atom)
2 comments:
There is also that grey area where physical and logical resources overlap. Actually, devices which obviously have a physical manifestation also have logical aspects. The functions that the device can perform can be treated as logical aspects of the physical resource. For example, a modern "cable modem" is typically a router, a WiFi access point, an Ethernet switch, and a firewall all in one box. A service provider's multi-service access node might be an ATM switch, a MPLS LSR, and a Gigabit Ethernet switch.
Ben
Yes, of course you are right. In fact unless a resource is completely mechanical it will always be a compound resource composing of both logical resources and physical resources. Every thing from cars to credit cards have both hardware and software embedded in them.
Even within your example of the cable modem, the router is itself a compound resource made up of a combination of software embedded in the circuit boards and the circuit boards and chips themselves.
Unless the organisation (Service Provider, or whoever is using the SID/Frameworx Information model) is going to manage the logical resource elements separately then what benefit is there in modelling the 'absolute truth' about the resource by calling it a compound resource and then modelling the hardware separately, when an approximation will serve.
My approximation of saying that Resource Facing Services are provided by Logical Resources that is installed in physical resources is (usually) sufficient for most OSS/BSS applications and to support the information exchange between those applications.
If however you are building an application that works right down at the Element Management level then within that application you may well have to model many of the Resources as Compound Resources, but when this app communicates with the rest of the OSS/BSS domain an approximation may suffice as the detail is not relevant to the 'enterprise'.
I will be posting the blog entry I recently wrote on the TMForum on "No Absolute Truth" here soon. This discusses a related subject; deciding how to implement the SID within an organisation, which I believe depends on how it is going to be used.
Post a Comment