Our platforms and tech are constantly evolving

Fact based decision making

Here at Blueriq, we deliver a platform for the design, realization and eventually execution of webservices, forms, processes and case management solutions. We can deliver these functionalities dynamically, by virtue of our ability to execute logic. Our Rule Engine enables us to derive new information from user input, external data or other forms of information by executing the logic that has been modelled into Rules and Decision Tables using our Encore studio.

The information that is thus derived can be used to make decisions, whether these are formal or internal. For instance, the derivation of a fact from input data can result in the decision to perform a task, or the information entered into a form and the subsequent application of business rules to this information can cause the decision to grant a loan, subsidy or product. 

These decisions are all based on factual information, either direct our derived from the execution from rules. These facts are inherently rather rigid: a fact is either true or false. But what if we want to incorporate past experience in our decision making? In a rule-based system this means the rules have to be adapted, so that the derived facts represent the expectations we have because of our experience.

In a software delivery world, even using agile methodologies and a platform like ours that makes designing, realizing, testing and delivering the execution of these rules considerably easier than in a classic high coding context, this means a delivery pipeline has to be traversed, starting with (human!) interpretation of the past experiences and ending with the deployment of a new piece of software. This can be complex, time consuming and error prone. So how can we make our applications use experiences without these setbacks?

When things get more fuzzy

Fuzzy logic classically provides a solution to rules that are not (yet) clear cut. By comparing a current use case to a collection of information gathered earlier, the steps taken in the most similar case found can be repeated. Whether this is the making of a decision or the taking of an action, the similarity to past experiences gives a (limited) guarantee that we can do the same thing again. In reasoning task this is referred to as case-based reasoning, called thus because it requires a case base, or repository of past experiences, to compare a current case to and score similarity by applying a matching algorithm. Usually, similarity score is represented using a percentage. This percentage can be viewed as the probability that execution in this fashion will yield favorable results. The information that is thus derived can be used to make decisions, whether these are formal or internal. For instance, the derivation of a fact from input data can result in the decision to perform a task, or the information entered into a form and the subsequent application of business rules to this information can cause the decision to grant a loan, subsidy or product.

In this initiative we aim to investigate - and realize - the use of experience in predicting favorable future execution, by applying this concept to prediction of case execution speed based on available choices by answering the flowing research question: can we predict the Best Next action, based on past execution and case data, to minimize the remaining execution time for this case?

Road to success

To gradually come to the necessary knowledge and technology, this initiative will be built following these steps:

Future applications

Platform Authentication

During the development of the DCM dashboards, we have started applying the 'backend for frontend' pattern to develop a gateway for the authentication and authorization tokens used towards the dashboard component. To maintain consistency across our platform, we are investigating whether we can adopt this method as the standard for all our runtime components.

What if Business Engineers could immediately use tools released the same day in Encore? We believe this is possible! Currently, however, the Blueriq Encore release cannot precede the runtime version. We are working on a plan to enable the Encore version to be ahead, allowing Business Engineers working with the Encore SaaS to directly benefit from model-independent tools and usability improvements (such as multiselect), even with a lower runtime version.

Currently, Blueriq does not offer a clear strategy for model versioning. Version numbers follow the format '0.0-branchname', meaning exports from the same branch always receive the same version, even if they differ. In practice, release branches are created, with the convention that the branch name includes a version number. Introducing release exports with mandatory versioning gives the releases an official status, which can also be traced back to a state in version control.

Having release versions gives the platform the opportunity to expand in the future (currently out of scope) with features such as:

• Defining and executing data migrations
• Starting old cases with an older model
• Increased confidence in using the correct model during session continuations (in case of failover)
• Better ability to monitor publication history

The Blueriq platform is designed to represent a wide range of organizational policies and processes in an executable model. This is made possible in a flexible way that supports a broad array of use cases and is also reusable... and we could keep going on with the list. All of these possibilities make the Blueriq platform powerful, but they can also feel overwhelming.

Especially when you want to create a service that makes a single decision. However, this could still be backed by a complex decision-making model, such as conducting risk assessments, determining prices, approving loans or subsidies, and so on. We believe that using the rule engine in its purest form can be made easier with the help of a new project type in Encore: Knowledge Service. This focuses on modeling business rules. The creation of interfaces (in Blueriq terms: REST service, web service, domain schema, modules) is done as automatically as possible. In this way, limiting options opens up new opportunities!

Explaining Decisions

With Blueriq, complex solutions are often created. When something is rolled out based on given input—whether it's a result, judgment, or decision—the (end) customer doesn't always know how this answer was reached. In a time when AI is playing an increasingly larger role, it’s becoming more essential to explain why something happens. The answer itself, even if it comes from an approved system, is no longer enough.

Why?

Optimizations in UX and work processes can flow back into the platform through the broad implementation of Blueriq DCM across diverse clients and applications.

What?

Initially, we will explore how to effectively support user profiles. This will, for example, allow users to customize their widgets on the Dashboard to their liking.

Ultimately, we aim to add more native features that focus on supporting users in knowledge-intensive tasks carried out with Blueriq DCM.

Think of native integrations with DMSs for comprehensive document management, or a Messaging Box that can be used both within a case and across cases.

The application of Case Based Reasoning will help users by providing suggestions on how to proceed with a case, based on various case properties.

When a task is being performed, data is modified by the user. In some cases, the user may stop responding or the session may be closed. We want to ensure that the data changes made during this time remain available so that the user can continue editing where they left off, without having to start over.

Blueriq applications are often mission-critical and play a central role in our customers' IT landscapes. Due to their strategic position in complex environments, performance issues can have a significant impact. However, identifying the root cause of these bottlenecks is not always easy. Delays often occur with connections to other systems or databases, but pinpointing the exact bottleneck can be challenging.

To improve this process, we want to add metrics to the runtime. These metrics will provide insight into the performance of Blueriq applications and their interactions with other systems. The goal is not only to identify bottlenecks faster but also to signal them in the Blueriq Cloud Platform before users experience any issues. This will enhance the reliability of these critical systems and ensure an even more stable and efficient IT environment.

This situation is unique, so the unity of policy and execution does not apply...

In conversations we have with our clients, we sometimes hear that it is difficult for knowledge workers to make consistent decisions across different cases. Sometimes this is due to the variety of cases, but other times it is due to the (privacy) sensitivity of a case.

This is precisely the challenge we want to investigate with the following hypothesis:
Can we, through matching combined with homomorphic encryption, enable the recognition of patterns across cases and return key insights/results to knowledge workers without sharing sensitive information, but instead sharing data patterns and results?

 

Whitebox testing with Blueriq

Traditionally, Blueriq flows are often tested by applying test scenarios to the entire application where these flows are used. This means not only is the correct operation of the flow tested, but also its combination with the frontend. Additionally, smaller subflows cannot be tested individually as units but only as part of an exposed flow they belong to. We aim to solve these challenges and more with the Blueriq Testcenter.

The Blueriq Testcenter enables us to test flows as units, regardless of whether they are exposed, and without the need to test "through the frontend." This provides business engineers with better feedback at lower costs.