The adventures of The Decision Modeler

What? No ranting and raving about cultural barriers in IT today? Outrageous. So this post is a little different to the ones I’ve done previously, as it’s a review of the BiZZDesign Decision Modeler that’s been recently released to support The Decision Model (TDM). So I’m going to a certain level of detail about one specific tool and technique.


My background in TDM

I’ve been using TDM as my preferred method for expressing decision business rules for about 2 years. What’s TDM? I’m not going to go into detail about it in this post, but I did a handy slideshare presentation that gives you a decent background in what it is and how it fits with other requirements artefacts. The first 18 months, I did modelling with Excel and Visio – great for really understanding the method itself, because you’ve got no automated validation to fall back on. I learned BPMN the same way – understand the method and almost any tool that supports it becomes easy to use. You learn with a tool first and your analysis becomes constrained by what that particular tool can support, so you don’t learn the method properly. Anyway, the past 6 months I’ve had the opportunity to work directly with Knowledge Partners International (KPI): the creators of TDM. That’s been as part of an engagement with a major financial client in the City of London, UK, delivering regulatory reporting. During that time I’ve also completed my TDM certification, which makes me the first certified practitioner in the UK [gives self massive pat on back and congratulatory cup of tea].


Tooling for TDM

So, that means I’ve experienced extensive use of the two ends of the tooling scale – Excel/Visio and Sapiens’ DECISION. I’ve run DECISION pretty ragged, so I know a lot of its capabilities and its ‘features’ 🙂 In fairness, I should probably do a review of that as well, but I’ve taken a look at The Decision Modeler because a) it’s new and b) it’s the first proper TDM tool to enter the market since DECISION. So, honestly, I’m pretty curious. Jan Purchase has already done an excellent post on The Decision Modeler, of which I would recommend a read. But part of that’s coming at it through the lens of projects that have not had the budget to support DECISION. I’m hoping my post will occupy a middle ground, rather than the opposing view, based on my aforementioned experience of both ends of the tooling spectrum.

Please note that this post expresses my own personal opinions; I’m not affiliated with the tool provider, nor have I been financially compensated in any way for evaluating the product or writing this review.


The basis for this review

OK so what I am I going to look at? Well, first and foremost I’m looking to see how well The Decision Modeler supports The Decision Model. Well, duh. But the reason I make that specific distinction is that I’m focussing on its ability to support the analysis I would do on any given project. So, harking back to my previous point, I know how the Decision Model works, so I’d like to see how this tool supports it in practice.


What am I not reviewing?

I’m not going to look at the tool’s export capabilities. Export of decisions to code is another topic in its own right, granted a very interesting one, but the way I look at it, the value of the export is only going to be as great as the tool’s ability to support the method.


How have I conducted the review?

I took an example of my most recent TDM work and tried to see how The Decision Modeler would support it. Disclaimer: the content has been desensitised – there is no confidential client information contained in this post. So, a brief overview of the constituent parts of that work:

  • Overall requirement was to produce monthly regulatory reports
  • Key analysis artefacts required during the project lifecycle:
    • BPMN process model (non-executable – used to provide context for decisions and provide detailed requirements and design to support development);
    • TDM decision models (including export of decisions into code);
    • Glossary (including mapping of Fact Types to physical data attributes to support decision export);
    • Logical Data Model.

As this is primarily a review of TDM capabilities, I’ll talk a little bit about the other parts of the BiZZDesign suite that support integration of other artefacts, like process models, but won’t go into detail. This is also not a ‘how-to’ guide, so you’ll have to forgive me if I skip over the minutiae of creating each TDM element.


What did I need to complete the review?

In order to demonstrate TDM and the integration with other artefacts, I used Architect 4.2.1 – the version with the BPMN add-in in addition to The Decision Modeler. I needed BiZZDesigner for the UML support. The former doesn’t appear to be the same as the TDM evaluation version you can download off the website, which just provides the TDM module, so I had a bit of back and forth with the BiZZDesign helpdesk who got me sorted; they were very prompt and I was up and running soon after.


The decision modelling context

The process model I’ve picked to provide the framework for the decisions is a sub-process within the overall end-to-end piece (see also my other post on how decisions and process act together). The reason I picked this particular process is that the decisions cover a lot of the TDM features, plus they are at different levels of complexity. Process brief: for each row of input data, work out whether it’s required in the report; what type of reporting line(s) it belongs on; what the specific reporting line(s) is/are and what value should be assigned to that line. Finally, work out an additional weighted value.

BiZZDesign Architect expanded BPMN sub-process

Expanded BPMN sub-process to determine reporting lines and values

Within this process, there are 5 separate decisions, denoted by the business rule icon in the top-left corner of the task. Pretty impressed with the BPMN capabilities, just as an aside.


Support for The Decision Model

So now we understand the process in which these decisions are being executed, let’s looks at how well The Decision Modeler does its thing. I’m going to look at:

  • Usability;
  • TDM feature support (so what aspects of TDM are supported by the tool);
  • TDM principles validation;
  • Glossary administration;
  • Integration (fit with other requirements deliverables).

For each, I’m going to provide a notional score (my gut feel; nothing too scientific) and then hopefully explain how I got there.


Score: 8/10 Verdict: intuitive, particularly if you’ve used other case tools before. There’s quite a lot of rekeying when creating the business decision itself, but that isn’t overly onerous in the scheme of things.

Review: The whole thing hangs together well; decisions are organised into their own model packages, separate from packages for the process and any other artefact. It’s a fairly standard user interface and the help function is superb. I didn’t request any support for how to use the tool and I found my way around it quickly and part of that was down to the help files. The creation of the business decisions themselves can be a little clunky: I have to create a Decision View and name it; drop the business decision onto the canvas and then name that; then create the decision Rule Family View and name that, despite the fact that all of these things will be named the same because they’re based on the conclusion Fact Type, the only difference being the decision verb.

BiZZDesign Architect The Decision Modeler User Interface screenshot showing TDM graphical model and Rule Family View

The User Interface of BiZZDesign Architect, showing the Decision View in the model package browser at left and the graphical model at right, along with the Rule Family View table and the prompt to select a Fact Type when adding a new condition.

That said, the creation of the Rule Family Views, the insertion of rows/columns and messages, the manipulation of the structure (moving rows around and so on) works seamlessly. When you first add a column, you get the option to select an existing Fact Type from the glossary, but if it doesn’t exist, you get asked if you want to create from scratch and the Fact Type is added as a new entry into the glossary.

It also has good printing support, including printing output to PDF. All aspects of the models can be printed and the PDF export means that each model can be fitted to a single page, making the preparation of offline review material much quicker.


TDM feature support

Score: 6/10 Verdict: does most of the basic stuff and even does List Fact Types, but struggles with supporting Rule Family Views used within operands, the populated characteristic of Fact Types and some aspects of rule family reuse.

Review: The first two decisions in the process were handled well, showing the tool can handle both regular and List Fact Types. Both are single Rule Family View decisions; the idea with the second one (the List Fact Type) is that one row of data could be split onto two reporting lines; this is handled by creating a reporting line type list and each item on that list can then evaluated separately and then associated with a specific value. The tool also supports testing of the decision in addition to the validation of TDM principles, thereby proving the support for the List Fact Type was also performing as expected. So, out-of-the-box, that’s pretty neat.

BiZZDesign screenshot of TDM Rule Family View Testing

Shows the second decision, which produces domain values that are added to a list. Test data has been entered and the results show that, for the given input values, two items are added to the list. The tool highlights the rows that have been triggered.

It also supports the use of formulae in the conclusion as well as Fact Types, so you’re not constrained to just using values. However, where it all starts to go a bit wrong is if I want to use a Fact Type as an operand, but where that operand is also a supporting Rule Family View. I use this technique quite a lot and it is a great way to normalise a Rule Family View. The tool sort of supports it, but not quite. You may be saying, “You what now?” but stick with me, this is pretty important. Most often this kind of thing occurs when you are using a formula as the conclusion, where the formula uses another Fact Type.

An example using natural language expression When an investment bond policyholder dies and the bond’s guarantee effective date is less than today and its guarantee type is linked to an inflation index, then the bond’s surrender value is the bond death claim inflation-protected guaranteed value. In this example, the bond death claim inflation-protected guaranteed value is a Fact Type which has its own rules for calculation depending on the rate of change in inflation, so it’s defined as a supporting Rule Family View. It is not a condition in the rule, it’s just an outcome.

Remember what I said right back at the start? “You learn with a tool first and your analysis becomes constrained by what that particular tool can support, so you don’t learn the method properly.” Here’s what the third decision, “Determine Reporting Line Description” should look like, having modelled it in Visio:

TDM graphical Decision Model with Rule Family Views shown in Microsoft Visio

The third Decision showing that the Decision Rule Family View uses three different supporting Rule Family Views as operands in the conclusion (shown by the Fact Type names in brackets directly underneath the conclusion name)

Here’s what it looks like in Architect:

A TDM Decision modelled graphically using The Decision Modeler with BiZZDesign Architect

The Decision as modelled in The Decision Modeler. No, it’s not me being lazy, so where are my Supporting Rule Family Views?

So, slightly different. I also said that the tool sort of supports it. That’s shown by the ‘=’ in the operand of the conclusion. The tool terms this an ‘expression’, which is how it supports Fact Types and formulae. So in this example, those values are Fact Type names. They’ve been created in the glossary and I can actually create them as Rule Family Views, but I seem to need to do that by going into the glossary, selecting the Fact Type and creating a Rule Family View from there. I can put the Rule Family View on the Decision View canvas, but I have to drop it on there without linking it to its dependent. If I try and link it inferentially, it creates a new condition in the decision Rule Family View. Not what I was after either. So I’ve got no indication on the graphical model that I’ve got links to supporting Rule Family Views and I’ve got no real indication within the table that the Fact Type in the operand is actually the result of a supporting Rule Family View. Behind the scenes, however, it is all linked up, because if I want to test the decision, I still get prompted for each of the persistent Fact Types in the decision as a whole. Which is all well and good if you’re an experienced practitioner, but not great if you’re getting to grips with decision modelling and not great if you’re a stakeholder that has accountability for the decisions but can’t get at all of the information easily.

The tool also doesn’t support the populated characteristic of a Fact Type; so simply testing for the presence of a value and not actually caring what that value is. This is also used quite a bit – in Architect I’d actually have to create a new Fact Type to represent this, which is not technically correct: it’s the same Fact Type, just a different facet of it. The tool struggles a little with some of the reuse aspects of Rule Family Views. There are some instances in which you may choose to create a decision for a Fact Type and then the outcome of that decision is passed downstream in your process so that the value can be used as persistent data within another decision. The tool doesn’t really allow that to happen. As soon as you put a Fact Type in a Rule Family View, where that Fact Type has been defined as a supporting Rule Family View within the same package, then it assumes you’re going to use all of the same logic. So it does some good stuff on the TDM features side, but some of the things it can’t handle would be enough for me to give it a miss for now.


TDM principles validation

Score: 7/10 Verdict: highlights some of the most common errors, but the error messaging is not always that meaningful

Review: Now, I’m not a man that can recite each principle according to number, sub-paragraph, sub-section etc etc. I know what they are in practical usage, but I haven’t done this bit of the review according to the principle that I’m testing. That may lack a little rigour for some, but I’m coming at it from a pragmatic perspective, looking at those things I would expect it to pick up. Whilst I think validation is a good thing, I also think it should be your final final final check, not the first thing you do; I think there’s a risk it can be used as a crutch and a more reactive way of learning the method, rather than really understanding what you’re trying to do. To that end, some may think I’ve scored this too high, but for the way in which I’d use it, I think it does a decent job. So the stuff I’ve tested: Overlapping condition keys – making sure that, for the same input conditions, there cannot be different conclusion values.

TDM Rule Family View testing - Principle 12c overlapping condition validation

Tells the user that there is more than one conclusion that can be reached for the same input conditions. In this case, non-zero in the Exposure Amount could mean both a ‘Yes’ and a ‘No’ are triggered

Yep, that’ll do. No conclusion – every rule must result in a conclusion value. In this example, I’ve deleted the conclusion from the second and third rows.

BiZZDesign Architect The Decision Modeler Rule Family View Testing missing conclusion value validation

Validation that is prompted when no conclusion value is present. Identical to the validation from the first example

Spot the difference to the first test? No, me neither. #fail. Circular relationships – a Rule Family View cannot be dependent on AND be a dependency of the same Rule Family View within one decision. For this example, I just trashed one of my previous decisions to create the relationship to see what would happen.

BiZZDesign Architect The Decision Modeler Rule Family View circular relationship testing

Shows the validation that appears when evaluating a decision with a circular relationship between Rule Family Views

I think this works? It doesn’t evaluate the Decision View, so it looks to work, but I can’t tell from the error message that it’s definitely the circular relationship that’s caused it.

Valid Fact Type domain values – this would probably be part of Principle 3: The Cell Principle (I looked it up). Accurate and complete glossary entries are a must, so it’s good if a tool can support the validation of the values used in a Rule Family View for a Fact Type where the range of values has been specified, or the data type has been specified. There’s no point specifying a Fact Type as a number if you then put in a value that’s a name.

BiZZDesign Architect The Decision Modeler screenshot Rule Family View domain value validation screenshot

Shows the validation errors associated with the Fact Type values. A mouse hover-over on the error provides error details

This also looks good. If you put something in that doesn’t match the data type or domain value in the glossary, then a red violation pops up and you won’t be able to evaluate the decision. Of course, if you’ve not set up your glossary properly, you can get away with anything, but then it just won’t make sense 🙂

So I think the validation’s got merit. A couple of issues with the way in which the validation is articulated, but overall, I was happy.


Glossary administration

Score: 8/10 Verdict: well integrated with the Rule Family Views, supports several domain types for each Fact Type and allows linkage to data models. Support for List Fact Types is a plus.

Review: The glossary is a huge part of TDM. I mean HUGE. Get this wrong, or don’t give it enough attention and your decisions will be ambiguous at best and just plain wrong at worst. After all, if you don’t understand what the terms are, how can you validate the combination of conditions are right? So it’s important that any tool provides good glossary support. Within the tool, a glossary is automatically created as part of the package. Fact Types are added to it either directly within the glossary itself, through the creation of a Decision View, or the addition of a condition within a Rule Family View. All good stuff.

BiZZDesign Architect The Decision Modeler TDM Glossary screenshot

A screenshot of the glossary with some of the fields populated. I’ve not put in the description, which I would have done if this was a real project using the tool, but you get the gist.

Attributes associated with each Fact Type are updated in the glossary, where you can define the description, the domain of the data (text; money etc) and (one of my favourite bits) its relation to an entity and attribute within a data model (I cover this within the Integration part of the review). You can toggle the Fact Type between being a list or a regular Fact Type. The attributes associated with each Fact Type are well integrated with the decisions. Specifying the domain of a Fact Type is very useful, not just because it aids with the validation and testing of your decisions, but also it ensures that you really think about how the Fact Type is named. It’s important that a Fact Type name is qualified in such a way that it is crystal clear what you are trying to express. There are a number of domain types that you can select:

BiZZDesign Architect The Decision Modeler Fact Type Domain Type selection

When I select the arrow at the top of the ‘domain’ box, I get to choose the domain type.

Enumeration allows me to specify a specific set of values that are allowable for a Fact Type. If you set this and then set a Fact Type value in a Rule Family View with something not in this list, then you’ll get the validation warning that I talked about earlier on. Equally, it does the same thing if you set a domain such as ‘money’ and then enter text into the condition value. Rule family views can be created directly from the Fact Type as well. At first glance, that looks like a good feature, but one that you’d need to be pretty careful of. It would be quite easy to create huge numbers of rule families but then forget to create the decisions to go with them, or forget to link them to an existing rule family within a decision. You can also create multiple glossaries, which is a useful feature if you’re operating this method across multiple business areas. Each business area may have terms specific to itself and having a separate glossary ensures a separation of concerns and minimises confusion. It also ensures that a term can only exist once, so if you try and create the same term in a different glossary, it grumbles at you:

BiZZDesign Architect The Decision Modeler screenshot for duplicate glossary terms

I’ve attempted to create a Fact Type in a second glossary that already exists in my original glossary and the system stops me.

You can also move Fact Types between glossaries quite easily.



Score: 8/10 Verdict: from an holistic analysis viewpoint, one of the best bits, but it’s less of an achievement when looking specifically at the TDM feature support.

Review: The integration is great; I can link business rule tasks to a business decision and I can relate my glossary terms to my logical data model. Splendid.

BiZZDesign Architect The Decision Modeler BPMN business rule task showing link to Decision Model

Screenshot shows cascaded windows in the tool, where the business rule icon in the task has been selected and the user is taken directly to the related decision model

BiZZDesign Architect The Decision Modeler glossary entry and relationship to UML data model

If I click on the arrow in the ‘Entity’ field of the glossary, I can relate my Fact Type to an entity within my UML Class Diagram that acts as my Logical Data Model.

BiZZDesign screenshot of Logical Data Model using UML Class Diagram

Shows the package at left where I’ve built the data model for the report using the UML Class Diagram. The entities and attributes are then available for linkage to a Fact Type in the glossary

There are also a whole host of other linkages that can be made, such as linking to business models, business motivations. So basically, the whole thing nestles well within all the other project aspects. I like it. I like it a lot.


Overall verdict

Overall, I was pretty impressed, particularly given that this is the first version. My caveat would be that, as I made clear at the start, I haven’t tested the end-to-end executable capabilities. But, that said, I wasn’t doing this review as a like-for-like comparison with DECISION. Plus, the review would have taken a lot longer!! There are a few bugs with the system, but those sorts of teething troubles are to be expected on a first release. If you want to do version control, you could either handle it externally, by saving your model packages to something like SharePoint, or you could use it in combination with the BiZZDesign repository for enterprise-scale version control.

What’s right with it?

The user interface is intuitive and the whole thing reflects BiZZDesign’s prior tooling experience. You don’t have to use the mouse for everything (take note, Sapiens) and navigation around the tool is pretty effortless. The ability to create each aspect of TDM works well and there is a decent level of automation between the decisions, the creation of supporting Rule Family Views and the glossary. The validation it does is pretty good, bar a couple of niggles. The integration with other requirements artefacts is excellent.

What’s wrong with it?

The lack of proper support for what I see as a couple of key features of TDM means that, whilst the scores across the rest of the sections are high, I’d place greater weighting on that score, which ultimately drags the overall mark down. After all, I want to model decisions correctly first and foremost. If I buy a car purely for its fuel economy, yet I have to refuel every 100 miles, the impressive design or the integration of the Sat Nav with the dashboard is still very nice, but not the reason I bought the car.

Score: 6.5/10 Verdict: good first attempt, great integration but some of the mishandling of TDM features means I’d wait for version 2.


7 thoughts on “The adventures of The Decision Modeler

  1. Based on Nick’s comments we are working on some adjustments to our tool. Those adjustments / improvements will be incorporated in the spring release of BiZZdesign’s Decision Modeler.


    Roberto Hoeve

  2. Pingback: The adventures of The Decision Modeler | The Hive Collaboration Central

  3. Nick,

    Its been a while since your review. but many of the issues you raised in your “TDM Feature Support” section have now been addressed. Like you, we find this pattern of delegating a rule family conclusion to one of a number of subordinate rule families is very handy in normalisation of our logic. It’s particularly useful in regulatory compliance which has many product-specific condition sets, driving the need to separate and normalise rule families. This works very well in Decision Modeler now.

    For my money the tool still has the best glossary and BPMN integration on the market.

    Looking forward to your next tool review (whatever it may be).


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s