Designing cases using aggregates [editor]

As show above, in DCM a case is a concept that combines many other concepts. We do not aim to give one precise definition of a case in this document, but try to explain which concepts can play a role when designing a case. One misunderstanding can be corrected upfront: a case is not just a process or an instance of a process. A case is way more than that.

A case always has a goal, this is most likely singular. In order to reach that goal, decisions are made, in one or more processes. A case goes through phases, where a phase change is achieved formally by means of reaching or crossing a milestone. A case can have different states, even more than one simultaneously. Information is persisted within a case or outside of a case in a register. Within cases, some tasks are not really part of the main or other processes, but can always be executed. Such generic tasks are part of the case definition as well. Notes and appointments are similar to generic tasks, they are part of the case definition and are probably available throughout the life cycle of a case. Outside triggers or events can lead to actions that need to be performed in a case. Cases will most likely contain uploaded documents and will generate documents themselves as well. Finally, case management is all about collaboration; people can be involved and teams, organizations and roles can be defined to execute parts of the processes within a case.

All afore mentioned concepts contribute to a case, but that does not mean that each case has to consist of all these concepts necessarily. However, most (or even all?) cases contain decisions, will have at least one process and will most likely store some data and/or produce a document.

Blueriq concept of a case

With Blueriq's proposition of Dynamic Case Management, many DCM concepts are available within the Blueriq software platform. However, not all concepts can be found in Blueriq as a standard out-of-the-box concept. Shown below is the same diagram as above, containing a case and all its related concepts. The concepts in blue deviate from the previous diagram; this means that the DCM concept itself is not available within Blueriq as such, but one or more Blueriq concepts can be used to model the DCM concept effectively, completely and correctly.

In the diagram above, all pink concepts are DCM concepts that are part of Blueriq by default. The concept of a decision is one of the most dominant ones, but also processes, persistency by means of aggregates and output documents are used in many - if not all -  Blueriq applications. Teams and roles may not be as common as decisions, but are used very frequently.

The blue concepts in the diagram above indicate DCM concepts that are not available within the platform as a standard Blueriq module element, but can be modeled using out-of-the-box Blueriq functionality. For instance, the goal of a case, milestones and states; they can all be modeled using decisions, most likely decision tables or business rules. Notes and incoming documents can be modeled using specific containers. For triggers, incoming message events can be used. Appointments, involvements and organizations can be modeled with attributes.

The most protruding blue icons are that of the case itself and related cases; aggregates are used to model cases. This means that not only standard persistency by means of registers is done using aggregates, but also the case itself is an aggregate!

Comparison

The table below compares all DCM concepts with Blueriq concepts and briefly explains how standard Blueriq concepts can be used to model the DCM concept.

Concept in DCM		Concept in Blueriq		Remarks
	Case		Aggregate	A case is modeled as an aggregate, meaning that for each case an aggregate is defined, containing all entities that are relevant throughout the life cycle of the case. See also Designing cases using aggregates [editor].
	Goal		Decision	The goal of a case could be to grant a permit, register an applicant, pay a benefit, sell a product etc. A goal can easily be modeled by an attribute with a default value false and a decision table or business rule which sets the attribute to true when the goal is reached.
	Decision		Decision	The concept decision is available in Blueriq.
	Process		Process	The concept process is available in Blueriq.
	Milestone		Decision	Whether a milestone is reached or not is a decision, based on the context of the case. For more information on how to model milestones in DCM applications, see Designing dynamic processes.
	Phase		Process	With phases, a case can be broken down using the lowest granularity. Most cases consist of five plus or minus two phases. All phases are modeled as processes and since processes can be modeled hierarchical within Blueriq, the main process itself, containing the phases, is modeled as a process as well. For more information on how to model phases in DCM applications, see Designing dynamic processes.
	State		Decision	A state is a characteristic of a case that tells the end user not so much about the progress of the execution of the case over time (phases are used for that), but more about the progress regarding the case's identity. For instance, a case can have the state In progress. This does not really tell us how far we are, merely to be patient. Another example of a state is Waiting for customer, when additional data or documents are needed. States are plural, so a case could be in two states, for instance Part of spot check and Confidential.
	Persistency		Aggregate	For persistency of registers, aggregates are used. When these registers are external, web services are used.
	Generic task		Process	A generic task can be modeled as a task that has no precondition and is not part of a flow. For an example of a generic task, see Designing dynamic processes.
	Related case		Aggregate	Related cases are modeled as aggregates, just like the case itself. The relation between the case and the related case is modeled as a (multivalued) attribute within the case, holding all Id's of related cases. The type of relation (parent-child, sibling, association, etc) can also be modeled using attributes. The attributes are most likely part of a Case data or Control entity, but this is the designer's choice.
	Note		Dashboard Comment container	Notes are similar to generic tasks and could be modeled as such (in combination with a multivalued attribute), but within Blueriq the dashboard comment container can also be used for comments. By default the comments are multivalued and date-time and user are stored alongside the comment (toch?).
	Appointment		Attribute(s)	To model an appointment within a case, the best fit is attributes of an Appointment or Control entity. For the integration with a calender (for instance Google mail or Outlook), tailored software has to be bought or built, since this is not available in Blueriq out-of-the-box.
	Trigger		Incoming external message	Triggers or events are situations form outside the case that require actions to be taken withing the case. For instance the death of the applicant could require the case to cancel, or the divorce of an applicant could result in recalculation of a fee. In Blueriq, triggers or events are modeled as in incoming external message. For an example of an incoming external message, see Designing dynamic processes
	Document input		File upload container	File management is an integral part of Blueriq. Containers are available to upload and download documents to memory or the file system. Documents that are input for the case and need to be uploaded within the case, use the file upload container for that.
	Document output		Document	The concept output document is available in Blueriq.
	Involvement		Attribute(s)	Involving persons or roles in a case is not part of standard Blueriq functionality, but can easily be modeled using one or more (multivalued) attributes, most likely as part of an Involvement, Case or Control entity, but this is up to the designer. To involve someone in a case, for instance the civilian or a case handler or investigator, means setting an attribute with the desired involvement.
	Team		Team	The concept team is available in Blueriq.
	Organization		Attribute(s)	Organizations strongly resemble teams, but the concept itself is not available in Blueriq by default. Therefore, organizations can be modeled using one or more (multivalued) attributes, most likely part of an Organization, Case or Control entity, but this is up to the designer. To rout a case to an organization, means setting an attribute with the desired organization.
	Role		Role	The concept role is available in Blueriq.

The generic case aggregate

Since all cases can be modeled as aggregates, one might wonder what such an aggregate would look like. Are they completely different for each case or is there a common ground among all cases? The answer is the latter; aggregates that resemble cases all look alike. Shown below is the outline of such a generic case aggregate.

The design of the case aggregate as shown above is not mandatory, but strongly advised. It is based on designs used in several projects, pocs and demos and has proven to be successful thus far.

Entities in the case aggregate

The table below discusses briefly explains each entity within the generic case aggregate.

See also

More information on how to design dynamic processes in Blueriq can be found here: Designing dynamic processes.
Everything about persistency management and aggregates can be found here: Persistency Management guide.
A visualization of most concepts discussed in this article can be found here: Blueriq visuals.
Specifically for dynamic case management and persistency management, see