You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

Introduction

Solution design, or solution architecture, is a field of expertise where many discussions are held. Not only is the type of solution always clear when embarking on a journey to solve our customers' problems, also the ideal approach to design the solution is subject to discussion very often. This main characteristic of solution design - and in fact design in general - has two flavors: Bottom-up and top-down. As discussed in Designing solutions top down [editor] of the Persistency Management guide, Blueriq allows both a bottom up and a top down design approach. In this article, the top down solution design approach using the business function model is discussed.

Implementation method

In this design guide

Blueriq's implementation method consists of four iterative phases

  • Discover
  • Design
  • Model
  • Use

and two continuous phases

  • Continuous control
  • Continuous improvement

Throughout the entire implementation of a solution, from discover to use, the customer (and the customer's customer) are at the center.

Each phase has a specific goal, a list of mandatory and optional artifacts and a list of milestones. For more information on the Blueriq implementation method (dutch only for now), see Blueriq implementatiemethode (Dutch).

Business function model

Within the design phase, one of the most important artifacts is the Business function model (in Dutch: bedrijfsfunctiemodel). This model is heavily based 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 or by whom. Since the operations of a business are not as volatile as organizational structures such as departments, 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 all the business functions are depicted, but not all these functions are in fact in scope of the part 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 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 solution. 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 information themselves, but there is also a lot of information that is not stored within cases that reflect these functions. For instance, registers that are part of the solution or are stored outside the solution.

Primary functions

Designing primary functions immediately raises a question that has been and will be heard a lot amongst designers: "What is a case?". To answer this, 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.

Registers

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.

  • No labels