com wp cbe concepts.1.2

8/3/2019 COM WP CBE Concepts.1.2

1/73

OSS through JavaTM Initiative

Core Business EntitiesModel White Paper

OSS through Java Initiative

COM-WP-CBE_concepts.1.2.doc

Copyright 2004 BEA Systems, Inc., Mahindra-British Telecom, Metasolv

Software Inc., Motorola, Inc., NEC Corporation, Nokia Networks Oy,Nortel Networks Limited, Sonic Software Corporation, Sun Microsystems,

Inc., Telcordia Technologies, Inc. All rights reserved. Use is subject to

license terms.

Edited by John P. Reilly and Pierre Gauthier, MetaSolv Software

Contributors:

Dave Raymer, Motorola; Andreas Ebbert, Nokia; Melody Khair, Digital

Fairways; Maricio Arango, Sun; Colin Ashford, Nortel

TM Forum SID Team John Strassner (Intelliden), Wayne Sigley (Telstra),

Helen Hepburn (British Telecom), Chris Hartley (Telstra), and Cliff Faurer

(TM Forum)

COM-WP-CBE_concepts.1.2.doc page 1 / 73


2/73


Executive Summary

API developers face the task of defining, modeling, and implementing coreconcepts in the course of almost every project in which they are involved.

Core concepts include individuals (such as employees) & organizations

(such as customers), products, services, & resources, locations & addresses,

along with interactions that involve individuals and organizations. Thesecore concepts represent who, what, when, where, and why that

make up the set of fundamental concepts present in todays world.

Perceptive developers reuse these concepts across the projects on whichthey work, but they still must implement them at least once. As well as

being time-consuming, this effort also breeds inconsistency, a major threat

to interoperability.

The OSS through Java initiative has the opportunity to improve the

efficiency of API developers and maintain consistency by defining,

modeling and implementing these core concepts. This work effort canleverage work already in progress being carried out by the TeleManagement

Forums New Generation OSS (NGOSS) Shared Information/Data (SID)

Model team.

The SID represents a synthesized view of information derived from various

industry models. This enables existing applications and software to beleveraged in building systems. The SID, a federation of models, also forms

a common information language that the industry can use to describe

management information.

The scope of this document is the explanation (based on the TM ForumSID) of these core concepts, their associated information models, and thespecification of the interfaces, which involve these core concepts. The core

concepts are referred to as core business entities in this document. Thesedefinitions, information models, and specifications, which together

represent the OSS/J API core model, can and should be used as the

cornerstone for any subsequent OSS/J API development.

The CBE is a subset of the SID that is based on the needs of the OSS/J APIsin existence. The subset may represent complete portions of the SID model

or partial portions that contain only higher level SID entities. As new APIs

are added or existing APIs are enhanced, the CBE model will expand based

on the scope of the new or enhanced API.



3/73


Table of Contents

Executive Summary .......................................................................................................... 2

Table of Contents .............................................................................................................. 3

Table of Figures................................................................................................................. 6

Table of Code Snippets..................................................................................................... 7

1 Preface........................................................................................................................ 8

1.1 Objectives............................................................................................................ 8

1.2 Audience.............................................................................................................. 8

1.3 Approval and Distribution.................................................................................. 8

1.4 Related Information ............................................................................................ 8

1.5 How this document is organized......................................................................... 8

1.6 Revision History for version 2.0 ......................................................................... 9

2 Introduction............................................................................................................. 10

2.1 Opportunity Knocks .......................................................................................... 10

2.2 Core Business Entities ...................................................................................... 10

2.3 A Starting Point for Core Business Entities (CBE) .......................................... 12

3 Concepts................................................................................................................... 14

3.1 Business entity................................................................................................... 14

3.2 Core Business Entity......................................................................................... 14

3.3 Core Model ....................................................................................................... 14

4 Core Business Entity Modeling Concepts............................................................. 15

4.1 Introduction....................................................................................................... 15

4.2 Managed Entities .............................................................................................. 17

4.3 Entities .............................................................................................................. 17

4.4 Entity Specifications.......................................................................................... 17

4.5 Associations ...................................................................................................... 21

4.6 Constraints........................................................................................................ 23

4.7 Generalization................................................................................................... 23

5 SID Model Overview............................................................................................... 24



4/73


5.1 The Who - Party................................................................................................ 245.1.1 Overview................................................................................................... 24

5.1.2 Party Fundamentals................................................................................... 24

5.1.3 Contact Medium........................................................................................ 255.1.4 Party Roles................................................................................................ 26

5.1.5 Interactions between Parties ..................................................................... 295.1.6 Associations between Party Roles ............................................................ 295.1.7 Party Names.............................................................................................. 30

5.1.8 Interworking with other business entities ................................................. 31

5.1.9 Example Extension of Party Customer .................................................. 32

5.2 The What Product, Service, and Resource..................................................... 335.2.1 Overview................................................................................................... 33

5.2.2 Product Inventory...................................................................................... 35

5.2.3 Service Inventory...................................................................................... 35

5.2.4 Resource Inventory ................................................................................... 365.2.5 Use Cases.................................................................................................. 37

5.3 The Where - Location........................................................................................ 375.3.1 Disclaimer ................................................................................................. 38

5.3.2 Overview................................................................................................... 385.3.3 Location .................................................................................................... 39

5.4 The When and the Why Business Interaction................................................. 415.4.1 Overview................................................................................................... 41

5.4.2 Sample Business Interaction Use Cases ................................................... 46

6 Core Model and SID Adoption Strategies ............................................................ 50

6.1 Core Model Strategy......................................................................................... 50

6.2 SID Adoption Strategy ...................................................................................... 50

6.3 CBE Scope Defined Using the SID Framework ............................................... 54

6.3.1 Product Domain ........................................................................................ 556.3.2 Customer Domain..................................................................................... 55

6.3.3 Service Domain......................................................................................... 55

6.3.4 Resource Domain...................................................................................... 55

6.3.5 Common Business Entities Domain ......................................................... 56

7 CBE Java Interface Definition Examples ............................................................. 57

7.1 Inventory and Service Activation Interaction Example .................................... 587.1.1 Inventory and Service Activation Collaboration Principals ..................... 58

7.1.2 Use-Case Customer Orders A Product ..................................................... 59

7.1.3 Use-Case: Product Order Decomposition................................................. 617.1.4 Usage of CBE in Service Activation ........................................................ 62

7.1.5 Code examples of Inventory and Service Activation Usage .................... 63

8 Compatibility with Other Industry Models.......................................................... 66

8.1 ebXML Party Information................................................................................. 66



5/73


8.1.1 PartyId element......................................................................................... 678.1.2 PartyRef element....................................................................................... 68

8.1.3 CollaborationRole element ....................................................................... 69

8.2 CBE Representation of ebXMLs Party Information Requirements................. 70

Glossary and References ................................................................................................ 72

8.3 Glossary............................................................................................................ 72

8.4 References ......................................................................................................... 72



6/73


Table of Figures

Figure 1 - Fundamental Entities........................................................................................ 10Figure 2 - Meta-Layers ..................................................................................................... 16

Figure3 - Example of a Core Business Entity................................................................... 17

Figure 4 - Example of Entity Instance Defined by Entity Specification .......................... 19

Figure 5 - Example of Entities and Entity Specifications................................................. 20Figure 6 - Associations Between Entity and Specification Instances............................... 21

Figure 7 - Example of an Association............................................................................... 22

Figure 8 - Showing How Party Fits In.............................................................................. 24Figure 9 - Basic Party Model (source: TM Forum) .......................................................... 25

Figure 10 - Initial Party Model (source: TM Forum) ....................................................... 26

Figure 11 - Party and the Main eTOM Roles (source: TM Forum).................................. 28Figure 12 - Parties Interact Via Their Roles (source: TM Forum) ................................... 29

Figure 13 - Parties Can Be Associated Via Their Roles (source: TM Forum)................. 30

Figure 14 - Naming For Parties (source: TM Forum)....................................................... 31

Figure 15 - Possible Links to Other Parts of the Core Model (source: TM Forum)......... 32Figure 16 - Customer Shown As An Extension of Party Role (source: TM Forum)........ 33

Figure 17 - Showing How Products, Services, and Resources Fit In ............................... 34

Figure 18 - Inventory Business Entities............................................................................ 37Figure 19 - Showing How Locations Fit In ...................................................................... 38

Figure 20 - Initial Location Model.................................................................................... 40

Figure 21 - Showing How Interactions Fit In................................................................... 41Figure 22 - Types of Business Interactions (source: TM Forum)..................................... 42

Figure 23 - The Relationship Between Business Interactions and Business Participants

(source: TM Forum).................................................................................................. 43Figure 24 - The Relationship Between Business Interaction and Products, Services, and

Resources (source: TM Forum) ................................................................................ 44Figure 25 - The Relationship Between Business Interactions and Locations (source: TM

Forum)....................................................................................................................... 45

Figure 26 Business Interaction Business Entity Model (source: TM Forum) ............... 46

Figure 27 - SID Product Offering ABE ............................................................................ 51Figure 28 - Sample OSS/J API Trouble Ticket Attributes ............................................... 52

Figure 29 - Sample OSS/J Trouble Ticket Methods......................................................... 52

Figure 30 Current CBE Scope ....................................................................................... 54Figure 31 - Interaction Principals between Inventory and Activation Components......... 58

Figure 32 - Customer Interaction: Order a New Product.................................................. 59

Figure 33 - Decomposition of a Product Order into Two Service Orders........................ 61

Figure 34 - Modeling Concepts between Service Activation and CBE............................ 63Figure 35 - CBE Party Model's Compatibility with ebXML Party .................................. 71



7/73


Table of Code Snippets

Snippet 1 - Query the Product Catalog ............................................................................. 63Snippet 2 - Use A Specification To Instantiate A Product ............................................... 64

Snippet 3 - Create And Start An Order............................................................................. 64

Snippet 4 - Query Resources............................................................................................. 64

Snippet 5 - ebXML PartyInfo Element............................................................................. 66Snippet 6 - Example of Two URI References .................................................................. 68

Snippet 7 - Example of the PartyRef Element .................................................................. 69

Snippet 8 - Example of the CollaborationRole Element................................................... 69



8/73


1 Preface

1.1 Objectives

The intention of this document is to provide definitions and to present

outline models for an initial set of core business entities (also called shared

business entities). A companion Rational Rose model contains the UMLrepresentation of the core business entities. The initial set of objects

includes Party (individual or organization), Product, Service, Resource,

Location and Address, and Interaction (between parties).

1.2 Audience

This guideline is intended for use by various groups specifying APIs within

OSS/J.

1.3 Approval and Distribution

This document has been reviewed and approved by the OSS/J Core

Business Entity (CBE) team as well as the OSS/J Common team.

Subsequent versions will be developed, reviewed, and approved by the CBE

team. Versions will also be reviewed and approved by the OSS/J Common

team. The TeleManagement (TM) Forum Shared Information and Data

Model (SID) team may also provide reviews of subsequent versions.

The documents latest version will be made available for distribution on the

OSS Through Java web site.

1.4 Related Information

Some of the content of this document was extracted from TM Forum SID

documents (GB922 and GB926 series) and the OSS/J Inventory API

(JSR142).

Copies of these documents are available to registered users on the TMForum web site and the OSS Through Java website.

1.5 How this document is organized

This document contains a brief introductory section and a section explaining

core business entity concepts.



9/73


Following these two sections are separate sections that present the core

business entities

Party

Product, Service, Resource

Location & Address Interaction

Each of these sections provides examples of how the core business entities

represented in the core model can be used in OSS/J API specifications, such

as the Service Activation and Inventory APIs

1.6 Revision History for version 2.0

Date Version Author State Comments

12 Apr2004

2.0 John Reilly Draft Add CBE coverage ofSID Framework; place

interface definitions into

a separate document

23 Apr

2004

2.1 Andreas

Ebbert

Draft Improved Figure 4

Added chapter 7.1

8 Dec 2004 1.2 John Reilly Final Updated doc name andversion number for

inclusion in 1.2 Design

Guidelines.



10/73


2 Introduction

2.1 Opportunity Knocks

Throughout the years, API developers have repeatedly come up with

definitions and implementations of core concepts such as locations,

addresses, individuals, and organizations, products, services, and resources.These attributes represent a core set of objects that should be defined and

implemented once, and then reused again and again.

This represents an opportunity for the OSS through Java initiative todefine a set of core business entities (sometimes referred to as shared

business entities) represented in a core model. The end result would be a

java package for the core business entities, javax.oss.cbe, and its

associated XML schema. Any OSS/J API should use the core model as a

starting point for API development. The use of this model would resolvethe overlaps and inconsistencies already present in some OSS/J APIs. Itwould also eliminate any future inconsistencies and duplication of effort.

Additionally, the core model could be distributed to several repositories to

implement the model with different technologies and/or differentnative

schemas

As new APIs are developed, additional core business entities may be added

to the core model.

2.2 Core Business EntitiesThe first step is to identify a set of core business entities. The things in

which any enterprise is interested can be represented by entities that answer

five fundamental questions as shown in the figure below.

Who (Party)

Why (Reason)

What (Thing)

When (TimePeriod)

Where (Location)

Figure 1 - Fundamental Entities

For example, an SLA Violation Alarm (Notification) about Service is

communicated to SLA Management (Organization). The SLA Violation



11/73


Alarm may result in a Billing Credit Notification being sent to a Customer

(Individual or Organization) at the Customers home Address.

The initial scope of the core business entity package would include

The Who Party and Party Roles (Customer, Service Provider and soforth)

The What - Product, Service, and Resource

The Where - Location & Address

The When and Why - Interaction

Parties are individuals and organizations that interact with an enterprise as

the enterprise carries out its day-to-day business. Parties play roles as they

interact with an enterprise. The roles parties play can be customers,employees, suppliers, partners, the enterprise and its organizations, and so

forth. Parties and the roles parties play represent a distillation of all the

attributes, associations and behavior that customers, employees, and so forthhave in common. Examples from an attribute perspective include name,

location and address, and contact medium. From a behavioral perspective,

parties come into existence, their status is tracked during their life of

interest to the business, and they are eventually no longer of business

interest.

Location is a concept representing a place, such as a structure like a

building. An address is not a type of location but is a means of finding alocation. Addresses may have aliases, for instance Cnr Surf and Roban

streets may be an alias for (refers to the same location) as 15 Roban Street.

Unlike parties and interactions, which are distillations of things common toa number of different objects, locations and addresses are not abstractions

but business entities in their own right that are associated to a number of

other business entities, including parties, interactions, resources, services,

products, and so forth.

A Product is an externally facing representation of a service and/or resource

procured by the market. For example, a real-time broadcast of a footballmatch. A Service is an intangible realization of a Product or something

provided in support of a Product. For example, a video streaming

connection used to transmit the football match to a customers PDA; an

installation service provided for a cable modem. A Resource is part of anenterprises infrastructure utilized by a Service or a good procured by the

market. One example of a resource is a wireless network (infrastructure)

utilized by the video streaming connection. Another example is aninventory of cable modems (goods procured by the market) offered to the

market.

Interactions are arrangements, contracts, communications and activities that

involve parties playing a role. For example, a prospective customer may



12/73


request information about a real-time football match broadcast productoffering. This request may then become an order for the broadcast to be sent

to the customers PDA. This order is another type of interaction.

Interactions, like parties, represent a distillation of attributes, associations,and behavior common to requests, responses, notifications, and agreements.

For example, in addition to all forms of interactions involving partiesplaying a role, interactions also involve products, services, resources,

product offerings, locations, and addresses from an association perspective.

A number of core business entities, such as Party and Interaction, represent

abstract concepts. As such, their concrete subclasses inherit the behaviors,attributes, and associations of the abstract class. Use Cases associated with

the abstract class can also be inherited. The benefits of Use Case inheritance

will be shown via example in this white paper. With the introduction of

UML 1.3, a new relationship between use cases was introduced-

generalization. A generalization relationship between parent and child use

cases is one in which the child is a more specialized form of the parent usecase. The child inherits the behaviors of its parents and adds new behaviors,

and specializes in behaviors inherited from the parent. Generalized use

cases typically involve abstract actors and abstract classes.

2.3 A Starting Point for Core Business Entities (CBE)

Today the communications and information service industry is awash with

information and data models and model fragments. Organizations andforums such as the OSS through Java Initiative (OSS/J), Object

Management Group (OMG), DMTF (Distributed Management Task Force),

T1M1 committee of the Alliance for Telecommunications IndustrySolutions (ATIS), International Telecommunications Union (ITU), InternetEngineering Task Force (IETF), and Internet Protocol Detail Record

Organization (iPDR.org), TeleManagement Forum and others, havedeveloped models and model fragments. These models have formed the

foundation for fruitful attempts at OSS interoperability.

While it is unfortunate that we have so many models, their existence has

pointed out the pressing need for a shared information model. What wouldbe better than these disparate models is a shared information/data model

that represents a synthesized view of a number of these industry models.

This synthesized model would form a common information/data languagefor the industry along with facilitating interoperability among diverse sets of

applications. This is the focus of a major initiative underway in the

TeleManagement Forums Shared Information and Data Modeling team

(SID)

The SID model is gaining acceptance within the communications and

information services industry. For example, the TM Forums DEN-ng

project is an application representing the practical implementation of the



13/73


SID model. TM Forum Catalyst projects are using the SID as aninteroperability model for products, services, and resources. The OMG is

planning to present the SID documents as a OMG white paper that

recommends the use of the SID as the foundation for the OMGs TelecomDomain Task Force configuration independent model. ITU/T1M1 are using

the SID as a source for its Global Telecom Data Dictionary (GTDD).

The SID model contains a set of common business entity definitions andmodels that can be used to form the foundation for the core model of OSS/J

CBEs (shared business entities using TM Forum terminology). This

foundation can be extended as needed by OSS/J APIs, but the foundations

basic structure should not be compromised.



14/73


3 Concepts

3.1 Business entity

A business entity is a thing of interest to the business. Business entities are

characterized by attributes. Business entities also possess other properties,

such as involvement in associations with other business entities or entitytypes and exhibition of behavior. These properties (attributes, associations,

and behavior) ofbusiness entities may be inherited by the other entity types

or other business entities.

3.2 Core Business Entity

Core business entities represent five basic concepts present in the day-to-

day running of every enterprise. The concepts are who, what, where, whenand why.

A core business entity may be an object that primarily supports a group of

TM Forum eTOM processes. These business entities support processes inthe Product, Service, and Resource layers of the eTOM. A core business

entity may also be a business entity that is common to a number of eTOM

processes, for example Location and Address.

Core business entities can represent an abstraction, such as a superclass, or

a real world object.

3.3 Core Model

The core model contains the artifacts that fully describe core business

entities. The artifacts include core business entity definitions and UML

models. The UML models contain class diagrams that document the

attributes and operations of the core business entities.



15/73


4 Core Business Entity Modeling Concepts

Note: The contents of this chapter are a modified extract from the OSS/JInventory API Specification (JSR 142). The concepts presented in the

Inventory API have been generalized here so that they apply to the Core

Business Entity model.

4.1 Introduction

The framework for meta-modeling data proposed in this document is based

on an architecture composed of three layers. Each of the layers provides

different levels of abstraction. These layers are defined as follows:

The meta-model layer is comprised of the descriptions that define thestructure and semantics of core business entity models (i.e., information

model for meta-data). The model layer is comprised of the meta-data that describes the core

business entity information. This layer is also referred to as meta-data

or core business entity model. Core models could be translated to

specific schema definitions for various repositories (e.g., XML Schema,

SQL DDL, LDAP Schema, etc.)

The instance layer is comprised of the core business entity informationstored in the repository. This information is also referred to as coredata.

The meta-model defines a subset of UML elements to be used for modelingCore Business Entities. The meta-model uses the UML concepts of class,

association and constraint to model the elements managed entity, entity,

entity specification and association. (see Meta Layers Figure).



16/73


Meta-model Layer

Model Layer

Instance Layer

Entity Entity Specification Association

Subscriber

VPN_Product

SP1 Inc.

VPN_1

VPN_2

SubscriberSubscribesProduct

0..* 0..*

Managed Entity

Figure 2 - Meta-Layers

The core model defines completely the meta-model layer and partially the

model layer.

Core business entity models are expressed using class diagrams (see the

following chapters). Object diagrams (snapshots), which are the

instantiations of class diagrams, may be used to provide examples and

explore particular situations.

The Core Meta-model extends the UML vocabulary with the following

concepts:

Entity with stereotype Entity Interface ().Entities are value type objects representing for example inventoryconcepts such as Product, Service and Resource.

Entity Specification with stereotype Specification Interface(). Entity Specifications are value type

objects representing for example specifications of inventory entities.

Association with stereotype Association Interface ().

A class diagram representing a Core Business Entity Model could contain

the following elements:



17/73


Interfaces with stereotype Entity Interface () andtheir methods to get and set their attributes, leveraging the Entity

concept defined in the Core Business Entity meta model.

Interfaces with stereotype Specification Interface () and their methods to get and set their attributes, leveraging

the Entity Specification concept defined in the Core Business Entitymeta model.

Associations (Aggregation is a special form of association). Someassociations are represented as first class objects with stereotype

Association Interface ()

Constraints

Generalizations

4.2 Managed Entities

A Managed Entity is the root class for all Core Business Entity model

entities and entity specifications.

4.3 Entities

An Entity is used to represent core business entity objects, which share the

same structural and behavioral features.

Entities can be represented as interfaces with stereotype Entity Interface(). The entity contains a list of methods to get and set

its attributes.

Resource

getAttributeValues()setAttributeValues()getAllPopulatedAttributes()

Figure3 - Example of a Core Business Entity

4.4 Entity Specifications

An Entity Specification captures invariant characteristics and constraintsapplicable to all instances of the same business entity. For example, a

GoldBroadbandAccessServiceSpecification may capture the

characteristics, configuration and QoS parameter ranges, specific to a

Gold Broadband Access service offering. Several specification instances

may exist for the same inventory entity type. For example, Gold, Silver

and Bronze specifications may be defined for a

BroadbandAccessService. A Product Specification includes features,



18/73


such as height, weight, and so forth, common to all instances of a ProductOffering based on the specification. The use of the Entity

Specification/Entity modeling pattern provides a number of benefits over

using a pattern that models invariant characteristics as attributes of anEntity. First, the attribute values are not duplicated for each instance of an

entity characterized by the same specification. Second, when updating oneor more characteristics, only the specification instance characteristicsrequire updating as opposed to the characteristics embedded in each entity

instance. Third, if the last entity for a specification is deleted, then entity

specification characteristics remain, as opposed to losing the entity

specification characteristics if the characteristics are embedded within each

entity instance.

In some cases, a characteristic, such as color, may take on multiple possible

values. To satisfy this requirement an Entity Characteristic and EntityCharacteristic Value is used. Color would be an instance of Entity

Characteristic. There would be an instance of Entity Characteristic Value

for each possible color, say for a Product, such as red, blue, green, and soforth. This pattern allows new characteristics and their values to be added

or inactivated without impacting the model. Each Entity instance associated

with an Entity Specification would be associated to the characteristic valuechosen for the Entity. For example, Jims cell phone is associated with red;

Joans phone is associated with blue. Adding a new color does not impact

any existing entities, nor does inactivating an existing color.

Catalogs are collections of entity specifications (e.g., service catalog

composed of service specifications, product catalog composed of product

specifications, resource catalog composed of resource specifications, and so

forth.).

An entity instance is defined by a single entity specification. (The same

entity specification may be used to define multiple entity instances.) Note

that some entity instances may refer to no entity specification and still be

valid ones.

Another possible use of entity specifications is in the Customer SLA API.

For example, an SLA specification could be the repository for standard

terms and objectives used to create SLA entity instances. Additionally, thespecifications could contain standard compensation amounts, such as

discounts and rebates, which could be associated to SLA entity instances, ifSLA objectives are not met. Associations among these entity specificationswould define rules as to how the terms, objectives, and compensation

amounts can be used together to define an SLA instance. For example, one

type of objective may only be compensated via a discount, and not a cash

rebate.

A number of other OSS/J APIs including those planned in the API roadmap,

such as Customer Order Management, Workforce Management, Trouble



19/73


Ticketing, could take advantages of entity specifications. For example, aspecification list of commonly performed tasks could find a home as

Workforce Management specifications.

I nvent ory Model Inst anc es

BroadbandAccessSpecification

transferVolume

supportType

getTransferVolume()

setTransferVolume()

getSupportType()

setSupportType()

BroadbandAccess

username

password

domain

getUsername()

setUsername()

getPassword()

setPassword()

getDomain()

setDomain()

describes

GoldAccess :


# supportType = priviledged

# transferVolume = 1000000

BobsAccess :

BroadbandAccess

# domain = java.org

# password = sarah

# username = bob

describes

Figure 4 - Example of Entity Instance Defined by Entity Specification

In order to define the characteristics of complex entities (e.g., servicebundles containing multiple services, devices containing shelves, cards and

ports, etc.) entity specifications could also participate in associations with

other entity specifications. An example of relationships between entities and

entity specifications is presented on the following diagram.1

1 Relationship meaning is discerned as in reading from top to bottom, left to right. For example, in

, the describes relationship is read as

BroadbandAccessSpecification describes BroadbandAccess.

Figure 4

- Example of Entity Instance Defined by Entity Specification



20/73


Product

Service

aggregates

aggregates

ProductSpecification

describes

ServiceSpecification

aggregates

aggregates

BroadbandAccess


describes

E-Mail

E-MailSpecification

describes

Backup

BackupServiceSpecification

describes

Figure 5 - Example of Entities and Entity Specifications

The following instance diagram (corresponding to the information model on

Figure 5 - Example of Entities and Entity Specifications) provides examples

of relationships between entity and specification instances.



21/73


goldInternetService :


bobsInternetSu

b : Product

goldBAccess :


goldEmail :

E-MailSpecificationgoldBackup :

BackupServiceSpecification

bobsAccess :

BroadbandAccess

bobsEmail :

E-Mail

bobsBackup :

Backup

: aggregates

: aggregates

: aggregates

: describes

: aggregates

: aggregates

: aggregates

: describes

: describes: describes

Figure 6 - Associations Between Entity and Specification Instances

4.5 Associations

Associations are the means by which binary relationships between entities

and entity specifications are represented.

Associations are characterized by their cardinality and the roles at each

association end.



22/73


PartyRole

Resource0..* 0..*

+owner +ownedResource

OwnerOwnsResource

Figure 7 - Example of an Association

No specific implementation is assumed for associations defined in the core

business entity model. However, it is expected that with the OSS/J API inmost cases associations will be implemented as first class objects (that is,

Java classes).

The recommended implementation of the associations could be explicitly

captured in the information model, using a constraint for the association,indicating that first class objects or attributes should be used.

The separation of object structure from associations allows the creation and

removal of associations without affecting the objects themselves.

The following rules apply to core business entity associations:

When creating an association the two entity instances linked by theassociation must exist in the core business entity repository.

When one of the entity instances linked by an association instance isdeleted, the association instance should be deleted as well.

If the association instance is not deleted, then, in order to maintainreferential integrity, references to a deleted entity must be updated to benull.

Containment is a special type of relationship. It is of particular importance

for business entities such as the resource inventory business entities, forexample, representing physical equipment hierarchies. There shouldnt be



23/73


any difference in the way containment relationships are managed by theOSS/J APIs. For some functions specific containment based queries may be

defined.

In order to allow validation, association rules are used. Association rules area metadata concept and can be accessed through the APIs, such as the

Inventory API, i.e., the client will not only be able to retrieve the list of

supported association types but also the rules applying to these associations.

Each association rule consists of the following components:

The type of each entity involved in the association;

The role of each entity;

The cardinality constraints;

The constraints on the entities involved in the association.

An association is considered valid if it satisfies all the requirements of thecorresponding association rule.

Although association rules may appear similar to entity specifications, thereare fundamental differences between the two concepts. Entity specifications

are dynamically created while association rules are not. The primary goal of

the entity specifications is to allow specialization according to a predefinedset of parameters, while the primary goal of association rules is to provide

means for validation.

4.6 ConstraintsConstraints are used to attach consistency rules to model components.

Constraints for the Core Business Entity model may be described in

informal language (e.g., English) or could be formally expressed in Object

Constraint Language (OCL) as described in the UML specification.

Note that for instance the association rules are captured in Core Business

Entity information models as constraints attached to the association links.

4.7 Generalization

Generalization represents a classification relationship between classes. The

most important characteristic of this relationship is the substitutability. Thisrequires that wherever a super-class is used in a model, it is possible to

replace it with one of its subclasses with no effect on the properties of the

model. This means that all attributes, associations and constraints of a

super-class should be inherited by its subclasses.



24/73


5 SID Model Overview

5.1 The Who - Party

Note: The contents of this chapter are a modified extract from the

TeleManagement Forums Shared Information/Data (SID) Model document

GB922 Addendum 1P.

5.1.1 Overview

This chapter answers the question who? and deals with people and

organizations in the context of the eTOM, which looks at processes from a

Service Providers point of view.

The eTOM is a business process model or framework that provides the

enterprise processes required for a service provider. [eTOM]

Who (Party)

Why (Reason)

What (Thing)

When (TimePeriod)

Where (Location)

Figure 8 - Showing How Party Fits In

Organizations can be internal (department, subsidiary) or external to the

Service Provider (suppliers, customers).

Individuals can be internal (employees, board members) or external to the

Service Provider (customers, organization contacts, shareholders).

5.1.2 Party Fundamentals

Figure 9 - Basic Party Modelshows a Party representing an Individual orOrganization. 2

2 All entities referenced in this chapter are fully described in the SID addenda.



25/73


Party

partyId

IndividualgenderplaceOfBirthnationalitymaritalStatusdriversLicenceNrpassportNrskillsdisabilitiesaliveDuring : TimePeriod

Organization

companyNr

isLegalEntity

industrySector

existsDuring : TimePeriod

Figure 9 - Basic Party Model (source: TM Forum)

In this model, both organization and organization unit (e.g. consortium,

parent company, subsidiary, division, department, branch or team) are

represented by the Organization entity, which should be subclassed as

required.

Organization can also represent government agencies, clubs, charities and

educational & religious organizations

While Party is not a term often used in the business, the concept of a

person or a company is often heard, and the Party abstraction makes the

domain model easier to understand.

5.1.3 Contact Medium

A Party can be contacted using a contact medium, which is an abstraction of

the commonly used contact types: eMail, Postal Address, telephone, fax etc.

When there is a need to show that a Business Entity is only valid for a

certain time, this will be shown by an attribute called validFor, of typeTimePeriod. In the design model, temporal support may be implemented in

other ways, but this approach has been chosen for the analysis model as it

shows the requirement without cluttering up the model.



26/73


Organization

companyNr

isLegalEntity

industrySector

existsDuring : TimePeriod

PostalContactEmailContact

eMailAddress

eMailProtocol

this will get converted

to Location in a later

version

Country

Individual

gender

placeOfBirth

nationality

maritalStatus

driversLicenceNr

passportNr

skills

disabilities

aliveDuring : TimePeriod

1

0..n+countryOfBirth

1

Contact Medium

validFor : TimePe ri...

Party

partyId

0..n

0..n

PartyContactMedium

0..n

mayBeReachedUsing0..n

0..n

Figure 10 - Initial Party Model (source: TM Forum)

An Organization (unit) can contain other Organization (unit)s in a

hierarchy.

5.1.4 Party Roles

People and Organizations exhibit complex behavior. A lot of the behavior

can be grouped, based on a particular context, or participation in a certaininteraction.

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.

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 many roles at one time (an employee may also be

a customer, a graduate student may also be a tutor)

By modeling PartyRole as a separate concept from Party, we allow for

proper representation of these complex sets of behaviors.

When looking at the eTOM, we see that in the Value Network, Parties play

roles in the context of an interaction to provide Customer value. This

interaction may be per service or per event (e.g. a phone call).



27/73


Note that these are roles and that individual organizations (andorganizational entities) 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 valuenetwork and a third party (e.g. wholesale) service provider in another.

Relationships are established between the roles, hence the businessrelationship context model. In todays 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. Organizations can adopt and shed rolesdynamically, but the relationships between the roles are established, so the

adoption of a particular role will also define the relationship of the

organization playing that role towards another role player. [eTOM]

The Value Network roles defined in the eTOM are shown as subclasses of

PartyRole in Figure 11

Note that even though we are modeling from the point of view of the

service provider, we need to model all of the value chain.

In todays marketplace, companies must implement an end-to-end value

stream and have an integrated and customer-centric technology foundation.

It is also necessary to be a part of and to manage eBusiness communities(EBCs), which are networks of relationships linking businesses, customers

and suppliers to create a unique business entity that is re-configurable, to

meet customer needs. In order to develop customer relationship solutions,

companies must extend beyond their own boundaries to encompass the

entire extended enterprise and make this transparent to the customer.[eTOM]



28/73


Customer

favouriteColorInterme diary

Vendor

Service Provider

Complementary

Provider

Th ird P arty Se rvi ce

ProviderFunc tio n or Process

Provider

Value Network Role

PartyRole

status

Party

partyId

* 1* 1

Service Provi der Em ployee

employmentStatus

employeeNr

currentSalary : M oney

These are business entities, not

software classes

Figure 11 - Party and the Main eTOM Roles (source: TM Forum)

The role entity represents the common behavior by a Party when acting in

the role.

This model explicitly separates the information held about individuals and

organizations from the roles that they perform and the relationships theService Provider forms with them. for example, 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 ofPhone Dealer, but there may never be any Interaction between the

dealers and the Service Provider.

An Employment Position or Post is represented by creating an Organization

Role of type POST for the relevant organization unit. e.g. .the Org unit

Western Region has a Post of Western Region Data QualityCoordinator. A Party Role linked to Western Region is created for this

Post and employees can be assigned to the Post using interactions.

Typically, there would only be one person assigned to a Post at any point in

time (using TimePeriods).

Note:

In the value network, roles may not be exclusive, e.g. a customer may also

be a supplier

In a number of cases, we are interested in parties playing a combination of

roles, e.g. staff, who use our services, get staff discount and suppliers who,

use or products, are preferred suppliers.



29/73


5.1.5 Interactions between Parties

Combining Figure 9 - Basic Party Modeland Figure 11 - Party and the

Main eTOM Rolesgives us the model shown in Figure 12 - Parties Interact

Via Their Roles.

Sets of Party Specification entities together with Party Specification Policy

entities provide rules, conditions, and allowable actions for Parties and

Party Roles. These entities are not shown in the model.

PartyRoleGroup allows Party Roles to be grouped (e.g. into Customer

Demographics)

An Interaction will involve one or more Parties playing roles participating

in the value network to provide Customer value.

An Interaction may have links to Product & Location.

Individual

gender

placeOfBirth

nationality

maritalStatusdriversLicenceNr

passportNr

skills

disabilities


Organization

companyNr

isLegalEntity

industrySectorexistsDuring : T imePeriod

Interaction

PartyRole

Value Network Role

These are business e ntiti es, n ot

software cla sses

Party

partyId

PartyRole

Group

PartyRole

status1* 1*

0..n

0..n

Interaction

validFor : Tim ePeri...1..** 1..**

0..n

0..n

Figure 12 - Parties Interact Via Their Roles (source: TM Forum)

5.1.6 Associations between Party Roles

We need to be able to show associations between Parties playing roles that

are not directly involved in the value network.

Examples of these associations include

Organizational associations in the service providers own business(organization unit employee, organization unit organization unit)

Associations in other Organizations participating in the value network(organization unit employee, organization unit organization unit)



30/73


Associations allowing us to determine the make-up of a household(household member household member)

Associations showing family make-up (parent-child)

PartyRoleAssociation and any subclasses must not be linked toLocation, Product or Interaction.

Party Role Association

associationType

validFor : TimePeriod

status

Party

partyId

Interaction

validFor : Tim ePeri...

PartyRole

status

* 1* 1* 1..** 1..*

*

*

+from

*

+to*

Party Role

Organization Assoc

Party Role

Household Assoc

Party Role

Famil y Assoc

Figure 13 - Parties Can Be Associated Via Their Roles (source: TM Forum)

5.1.7 Party Names

An individual is referred to by their name. This name can change over time

(e.g. After marriage, by deed poll) and to allow for this we will model anindividuals name as a separate entity. Similarly, organizations can change

their names (e.g. from Telecom to Telstra) and we will also model

organization names as a separate entity. Note that this model does not allow

for individual name or organization name aliases.



31/73


Party

partyId

Individual

gender

placeOfBirth

nationality

maritalStatus

driversLicenceNr

passportNr

skills

disabilities


IndividualName

formattedName

aristocraticTitle

salutationgivenName

preferredGivenName

middleName

familyNamePrefix

familyName

familyGeneration

qualifications

1 1..n1..n

Organi zation

companyNr

isLegalEntity

industrySector

existsDuring : TimePe riod

Organization Name

tradingName

1 1..n1..n

Country

Language

alphabetName

dialectNames

1..*

n

1..*

n

PartyName

validFor : T imePeri...

1

0..*

+nameRuleCountry

0..*

10..*0..*

this will get converted to

Location in a later version

These are business entities, not

software classes

1

1

1

1

Figure 14 - Naming For Parties (source: TM Forum)

5.1.8 Interworking with other business entities

Figure 15 - Possible Links to Other Parts of the Core Modelshows the

main Party classes and the expected connections to other parts of the coremodel. This is for information only and is not guaranteed to be complete.Note also that the Location linkages will be refined after the Location model

facet has been defined.

Note that having PartyContactMedium allows us to store a default set ofcontacts for a Party, which can be overridden by PartyRole if there are

any role-based contacts. In most cases, only the one set of contacts would

be required. Contact details for a Post would use a PartyRole

ContactMedium.



32/73


Contact Me dium

v alidFor : TimePer...

Interaction Party Role

to be refined

later

Address

Location

Party Role

Location

Interact ion

v alidFor : TimePer...

Party

partyId

0..n

0..n 0..n

0..n

Agreement

Party Location

PartyRole

status

*

1..*

*

1..**1 *1

**

0..n

0..n

mayBeReachedUsing

0..n

0..n

0..n

0..n

0..n

0..n

Figure 15 - Possible Links to Other Parts of the Core Model (source: TM Forum)

Notes:

Note that these entities represent business concepts in a Service Provider

that conforms to the eTOM process model [eTOM].

Entities that are outside the scope of this model facet are shown with a

white fill color.

This is intended as a minimalist model. Subtypes and attributes should be

added as required. The attributes shown should be considered as suggested,

not required.

5.1.9 Example Extension of Party Customer

The figure below shows how a Customer business entity represents an

extension (from an information model perspective) of Party. A number ofattributes (such as name and contact medium) and associations now reside

in the Party core business entity.



33/73


0..n

CustomerAccountRelationship

relationshipType


IdentityContactMedium(from Party)

CustomerAccountContact

contactType


0..n

0..n

0..n

0..n

accessedVia

CustAcctCreditProfileReference

financialInstitutionName

financialInstitutionAccoutNumber

financialInstitutionAccountType

financialInstitutionContactName

financialinstitutionContactMedium

CustomerQuote/Offer(from C ustomer Interaction)

PartyRole(fromParty)

CustomerAccountCreditProfile

creditProfileID

creditProfileDate


0..n11

includes

Customer

customerID

customerStatus

customerRank

0..n1

0..n1

requests

CustomerAccountTaxExemption

issuingJurisdiction

certificateNumber


CustomerAccountBillCycle

billCycle


CustomerAccount

accountID

accountName

accountType

accountStatus

0..n

0..n

0..n

0..n

usedAs

0..n0..n 0..n

references

0..n

0..n

1..n

0..n

1..n

stabilityMeasuredBy

0..n

1..n

0..n

1..n

posseses

0..n

1

0..n

1exemptedFromTaxesVia

0..n1

0..n1

receivesABillDuring

Figure 16 - Customer Shown As An Extension of Party Role (source: TM Forum)

5.2 The What Product, Service, and Resource

5.2.1 Overview



GB922 Addendum 1P and the OSS/J Inventory API (JSR 142).

This chapter answers the question what? and deals with products offered

by an enterprise, the services through with a product is realized or

supported, and the resources utilized by products and services.



34/73


Who (Party)

Why (Reason)

What (Thing)

When (TimePeriod)

Where (Location)

Figure 17 - Showing How Products, Services, and Resources Fit In

Product, Services, and Resources are specializations of the Entity

Specification and Entity modeling concepts presented in the Core Business

Entity Modeling Concepts chapter of this paper.

Core what business entities are

Product Specification and Product

Service Specification and Service

Resource Specification and Resource

Each of these three pairs of business entities is described below, followedby a model that depicts how these business entities fit into part of the core

model. The three pairs of business entities are commonly referred to as

Inventory core business entities.

Operation business processes require information on planning, availability,usage and state of various products, services and resources. OSS

components such as Order Management, Service Impact Analysis, Planning

cannot be built without this knowledge. Therefore, inventory informationcannot be local to a specific component, but must be considered as

enterprise data, that although stewarded by specific OSS components, needs

to be shared across the enterprise. In emerging scenarios for e-business,

some information may also be shared across enterprises in a controlled way.

The variety of inventory information can be classified in three groups

defining three Inventory functions focused on products, services or

resources. Each function has its specific set of inventory entities andrelationships, its specific business logic and interacts with different subset

of OSS functions. However, all Inventory functions share commonabstractions (e.g. entities, associations, specifications) and common base

interaction model (e.g. queries based on traversal of relationships, atomic

update procedures etc.).

The Inventory functions are central part of an integrated OSS solution. They

provide storage of physical resources and configurations, network topology,



35/73


logical resources, services, customer account information, products, etc.They also provide the business operations required by other OSS

components in order to query, monitor, assign and update the inventory

information.

The Inventory functions are described in the following sections.

5.2.2 Product Inventory

The main responsibility of the Product Inventory is to manage the Product

Catalog and keep track of the of product subscriptions. The Product Catalogdefines the product offering from marketing perspective and consists of

collection of product specifications. Each product specification describes a

product. Several product specifications may be defined for the same product

type. For example, the Product Catalog may define Gold, Silver and BronzeVPN products. Product specifications are associated with service

specifications, stored in the Service Catalog, thus capturing the relationshipbetween a product and the set of services bundled by this product.

Each subscription is captured in the Product Inventory through a product

instance associated with the corresponding specification in the catalog. The

product instance is also associated with the subscriber of the product and the

related subscriber account information.

The information stored in the Product Inventory is used by SLA

management, Trouble Ticketing, Billing and Customer Order Management

OSS/J APIs.

Product Inventory is part of the eTOM Customer Relationship Managementand Operations and Product Lifecycle Management processes.

5.2.3 Service Inventory

The main responsibility of the Service Inventory is to manage the Service

Catalog and keep track of planned, subscribed and provisioned services.

The Service Catalog captures the engineering view of the Service Providers

offering and consists of collection of service specifications. Servicespecifications define the services from an engineering perspective. Several

service specifications may be defined for the same service type. For

example the Service Catalog may define Gold, Silver and Bronze VPNservices. Service specifications are associated with resource specifications,

stored in the Resource Catalog, thus capturing the relationship between a

service and the set of resources supporting this service.

Each subscription is captured in the Service Inventory through a set of

service instances associated with the corresponding specifications in the

Service Catalog, the subscribed product, bundling these services and the

users (recipients) for these services.



36/73


The information stored in the Service Inventory is used by SLAmanagement, Trouble Ticketing, Billing Mediation, Service Activation,

Service planning, Process Quality Management, Service Impact Analysis,

Service Problem Resolution, Customer Order Management, Provisioning

Control and Service Quality Management OSS/J APIs.

Service Inventory is part of the eTOM Service Management and Operations

and Product Lifecycle Management processes.

5.2.4 Resource Inventory

The Resource Inventory stores network and computing equipment, logical

resources and topology. This function keeps track of the physical and

geographical configuration of the network, equipment inventory (cards,

ports, etc.), physical connectivity, and logical connectivity of the different

network layers.

Resource Discovery components populate and synchronize the Resource

Inventory.

Data in the Resource Inventory is used by Provisioning Control OSS/J API

to design services and understand where capacity is available. It is also used

for root-cause alarm analysis and network activation.

Resource Inventory is part of the eTOM Resource Management and

Operations and Product Lifecycle Management processes.

The figure below depicts the Inventory core business entities along with

their relationship to Party, another core business entity.



37/73


PartyValue...>>

ProductValue

(from product)

* *

+aggregatedProduct

*

productAggregatesProduct

+aggregateProduct

*

PartyRoleValue

1 0..*1 0..*

0..*

0..*

+subscribedProduct

0..*

+subscriber0..*ServiceValue

(from service)

0..*

0..*

+product

0..*

+service

0..*

productAggregatesService

*

*

+aggregatedService

*

serviceAggregatesService

+aggregateService*

0..*

0..* +deliveredService0..*

+recipient0..*

ProductSpecificationValue (from produ...

0..* 0..10..* 0..1

describes

** *

productSpecificationAggregatesProductSpecifiacation

*

ResourceValue

(from resource)

0..*

0..*

+service0..*

+resource

0..*

resourceSupportsService

* *+aggregatedResource *

resourceAggregatesResources

+aggregateResource*

0..*

0..*

+ownedResource

0..*

+owner0..*

ServiceSpecificationValue(from servi...

0..* 0..10..* 0..1describes

0..*

0..*

0..*

0..*

productSpecificationAggregatesServiceSpecification

*

*

*

serviceSpecificationAggregatesServiceSpecification

*

ResourceSpecificationValue (from resour...

0..*

0..1

0..*

0..1

describes

0..*

0..*

0..*

0..*

resourceSpecificationsSupportServiceSpecification

*

* *

resourceSpecificationAggregatesResourceSpecification

*

subscriberSubscribesProduct

ownerOwnsResource

Figure 18 - Inventory Business Entities

5.2.5 Use Cases

Exemplary use cases for Inventory Business Entities can be found in the

OSS/J Inventory API Specification (JSR 142).

5.3 The Where - Location



GB922 Addendum 1L.

This chapter answers the question where? and deals with locations, such

as buildings addresses, geographic locations and so forth, where customers

are found, resources are situated, services are provided, and so forth.



38/73


Who (Party)

Why (Reason)

What (Thing)

When (TimePeriod)

Where (Location)

Figure 19 - Showing How Locations Fit In

5.3.1 Disclaimer

This Location model is complex and has a number of subtleties. It providesa high level framework, explains broad concepts and gives illustrative

examples. Actual solutions for particular requirements will be dependantfactors such as

Country address standards

State/ country / province map standards

Service Provider network inventory addressing standards

Equipment vendor equipment naming & addressing conventions

Whether textual only or map based representations will be provided

It is expected that when this model is used in TeleManagement Forum

NGOSS Catalyst projects, the feedback will clarify its application & usage.

5.3.2 Overview

A Service Provider will be interested in the location of many things:

Where is the customer (more on this later)?

Where is our equipment?

Where is the fault and where is the nearest person who could repair theequipment?

Where did the cyclone pass (and what equipment may have been

affected)? Where is growth for this product?

Where can we expand our business operations?

Where are our service vans and the work sites (optimize workdispatch)?

Where (which shops) do we require products to be shipped?

Where do I send the bill for Customer Xs use of product Y?

Where do I need additional employees?



39/73


Who owns this property (advise of digging) {note property may berented, i.e. customer living at property may not be owner}

Note that the business requirements will not just be Resource related but

will also be required by marketing, corporate strategic, etc processes.

In some cases, these locations will be well-defined points. In others, they

may be fuzzily defined regions of interest.

The Location model needs to allow us to answer questions like What is the

nearest network access point to the Customers location that can providethis product? Network, Customer and Product Capability should not just be

seen as separate location views.

5.3.3 Location

We will define location as a generic concept that can answer the questionWhere ?

A Location is an area, position, or portion of space that somebody or

something can be in; a location can also be a locality, a dwelling (or someother structure via associations to the Resource Model). In this model an

abstract modeling concept, used to generalize Location Coordinate, Address

and Geographic Area and Structure.

This model provides four options for locating something geographically:

With a defined (named) location {Structure} With an address {Address}

With a (named) area {Geographic Area}

With a survey location (geocode) e.g. a GPS position for an off-shoreoil rig {Location Coordinate}

The way that the Location hierarchy is defined is the key to this model. A

model that represents the high level concepts is shown below.



40/73


ManagedEntityPlacement(from Managed Entity Business Entities)

LocationRole

LocationSpecification

Location

0..n

1

0..n

1

playedBy

0..n

0..n

0..n

madeUpOf0..n

0..n

1

0..n

1 definesManagedEntity

(from Managed Entity Business Entities)

0..n

0..n

0..n

0..n

identifiesPlacementOf

Roles include where the

ManagedEntity is located, (one or

more) Places at which the

ManagedEntity terminates (for entities

such as connections), where a

ManagedEntity (such as a

ProductOffering) is available, and so

forth

Address

GeographicArea

0..n0..n 0..n0..n

liesWithin

Structure

(from Resource)

LocationCoordinate

0..n

0..n

0..n

0..ngraphicallyPositions 0..n

0..n

0..n

0..ngraphicallyPositions

0..n0..n

0..n0..n

graphicallyPositions

Figure 20 - Initial Location Model

A location is a location that can be represented graphically. By definition

then, a locations attributes includes some type of coordinates that facilitate

the locations graphical positioning.

An address is a structured textual way of describing how to find a location,geographic area, or structure. It is usually composed of an ordered list of

names based on context specific rules.

A geographic area is a location that has (existing, planned, or former) thingsof interest to an enterprise. Things of interest include products, services, and

resources. Characteristics include associated parties (property owner,

property lessee, and so forth).

A structure is a physical resource that may be considered a location. A

structure is a set of inter-related parts (resources) that function as a whole.

Entity Specifications in the form of Location Specifications are used in thispart of the CBE model also. Location Specifications specify such things as

address formats, such as Australian and European formats, as well as the

way in with geographic areas can be aggregated, such as a city in a state in a

country.

APIs that can employ this CBE include but is not limited to the Customer

Order Management API (the locations where product offerings are to be

installed), Activation API (where is the product, service, or resource that isto be activated), Trouble Ticketing API (where is the trouble), and the Fault

Monitoring API (where did the fault occur).



41/73


5.4 The When and the Why Business Interaction

5.4.1 Overview

Note: The contents of this chapter are an extract from the TeleManagement

Forums Shared Information/Data (SID) Model document GB922Addendum 1BI.

This chapter answers the question when and why? and deals withcommunications, activities, and agreements that involve products, services,

and resources found at locations, such as buildings addresses and so forth.

Who (Party)

Why (Reason)

What (Thing)

When (TimePeriod)

Where (Location)

Figure 21 - Showing How Interactions Fit In

In the course of doing business a service provider interacts with individuals

and organizations (or parts of organizations). Interactions also includeactivities and communications between systems and between systems and

parties. These interactions take the form of requests, responses,

notifications, agreements, and commands. The figure below depicts the

various types of business interactions.



42/73


Request Response Notification

BusinessInteraction

interactionDate

interactionDescription

interactionDateComplete

interactionStatus

interactionID

name

0..n0..n 0..n

references

0..n

Agreement(from Agreement)

Figure 22 - Types of Business Interactions (source: TM Forum)

Individuals, organizations, and systems, and so forth involved in

interactions are collectively referred to as business participants. In fact, a

business participant may be a party playing a certain role or a resourceplaying a role, such as a system or piece of equipment. During an

interaction, a party can play different roles as a business participant. For

example, Bob Smith, a party playing the role of a customer, requests

information about cable modem service from Joe Jones, a party playing therole of a customer service representative. The figure below depicts the

relationship that business participants have with all types of interactions. In

this example, the type of interaction is an inquiry request. In fact, all types

of interactions participate in the relationships described in this section. Thisis illustrated by the examples used through this section.

A number of APIs can take advantage the Business Interaction CoreBusiness Entity. For example, an alarm is a type of notification created as

the result of an alarm being sensed by a fault monitoring process. The Fault

Monitoring API is used to communicate this to an SLA process. The SLAprocess may recommend a rebate be issued customer base on an SLA in

place with the customer. The recommendation is communicated to a billing

mediation process via a rebate notification type of interaction via the SLA

API.



43/73


PartyRole(fromParty)

BusinessInteraction

interactionDate



interactionStatus

interactionID

name

BusinessParticipant0..n 0..n0..n 0..ninvolves

BusinessParticipantType

PartyRoleType(f rom Party)

classifies

1..1

0..n

ResourceRole(from Resource)

ResourceRoleType(from Resource Specification)

Figure 23 - The Relationship Between Business Interactions and Business Participants

(source: TM Forum)

As described in the example above, the inquiry request type of interaction

from Bob Smith involves a product offering that is made available by a

service provider. The figure below depicts the involvement that products,

services, and resources have with all types of interactions.



44/73


BusinessInteraction

interactionDate



interactionStatus

interactionID

ProductOffering(from Product Specification)

Product(f rom Product )

ProductSpecification(from Product Specification)

Service(from Service)

ServiceSpecification(from Service Specification)

Resource(from Resource)

Res ource Specification(from Resource Specification)

BusinessInteractionItem

quantity

action

1 1..n1 1..n

comprises

0..1

0..n

0..1

0..n

involvedIn

0..n

0..1

0..n

0..1

involvedIn

0..1

0..n

0..1

0..n

0..1

0..n

0..1

0..n

0..1

0..n

0..1

0..n

0..1

0..n

0..1

0..n

0..1

0..n

0..1

0..n

Figure 24 - The Relationship Between Business Interaction and Products, Services,

and Resources (source: TM Forum)

Similarly, if Bob Smith already has cable modem, the request may referencean entity, such as a product, provided to Bob. Product offerings obtained by

a customer are called products.

During the interaction, Bob Smith may also provide information about thelocation, for example address, of his cable modem. Therefore, as shown in

the figure below, an interaction also can involve one or more addresses.



45/73


BusinessInteractionLocation(fromBusiness I nteraction)


quantity

action

0..n

0..n

0..n

+specifiesTheLocationFor

0..nBusinessInteraction

interactionDate



interactionStatus

interactionID

name

1 1..n1 1..n

compriseOf

Location(f rom Location)

0..n

0..n

0..n


0..n

Figure 25 - The Relationship Between Business Interactions and Locations (source:

TM Forum)

In summary, a business interaction involves a number of other business

entities, including product offerings, products, locations, and business

participants.

By using the concept of a business interaction, each of its various types,

such as agreement and notification, can inherit the interactionsrelationships, attributes and behaviors without having to explicitly show

these for each type. For example, it would be quite redundant and unstable

to show an agreement and a notification, and a request, and a response, anda command each participating in relationships to parties, locations, entity

specifications and entities. What would happen if this was done and anothertype of interaction was discovered?

The full Interaction model is shown if the figure below.



46/73


BusinessInteractionLocation

Product

(from Product )

ProductOffering

(from Product Offering)


(from Product Specification)

ServiceSpecification(from Service Specification)

Service

(from Service)

Resource Specification

(from Resource Specification)

Resource(from Resource)

BusinessInteractionRole

interactionRole

BusinessInteractionType

Location

(from Location)

CustomerAccount(from Customer)

BusinessParticipant


quantity

action0..n

0..n

+references

0..n

0..n

0..n

0..n


0..n

0..n

0..1

0..n

0..1

0..n

involvedIn

0..1

0..n

0..1

0..n

involvedIn

0..n

0..1

0..n

0..1

involvedIn

0..n

0..1

0..n

0..1

0..n

0..1

0..n

0..1

0..n

0..1

0..n

0..1

0..n

0..1

0..n

0..1

involves

0..n0..n 0..n0..n

ofInterestTo

BusinessInteraction

interactionDate


interactionDateC omplete

interactionStatus

interactionID

na

com wp cbe concepts.1.2

Documents