DMN
The SMARTS Way for Personalization
Personalization has always been the holy grail of marketing, advertising, sales, and customer relationship management. So far, two approaches have been used. The most fashionable today uses statistical data to make recommendations, the second oldest but which is coming back to the fore uses coded knowledge to make these recommendations. In this blog, we will show when one is preferable to the other as well as when the two approaches can be combined in SMARTS.
Personalization
Personalization can play many roles in marketing, advertising, sales, and customer relationship management such as identifying good prospects for a specific product or service, choosing a communication channel to reach prospective customers, and picking appropriate messages that fit both customer and channel.So far, two approaches coexist. Data-based personalization and knowledge-based personalization. You may wonder which one is the best. In fact, it depends on the sector in which you are.
Data-driven personalization works well when you have a lot of data to draw insights from and when the new data doesn’t deviate too much from the old data you based your insights on. We find this case in fast-moving consumer goods sectors such as retail, as people tend to consume the same consumables every week.
On the other hand, knowledge-based personalization works well when you don’t have enough data but want to offer a product, service or content based on the knowledge you have about the prospects and your offer. We find this case in premium sectors such as luxury, wealth management, and high-touch hotels, where customer intimacy is a must.
By design, SMARTS treats both data and knowledge equally. After all, what is often called data comes from knowledge of the subject matter – It is always someone knowledgeable about the subject who labels or explains the data collected. Thus, SMARTS supports both data-based personalization and knowledge-based personalization.
The SMARTS way
SMARTS is a low-code platform that enables creating, testing, deploying, and improving automated decisions in the form of decision tables, business rules, and other representations. I will not detail it here, but you can find a brief overview of SMARTS on our blog page and a full description on our resources page. Instead, I will focus the rest of this article on how to use SMARTS for data-based personalization and knowledge-based personalization.Data-based personalization
For data-based personalization, you can import recommendation models developed by your data scientists and leverage them in SMARTS. The models could be in Python, SPSS, SAS, or Project R among others. SMARTS integrates them if they are compliant to PMML, a standard for sharing and deploying predictive models.SMARTS supports importing as PMML neural networks, multinomial, general, and linear/log regression, trees, support vector machines, naïve bayes, clustering, ruleset, scorecard, K-Nearest Neighbors (KNN), random forest, and other machine learning models.
There may be situations where the model must be called as an external service. SMARTS provides support for remote functions, which makes it possible to invoke the model through JSON-RPC or REST services.
Knowledge-based personalization
RedPen. For knowledge-based personalization, you can use our rule authoring tool RedPen to write decisions in the form of rules using a use-case driven approach. A loaded data sample supplies the context for the rules and enables immediate execution and testing of each rule. RedPen mimics what subject-matter experts do when they flag decisions. When you activate RedPen, you can pin an existing rule, a field of this rule, or a rule set and change it as if you were using a real pen on real paper. You can also create new rules with RedPen, SMARTS automatically turns them into executable rules.Pencil. You can also use Pencil, our DMN compliant graphical decision design tool for uncovering, documenting, and sharing decisions with colleagues and partners. With Pencil, you just drag and drop graphical shapes to form a complete personalization diagram. Then you add logic to the graphical shapes and let SMARTS execute it.
SparkL. Finally, you can also use SparkL, Sparkling Logic’s language for writing rules in a natural language fashion. SparkL comes with everything you need to write rules and calculations —mathematical expressions, string manipulations, regular expressions, patterns, dates, logical manipulations, constraints, and much more. You can express any imaginable personalization logic and symbolic computation, making it the choice for highly sophisticated personalization applications.
Personalization based on data and knowledge
BluePen. As said before, SMARTS treats data and knowledge equally. When you have both, you can use BluePen, our machine learning tool.BluePen lets you explore and analyze your data using your domain knowledge to find predictors. Then, using these predictors, you can generate a model in the form of legible rules and integrate them into your decision logic.
Using BluePen, you can engineer or change the models anytime you need to. Without heavy investment in data analytics tools and efforts, you can evaluate BluePen models in simulations and quickly deploy them in the context of an operational decision.
Wrap-up
- Personalization has always been the holy grail of marketing, advertising, sales, and customer relationship management.
- So far, two approaches have been used: data-based personalization and knowledge-based personalization.
- No one is superior, it depends on the sector in which you are: mass marketing vs. intimacy marketing.
- SMARTS treats data and knowledge equally. So, you can use it for both data-based personalization and knowledge-based personalization.
About
Sparkling Logic is a company at the forefront of technological innovation in decision management. We help businesses automate their operational decisions with a powerful decision management platform, designed for business analysts first.Our motto is “your decisions, our business.” Using SMARTS, organizations have automated complex decisions in days, not weeks, or months. Our mission is to enable customers to implement the most demanding decisioning requirements and to easily maintain and improve them over time.
Sparkling Logic SMARTSTM (SMARTS for short) is a decision management platform that enables creating, testing, deploying, and improving automated data-based decisions in an integrated easy-to-use environment.
Unlike other tools that focus solely on the authoring and maintenance of business rules, SMARTS is decision-centric and focuses on measuring and improving business outcomes in the context in which our clients work, especially with complex regulations. Major enterprise customers like Equifax, First American, SwissRE, Centene, and NICE Actimize integrate SMARTS in their core systems.
Sparkling Logic SMARTSTM in 10 Questions and Answers
Sparkling Logic helps businesses automate and improve the quality of their operational decisions with a technology platform that is powerful and simple: SMARTS for short. In this post, we present SMARTS through 10 selected questions and answers.
Q&A
1) What is SMARTS?
SMARTS is a decision management platform for business analysts and ‘citizen developers’ to author, test, simulate, deploy, run, and change decisions autonomously, without involving developers or IT beyond first installation.
2) Is SMARTS a business rules engine?
SMARTS is more than a business rules engine. It integrates multiple decision technologies into the same platform. SMARTS provides eight execution engines: A decision flow engine to sequence tasks of a business process; a state-machine engine to orchestrate tasks; a rule set engine to sequence decisions; a sequential engine that either fires all or just the first valid decision; a Rete-NT engine for inference; a lookup engine for data search in large datasets; a PMML engine to execute predictive models; and a DMN 1.3 engine to execute decision models. Depending on the problem you have, you may choose one or the other, or even combine them in the same set-up.
3) What are the typical applications for which SMARTS is the best fit?
In the financial, insurance, and healthcare services, SMARTS often won over the competition for origination and underwriting, pricing and rating engines, account management, fraud detection, and collections and recovery. More generally, SMARTS is a good fit when there are a lot of decisions that are data-based, frequently invoked, and likely to change often.
4) What is the difference between authoring business decisions and rules with SMARTS and coding them directly in the final application?
You can code decision logic but you will need detailed specifications from business analysts. This process may take too much time when compared to SMARTS. And once the decision logic is coded, it becomes complicated for business analysts to understand and take control of. SMARTS targets business-critical decision logic that either implements business models, corporate policies or industry directives in a dynamic and continually changing economy. Think of all the financial, insurance, and healthcare regulations since the financial crisis of 2008 and the changes since the coronavirus crisis of 2020. These two crises are typical examples of complex situations where business decisions not only need to be implemented quickly and accurately, but they also need to change dynamically and continuously.
5) Does SMARTS come with a decision design process?
SMARTS not only supports but it also augments the Decision Model and Notation (DMN) standard of the OMG (Object Management Group). DMN models decision dependencies very well, but not decision sequencing, which is also a natural way experts use to describe a complete decision logic. SMARTS addresses both dependency and sequencing through the combination of Pencil, RedPen, and the decision flow.
6) What machine learning models does SMARTS support?
SMARTS supports the execution of 13 machine learning models including classification, linear and logistic regression, support vector machines (SVMs), decision trees, random forests and ensemble learning, clustering, and neural networks. SMARTS uses PMML, the standardized predictive model markup language, to import and execute whatever model your data scientists have built.
7) Does SMARTS integrate with business process management platforms?
Yes, a SMARTS decision service can be natively invoked by a business process like any other service. Also, for decision-centric processes, SMARTS provides an orchestration capability.
8) What is the difference between an RPA tool and SMARTS?
If you think of a process as a sequence of “what to do”, “how to do it”, “do it”, and “report it”, then SMARTS automates the “what to do” and “how to do it” tasks while an RPA tool automates the “do it” and “report it” tasks.
9) Is SMARTS cloud-based?
SMARTS was designed from the ground-up for the cloud. Whether you have chosen to host your application or use our SaaS solution, we provide you with the most modern tools. SMARTS comes in a container, ready to install on your premises, AWS, GCP, Azure, or Aliyun. Choose yours, change your mind, no need to recode to redeploy your application.
10) What makes you unique?
Our motto is “your decisions, our business”. We enjoy nothing more than helping customers implement their most demanding business requirements and technical specifications. Our obsession is not only to have clients satisfied but also to be proud of the system they built. So dare to give us a challenge and we will solve it for you in days, not weeks, or months. Just email us or request a free trial.
In this post, we introduced SMARTS through 10 selected questions and answers. If you have more, feel free to read our blog, sign up for our webinars, or contact us. We would be happy to get back to you very quickly.
About
Sparkling Logic is a Silicon Valley company dedicated to helping businesses automate and improve the quality of their operational decisions with a powerful decision management platform, accessible to business analysts and ‘citizen developers’. Sparkling Logic’s customers include global leaders in financial services, insurance, healthcare, retail, utility, and IoT.
Sparkling Logic SMARTSTM (SMARTS for short) is a cloud-based, low-code, decision technology platform that unifies authoring, testing, deployment and maintenance of operational decisions. SMARTS combines the highly scalable Rete-NT inference engine, with predictive analytics and machine learning models, and low-code functionality to create intelligent decisioning systems.
Hassan Lâasri is a data strategy consultant, now leading marketing for Sparkling Logic. You can reach him at hlaasri@sparklinglogic.com.
Decision Requirements and Modeling with DMN in SMARTS
In this post, we present how Sparkling Logic continues its involvement in the DMN standard, through its graphical tool SMARTS Pencil, which business analysts use to model business decisions by drawing a diagram to form a decision process.
DMN, a bit of history
The Decision Model and Notation (DMN) was formally introduced by the Object Management Group (OMG) as a v1.0 specification in September 2015. Its goal was to provide a common notation understandable by all the members of a team whose goal is to model their organization’s decisions.The notation is based on a simple set of shapes which are organized in a graph. This allows the decomposition of a top-level decision into more, simpler ones, whose results must be available before the top-level decision can be made. These additional decisions themselves would be decomposed, and so on and so forth until the model reaches a more complete state. In addition, the implementation of the decisions can be provided, notably in the form of decision tables (which is also a very common means of representing rules).
The normalization of the graphical formalism (the DMN graph) and of the way the business logic is implemented (e.g., decision tables) allows teams to talk about their decisions, using diagrams with a limited set of shapes.
Sparkling Logic was one of the early vendors to provide a tool to edit (and execute) these decision models: Pencil Decision Modeler. It was released in January 2015, before the standard was officially approved.
Since then, the DMN standard evolved significantly, by adding new diagram elements, new constructs and new language features, while clarifying some of the existing notions. It is now at version 1.3. And we didn’t rest on our laurels either: in SMARTS Ushuaia, we made Pencil Decision Modeler part of SMARTS, as a first-class feature and added full compliance to DMN 1.3! This post describes how SMARTS supports DMN 1.3.
Basics
DMN 1.3 still defines the building blocks which were in the original standard and which I mentioned in Talking about decisions.As a recap:
- A Decision determines its output based on one or more inputs; these inputs may be provided by an input data element, or by another decision
- An input data is information used as input by one or more decisions, or by one or more knowledge sources
- A business knowledge model represents knowledge which is encapsulated, and which may be used by one or more decisions, or another business knowledge model. This knowledge may be anything which DMN does not understand (such as a machine learning algorithm, a neural network, etc.) or a DMN construct (called a “boxed expression”, see below)
- A knowledge source represents the authority for a decision, a business knowledge model, or another knowledge source: this is where the knowledge can be obtained (be it from a written transcription or from someone)
These blocks are organized in a graph and the links between them are called requirements.
What’s new in SMARTS’ DMN Support
More building blocks
In DMN 1.3, the following elements may also be added to a graph:- A decision service exposes one or more decisions from a decision model as a reusable element (a service) which might be consumed internally or externally
- A group is used to group several DMN elements visually (with whatever semantics may be associated with the grouping)
- A text annotation is a shape which contains a label and can be attached to any DMN element
Custom types and variables
Input data, decision and business knowledge model elements all have an associated variable, which is of a given type (string, number etc., or custom). A variable is a handle to access the value directly passed by an input data element, or calculated by the implementation of a decision or a business knowledge model, from within the decision implementation.Custom types may be defined to group multiple properties under a single type name (with structure) or to allow variables which will hold multiple values (arrays).
Boxed Expressions
A few constructs are available to provide an implementation for a decision or a business knowledge models; they are termed boxed expressions since such expressions are shown in boxes which have a normalized representation. The following types of boxed expressions are available in DMN 1.3:- Literal expression: this is a simple expression which can use the available variables to calculate a result
- Context: this is a set of entries, each combining a variable and a boxed expression. Each entry in the context can use the variables of the entries defined before it, which is like using “local variables” in some languages
- Decision table: this is a tabular representation where rows (called rules) provide the value of outputs (supplied in action columns), depending on the value of inputs (supplied in condition columns)
- Function: a function can be called using an invocation, by passing arguments to its parameters. The result of a function is the result of the execution of its body (which is an expression that can use the values of the passed parameters). A Business knowledge model can only be implemented by a function
- Invocation: this is used to call a function by name, by passing values to the function’s parameters
- List: this is a collection of values calculated from each of the boxed expressions in the list
- Relation: this is a vertical list of horizontal contexts, each with the same entries
In addition to these, SMARTS defines an additional boxed expression, called the rule set. This is a set of named rules, where each rule is composed of a condition (an expression evaluating inputs) and action (an expression providing some values to outputs).
Helping Industry Adoption
With SMARTS Ushuaia, decision models are first-class citizens. The full compliance with DMN 1.3 means that all the DMN elements and boxed expressions, as well as the ability to interchange diagrams with other tools, are part of the package.As is usual, any model can be tested and executed in the same context as your SMARTS decision –a decision is never made in isolation, and a model is never used in isolation either. And of course, you will benefit from the great tooling we provide.
Finally, we at Sparkling Logic strongly believe that decision management technologies should be put in the hands of all business analysts. This is why we are part of the DMN On-Ramp Group, whose mission is to provide a checklist to help customers find the DMN tool to suit your needs, educate and raise awareness about DMN, and help with DMN compliance. For a great presentation of the group, check out here.
About
Sparkling Logic is a Silicon Valley company dedicated to helping businesses automate and improve the quality of their operational decisions with a powerful digital decisioning platform, accessible to business analysts and ‘citizen developers’. Sparkling Logic’s customers include global leaders in financial services, insurance, healthcare, retail, utility, and IoT.Sparkling Logic SMARTSTM (SMARTS for short) is a cloud-based, low-code, AI-powered business decision management platform that unifies authoring, testing, deployment and maintenance of operational decisions. SMARTS combines the highly scalable Rete-NT inference engine, with predictive analytics and machine learning models, and low-code functionality to create intelligent decisioning systems.
Marc Lerman is VP of User Experience at Sparkling Logic. You can reach him at mlerman@sparklinglogic.com.
If you envision modernizing or building a credit origination system, an insurance underwriting application, a rating engine, or a product configurator, Sparkling Logic can help. Our SMARTS digital decisioning platform automate decisions by reducing manual processing, accelerating processing time, increasing consistency, and liberating expert resources to focus on new initiatives. SMARTS also improve decisions by reducing risk and increasing profitability.
Authoring Business Rules with Data, Standards, and Apps in SMARTS
Nowadays, business rules automate hundreds, thousands, and sometimes millions of operational decisions that some organizations make every day. The most representative examples of such organizations are financial, insurance, and healthcare sectors. All these organizations make automated decisions with several combinations of terms and conditions, legal constraints, eligibility criteria, risk levels, and price ranges. In this blog, I explain how business analysts and ‘citizen developers’ author decisions with rules, data, standards, and apps in Sparkling Logic SMARTSTM.
Business rules
Business rules are not new; but until recently they were encoded in the rule syntax as “IF THIS THEN DO THAT” statements. As such, they needed detailed specifications from business analysts and skilled developers to code these business rules. And once the business rules were coded, they were complicated for business analysts to understand or control.Authoring with data
Gone are the days when business rule creation started with lengthly interviews where IT professionals asked business experts how they made decisions in line with company policies, industry regulations, and market dynamics. Starting with data, transactions, and use cases is now the new way. Fully in line with this new approach, SMARTS provides RedPenTM, SparkL, and Pencil. These are three independent but complementary technologies that business analysts can use to import data, and start authoring rules.RedPen is Sparkling Logic’s patented technology for authoring decisions through point-and-clicks. Using RedPen, business analysts write business rules using a use case approach. The loaded sample data provides the context to create, test, and run rules without prior knowledge of a special rule language and syntax. RedPen mimics what business experts do on paper when they flag decisions with a red pen. When business analysts activate RedPen, they can pin an existing rule, a field of this rule, or a rule set and modify it as if they were using a pen on a paper. They can also create new rules with RedPen, SMARTS will automatically turn them into executable rules. For cases where advanced logical, mathematical, and symbolic manipulations are required, business analysts can use SparkL.
SparkL (pronounced “sparkle”) is Sparkling Logic’s language for writing rules in a natural language format. SparkL can be used by business analysts with no formal technical background in rules syntax while still benefiting from mathematical expressions, string manipulations, regular expressions, patterns, dates, logical manipulations, constraints, and much more. They can express any imaginable decision logic and symbolic computation, making it the choice for highly sophisticated decisioning applications where the conditions as well as the actions can take a great variety of forms.
Other cases where the decisioning projects necessitate formal requirements and decision modeling, the standards development organization (OMG) offers a standard called Decision Model and Notation (DMN). Sparking Logic has adopted this standard and developed Pencil to operationalize DMN.
Authoring in the context of DMN standard
Pencil is a tool for users to model business decisions by dragging and dropping graphical icons to form a decision process. Pencil models comply with the DMN standard. Using an intuitive graphical interface, business analysts can immediately start capturing data requirements, decision models, and business rules, while collaborating to achieve the best explicit description of the decisions required for systems and applications. Pencil’s glossary can be used across decisions to achieve consistent use of terminology related to decisions. Business analysts can create or import data and then execute, test and continue to refine and improve decisions. Once decision modeling is done, Pencil provides a direct path to an executable decision.With SMARTS, a user has not to adapt to the tool, but the reverse, it is the tool that adapts to the user. The business analysts select the appropriate way for the task at hand. In the same project, they may choose Pencil to model decisions, RedPen for the major part of the application, and SparkL for the rest of the application. At any time, they can choose to display the rule sets as a group of rules, a decision table, a decision tree, or a decision graph. Moreover, they can switch from one representation to another and vice versa.
Orchestrating business apps
As intuitive as a decision management tool can be, it may never meet the needs of a real business person. The bells and whistles that business analysts need can be overwhelming for the credit manager or insurance underwriter who needs access to decision logic. This person is certainly more inclined to exploit decision-making logic than interested in learning how to create it, and even less in training on a rules authoring tool.For untrained business users, SMARTS sets the bar higher towards more simplification, and still within the same interface. They have full control over the configuration, management, and assembly of the decision applications that business analysts have developed, and they can do it all through web forms and point-and-clicks. With this added level of abstraction, untrained business users, business experts, and ‘citizen developers’ can adapt to industry regulations, company policies, and market dynamics, without IT intervention beyond the first installation.
Takeaways
- Business rules have moved from coding rules in “IF THIS THEN THAT” statements to authoring them with data, standards, and apps
- SMARTS implements this new way via RedPen, SparkL, and Pencil, three independent but complementary authoring tools that business analysts can use to express their decision logic
- Business users need business applications, not authoring business rules or developing machine learning models
- SMARTS gives business owners full control of business apps through web forms and point-clicks
- Today change is the rule, with SMARTS, automated decisioning is flexible to accommodate ever-changing regulations, company policies, and market dynamics
If you envision modernizing or building a credit origination system, an insurance underwriting application, a rating engine, or a product configurator, SMARTS can help. The Sparkling Logic team enjoys nothing more than helping customers implement their most demanding business requirements and technical specifications. Our obsession is not only to have them satisfied, but also proud of the system they build. Just email us or request a free trial.
About
Sparkling Logic is a Silicon Valley company dedicated to helping businesses automate and improve the quality of their operational decisions with a powerful digital decisioning platform, accessible to business analysts and ‘citizen developers’. Sparkling Logic’s customers include global leaders in financial services, insurance, healthcare, retail, utility, and IoT.Sparkling Logic SMARTS is a cloud-based, low-code, AI-powered business decision management platform that unifies authoring, testing, deployment and maintenance of operational decisions. SMARTS combines the highly scalable Rete-NT inference engine, with predictive analytics and machine learning models, and low-code functionality to create intelligent decisioning systems.
Hassan Lâasri is a data strategy consultant, now leading marketing for Sparkling Logic. You can reach him at hlaasri@sparklinglogic.com.
Tags: business rules • decision automation • decision management • decisioning • DMN • RPA • rule authoring • SMARTS
Business Decision Management (BDM) vs. Business Process Management (BPM)
Regardless of its market, in order to thrive, a business must manage its daily operations through well-defined, executed, and controlled processes and decisions. The top performers automate both with business process management (BPM) and business decision management (BDM).
Introduction
Generally speaking, BPM is the set of technologies that automate processes of an organization, that is to say the stages through which the organization passes. Often, the stages include data entry, transformation, and enrichment. Then data activation, exploitation, and reporting. On the other hand, BDM is the set of technologies that automate the multitude of operational decisions of an organization. The number often varies from hundreds to thousands, and sometimes millions of times a day.
As is always the case in technology, there is no clear distinction between BPM and BDM. Suppliers of both technologies operate in both markets, and companies combine them to maximize the benefit of each technology. The purpose of this article is to draw a line between the two technologies through an example from subscription-based businesses such as Amazon Prime, Netflix, and WSJ, and a second example from life, property, and causality insurances.
Processes and decisions
Subscription-based businesses such as those listed above take the form of a billing relationship with a starting subscription event, a continuous servicing or insuring process, and an eventually un-subscription event.
Figue 1: Simplified lifecycle of subscription to a media
Figure 1 presents a high-level view of the processes and decisions that take place behind the websites of Amazon Prime, Netflix, and WSJ. Figure 2 does the same for the life, property, and causality insurances. When you take a close look to the diagrams, you may wonder what a process is and what is a decision. In fact, both are taking place within these two examples.
Figure 2: Simplified lifecycle of subscription to an insurance
The key difference
The processes are stable enough in the sense that they do not change, because they are independent of each situation and indeed of each data. Whether it is a media or an insurance, the company always starts by prospect acquisition, then customer activation, and then customer management.
On the other hand, the decisions change too often, depending on the situation captured through data. Take the subscription to a streaming media (Figure 1). Ending the contract can be a tricky decision. Should the media end the contract the date of the subscriber’s call to cancel? Or should it try to propose a discount to keep the subscriber? Should the media recall subscribers who have not paid their last bill? A week or two weeks after the due date? These are the typical decisions that separate the media from each other. Each media has its own specific way to investigate customers when the relationship has ended.
Now, take the subscription to a car insurance (Figure 2). The insurance, like any other insurance competing for the same policies, searches to augment its business. But at the same time, it wants to reduce its risks. So decisions are more complex than in the case for a media. The subscriber may not be eligible for different reasons and to decide, third-party data may be needed. Also, the subscriber may present different risks depending on the age, car, and accident history. So the insurance has to take another series of decisions: Compute a risk level, then a price that hedges the risk.
In short, the processes are what make a company belonging to an industry, the decisions are what make the company unique in this industry.
BPM, BDM, and standardization
Under the pressure of competition on the one hand and regulation on the other, many service companies have realized the importance of separating decisions from processes. Until recently, they were nested. Leading this trend, the Object Management Group (OMG) has published two recommendations (BPMN for the former, DMN for the latter), thus accelerating the emergence of BPM and BDM as two different yet complementary technologies.
Conclusion
In practice, BPM technologies are appropriate when the problem is centered on a document that must be co-signed by different stakeholders. For example, a loan contract that passes from the Sales to Finance, then to the Legal department, then back to the Sales, and finally to the client.
On the other hand, BDM technologies are more appropriate when the problem is centered on operationalizing decisions. For instance, evaluating the eligibility for a loan, accepting or rejecting the application, and so on.
Takeaway
- Regardless of its market, in order to thrive, a business must manage its daily operations through well-defined, executed, and controlled processes and decisions
- Processes are what make a company belonging to an industry, decisions are what make it unique in this industry
- BPM is the set of technologies that automate processes, that is to say the stages through which the organization passes. BDM is the set of technologies that automate the daily decisions
- In practice, BPM technologies are appropriate when the problem is centered on a document that must be co-signed by different stakeholders. BDM technologies are more appropriate when the problem is centered on operationalizing decisions
Disclaimer
The statements in this article belong solely to the author. The article was not reviewed nor endorsed by any company or organization mentioned. You can send your comments to the author at hlaasri@sparklinglogic.com.
DMN and Pencil
Back in my early product management days, I looked at several tools for requirement capture. I found quite a few good solutions for product requirements, but nothing I really liked for capturing source rules. When working on business rules or decision management project, I leaned towards Spreadsheets and Word documents. And then, DMN was created!
With the DMN standard (Decision Model and Notation), we finally have a notation that works with a powerful underlying methodology. I really like that the notation forces you, the business analyst, into thinking about the ultimate decision(s) in a structured way. Instead of thinking exhaustively about all the rules that exist in your business, the methodology encourages you to decompose your big decision into smaller sub-decisions. This iterative process is very friendly, and very easy to share with your colleagues.
In our upcoming webinar, on April 11, we will introduce the DMN methodology. We will illustrate actual use cases using our Pencil Decision Modeler.
Best Practices Series: Object Model First
Where do you start? Do you upload a predefined object model? Or do you develop it with your decision logic?
Object Model First
It is our experience that, in the vast majority of the projects, object models already exist. The IT organization defines and maintains them. This makes perfect sense, since the object model is the contract for the decision service. We need to know all features of the application before processing it. The invoking system also needs to know where to find the decision and all related parameters.
The object model, or data model, or schema, really defines the structure of the data exchanged with the decision service. Some sections and fields will play the role of input data. Some will be output. The business rules will determine or calculate those.
In our world, at Sparkling Logic, we call the object model the form. When you think about the application as data, the form represents the structure specifying what each piece of data means. For example, Customer Information is a section; and first name, last name and date of birth are fields in this section.
While business rules are based on these fields, the field definition typically belong to the system. The system will produce the transaction payload, aka the transaction data, and receive it back after the rules execute and produce the final decision.
To summarize it, the ownership of the object model lies with the IT organization, since they are responsible for making the actual service invocation.
Modifying the Object Model
Does that mean that we cannot make changes to this object model? Absolutely not. Augmenting the object model with calculations and statistics is expected. The customer info will likely include a date of birth, but your business rules will likely refer to the age of the person. It is common practice to add an Age field, that is easily calculated using a simple formula. More fields could be added in the same fashion for aggregating the total income of all co-borrowers, or for calculating the debt to income ratio.
In most systems, these calculations remain private to the decision service. As a result, the IT organization will not even know that they exist.
Quite a similar mechanism exists to add business terms to the form. In order to complement your business concepts in the form, Business terms constitute an additional lingo that is shared across project. for example, you might want to define once and for all what your cut-off values are for a senior citizen. Your business term could even specify cut-off values per state. Your rules will not have to redefine those conditions. They can simply refer to the business term directly: ‘if the applicant is a senior citizen and his family status is single’. Each project leveraging that form will reuse the same terminology without having to specify it again and again.
Like calculations, business rules can use business terms, but IT systems will not see them.
It eventually happens that variables might need to be created. That’s okay. There is no issues with introducing intermediate calculations in order to simplify your business rules. Although these fields will be visible to IT, they can be ignored. As intermediate variables, the system might not even persist these values in the database of record.
When is the Object Model provided?
It is ideal to start your decision management projects with an established object model. Uploading your data is most definitely the very first step in your project implementation. This is true regardless of whether you have actual historical data, or are building data sample for unit testing your rules as you go.
The reason you want your object model established prior to writing rules is quite simple, frankly. Each time you modify the object model, rules that depend on the affected portions of the object model (or form in our case) will need refactoring.
Granted, some changes are not destructive. If that is your case, you can absolutely keep extending your object model happily.
Some changes only move sections within the form. As long as the type of the affected fields remain the same, your rules will not need rewriting. The only exception being for the rules that use full path rather than short names. If you rule says “age < 21", you will be okay whether the age field is located. If your rule says "customer.age < 21", then you will have to modify it if age moves to a different section.
And finally some changes are quite intrusive. If you go from having one driver in the policy, to multiple drivers, all driver rules will have to account for the change in structure. You will have to decide if the age rule is applicable to all drivers, any driver in the policy, or only to the primary driver. This is where refactoring can become a burden.
The more established the object model is, the better suited you will be for writing rules.
One point I want to stress here too is that it is important for the IT team and the business analyst team to communicate and clearly set expectations on the fields of the object model. Make sure that:
- Values are clearly documented and agreed upon: CA versus California, for example
- You know which fields are used as input: if state appears in several addresses, know which one takes precedence for state requirements
Sorry for this quick tangent… This is where we see the most of ‘rules fixing’ spent!
When do Rules own the Object Model?
It is rare, but it happens. We see it mostly for green field projects. When the database of record does not exist, and there is no existing infrastructure, new projects might have the luxury of defining their own object model. When there is none, all options are on the table: have data modelers define the object model, or proceed with capturing it as you capture your business rules.
In these cases, we see the DMN standard (decision modeling and notation) leveraged more often than not. As business analysts capture their source rules in a tool like Pencil, its glossary gets assembled.
For those of you not familiar with DMN, let me summarize the approach. The decision model representation guides the business analyst through the decomposition of the decision logic. Let’s say that you want to calculate Premiums. You will need to establish the base rate, and the add-on rates. For the base rate, you will need to know details about the driver: age, risk level, and location. You will also need to know details about the car: make, model and year. Your work as a business analyst is to drill down over the layers of decisioning until you have harvested all the relevant rules.
The glossary is the collection of all the properties you encounter in this process, like age, risk level, location, model, make, year, etc. Input and output properties are named in the process. You can also organize these properties within categories. When you have completed this effort, your glossary will translate to a form, your categories to sections, your properties to fields. In this case, your harvesting covers both decision logic and object model.
Final Takeaway
Besides minor additions like computations and variables, the object model is by and large owned and provided from the start by the IT organization. Only green field projects will combine rules and data model harvesting.
For further reading, I suggest checking our best practices for deployment and how to think about decisions.
Best Practices Series: How to Think about Decisions
Let’s continue with our series on best practices for your decision management projects. We covered what not to do in rule implementation, and what decisions should return. Now, let’s take a step back, and consider how to think about decisions. In other words, I want to focus on the approaches you can take when designing your decisions.
Think about decisions as decision flows
The decision flow approach
People who know me know that I love to cook. To achieve your desired outcome, recipes give you step by step instructions of what to do. This is in my opinion the most natural way to decompose a decision as well. Decision flows are recipes for making a decision.
In the early phases of a project, I like to sit down with the subject matter experts and pick their brain on how they think about the decision at hand. Depending on the customer’s technical knowledge, we draw boxes using a whiteboard or Visio, or directly within the tool. We think about the big picture, and try to be exhaustive in the steps, and sequencing of the steps to reach our decision. In all cases, the visual aid allows experts who have not prior experience in decision management design to join in, and contribute to the success of the project.
What is a decision flow
In short, a decision flow is a diagram that links decision steps together. These links could be direct links, or links with a condition. You may follow all the links that are applicable, or only take the first one that is satisfied. You might even experiment on a step or two to improve your business performance. In this example, starting at the top, you will check that the input is valid. If so, you will go through knock-off rules. If there is no reason to decline this insurance application, we will assess the risk level in order to rate it. Along the way, rules might cause the application to be rejected or referred. In this example, green ball markers identify the actual path for the transaction being processed. You can see that we landed in the Refer decision step. Heatmaps also show how many transactions flow to each bucket. 17% of our transactions are referred.
Advantages of the decision flow approach
The advantage of using this approach is that it reflects the actual flow of your transactions. It mirrors the steps taken in a real life. It makes it easy to retrace transactions with the experts and identify if the logic needs to be updated. Maybe the team missed some exotic paths. maybe the business changed, and the business rules need to be updated. When the decision flow links to actual data, you can use it also as a way to work on your strategies to improve your business outcome. If 17% referral rate is too high, you can work directly with business experts on the path that led to this decision and experiment to improve your outcome.
Think about decisions as dependency diagrams
A little background
In the early days of my career, I worked on a fascinating project for the French government. I implemented an expert system that helped them diagnose problems with missile guidance systems. The experts were certainly capable of layout of the series of steps to assess which piece of equipment was faulty. However, this is not how they were used to think. Conducting all possible tests upfront was not desirable. First, there was a cost to these tests. But more importantly, every test could cause more damage to these very subtle pieces of engineering.
As it was common back then in expert systems design, we thought more in a “backward chaining” way. That means that we reversed engineered our decisions. We collected evidences along the way to narrow down the spectrum of possible conclusions.
If the system was faulty, it could be due to the mechanical parts or to the electronics onboard. If it was mechanical, there were 3 main components. To assess whether it was the first component, we could conduct a simple test. If the test was negative, we could move on to the second component. Etc.
In the end, thinking about dependencies was much more efficient than a linear sequence, for this iterative process.
The dependency diagram approach
Today, the majority of the decision management systems might pale in sophistication compared to this expert system. But the approach taken by experts back then is not so different from the intricate knowledge in the head of experts nowadays in a variety of fields. We see on a regular basis projects that seem better laid out in terms of dependencies. Or at least, it seems more natural to decompose them this way to extract this precious knowledge.
What is a dependency diagram
A dependency diagram starts with the ultimate decision you need to make. The links do not illustrate sequence, as they do in the decision flows. Rather, they illustrate dependencies obviously, showing what input or sub-decision needs to feed into the higher level decision. In this example, we want to determine the risk level, health-wise, of a member in a wellness program. Many different aspects feed into the final determination. From a concrete perspective, we could look at obesity, blood pressure, diabetes, and other medical conditions to assess the current state. From a subjective perspective, we could assess aggravating or improving factors like activity and nutrition. For each factor, we would look at specific data points. Height and weight will determine BMI, which determines obesity.
Similarly to the expert system, there is no right or wrong sequence. Lots of factors help make the final decision, and they will be assessed independently. One key difference is that we do not diagnose the person here. We can consider all data feeds to make the best final decision. Branches are not competing in the diagram, they contribute to a common goal. The resulting diagram is what we call a decision model.
Advantages of the dependency diagram approach
Dependency diagrams are wonderful ways to extract knowledge. As you construct your decision model, you decompose a large problem into smaller problems, for which several experts in their own domain can contribute their knowledge. When decisions are not linear, and the decision logic has not yet been documented, this is the right approach.
This approach is commonly used in the industry. OMG has standardized the notation under the “DMN” label, which stands for Decision Model and Notation. This approach allows you to harvest knowledge, and document source rules.
Choose the approach that is best for you
Decision flows are closest to an actual implementation. In contrast, dependency diagrams, or decision models, focus on knowledge. But they feed straight into decision management systems. In the end, think about decisions in the way that best fits your team and project. The end result will translate into an executable decision flow no matter what.