CMS Programs and Data

It was explained at 1.3.2 that computers store data that includes program code. To perform work a process is created from the program code. The process loads input data from memory or input device, processes it and outputs the resultant data to memory or output device.

Here program code is termed Service Code and process termed Service Process

because, of the three Component Types, only Services have program code and generate processes.53 The ServiceCode is stored as part of Service Data. Figure 36 shows how a Service Process is created from the Service Code of a particular Service, and how it uses and produces data.

53 _{Services are “dynamic” in that they represent things (business processes) that are happening and}

changing, whereas Groups and Service Contracts are (relatively) “static” in that their state rarely change (in terms of computer time). In other words, of the three components, Services do all the changes while Groups and Service Contracts just sit there and wait to be changed (by a Service).

Figure 36: CMS Service Process

Figure 37, below, shows the entire content of the CMS. All that is stored is CMS Data. The CMS Data is made up of six data collections, with a Component Data

collection and a Component Instance Data collection for each of the three Component Types. Each row (termed Data Set) of the tables shown represents a single Component or Component Instance; each Component and Component Instance, therefore, has its own Data Set. 54 The only program code that the CMS contains is stored in each ServiceData item.55

A Component Instance is created when an Authorisation Request for its creation is accepted by the CMS. The Component Instance Data is created and initialised (usually with some default values from the Component Data) at this point. The Component Instance Data is the only thing that the System has that represents the Component Instance, so from the System’s point of view, the Component Instance Data is the Component Instance. This is analogous to a system seeing its users as their aliases (for example, their usernames).56

An example of a Client-Service Contract in the form of a Standard Paper Contract clarifies the difference between Component Data and Component Instance Data. The paper contract is the Contract Data (which is Component Data) and the

54 _{While storing data in tables in a database is common, it is not the only storage method available.} 55 _{Alternatively, pointers to a separate Program Code storage repository can also be employed.}

information that is supplied by the participants is the Contract InstanceData (which is Component Instance Data).57 The Contract Instance Data represents the state of the particular contract, while the Contract Data is the same for all contracts of the type.

In logical terms, each Component has Component Data associated with it and each Component Instance has Component Instance Data associated with it. But in physical terms the data is normally stored in some form of collective data repository (for example, computer databases). A logical address is an address related to a model whereas a physical address is a real physical location. For example, the street address of a house is a logical address whereas its physical address is its global location (perhaps expressed by global coordinates). The physical address of data is given by its location in computer memory.

Figure 37: CMS Contents

The CMS Data contains all the information that represents the business structure of the Organisation and all the data that represents the current (and past) state of the Organisation. The data includes the Service Code and information that defines all the relationships between Components, other Components and Component Instances.

57 _{Normally paper contracts would be printed from a digital version, even if the digital version was}

Figure 38 shows the relationships (expressed as pointers to related data sets) that are stored in each Component and Component Instance Data Set.58 The Component Icons appear in the left column. They are simply a graphical representation of the Components that are used for explanation purposes. The actual Components and Component Instances are the Data Sets.

The relationships are depicted by the lines connecting the various Data Sets.59 The “Relationship Key” on the right briefly summarises the meanings of the lines.

Figure 38: Data and Component Relationships

There are four types of relationships: 1) Component to Component Instance; 2) Component to Sub-Component; 3) Service to Group/Contract; and 4) Management Service to Component.

Component to Component Instance relationships are those between Components and the Component Instances that are generated from them, for example, Service to

58 _{A pointer is a data item which is an address – the memory location of related data. Where}

necessary, data associated with pointers (pointer data) is used to detail the nature of relationships.

Client-Service. The relationships are 1 to 0…many as, for each Component, zero to many ComponentInstances can be generated.

Component to Sub-Component relationships are the hierarchical relationships between Components and their own Sub-Components, for example, Service to Sub- Service and Group to Sub-Group. Again the relationships are 1 to 0…many as each Component can have zero to many Sub-Components.

Service to Group and Service to Contract relationships represent the allocation of Services to Groups (a 1 to 0…many relationship) and the association of a Service to its Service Contract (a 1 to 1 relationship).60

Management Service to Component relationships define how Services, Groups and Contracts are managed. Each Service, Group and Service Contract can have zero to many Management Services acting on them. Management Services have the effect of changing the state of Components and Component Instances.