Figure P.04 - Party and the Main eTOM Roles

People and Organizations exhibit complex behavior. A lot of the behavior can be grouped, based on a particular context, or participation in a certain interaction. <br/>For instance, a child at school will behave as a student and an adult may behave as a teacher. A person playing cricket may behave as a bowler, a batsman or as a fielder or wicket-keeper.<br/>These behavior groups will change over time and will cause problems if we model them using inheritance / specialization. Also, we need to allow for the fact that a Party may play more than one role at any given point in time (an employee may also be a customer; a graduate student may also be a tutor).<br/>By modeling PartyRole as a separate concept from Party, we allow for proper representation of these complex sets of behaviors.<br/>When looking at the eTOM, we see that Parties play roles in the context of an interaction to provide Customer value. <br/>This interaction may be per service or per event (e.g. a phone call).<br/><i>“Note that these are roles and that individual enterprises can adopt different roles in different value networks. Roles represent activities that businesses can engage in and, for example, a service provider may be the customer-facing service provider in one value network and a third party (e.g. wholesale) service provider in another. Relationships are established between the roles, hence the business relationship context model. In today’s fast-moving marketplace, relationships can be very short-lived compared with the more static relationships of the traditional telecommunications market. By focusing on roles rather than organizations, a more flexible business relationship context model can be achieved. Enterprises can adopt and shed roles dynamically, but the relationships between the roles are established, so the adoption of a particular role will also define the relationship of the enterprise playing that role towards another role player.” [eTOM]</i><br/>The roles defined in the eTOM are shown as subclasses of PartyRole in Figure P.04 – Party and the Main eTOM Roles.<br/>Note:<br/><ul>
<li>To support these roles, we will use the “Role Object” pattern [Fowler-Role] [Larman].</li><li>The PartyRole entity represents the common behavior by a Party when acting in the role.</li><li>This model explicitly separates the information held about individuals and organizations from the roles that they perform and the relationships between the roles.</li><li>PartyRole is shown with an id attribute. Existing data may have different id formats for different role types, e.g. “customer number”, “supplier id”, “employee nr” …</li><li>In a value fabric, roles may not be exclusive, e.g. a customer may also be a supplier</li><li>In a number of cases we are interested in parties playing a combination of roles, e.g. staff who use our products get staff discount, suppliers who use our products are “preferred suppliers”</li><li>If the number of roles becomes very large, then it may be necessary to create “sub-roles” so that the inheritance tree does not become unmanageable.</li></ul>
Parties & PartyRoles may be recorded, even if there is no interaction with the Service Provider.<br/>e.g. a Service Provider may wish to keep a list of Phone Dealers (including competitors) to help in determining shop placements. The Organizations are stored, with a role of “Phone Dealer”, but there may never be any “Interaction” between the dealers and the Service Provider.<br/>Other roles are governmental entities, such as regulators, law enforcement, and tax. Shareholders also have a place. Such Business Process Framework process areas, such as Stakeholder and External Relations Management and Enterprise Risk Management (Fraud Management processes often engage Law Enforcement parties) and Shareholder & External Relations Management have various modes of engagement with these. <br/>Examples of roles played by parties include those of interest, such as competitors, sales prospects that provides value directly or indirectly, such as service providers, operators, cloud brokers, infrastructure providers and application developers.<br/>So, there is a need to maintain information about many different roles played by parties and for a common set of business process elements with which many roles are involved.  <br/>The introduction of a Party ABE in the Common domain with the PartyRole entity in it simplifies interactions among business enablers, enabling other organizations playing new/different roles in the value fabric to be represented in the model in their specific domain as specialization of PartyRole. Companies become more open to sharing information and process visibility. And the community of actors self-select themselves into like-minded communities of parties.<br/>Process flows that show the roles engaged in a scenario or use case can take advantage of the common process elements. It contains information about the entities whose lifecycles are managed by these process elements.<br/>It keeps Frameworx sufficiently agile to not require major structure changes to four of the component frameworks when new roles are introduced.<br/>