Business Case and Business Objects

Part of Process Knowledge. The business case is the bracket, the business objects carry content and state; they come into being by creation or derivation, can be subordinate to a main object and share the same core characteristics, and a calculation is an inquiry or a business object depending on whether it is kept.

Business Case as a Bracket

The business case (Geschäftsfall) is the identifier under which related business objects lie: in the application process the calculation, offer, application and contract of one transaction; in a contract change the contract change application for an existing contract. It corresponds to the business case number in OMDS 3 and replaces the former term "session".

The business case carries three things:

Persistence, authorisation and joint editing. Whether the insurer keeps the business case, who may access it and whether third parties – further brokers, clerks of the insurer – can edit it jointly are properties of the business case that the insurer declares as process knowledge.
The next steps. Every response states, at the business case and at its objects, which operations are permitted now (next-step links). What is not listed there is not permitted.
The type. Every business case belongs to exactly one business case type (see Business Case Types), which defines which business objects can come into being under it.

What the business case does not have are business states. "Calculated", "offered", "submitted", "accepted" are states of the business objects, not of the bracket. A business case under which an offer and an application lie has no state of its own that summarises the two; it is open as long as work goes on under it, and ended when its type provides for that (contract derived, application rejected, offer expired, transaction cancelled).

Business Object

A business object (Geschäftsobjekt) is what the insurer keeps and what can be changed: calculation, offer, application, contract, contract change application, claim report. It has an IRI of its own below the IRI of the business case, a content – in the application process the product configuration with risk objects, persons and application questions – and a business state. The states live at the business object; how they arise and change is described in States of a Business Object.

Coming into Being: Creation and Derivation

A business object comes into being in one of two ways:

by creation (Erzeugung) without a predecessor: the client sets up the object in full – an offer directly, an application without a previous offer, a claim report for a contract;
by derivation (Ableitung) from a predecessor: the new object takes over the content of the predecessor and carries its IRI as origin (Herkunft). The origin is a reference, not a fixed binding: an offer can be derived from a calculation and derived anew later (a new version of the offer in the history of the business case), the calculation remains unchanged, and the offer lives on if the calculation is discarded later.

In the application process the derivations calculation → offer and offer → application are optional: each of these objects may also be created without a predecessor (OMDS 3 knows this as "offer without calculation" and "submission without a previous CreateApplication"). The only mandatory derivation is application → contract: there is no contract without an application, and this derivation is triggered by the insurer, not by the broker.

application-process-chain-business-objects

The picture shows the application process as a chain of independent business objects under a bracket: the calculation remains unchanged while the offer is derived from it and later replaced by a new version; the second business case begins with an offer created without a predecessor; every contract has exactly one application as origin. Per business object type there is at most one current main object in a business case; earlier versions are kept in the history of the business case. Across the types, however, a business case holds several objects: in the application process calculation, offer, application and contract exist side by side, each with its origin, and the youngest link of the chain is the current business object of the business case, where the next steps hang. Which types may occur in which number is laid down by the business case type, not by the core of the model.

Subordinate Business Objects

A business object can be subordinate to another business object of the same business case (untergeordnetes Geschäftsobjekt, bc:parent). The superordinate object is called the main object (Hauptobjekt): in the application process offer, application or contract. A subordinate object has IRI, content, kind and a lifecycle of its own like every business object and is an aggregate of its own: own version, own lock, own conformity of its content. Main and subordinate object share no invariant; what connects them is a dependency that the insurer reassesses at every processing. The first kind of subordinate objects are the subprocesses.

The rule "at most one current object per type" applies to main objects only: an application can carry several subprocesses, for instance a discount approval and a previous damage inspection at the same time. How many subordinate objects of which kind a main object may carry is declared by the business case type. When the main object is derived (application → contract), open and fulfilled subordinate objects are carried over as far as the declaration of their kind provides for it; otherwise they stay with the predecessor.

Calculation: Inquiry or Business Object

An anonymous calculation – the client sends a configuration and receives premium and validation report – is not a business object and does not establish a business case. It is an inquiry (Auskunft): nothing remains with the insurer, and it can be repeated as often as desired, like a tariff calculator. As soon as the insurer keeps the calculation – because the broker wants to find it again later, share it with third parties or derive an offer from it –, it becomes a business object and thereby establishes a business case. The step from inquiry to business object is a creation, not a silent side effect of the inquiry.

Core Characteristics of Every Business Object

Beyond content and state, every business object – main object as well as subordinate object – carries the same set of characteristics. A client that can evaluate them once copes with every object of every business case type.

Characteristic Meaning

Characteristic	Meaning
Created, last modified (`bc:created`, `bc:modified`)	Points in time of coming into being and of the last change of content or state.
Version (`bc:version`)	Identifier of the current version, at the same time identifier of the entry in the history. It secures conditional writing: edit, replacement and transition name the version they presuppose (HTTP `If-Match`); if it does not match, the admissibility check rejects and nothing changes. The counterpart is conditional reading: every inquiry that delivers an object or product knowledge carries the version as `ETag` and answers `If-None-Match` with "not modified", so that unchanged objects are not transferred again. An edit may transmit several deltas in one call; they succeed or fail as a whole against one version, and the state is assessed anew once.
State reason (`bc:stateReason`)	For every set state optionally a code from a list declared per type and a text; mandatory for rejected, aborted, expired, invalid and cancelled. Messages of the conformity and completeness check remain separate from it (States of a Business Object).
Three roles: requester, owner, actor (`bc:requester`, `bc:owner`, `bc:actor`)	The requester caused the object to come into being, the owner decides on state and result (as a rule the insurer), the actor is who has to act next: customer, broker, insurer or third party. Requester and owner are set when the object comes into being, the actor changes with the state – for an application in query the broker is the actor, for an open expert assessment the assessor (Responsibilities).
Deadline and consequence (`bc:deadline`, `bc:consequence`)	By when action is required and what happens otherwise: the query at the application has a deadline, the offer a validity period, the subprocess a deadline with a declared consequence. Informative at the interface; binding are policy and letters of the insurer.
History as events	Every entry carries point in time, operation kind, acting party, version identifier and an event name from the vocabulary of the type (`bct:ApplicationSubmitted`, `bct:SubprocessFulfilled`). The inquiry "fetch state changes" delivers these events for all objects of the business case since a point in time, including the subordinate ones.
Reference to the declaration (`bc:declaredBy`)	Every object points to the declaration of its kind in the process knowledge, as the product instance points to the product definition. Thus a client finds transitions, deadlines, requirement and trigger condition of the kind without searching.
Navigation links (`bc:link`)	Next steps say what a client can do; navigation links say where it can go, using the IANA standard relations: `up` (business case or main object), `collection` and `item` (subordinate objects), `predecessor-version`, `successor-version`, `version-history` and `latest-version` (history), `related` (origin), `describedby` (declaration of the kind or product definition), `profile` (the profile of the standard the response belongs to). The typed references (`bc:parent`, `bc:derivedFrom`, `bc:declaredBy`) remain the source; the links are their hypermedia form, without an envelope of their own such as Hydra, HAL or Siren.

Created, last modified (bc:created, bc:modified)

Points in time of coming into being and of the last change of content or state.

Version (bc:version)

Identifier of the current version, at the same time identifier of the entry in the history. It secures conditional writing: edit, replacement and transition name the version they presuppose (HTTP If-Match); if it does not match, the admissibility check rejects and nothing changes. The counterpart is conditional reading: every inquiry that delivers an object or product knowledge carries the version as ETag and answers If-None-Match with "not modified", so that unchanged objects are not transferred again. An edit may transmit several deltas in one call; they succeed or fail as a whole against one version, and the state is assessed anew once.

State reason (bc:stateReason)

For every set state optionally a code from a list declared per type and a text; mandatory for rejected, aborted, expired, invalid and cancelled. Messages of the conformity and completeness check remain separate from it (States of a Business Object).

Three roles: requester, owner, actor (bc:requester, bc:owner, bc:actor)

The requester caused the object to come into being, the owner decides on state and result (as a rule the insurer), the actor is who has to act next: customer, broker, insurer or third party. Requester and owner are set when the object comes into being, the actor changes with the state – for an application in query the broker is the actor, for an open expert assessment the assessor (Responsibilities).

Deadline and consequence (bc:deadline, bc:consequence)

By when action is required and what happens otherwise: the query at the application has a deadline, the offer a validity period, the subprocess a deadline with a declared consequence. Informative at the interface; binding are policy and letters of the insurer.

History as events

Every entry carries point in time, operation kind, acting party, version identifier and an event name from the vocabulary of the type (bct:ApplicationSubmitted, bct:SubprocessFulfilled). The inquiry "fetch state changes" delivers these events for all objects of the business case since a point in time, including the subordinate ones.

Reference to the declaration (bc:declaredBy)

Every object points to the declaration of its kind in the process knowledge, as the product instance points to the product definition. Thus a client finds transitions, deadlines, requirement and trigger condition of the kind without searching.

Navigation links (bc:link)

Next steps say what a client can do; navigation links say where it can go, using the IANA standard relations: up (business case or main object), collection and item (subordinate objects), predecessor-version, successor-version, version-history and latest-version (history), related (origin), describedby (declaration of the kind or product definition), profile (the profile of the standard the response belongs to). The typed references (bc:parent, bc:derivedFrom, bc:declaredBy) remain the source; the links are their hypermedia form, without an envelope of their own such as Hydra, HAL or Siren.

In addition there is the idempotency key with which a client can safely repeat a creation, derivation or transition. The characteristics are provided as far as the pages of the business case types name them; version with conditional writing, conditional reading and navigation links follow with the switch of the reference implementations to business objects with states of their own.