CR-X Blog

Complementary to the concept of a business object is the concept of a business object history. Classical system implementations of business objects persist their current state within the object. A history of a business object records:

• the current state
• the history of changes of state of the object
• the events in which the object has participated, whether or not they result in a persisted change of state of the object itself.

Business object histories are a fundamental management tool, providing the factual basis for performance metrics, identification of behaviour patterns, and feedback on the impact of management actions.

The complexity in the representation of object histories arises in the event architecture within which the objects’ activities are portrayed. An event architecture comprises a general component applicable to all object types and a component specific to the types of business objects whose histories are to be recorded. We can describe each of these components as follows.

Three completely general event characteristics/relationships are desirable in any event architecture:

• representation of a part/whole relationship between two events
• representation of a sequence relationship between two events
• representation of start time-date and end time-date for events, and thereby by implication a simple earlier/later time relationship.

The part/whole relationship should be recursive, or capable of nesting to an indefinite depth. The sequence relationship implies that one event is the predecessor and the other the successor as understood in the concept of a synchronous thread of execution. The sequence relationship is many-many, asymmetric, irreflexive, and implies a transitive earlier/later relation: it creates a partial ordering on the events it relates. Therefore the sequence relationship is suitable for representing the relationship between contributions [1]  in a business process, where after certain contributions parallel activity streams are created which eventually will come back together as predecessors of a later or final contribution in the process.

To complete a given event architecture, it is necessary to add the specific part/whole hierarchy of event types which will be represented. For instance a customer history might include all the business processes in which a given customer has participated with an organization. Recognized parts of a business process might include telephone calls which the customer has made to the organization’s call centre. Recognized parts of the telephone call might include segments, or those periods during the call when the organization as B-party is represented by a given respondent or group of respondents. Thus a given call might have as segment parts an initial period when the customer interacts with an IVR, followed by a segment when the customer is provided messages and music-on-hold by an ACD while awaiting the availability of a suitable consultant, followed by a segment talking with a targeted consultant, followed by a segment talking with both the consultant and a conferenced-in subject matter expert, and concluding, after a transfer, with a segment talking with a second consultant. It might further be desirable to recognize as parts of segments events such as authentication, promises to pay, the scheduling of an appointment, and so on.

Where an event type represents the interaction of two or more business object types, the event type will be re-useable within the histories for each of the business object types. For instance, taking our call-centre example from the previous paragraph, a segment of a telephone call might appear not only in the customer’s history, but also in the history or histories of each of the consultants participating in that segment.

When an event appears in the history of a given business object type, insights are available into the relations between that event and others in the history. For instance, when a telephone call appears in a customer history, there may or may not be earlier call events. Furthermore, any earlier calls may or may not be part of the same business process instance and may or may not be part of the same step or contribution of the given business process instance. It is only by having all these aspects of context represented that a truly meaningful metric of “repeat call” can be formulated. When a relationship such as being a repeat call has been detected, it is good practice to record the existence of the relationship within the representation of both the related events. By doing this, when the event representation is re-used in another business object history, where the context is no longer available, we do not lose sight of the existence of the relationship. For instance, when repeat calls have been identified within customer histories and appropriately recorded, and call segment representations are then re-used in consultant histories, the relevant information becomes available within the consultant histories to evaluate poor performance in failing to resolve customer issues and superior performance in resolving customer issues which previous consultants have failed to address.

In implementing a business object history, it is inevitable that information will need to be drawn from multiple source systems. Often even chains of contiguous events will traverse multiple operational systems. For instance representing a call in to a call-centre and all its parts may use information from CTI systems, IVR systems, and CRM systems. At the level of contributions, the events of a business process are typically non-contiguous and are managed in different systems addressing the different operational roles of the various participants. The lesson is that event representations are best rendered in a highly generic format, such as one composed of XML markup and content elements. Prefixed to such representations should be the content applicable to all events, that is the specification of part/whole and sequence relationships, identifiers, and event start and end times. The use of data from multiple systems poses further challenges of managing the association of events accessed in the different systems via local identifiers or indices, and managing differing latencies of data availability.

Because object histories quickly become very large, the choice of underlying technologies for their system representation requires care. CR-X has found it possible to develop file-based structures managed by the CR-X Transformation Engine which maintain consistency between the related histories of several interacting business object types. These structures significantly out-perform general purpose relational databases and enable histories several orders of magnitude larger than those achieved with relational technology.

In addition to the straightforward reporting and analytical purposes served by constructing business object histories, exciting new classes of systems become possible. For example ongoing work at CR-X uses object histories in the development and testing of predictive models of the behaviour of complex business objects, such as customers, corporations, or partners.

Footnote

[1] A contribution is the content of a single box in a workflow model of a business process. At a given level of decomposition of a business process it describes an outcome achieved by an individual, a group, or a system without interruption due to external dependencies.