If you model your business decisions and rules using the Decision Model (TDM), it might at first appear that both the information captured in the TDM glossary and the inferential dependencies between rule families in the model itself, together, capture all the same information that might normally be caught in a fact model. All the business terms, their relationships and the fact types than bind them are already in the glossary—why bother to capture them again in a fact model? Would this not cause redundancy and undue maintenance overhead? Our experience of using TDM in the investment banking domain suggests that it is not as simple as that…
The Decision Model (first widely publicized as a book by Larry Goldberg and Barbara von Halle in 2009) is a structured approach to capturing and representing business logic that makes business decisions easier to understand, communicate, manage and test, for business SMEs without the help of IT. It ensures that dependencies between different elements of business logic are minimized, allowing one element to be changed with minimal effects on others. It normalizes business logic so that it is more compact and easier to maintain. It ensures that business logic is internally consistent and promotes reuse. Central to its definition is the notion of the business decision — a particle of business logic related to the business rule (this article explains the difference).
TDM is a powerful technique that is both popular with business SMEs and promotes the rigour of decision architecture. Although it has its weaknesses, it has proven an invaluable tool in our arsenal.
The question arises: how does this (relatively) new technique relate to the techniques that preceded it? Does it augment or replace them? Specifically, we are asked: is the fact model — a means of representing business terms and their inter-relationships, not unlike a data model — still needed if you are using TDM?
Fact Models Have Their Uses
Our experience of applying TDM in the investment banking domain is that, although fact models are (somewhat) derivative of semantic information already in the DM glossary (business terms and interrelationships) and the decision models themselves (fact types), fact model diagrams (and the underlying models) are often a useful adjunct to TDM. Specifically, they have two key uses not supported elsewhere in decision modelling:
- They can act as a very compact (usually one A3 page) illustration of the key concepts of a business domain and how they interrelate. In other words they visualise the fact, categorisation, composition and classification relationships between terms — something that can be hard to see in many pages of flat glossary text (see snippet diagram).We’ve found this to be both a useful summary and a means of spotting missing terms, relationships and synonyms; just as a map is a useful adjunct to a long list of textual directions. There seems to be no direct replacement offered by TDM.
- Once early iterations of the fact model are established, they can be a useful means of spotting potential holes in your business rules or decisions. Holes exposed when a certain juxtaposition of facts (i.e., a specific business scenario) encounters a certain business event which changes them — challenging the boundaries of your business logic. Ross calls these ‘flash points’ (see Business Rule Concepts, chapter 8). Addressing these will make the decision model more robust (from a business event perspective, I’m not talking about structural or inferential integrity in which TDM already excels) and can even identify new business rules, decisions and operational opportunities. This is a very powerful technique which addresses the current lack of business event support in TDM.
We’ve found both of these applications to be important additional tools for the business analyst who is already benefiting from the power and integrity provided by TDM.
Avoiding Redundancy and Inconsistency
So, given these uses, how can we overcome the just criticism that producing a full fact model would introduce too much documentation overhead, redundancy and inconsistency? It would require that SMEs make glossary entries for every business term and then enter them again into a fact model. Can we avoid that?
Of course we can. It would be excellent if BDMS tools like Sapiens DECISION could depict a fact model as a ‘derived view’ of a glossary. For this, a highly structured glossary would be required from which alternate views could be generated by the tool. Alas the decision model glossary, as currently published at least, is informally structured. It is just a collection of business term names and some text to define them. There is no publicly available documentation, of which we are aware, that suggests a more structured approach .
This lack of any regimented structure seems to rule out this ‘derived view’ approach. Indeed, there seems to be a concern that too much regimentation in the glossary might make it less approachable for business users. I disagree with this: good tools can always relieve the burden of such regimentation, and, in any event, TDM promotes (and benefits from) a highly structured approach to decision modelling — why relax this structure for the glossary? This seems inconsistent.
Thankfully there are indications that TDM tool vendors will provide these facilities and this innovation is welcome. They may not provide fact models, but some means of visualizing the interplay between terms is already being proposed by one vendor.
Fact Models and the Business SME
Then there is the assertion, made by some promoters of TDM, that fact models are unsuitable for business SMEs. Fact Models are supposedly too IT-centric and off-putting to business users. Is a fact model really a ‘business facing’ artifact, will business SME’s eyes glaze over at the sight of it?
In our experience this depends on the client: many get huge value from it and some do not. Once you get to know your client, you must make the decision about which tools in your toolbox are appropriate to their preferred way of working, while at the same time gently educating them. Our experience has been mostly very positive — when clients see the value of business-centric fact models, they are happy to use them.
Our experience indicates that the extra facility offered by the fact model is useful for many clients and we would tend to disagree with the implication, made in the TDM forums, that fact models are now unnecessary, or wholly derivative of the TDM glossary and decision model. They provide another view and they have their uses.
The decision modeler should be aware the proclivities of their client and use the fact model where it is appropriate, while at the same time minimizing the documentation burden. Tools can help toward this end. Modelers should not be afraid to structure their glossaries with the same degree of integrity and structure as elsewhere in TDM.