Call to Action

Webinar: Take a tour of Sparkling Logic's SMARTS Decision Manager Register Now

Decision Management

Best Practices for Decision Management


best practicesNaturally, the decision management community demands constantly more best practices. We delivered tips for writing and organizing business rules, and topics of that nature. However, success often depends on these crucial early choices. So, let’s take a step back, and discuss how to start a decision management project.

Join our upcoming webinar to explore what initial steps will ensure success. In particular, we will focus on data and data model, business rules requirements, and business performance.

Anyone with interest in decision management will benefit from this conversation. As a newcomer, you will hear practical advice for this first project you have to tackle. As an experienced practitioner, you will enjoy our design tips.

Best Practices Series: Rules for Data Validation


Data ValidationWhy should you care about Data Validation? Actually, your decisions can only be as good as the data they apply to. Consequently, by improving the quality of the data you apply your decisions to, you will improve the quality of your decisions. There is inherently a strong bond between data and decisions. Our previous post highlights the importance of data in Decision Management. In this post, we will focus on strategies to improve Data Validation.

As a matter of fact, there are many forms of bad data: incorrect, missing, fraudulent, etc. Data Validation needs to address all these forms of problems you might encounter. Let’s take a deeper look at those.
Read More »

Best Practices Series: Data-Centric Approach


For decades, writing rules has been an abstract exercise. Business Analysts review requirements. They write the corresponding logic. If they are lucky, there is a testing infrastructure they can push the rules to. Often, they have together code for test cases, or wait for QA to catch possible issues. There is a better way that involves bringing data in early on.

Instant Feedback

The primary objective of a data-centric approach is to provide immediate feedback. As you look at one transaction at the time, you can see what decision and intermediate decisions are made. For example, an insurance application might be too aggressively turned down due to a somewhat-poor driving record. Reviewing this result, you can fine-tune your rule right-away. After adding the proper safe-guards, that same application might end up approved with higher premium, rightfully-so. This quick turn-around is key to quality rules in your decision management projects.
Read More »

Best Practices Series: Rules Requirements 101


requirementsBusiness rules provide the flexibility and agility that systems need. By definition, they enable business analysts to adjust the system’s decision logic to ever-evolving business direction. Due to competitive pressure, business regulations, or executive direction, business rules keep adapting. The art of capturing rules requirements dictates the success of the rules implementation to follow.

Rules Requirements are Requirements

As a Product Manager at heart, I value a nicely written PRD (Product Requirement Document). Many articles provide guidance on requirements gathering, and the golden rules to adopt for success. In particular, I like Duncan Haughey’s concise take on the subject. Above all, I cannot stress enough the value of focusing on the problem rather than the solution. Engaging stake-holders or subject matter expert from the start is paramount. Kuddos to him for putting it into writing.
Read More »

Why Decision Management and How


Why Decision ManagementA little while ago, we hosted a webinar about “why Decision Management?“. However, including the business case presentation alone seemed somewhat incomplete. Indeed, we also needed to focus on ‘how’. As a result, we created a presentation that covered both aspects.

In this blog post, I will focus on the key takeaways of the presentation. However, I encourage you to watch the video, especially if you are a manager, new to decision management technology.
Read More »

Technical Series: Data Integration for Decision Management


Decision Management SystemIntegration with data is key to a successful decision application: Decision Management Systems (DMS) benefit from leveraging data to develop, test and optimize high value decisions.

This blog post focuses on the usage of data by the DMS for the development, testing and optimization of automated decisions.
Read More »

ETCIO: Equifax InterConnect helps Indian CIOs


ETCIOETCIO (an initiative of The Economic Times) has interviewed KM Nanaiah, country manager at Equifax. The article highlights the details of the tooling that is now available to financial institutions. They will see dramatic improvements in customer acquisition and loan decisioning.

InterConnect’s Rules Editor is our Sparkling Logic SMARTS decision manager. In particular, InterConnect customers have praised its Champion / Challenger capabilities.

Read more at ETCIO

Technical Series: Authentication and Access Control


Decision Management SystemA key benefit of using a Decision Management System is to allow the life-cycle of automated decisions to be fully managed by the enterprise.

When the decision logic remains in the application code, it becomes difficult to separate access to decision logic code from the rest. For example, reading through pages of commit comments to find the ones relevant to the decision is close to impossible. And so is ensuring that only resources with the right roles can modify the logic.
Clearly, this leads to the same situation you would be in if your business data were totally immersed in the application code. You would not do that for your business data, you should not do that for your business decision logic for exactly the same reasons.

Decision Management Systems separate the decision logic from the rest of the code. Thus, you get the immense benefit of being able to update the decision logic according to the business needs. But the real benefit comes when you combine that with authentication and access control:

  • you can control who has access to what decision logic asset, and for what purpose
  • and you can trace who did what to which asset, when and why

Of course, a lot of what is written here applies to other systems than Decision Management Systems. But this is particularly important in this case.

Roles and access control

The very first thing to consider is how to control who has access to what in the DMS. This is access control — but note that we also use authorization as an equivalent term.
In general, one thinks of access control in terms of roles ans assets. Roles characterize how a person interacts with the assets in the system.
And the challenge is that there are many roles involved in interacting with your automated decision logic. The same physical person may fill many roles, but those are different roles: they use the decision management system in different ways. In other words, these different roles have access to different operations on different sets of decision logic assets.

Base roles and access control needs

Typically, and this is of course not the only way of splitting them, you will have roles such as the following:

  • Administrator
    The administrator role administers the system but rarely is involved in anything else. In general, IT or operations resources are those with this role.

  • Decision definer
    The decision definer role is a main user role: this role is responsible for managing the requirements for the automated decision and its expected business performance. Typically, business owners and business analysts are assigned this role.

  • Decision implementer
    The decision implementer role is the other main user role: this role designs, implements, tests and optimizes decisions. Generally, business analysts, data analysts or scientists, decision owners, and sometimes business-savvy IT resources are given this role.

  • Decision tester
    The decision tester role is involved in business testing of the decisions: validating they really do fit what the business needs. Usually, business analysts, data analysts and business owners fill this role.

  • Life-cycle manager
    The life-cycle manager role is responsible for ensuring that enterprise-compliant processes are followed as the decision logic assets go from requirements to implementation to deployment and retirement.

More advanced needs

There may be many other roles, and the key is to realize that how the enterprise does business impacts what these roles may be. For example, our company has a number of enterprise customers who have two types of decision implementer roles:

  • General decision implementer: designs, implements the structure of the decision and many parts of it, tests and optimizes it
  • Restricted decision implementer: designs and implements only parts of the decision — groups of rules, or models

The details on what the second role can design and implement may vary from project to project, etc.

Many other such roles may be defined: those who can modify anything but the contract between the automated decision and the application that invokes, etc.

It gets more complicated: you may also need to account for the fact that only specific roles can manage certain specific assets. For example, you may have a decision that incorporates a rate computation table that only a few resources can see, although it is part of what the system manages and executes.

Requirements for the Decision Management System

Given all this, the expectation is that the DMS support directly, or through an integration with the enterprise systems, the following:

  • Role-based access control to the decision logic asset
  • And ability to define custom roles to fit the needs of the enterprise and how it conducts its business
  • And ability to have roles that control access to specific operations on specific decision logic assets

This can be achieved in a few ways. In general:

  • If all decision assets are in a system which is also managed by the enterprise authentication and access control system: you can directly leverage it
  • And if that is not the case: you delegate authentication and basic access control to the enterprise authentication and access control system, and manage the finer-grained access control in the DMS, tied to the external authentication

Authentication

Of course, roles are attached to a user, and in order to guarantee that the user is the right one, you will be using an authentication system. There is a vast number of such systems in the enterprise, and they play a central role in securing the assets the enterprise deals with.

Principles

The principle is that for each user that needs to have access to your enterprise systems, you will have an entry in your authentication system. Thus, the authentication system will ensure the user is who the user claims, and apply all the policies the enterprise wants to apply: two-factor authentication, challenges, password changes, etc. Furthermore, it will also control when the user has access to the systems.

This means that all systems need to make sure a central system carries out all authentications. And this includes the Decision Management System, of course. For example:

  • The DMS is only accessible through another application that does the proper authentication
  • Or it delegates the authentication to the enterprise authentication system

The second approach is more common in a services world with low coupling.

Requirements for the Decision Management System

The expectation is that the DMS will:

  • Delegate its authentication to the enterprise authentication and access control systems
  • Or use the authentication information provided by an encapsulating service

Vendors in this space have the challenge that in the enterprise world there are many authentication systems, each with potentially more than one protocol. Just in terms of protocols, enterprises use:

  • LDAP
  • WS-Federation
  • OAuth2
  • OpenID Connect
  • and more

Trace

Additionally, enterprises are interested in keeping a close trace of who does what and when in the Decision Management System. Of course, using authentication and the fact that users will always operate within the context of an authenticated session largely enables them to do so.
But this is not just a question of change log: you also want to know who has been active, who has exported and imported assets, who has generated reports, who has triggered long simulations, etc.

Furthermore, there are three types of usages for these traces:

  • Situational awareness: you want to know what has been done recently and why
  • Exception handling: you want to be alerted if a certain role or user carries out a certain operation. For example, when somebody updates a decision in production.
  • Forensics: you are looking for a particular set of operations and want to know when, who and why. For example, for compliance verification reasons.

A persisted and query-able activity stream provides support for the first type of usage. And an integration with the enterprise log management and communication management systems support the other types of usages.

Requirements for the Decision Management System

The expectation is that the DMS will:

  • Provide an activity stream users can browse through and query
  • And support an integration with the enterprise systems that log activity
  • And provide an integration with the enterprise systems that communicate alerts

There are many more details related to these authentication, access control and trace integrations. Also, one interesting trend is the move towards taking all of these into account for the beginning as the IT infrastructure moves to the models common in the cloud, even when on-premise.

This blog is part of the Technical Series, stay tuned for more!

[Image Designed by security from Flaticon]

 2019 SparklingLogic. All Rights Reserved.