Adoption of The Decision Model (TDM) is growing and includes major corporations, such as those in the financial industry. As a result, decision models based on TDM are operating in production worldwide on behalf of critical business transactions and some with huge transaction volumes. This means there are organizations and people with several years of TDM experience. However, there are also people and organizations interested in TDM and contemplating how to get started. This article provides insights by which business analysts can plant the seed for TDM.
The TDM business glossary is the home for naming conventions, data types, and domain values that are meaningful to, and defined by, the business audience. Best of all is that resulting decision models are exactly as the business community wants and in the business’s own terminology.
Now we delve into data modeling, one of the core model types. We choose to start here because data requirements are an important foundation for most information technology projects. If you are a business analyst and not doing data modeling today, you should be able to at least read them to validate requirements against what a data modeler has created and our bias is that business analysts can and should be doing “functional” data modeling.
In the real world, good decision modeling is always a balance between science and art. The science is systematic decomposition of a structure (of data or logic) into a set of smaller structures based on the definitions of successive normal forms. The art, on the other hand, is a general decomposition into a set of smaller structures based on factors not related to detecting and correcting normalization errors.
The purpose of this brief article is to provide a simple example on how to link and verify four models: use case, data flow diagrams, entity relationship diagrams, and state diagrams. Note the word verify, not validate. Verify in this context means that the technique is consistent and complete, not that it reflects correct requirements.
Today, it is very common for organizations to use The Decision Model for managing DQ logic. The results are impressive and also deliver unique advantages over other approaches. In some cases, organizations represent DQ logic in The Decision Model as part of requirements deliverables. In other cases, organizations create DQ logic in TDM-compliant software which validates the logic against TDM principles, generates and executes test cases, and sometimes deploys to target technology.
Have you ever been confused about why you were not allowed to do what you tried to do? Been judged or evaluated in a way you didn’t expect? Stumped by the result or decision a business system produced? If so you are a ‘why victim’.
brought to you by enabling practitioners & organizations to achieve their goals using: