Decisions can require Input Data, and this is shown with a solid arrow. Knowledge Sources act as an authority for a Decision, and this is shown with a dashed line/circular arrowhead.
Every input data will ultimately have a data structure and each element in it is defined with a data type. DMN calls these Information Items and Information Types. Information Items act a lot like an XML document in that they can contain additional Information Items and can be singletons or sets. Information Types can have validation logic to enforce specific values and ranges etc. as well as a base type like number or text. This means that an Input Data object can represent a single piece of data – like a date of birth – or a complex data structure with sub-structures and lists like a credit bureau report. As long as the data structure is defined, DMN allows you to group your Input Data however you like.
In general, though, the most useful way is to use logical entities from your data model. Each Input Data represents a single entity and is reused whenever a decision needs fields from that entity. You might split very large entities into several pieces, to make it clearer which groups of fields are used in which decisions for instance, This doesn’t need to be a hard and fast rule, but it does seem to work best as your SMEs generally understand the entities, a given entity is typically relevant to a coherent set of decisions and data normalization means that each is well structured.
One of the powerful side effects of building a decision model is that you can show which of your data entities is used in each decision. The requirements from your various diagrams will enable you to generate views like this one that show all the ways in which Customer data is used in this decision model:
A note on APIs
When data is passed into an API, it can be easy to think of all the data as input data. Often this is true but not always. Sometimes data is being passed in that was decided earlier – either by a person or by another system or service. In this case, the API is populated with decision outcomes as well as input data. These should be modeled as decisions not input data. If an upstream decision service calculates your credit rating and passes this to another decision service, the credit rating is still a decision. It doesn’t become input data just because you are passing it to a service. Decision Service definitions allow both input data and the results of other decisions to be passed in.
Similarly, APIs often contain data elements that are not needed in the decision model. This might be a legacy of a redesign or to allow the decision to evolve in the future without needing to change the API. This data can and should be modeled as Input Data but you should resist adding requirements to it unless they exist today.
Rule Sources, Policies, Regulations and more
Building a decision model involves analyzing rule sources such as policies and regulations as well as requirements documents, SME expertise, best practice guidelines, training materials and more. Any or all of these can be modeled as Knowledge Sources. Generally, it is worth tracking two kinds of knowledge sources – permanent ones and temporary ones.
Permanent knowledge sources are those that will continue to exist once the model is finished. A credit risk policy or a fair lending regulation will continue to be relevant even once you have a decision model of the decision. These documents will have their own update cycle and knowing how they impact the decision model can help with impact analysis and with regulatory compliance. They should be linked to the decisions they impact– those whose logic is based on them – using authority requirements so that this impact is clear moving forward.
Many of these permanent knowledge sources are large and complex. A network of knowledge sources can be developed using authority requirements so that, for instance, a large regulation can be shown as consisting of several chapters or that a policy is based on a regulation. This can improve impact analysis in situations where policies and regulations are complex. For example, using an example from the book I wrote with Jan Purchase, consider the Federal Reserve Bank regulatory specification 294 Advanced Best Practices controlling the disclosure of liquidity movements (“FED 5G”). This consists of different sections which address how assets are defined, counterparties are classified and how disclosures are made. The latter is further divided into liquidity inflow, outflow and supplementary reporting sections. These can be shown in a hierarchy like that below. Decisions can be linked to the whole regulation, as here, but can also be linked to specific sections or subsections where that makes more sense.