≡ Menu

#BBCCon Session: A Practical Approach to Decision Management/Modeling at Principal Financial


One of our clients was up next with Principal Financial Group presenting on A Practical Approach Using Decision Management and Decision Modeling at The Principal Financial Group. Doris and Don presented on their decision-centric approach for business rules implementation.

While Principal is focused on getting to good business rules, the right business rules, they take a decision-centric approach to analysis. This decision-centric approach focuses analysis and development of business rules for better, faster results. The approach has been developed over the last couple of years on projects in the Annuities space. The first project began with traditional business rules analysis but found this was time consuming and lacked clarity. The team became away of the growing focus on decisions and decision models. As a result they shifted to a decisions first approach, modeling decisions and documenting the business rules as rule families within that structure. This is the approach they have used on some subsequent projects.

For an example, one decision at the process level has decomposed to over 200 component decisions and thousands of business rules. The approach has also been used to kick off new projects in other areas – a 5 week effort for instance included training and mentoring and identified 50+ sub decisions with about half defined in detail. The team are able to teach people to use the approach quickly and easily, business analysts don’t find it hard to use. New projects are on deck and these are going to apply the technique.

With that intro, Don introduced some of the foundation concepts around discovery, elicitation and verbalization. Principal:

  1. Discovering and documenting decisions using Decision Management
  2. Eliciting business logic using rule families from The Decision Model
  3. Verbalize business rules using RuleSpeak

Step 1 begins by identifying the spots in a process where decisions are required. Identifying these decisions, specifying key characteristics for these decisions and documenting the question/allowed answers for this decision is next. Properties include things like descriptions and business owners, source materials etc.

Their experience (and mine) is that being able to clearly state the question/answers is critical. If you can then you are in a good space but if you can’t it often means you have multiple decisions overlapping or a lack of understanding.

They prioritize the decisions. They use the complexity, timeliness, time to outcome, business value, organizational impact and more to prioritize decisions so they focus where it will make the most difference.

Remember, they say, to begin with a specific process-level decision in mind. Ensure that the models developed in support of the decision, the analysis artifacts, are easy to understand and change. Make sue you are in a position to evolve and improve decisions over time. This is not a one-time effort.

Next they document the decision using a decomposition in a diagram – a decision requirements diagram (the core diagram of the Decision Model and Notation standard). These are the kinds of diagrams that you can manage in DecisionsFirst Modeler. These diagrams can show knowledge sources (where the rules come from) and input data or information sources. However the focus on their projects has been on the decision decomposition – what other decisions are required to make a decision. This decomposition can be repeated  for each decision, building out a network of dependent decisions. These networks can be large and complex so multiple diagrams showing summaries and different views are critical.

Having built the decision requirements diagram they use rule families to document the business logic in the decisions they identified. Rule families, a concept introduced by Barbara von Halle and Larry Golberg, apply a set of guidelines to normalize the business rules. Applying these principles to the models means that the leaves of the decomposition are coherent, normalized rule families (similar to what others call rulesets or decision tables). They don’t use the TDM diagram style as they use the Decision Requirements Diagram instead.

They use RuleSpeak to verbalize rule statements in these rule families to help explain them to business users (not using a formal fact model so this is a somewhat informal use of RuleSpeak).

To teach this approach Principal use a basic sequence:

  • Plan
    They generally begin with a decision task in a process model
  • Draft Shell of Decision
    Basic properties plus the conclusion / answer and more.

    • Elicit Conditions
      As the expert identifies the conditions they need to check before they can make the decision this identifies vocabulary terms and values that are needed.
    • Populate Rule Families
      The various possible answers from the sub-decisions or conditions are added to the rule family.
    • Add Message
      Rule statements are added to clarify each row, each rule in the family.
    • Identify sub-decisions
      If any of the conditions are not input data, if they require decisions to be made to create the condition information, these are sub-decisions that must be defined in term.
    • Repeat

Once the rule family being developed meets the normalization criteria – that all the conditions are based on raw input data – the decomposition stops as this is the lowest useful level.

This approach has worked well for Principal. They are producing higher-quality artifacts in part because each step is straightforward and clear. It helps keep elicitation sessions focused, validate completeness, find gaps, find reuse and train analysts. The artifacts produced work for business and IT and the diagrams allow Principal clearly define the scope boundaries for the next sprint or project.

Key lessons learned:

  • Its worth establishing guidelines for meta data, diagrams, rule family templates etc.
  • Work top-down from a process-level decision.
  • Decompose complex decisions into manageable chunks.
  • Separate data quality decisions from business decisions.

Great presentation. Lots and lots of good stuff.


Comments on this entry are closed.