Inspired by a recent discussion in The Decision Model Group [1], this month’s column focuses on the emerging role of decision models on Agile projects. While Chapter 6 of our book[2] introduces a connection between decision models and Agile development, The Decision Model Group takes it one step further based on recent experiences.
First, the Big Question: Agile and The Decision Model?
Agile development is an approach that evolves requirements and software through iterative deliverables. One of its principles is to deliver working software frequently, often through a series of two to three week iterations.
The Decision Model (TDM) is a model for the full and rigorous specification of logic.
Therefore, on one hand, a decision model contains a complete and rigorous set of detailed logic leading to a conclusion (normalized and analyzed to remove logic anomalies and tested against test data). On the other hand, agile development embraces changing requirements, preferring shortened timeframes to software delivery.
Do they belong together?
This is exactly the question raised in the LinkedIn group and addressed generously by people with experience. It turns out that The Decision Model and Agile development are perfect together. There are flexible options for agile delivery of decision models of all sizes and complexities.
What People are Asking
The discussion started with the following statement from a popular participant in the group, Nick Broom:
“One of my vested interests from a project delivery perspective is Agile, which got me thinking about the fit of TDM (as an analysis artifact) with developing Agile user stories. The Decision Model book talks a bit about Agile development and how The Decision Model fits as well with it as it does waterfall. To quote: ‘The business logic modeled in the Decision Model fits into a very well-defined scope, the business decision. Because that scope is typically a single step in a business use case or task in the business process model, it is an appropriately bounded scope for the single increment that Agile development seeks for its iterations’. I agree with this up to a point, but it's going to depend on the complexity of the model as to whether it would fit into a single iteration (given that we have to do development, testing and user demonstration)”.
A suggestion came from Suleiman Shehu, “There is a very interesting white paper at KPI website called “FirstSTEP, Accelerating and Perfecting Requirements” which outlines a methodology for developing all the functional or business requirements in a series of iteration for developing all the required models (including The Decision Model) together with an iterative simulation/ visualization of all the scenarios using a product such as iRise.” [3]
Another participant is also moving into the world of iterative development, including decision models. “The developers have since changed their development approach to building "skeletal" code, and will add functionality over time. Because of the more agile approach we just today came to an agreement with our developer friends to model in a "skeletal" way.”
Four Recommendations for Decision Models in Agile Projects
The experiences shared in the group range from a very large complex project, to one using decision models as rules engine templates, to one in which decision models serve as analysis tools, and to projects in many different industries.
Below are four important recommendations that arose within the discussion group, along with related experiences.
Recommendation #1: Recognize that not every decision model fits into one iteration.
As pointed out earlier, a decision model stands behind one task in a process model. This suggests its development will fit within one iteration. However, some industries and processes have more complex decision models than others. When this is the case, the skeletal decision model provides insight into how to break it into segments.
Related Experience
Nick Broom shared the following as an example resembling real-world experience.
“Consider the calculation of the value of a policy on death of the policyholder. This became a very complex Decision Model, with the bulk of the complexity coming in the calculation of each fund value in which the policy was invested. The complication came depending on the type of fund in which the policy was invested and this is what caused the number of rows and columns to grow. Let’s call this story “Calculate Fund Value at Death.
Given the complexity of the model, it could not have been delivered in its entirety within one iteration, suggesting that “Calculate Fund Value at Death” is actually an epic story, not a true user story. If I truly wanted to ensure that I could analyze and subsequently deliver these rules within single iterations, I need to break this down into smaller stories.
Therefore, if I break it down further, it may be sensible to break it down in terms of fund type. So my user stories might be “Calculate Inflation-Protected Guarantee Fund Value at Death”, “Calculate Moneyback Guarantee Fund Value at Death” and so on for each fund type. So in the same way as code would be iterated for each subsequent story, so would my Decision Model, but fundamentally, the complete model is not delivered within a single iteration in this example.”
Recommendation #2: Use the skeletal decision model as the foundation for agile development of decision models.
Experienced agile decision modelers recommend creating skeletal decision models as early as possible, such as during scoping, a proof of concept prior to agile scrums, or model storming.
Larry Goldberg explains, “A skeletal decision model is simply a high-level guess at what the model may contain.” Therefore, this means a skeletal decision model is a decision model diagram (visual representation of related Rule Families) that you create before you populate its Rule Families. At the highest level, it may contain only the conclusion fact types for the Rule Families. These may be all you know. At a more detailed level, it may contain all condition fact types for the Rule Families if you invest the time to guess at these. A hybrid skeletal decision model is sometimes useful. This is one for which you populate one or more Rule Families to gain a better understanding of their complexity and, more importantly, how they reveal more of the decision model structure.
Whether high-level, detailed-level, or hybrid, a skeletal decision model, you do not need to know all of the detailed logic to take a guess at its initial structure.
Related Experience
Kathryn Clarkson in the group shared the following real-world experiences.
“We have used The Decision Model in several agile projects and find it works successfully - probably explains why our models look a bit unfinished. We have taken a couple of approaches, in one very large and complex project, we did a feasibility study where we built a proof of concept prior to the agile scrums, in this scenario, the Decision Model was formed as part of the POC and then validated through the scrums / user stories. We color-coded the overall decision model to indicate which parts had been dealt with and were able to use it as a discussion/validation with the business users and developers. At the end of the agile project I will expect to have an 'implemented decision model' which we enter into our live rule inventory with the rule families and rule flow - it will be tightened up and base-lined at this point.”
Larry Goldberg, whose decision model experience includes insurance, finance, mortgage, logistics, and others, shares his own experience.
“Typically we complete a skeletal model before we start creating the detailed Rule Families to help us understand the approach we wish to take with a particular Decision Model, and this is often done for the critical Decision Models during the scoping step of the project.”
Recommendation #3: Divide complex skeletal decision models into segments and assign segments to iterations.
Let us look at a simple example for one way of dividing a skeletal decision model into segments.
Using Figure 1 as an example, the decision is “Determine Student Financial Aid Eligibility.” Apparently, there are three types of financial aid as indicated by the condition fact types in the Decision Rule Family. These are scholarship, loan, and work-study program. Because each of these conditions appears in the Decision Rule Family between the solid and dotted lines, each of them has a supporting Rule Family. Therefore, the skeletal decision model In this figure has three corresponding branches. One branch contains only a supporting Rule Family, another contains a supporting Rule Family and one below it, while a third branch contains a supporting Rule Family and two below it.
This kind of structure is common, especially in very complex decision models. A very complex decision model may have many branches. Alternatively, it may have only a few branches but each branch may contain many levels. In such complex decision models, the branches exist because the conclusion for each one derives from logic that differs from the conclusion for the others. The logic may differ by the quantity and depth of the branch of Rule Families and may involve different fact types as conditions. As is often the case, each such branch represents a logical business subset, such as one kind of financial aid package, one type of investment fund, one kind of loan program, or one type of insurance policy.
Therefore, a natural way to divide such a skeletal decision model among iterations is to assign each branch as a whole to an iteration and assign the entire decision to yet iteration. For this figure, this kind of division results in four iterations and four User Stories: one for scholarship, one for loan, one for work-study program, and one for the decision in its entirety.
Figure 1: Partial Skeletal Decision Model Divided and Assigned to Iterations
Related Experience
Larry Goldberg shared the following real-world experiences.
“A skeletal decision model makes logical segments visible. For example, if the skeletal decision model contains portions that use a specific set of conditions (e.g., fund type),then there is a natural segment for each portion (e.g., fund type) where each has its own Rule Family and supporting Rule Families.”
Recommendation #4: Determine how far you really need to develop each decision model segment or full decision model.
An innovative approach is to deliver skeletal decision models in one iteration that will serve as the template of fact types behind a decision. Populate these with detailed logic in a (possibly much) later iteration.
Related Experience
Kathryn Clarkson shared a real-world experience related to this recommendation.
“One of the things we are trying to do with the rules engine technology is identify the templates required for the rules, not necessarily the atomic rules themselves. The decision model gives you this, without having to identify every rule you might ever want to write e.g. for a pricing calculation, we might decide we want to have a template to rate by shoe size for the future, therefore, we can reflect the fact types associated with this in the decision model, put the data on the interface, build the template, but not actually write any rules around shoe size until next year.”
Five Steps for Building a Skeletal Decision Model
Since a skeletal decision model is a useful technique in Agile projects, this section explains how to build one.
Step 1: Identify a business decision for a decision model
Start by selecting a business decision. Create an octagon to represent it and create the Decision Rule Family, which at this point contains only the conclusion fact type.
Example: For our example, let us use the decision to “Determine Person’s Likelihood of Defaulting on a Loan.” See Figure 2
Figure 2: Decision Icon and Decision Rule Family
Step 2: Explore possible conditions
Involve the business right away. Lead them in contemplating fuzzy ideas about the conditions that should play a role in the business decision. This may involve facilitated sessions, legacy code inspections, interviews, or document reviews. Place these fuzzy condition ideas in the Decision Rule Family. For now, place them below the solid line and above the dotted line. It is helpful to indicate them in red because they are merely fuzzy ideas at this time.
Example: Our business experts propose two fuzzy conditions behind the business decision to “Determine Person’s Likelihood of Defaulting on a Loan”. These are employment history and a combination of mortgage and other debt. See Figure 3.
Figure 3: Decision Model with Fuzzy Ideas for Conditions
Step 3: Add supporting structures
Explore the fuzzy conditions by asking business experts to explain them further. Determine which are likely to have a supporting Rule Family. Create appropriate supporting Rule Families.
Example: Our business people believe that Employment History will need a supporting Rule Family. Therefore, Figure 4 adds that supporting Rule Family. The business experts also want to separate mortgage debt from other debt. This is good news because a data professional points out that a Person’s Mortgage Situation and Person’s Miscellaneous Loan Assessment are data elements used in existing systems. Therefore, Figure 4 shows them below the dotted line in the Decision Rule Family.
Figure 4: Two Supporting Rule Families
Step 4: Refine conditions into fact types
Continue conversations with business experts to modify the fuzzy conditions, refining them until they are tangible. Decompose them, name and define them, along with domains. Reuse fact types already in the community glossary, wherever possible.
Depending on the project, it may be important not to limit these to data elements in data models, databases or other electronic form. This is true if the project is to include all condition fact types the business decision needs, regardless of whether they are physically available.
Add these fact types to the appropriate Rule Family. If no one knows yet if their values are available in persistent data storage, they belong between the dotted and solid line.
Example: Our business experts decide that Employment History is determined by Person’s Years at Current Employer and Person’s Number of Jobs in Past Five Years. The data professional points out that these exist as persistent fact types, so Figure 5 shows them below the dotted line in the correct Rule Family.
Figure 5: Refined Condition Fact Types
Step 5: Refine conditions until decision model structure is complete.
Repeat steps 2-4 until you reach a level in the decision model where all condition fact types are below the dotted line. This means there are no more supporting Rule Families.
Wrap Up
Skeletal decision models are important deliverables whether your project is Agile or not. Skeletal decision models help business people focus on the bigger picture of the criteria needed to make a decision not the details. In this way, skeletal decision models elevate the practice of business rule management to the strategic practice of business decision management.
However, in Agile projects, skeletal decision models play an additional role. They are the basis by which you can assign them (or pieces of them) to specific iterations in ways that make business and logical sense. Yet, this is just the beginning of their value.
Skeletal and populated decision models become living business artifacts. It is through these that the business can continue to envision, accommodate, validate, and test business logic changes over time.
“Business people easily recognize that business value is not found in the individual business rule or business logic statement, but in entire business decisions. Therefore, entire Decision Models (even without details) emerge as the asset that drives toward business objectives.” (von Halle and Goldberg, 2009).
(We are grateful for input from participants in The Decision Model Group on LinkedIn).
Author: Barbara von Halle and Larry Goldberg of Knowledge Partners International, LLC (KPI)
Larry Goldberg is Managing Partner of Knowledge Partners International, LLC (KPI), has over thirty years of experience in building technology based companies on three continents, and in which the focus was rules-based technologies and applications. Commercial applications in which he played a primary architectural role include such diverse domains as healthcare, supply chain, and property & casualty insurance.
Barbara von Halle is Managing Partner of Knowledge Partners International, LLC (KPI). She is co-inventor of the Decision Model and co-author of The Decision Model: A Business Logic Framework Linking Business and Technology published by Auerbach Publications/Taylor and Francis LLC 2009.
Larry and Barb can be found at www.TheDecisionModel.com.
[1] All readers are invited to join the LinkedIn Group called “The Decision Model.” In this group, you can ask questions or simply listen to what people and organizations around the world are doing with The Decision Model.
[2] The Decision Model: A Business Logic Framework Linking Business and Technology, von Halle & Goldberg, © 2009 Auerbach Publications/Taylor & Francis, LLC.
[3] Go to www.kpiusa.com to download this paper