Where do you start? Do you upload a predefined object model? Or do you develop it with your decision logic?
Object Model First
It is our experience that, in the vast majority of the projects, object models already exist. The IT organization defines and maintains them. This makes perfect sense, since the object model is the contract for the decision service. We need to know all features of the application before processing it. The invoking system also needs to know where to find the decision and all related parameters.
The object model, or data model, or schema, really defines the structure of the data exchanged with the decision service. Some sections and fields will play the role of input data. Some will be output. The business rules will determine or calculate those.
In our world, at Sparkling Logic, we call the object model the form. When you think about the application as data, the form represents the structure specifying what each piece of data means. For example, Customer Information is a section; and first name, last name and date of birth are fields in this section.
While business rules are based on these fields, the field definition typically belong to the system. The system will produce the transaction payload, aka the transaction data, and receive it back after the rules execute and produce the final decision.
To summarize it, the ownership of the object model lies with the IT organization, since they are responsible for making the actual service invocation.
Modifying the Object Model
Does that mean that we cannot make changes to this object model? Absolutely not. Augmenting the object model with calculations and statistics is expected. The customer info will likely include a date of birth, but your business rules will likely refer to the age of the person. It is common practice to add an Age field, that is easily calculated using a simple formula. More fields could be added in the same fashion for aggregating the total income of all co-borrowers, or for calculating the debt to income ratio.
In most systems, these calculations remain private to the decision service. As a result, the IT organization will not even know that they exist.
Quite a similar mechanism exists to add business terms to the form. In order to complement your business concepts in the form, Business terms constitute an additional lingo that is shared across project. for example, you might want to define once and for all what your cut-off values are for a senior citizen. Your business term could even specify cut-off values per state. Your rules will not have to redefine those conditions. They can simply refer to the business term directly: ‘if the applicant is a senior citizen and his family status is single’. Each project leveraging that form will reuse the same terminology without having to specify it again and again.
Like calculations, business rules can use business terms, but IT systems will not see them.
It eventually happens that variables might need to be created. That’s okay. There is no issues with introducing intermediate calculations in order to simplify your business rules. Although these fields will be visible to IT, they can be ignored. As intermediate variables, the system might not even persist these values in the database of record.
When is the Object Model provided?
It is ideal to start your decision management projects with an established object model. Uploading your data is most definitely the very first step in your project implementation. This is true regardless of whether you have actual historical data, or are building data sample for unit testing your rules as you go.
The reason you want your object model established prior to writing rules is quite simple, frankly. Each time you modify the object model, rules that depend on the affected portions of the object model (or form in our case) will need refactoring.
Granted, some changes are not destructive. If that is your case, you can absolutely keep extending your object model happily.
Some changes only move sections within the form. As long as the type of the affected fields remain the same, your rules will not need rewriting. The only exception being for the rules that use full path rather than short names. If you rule says “age < 21”, you will be okay whether the age field is located. If your rule says “customer.age < 21”, then you will have to modify it if age moves to a different section.
And finally some changes are quite intrusive. If you go from having one driver in the policy, to multiple drivers, all driver rules will have to account for the change in structure. You will have to decide if the age rule is applicable to all drivers, any driver in the policy, or only to the primary driver. This is where refactoring can become a burden.
The more established the object model is, the better suited you will be for writing rules.
One point I want to stress here too is that it is important for the IT team and the business analyst team to communicate and clearly set expectations on the fields of the object model. Make sure that:
- Values are clearly documented and agreed upon: CA versus California, for example
- You know which fields are used as input: if state appears in several addresses, know which one takes precedence for state requirements
Sorry for this quick tangent… This is where we see the most of ‘rules fixing’ spent!
When do Rules own the Object Model?
It is rare, but it happens. We see it mostly for green field projects. When the database of record does not exist, and there is no existing infrastructure, new projects might have the luxury of defining their own object model. When there is none, all options are on the table: have data modelers define the object model, or proceed with capturing it as you capture your business rules.
In these cases, we see the DMN standard (decision modeling and notation) leveraged more often than not. As business analysts capture their source rules in a tool like Pencil, its glossary gets assembled.
For those of you not familiar with DMN, let me summarize the approach. The decision model representation guides the business analyst through the decomposition of the decision logic. Let’s say that you want to calculate Premiums. You will need to establish the base rate, and the add-on rates. For the base rate, you will need to know details about the driver: age, risk level, and location. You will also need to know details about the car: make, model and year. Your work as a business analyst is to drill down over the layers of decisioning until you have harvested all the relevant rules.
The glossary is the collection of all the properties you encounter in this process, like age, risk level, location, model, make, year, etc. Input and output properties are named in the process. You can also organize these properties within categories. When you have completed this effort, your glossary will translate to a form, your categories to sections, your properties to fields. In this case, your harvesting covers both decision logic and object model.
Final Takeaway
Besides minor additions like computations and variables, the object model is by and large owned and provided from the start by the IT organization. Only green field projects will combine rules and data model harvesting.
For further reading, I suggest checking our best practices for deployment and how to think about decisions.
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
