Designing solutions top down [editor]

Business function model

Within the design phase, one of the most important artifacts is the Business function model (in Dutch: bedrijfsfunctiemodel). This model is tailor made for Blueriq's knowledge driven Dynamic Case Management solution implementation. However, it is based very heavily on the Dutch governmental enterprise architecture standard called "Bedrijfsfunctiemodel Rijksdienst".

The business function model is a description of the operations or functions of a business. It describes what an organization does, not how. Since the operations of a business are not as volatile as organizational structures such as departments and divisions, a business function model is a stable reflection of a business' operations.

Shown below is an abstract version of such a business function model.

The business function model allows to scope. In the model above all the business functions are depicted, but not all these functions are in fact in scope of the solution design. Scoping is done using different colors, elements in pink are in scope of the solution, elements in grey are not. The elements in grey are however business functions and part of the business' operations.

The business function model contains 7 groups:

• Roles
  This part of the business function model contains the roles that play a part in the business' operations, such as the case handler, the citizen or customer, investigators etc.
• Channels
  This part consists of the channels on which the business runs its operations, such as a computer, tablet or phone but also the channels that provide incoming and outgoing communication in general, such as mail.
• Controlling/Governance functions
  Here all types of controlling functions are depicted. Most of the time this will be reporting or business activity monitoring, but also the links to law and legislation.
• Primary functions
  This part of the business function model is the most important one and contains all primary functions of the business. These functions are cases and can also be grouped, for instance by product. Examples are a permit request case, a benefit payment case etc.
• Knowledge functions
  Main decisions, calculations or classifications can be identified separately from the cases they are used in. They are the main decisions of the business and have their own ownership and life cycle. Examples are the eligibility for a permit, the amount and duration of a certain benefit etc.
• Secondary functions
  Next to the primary functions, functions can be distinguished that play an essential role in the business' operations, but are not part of the primary enterprise process. In many situations, appeal and object cases are considered secondary functions, but sometimes these are primary as well. Another example of a secondary function is a reporting case, containing information of more than one related case.
• Data
  The primary and secondary functions section contain data themselves, but there is also a lot of data that is not stored within cases that reflect these functions. For instance, registers that are part of the solution or registers that exist outside the solution.

Primary and secondary functions

In a business function model, the primary and secondary functions are shown as cases. One of Blueriq's propositions is Dynamic Case Management, so this is a good fit. As discussed in Designing cases using aggregates, the definition of a case is hard to give. Many times, the question arises

Instead of a definition, the following list of characteristics of a case is given:

• Each case is an independent unit, with its own goal and its own result.
• Each case is responsible for its own behavior.
• A case can trigger another case.
• A case can publish its result to another case.
• A case can publish part of its domain to another case.
• A case reasons/infers about its own domain.
• A case can provide navigation to related cases.
• A case does not perform transactions in other cases.

Now that we know what a case is and what it can do, the problem with solution design is still to identify all primary and secondary functions of a business, in other words to identify the cases. The second question therefore is:

Let's review some examples.

• An organization that is in charge of providing benefits to citizens has a business function or operation to handle requests for such benefits. Handing out a benefit will lead to consequences that also need to be processed. The benefit needs to be paid for instance. If the citizen needs to have a medical assessment to determine whether he is eligible for the benefit, this assessment might have to be repeated regularly. The citizen might object to the amount of the benefit and this objection needs to be processed, etc. All aforementioned operations could be regarded as cases, some primary and others secondary.
• An organization that offers pension products to its customers has a primary business function to process the requests for these pensions. Giving out a pension product to a customer will lead to consequences that also need to be handled, such as premiums that need to be collected. Pension funds invest in shares on the stock market, this is another primary business function. Another case could be when a customer divorces, and his capital needs to be split up and one part needs to be allocated to his ex partner.
• An organization that offers insurances to its customers has a business function to process the requests for these insurances. Providing an insurance to a customer will result in business functions of premiums that need to be collected, or claims have to be processed, etc.
• An organization that is in charge of handing out permits to citizens has a business function to process the requests for these permits. Handing out a permit will lead to consequences that also need to be processed, so other business functions are necessary. For instance, the fee for the permit needs to be collected. Or if the permit was handed out under special conditions, it needs to be checked whether these conditions are met. Some permits need to be extended periodically, etc.

Cases versus Registers

When identifying primary or secondary business functions - ergo identifying cases - a third question may arise immediately after the first (what is a case?) and second (what are typical cases?). This question is:

This question is not easy to answer as well and is subject to debate very often. Cases typically contain processes of which the character is decision making. Registers very often do not have processes and if they do, these processes are of all about maintaining data consistency. The decision whether to model a business function as a case or as a register is straightforward most of the times, but sometimes it is not.

The first few business functions that will be identified, are likely to be cases. These functions will typically constitute the primary process (requesting a product, processing a claim, etc) and are more decision oriented than data oriented. Usually, when identifying the more secondary functions (for example paying a benefit, repeating a medical assessment), the choice between expressing it as a case or as a register becomes a factor. In order to make this choice, the following two questions can help:

• Is the most important goal of the business function making a decision and communicating about it, or is the most important goal of the function to make sure data is consistent?
• Is this business function repeated periodically as a result of a previously made decision?

If the answer to the first question is that the most important goal is making a decision, identifying the business function as a case is likely to be a good choice. If the answer is making sure data is consistent, a register is a good choice. If the answer to the second question is yes, then a case is likely to be a good choice. Beware that this leaves room for personal or organizational preferences. In a lot of non straightforward situations, there is no right or wrong and the choice for a case or a register is based on discussions with the organization and the opinion of the solution architect.

Consider the next examples: Requesting a benefit and Creating a customer. The first example is very decision oriented and it is therefore highly likely to be expressed as a case. The second is very data oriented and it is therefore highly likely to be expressed as a flow for a register.

Other examples are less straightforward. When a citizen has requested a benefit for example, because he is unable to work due to sickness, the citizen has to have a medical assessment to determine whether he is eligible for this benefit. When the benefit has been granted, the medical assessment has to be repeated regularly to determine if the benefit can be continued. The choice whether the periodical assessment is to be modeled as a case or register is not that straightforward in this example. Both are likely choices, where the importance of the assessment plays a role. If the business merely asks how the citizen is feeling and stores this information, a flow for a register is a good choice. If the medical assessment is deemed to be very important however, expressing this as a related case is better.

When someone moves within the same municipality, this only involves changing his or her address. Such a simple task is likely to be expressed as a flow for a register. If someone moves to another municipality however, the situation is more complex. The amount of his taxes needs to be reassessed, permits need to be withdrawn or reconsidered, etc. It is highly likely that cases are triggered by such a move.

Modeling cases and registers

Bla bla

See also

More information on how to design dynamic processes in Blueriq can be found here: Designing dynamic processes.
How aggregates are used to model cases can be found here: Designing cases using aggregates.
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.