Involvement Roles

The class InvolvementRole was introduced in Release 12 of SID and is described in the SID document GB922_1UR_Users_and_Roles_R12-0v_1-3.pdf.  It generalised a structure that had been in place in SID for a long time (since V6 at least) the ProductInvolvementRole.

The diagram above is taken from SID V9. 

In SID V12 things changed ProductInvolvementRole became a sub-class of InvolvementRole and it is InvolvementRole that either a CustomerAccount, PartyRole or ResourceRole can be associated (not more than one of these – no “arc” notation showing exclusivity on associations in UML unfortunately).

The idea is that there are actors that can take roles in the use cases and life-cycles of Products (Subscriptions), Resources and Services, and these actors can be Parties (through PartyRoles) Resources (through ResourceRoles) and CustomerAccounts.
 
Looking at this from the PartyRole point of view; this is an excellent idea as it allows the different people involved in a Product, Service and Resource to be defined; the Users, the Administrators, the Engineers etc etc.
 
A CustomerAccount can have roles, other than direct ownership; the default role, I guess, between a Product and CustomerAccount (note there is no simple association between CustomerAccount and Product).  A Product can be paid for by two or more CustomerAccounts as in Split Billing whereby one account pays for, say the monthly recurring charge while the other account pays for any out of tariff charges. 

It is not so clear how this level of involvement can get down to the Service level so that one CustomerAccount ‘owns’ a Service while the other pays for it as according to classic SID the payment is for Products rather than Services, but, hey, it’s “symmetrical” and logically and generically pleasing, so let’s leave it there...
 
The roles a Resource can play and what involvement these can have is not so immediately obvious; however many CSPs use the phone number or MSISDN to identify a Product (subscription) and this can be modelled as a ResourceInvolvement, but a less obvious InvolvementRole is to do with identities – usernames and email addresses.  These are logical resources and these are relevant to Products, Services and I guess Resources.  For Physical Resources it could be tempting to use this for the BOMP (bill of materials) structure of a Resource, but there are far better ways of doing this within the Resource Domain.  I think again this is useful when talking about security – dongles and other security devices could have InvolvementRoles at all 3 levels (Product, Service and Resource).  I wonder if this could even be extended to include DRM.

I wonder if this approach could, should be extended to the CustomerAccount itself.  There a number of PartyRoles that can be involved in the use cases and life cycle of a CustomerAccount from the SalesRep or AccountManager to the PartyRole that signed the contract, theperson responsible for paying the bill.  Then again there can be multiple CustomerAccounts involved in a CustomerAccount – parent account for an account hierarchy, linked account for other more sophisticated split billing – a linking PAYG and Pay Monthly accounts for example, and finally if ResourceRole can be used to provide security through Usernames etc then this is obviously extended to CustomerAccount.

Therefore I believe that the SID should include a new class CustomerAccountInvolvementRole that is defined as follows:

An extension to SID to better model the different involvement roles played by Actors in a Customer Account - examples include "Contract Signer", "Bill Payer", "Account Manager" etc.

CustomerAccountInvolvementRoles can also be played by other CustomerAccounts - allowing a hierarchy of accounts to be set up for example. 

CustomerAccountInvolvementRoles can also be played by ResourcesRoles where for example a security device is used to identify a CustomerAccount.

 

Finally a thought about PartyRoles:  You might say “surely we’ve got PartyRoles that define the type of roles played by a party in a CustomerAccount, for example?”   And you would be right; we’ve got all these Party Roles defined in SID:

•    Customer
•    Competitor
•    Employee
•    OrganizationPost
•    Partner
•    ProjectPartyRole
•    ServiceProviderEmployee
•    Supplier
•    ThirdPartyPayeeAgency
•    ValueNetworkRole
•    WorkforceEmployeeRole
 

Which of these roles can be in an InvolvementRole?  Well obviously all of them – or perhaps it should be none of them.  The User and Roles document GB922_1UR_Users_and_Roles studiously avoids the issue and talks about “Actors” rather than PartyRoles – and perhaps that is right.
 

First of all the PartyRoles listed above are invariant across Products, Resources, Services and CustomerAccounts – a Supplier is always our Supplier, it doesn’t depend on which Product (subscription) we are talking about.  Even Customer is invariant – it is always the Customer across all CustomerAccounts, Products, Resources etc.
 

What the InvolvementRole allows us to do is to define fine grained roles that are different on different CustomerAccounts, Products, Resources etc.  So we can have a PartyRole playing different roles on different CustomerAccounts, Products, Resources etc.
 

So which PartyRole is playing which InvolvementRole?  It still is a little confusing having these different PartyRoles playing different InvolvementRoles – perhaps the SID needs a new PartyRole concrete sub-class called “Actor” and it is the only(?) PartyRole that can play InvolvementRoles.
 

What do you think?