For decades, writing rules has been an abstract exercise. Business Analysts review requirements. They write the corresponding logic. If they are lucky, there is a testing infrastructure they can push the rules to. Often, they have together code for test cases, or wait for QA to catch possible issues. There is a better way that involves bringing data in early on.
The primary objective of a data-centric approach is to provide immediate feedback. As you look at one transaction at the time, you can see what decision and intermediate decisions are made. For example, an insurance application might be too aggressively turned down due to a somewhat-poor driving record. Reviewing this result, you can fine-tune your rule right-away. After adding the proper safe-guards, that same application might end up approved with higher premium, rightfully-so. This quick turn-around is key to quality rules in your decision management projects.
When data contains expected results, this data-centric approach delivers dividends. Not only do you get immediate feedback, but the system can filter out test cases for you. By doing such, your attention goes instantly to unexpected outcomes. You can focus on fixing this mismatched transactions. Consequently, your precious time becomes more productive. When your regression tests are fully passed, QA can take over. This process should, in theory, reduce significantly the number of iterations between QA and the rules writers.
Better quality rules mean greater compliance with requirements, but not only. As a trained underwriter or credit officer, access to your decision logic gives you the opportunity to experiment. In absence of data, tweaking score limits will not tell you much about the improvement you achieved in doing so. Alternatively, reports based on historical data can estimate whether the change looks like an improvement for your key performance indicators (KPIs), or a step-back.
Keeping track of these KPIs, in your sandbox or in Production, will allow your organization to deploy more competitive strategies. In your sandbox, you can prepare one or more candidate strategies that show promising value. Simulation in that fashion will set expectation processing all transactions in your sandbox. Eventually, Production time will establish a verdict. When experimenting using champion / challenger, you can actually compare their true value. One fraction of the live traffic will be routed to each candidate strategy. Tracking PKIs in this setup allows you to measure how well each one of them does for its own segment.
From Data to Rules
Ultimately, data can serve you as a source for business rules. There are two fundamental approaches for that. On one hand, you can expose the data to subject matter experts, and leverage data for rules elicitation. On the other hand, you can expose the data to machine learning algorithms that can turn you tagged data into rules.
For rules elicitation, experts review transactions. They highlight for each transaction what is outstanding. In one application, the applicant is under-aged. The expected action would be to mark him or her as ineligible. In another application, an applicant with multiple DUI offenses should be declined. This knowledge turns into business rules. The more comprehensive the data set, the more ‘gold’ SMEs can mine.
For rules induction, we need to have enough data that have been marked with the trait we want to predict. For example, as fraud occurs, account holders complaint about fraudulent payment transactions. Having a mix of fraudulent and legitimate transaction, machine learning algorithms can pinpoint a set of rules that will identify fraudulent activity. Fraud experts have the opportunity to massage these rules to improve their performance.
Regardless of the path you take, writing documented rules, eliciting or inducing rules, they will all end up equally in your decision services. Data will make these rules more accurate, more powerful.
To learn more about technical details associated with data integration, take a look at Carlos’s thoughts in his technical series.
Business rules provide the flexibility and agility that systems need. By definition, they enable business analysts to adjust the system’s decision logic to ever-evolving business direction. Due to competitive pressure, business regulations, or executive direction, business rules keep adapting. The art of capturing rules requirements dictates the success of the rules implementation to follow.
Rules Requirements are Requirements
As a Product Manager at heart, I value a nicely written PRD (Product Requirement Document). Many articles provide guidance on requirements gathering, and the golden rules to adopt for success. In particular, I like Duncan Haughey’s concise take on the subject. Above all, I cannot stress enough the value of focusing on the problem rather than the solution. Engaging stake-holders or subject matter expert from the start is paramount. Kuddos to him for putting it into writing.
In addition, this simple golden rule will keep you safe in such efforts: “a good requirement is SMART”
Overall, requirements gathering for rules and for systems do not differ that much. Yet, subtleties make those two exercises different enough. Let me emphasize some key aspects.
Best Practices in Source Rules Gathering
Rules requirements are also called “source rules” in our industry.
Typically, source rules contain lots of details
A PRD for a system could be long, yet each requirement is typically relatively small. For example, think about all aspects of a function such as “print”. You need to describe what it does, how it is engaged, what limitations there are… While you could write a full page on the subject, it is likely that you will not write much more than that. Keep in mind that requirements are meant to be specific. One requirement will not cover the full “underwriting” component of a policy admin system. With that in mind, we should see decently short descriptions of all those aspects for one functionality.
In contrast, business rules tend to contain lost of details. While not all decision steps in your reasoning contain that level of variations, we often see steps that include hundreds if not thousands of variations. For instance, rates could be broken down by age, gender, state, risk level. At some point in time, source rules will overflow your PRD. Reference spreadsheets or external documents at this point.
Most noteworthy, these tables are bound to evolve over time. By keeping them separate, you make it easier for the experts to provide iterations as needed. You might also accelerate your rules implementation by importing them as is. This webinar recording shows how spreadsheets can import natively.
Structure is your Friend
Because decisioning is complex, source rules are not always straight-forward to organize as you capture them. Business Analysts excel at structuring information as they go. Yet, source rules might challenge their abilities if they are not careful. Due to the mere volume of source rules, any human being could get trapped.
Most likely, this is the one pitfall I encounter the most often. Starting with one source rule, one thing leading to another, the source rule turns into this uber-requirement. For example, you might start documenting an eligibility rule. The age limit varies per state. Then again, some states are not eligible at all. But, if the applicant is not eligible for this product, we could suggest a cross-sale offer. If eligible for multiple cross-sale offers, how do you decide which offer is the best?
One simple age requirement turned into a mesh of eligibility and cross-sale logic. It is important for the business analyst to structure these requirements into the proper buckets as they are encountered.
Thanks to its underlying methodology, the DMN standard (Decision Model and Notation) guides you through this decomposition. You can learn more on how create decision models using Pencil in this recording.
Not using DMN tooling, business analysts must remain aware of the danger. In the end, it only takes attention to avoid spaghetti source rules.
- Consider adopting a different approach to requirements gathering for source rules
- Keep the sources rules that are maintained in a spreadsheet separate
- Structure, structure, structure… Organize your sources rules as you go
A little while ago, we hosted a webinar about “why Decision Management?“. However, including the business case presentation alone seemed somewhat incomplete. Indeed, we also needed to focus on ‘how’. As a result, we created a presentation that covered both aspects.
In this blog post, I will focus on the key takeaways of the presentation. However, I encourage you to watch the video, especially if you are a manager, new to decision management technology.
To begin with, let’s define what we mean by Decision Management.
Decision Management is a Discipline
supported by Technology
for Capturing, Automating and Improving
Large-Volume Transaction Processing
for the purpose of making Decisions
Capture Decision Logic – Why and How
The typical audience for Decision Management tools includes mainly Business Analysts. It happens that people ranging from IT to Business could use these tools. Nevertheless, Business Analysts (BA) remain the main users. Their role is to translate business concepts into business requirement documents. While convenience leads to known entities such as Word and Excel, there is value in leveraging DMN Tools. Not only do they guide BAs through the discovery process, but they also give you a leg up when implementation comes.
When projects do not allow for a discovery phase, or when expertise is solely in the heads of experts, other capability in the decision Management world can lead to an effective elicitation. RedPen mimics the work of the expert making manual decision, and capture business rules in the process. Of course, you will need and want to author business rules in other ways too. For example, one ruleset might be better represented as a Decision Tree. That being said, the compliance team may want to review it as a Decision Graph or a Decision Table. In the end, flexibility in representation and approach is the key to a successful project.
Let’s keep in mind that the purpose of capturing the Decision Logic is to automate processing, and to eventually improve the decisions.
Automate Decisions – Why and How
Each organization has a different internal architecture, different mandates. Decision Management technologies make it easy to deploy your decision logic in your architecture of choice. For one company, it might be flexible REST services. For another, it might be the speed of native components such as Java classes or .NET assemblies. For other, it might be the elasticity of a grid framework. In the end, what matters is that the deployment is easy to integrate in that architecture you have chosen.
Architecture is far from being the only consideration though. You must also consider:
- Runtime Performance in all forms
- Release Management
- Deployment Management
With all that in place, you will benefit from automated decision that reduce manual processing, without the nightmare of managing code.
Improve Decision Performance – Why and How
Once decisions are automated, you can fully appreciate the power of Decision Analytics. Not that we recommend you only consider your Key Performance Indicators (KPIs) at the end of the cycle. Of course not. A significant part of their value appears at authoring time. By defining them early, and checking progress as you add more and more logic, you will be guaranteed better quality business rules.
Furthermore, actual historical or pooled data samples can reveal expected business performance through large scale simulations. Finally, when the final outcome might be delayed, Champion / Challenger experiments allow you to test competing strategies. For example, you might make a marketing offer as a result of your business rules. Yet, the distribution of offers is not enough to anticipate future business performance. The key question is whether or not the customer will accept the offer.
In extreme scenario, like fraud detection or marketing offers, you might want to explore new frontier. We have seem incredible business performance by giving machine learning tools to Business Analyst or fraud Experts. In doing so, they complement the work of Data Scientists, and can produce predictive models very quickly, in those incertain circumstances.
In conclusion, Decision Management technologies offer amazing return on investment for your decisions that happen in large volumes.
Integration with data is key to a successful decision application: Decision Management Systems (DMS) benefit from leveraging data to develop, test and optimize high value decisions.
This blog post focuses on the usage of data by the DMS for the development, testing and optimization of automated decisions.
Data is necessary at every stage of the life-cycle an automated decision. In particular,
- during development, you will incrementally build the business logic with simple test cases.
- while testing, you will use more elaborate test cases to fully check the decisions being made. If available, you will use existing production data to check their quality.
- in production, you will use data to make live decisions, and you will leverage the resulting decision data to improve the automated decisions in their next iterations.
Usual DMS implementations focus purely on the logic itself: flows, rules, etc. In some cases, they may allow you to start from a schema for the data.
However, we believe assessing the quality of the logic is as important, if not more, than implementing it according to the requirements. You can only assess the quality of a decision by measuring it. In other words, you’ll need to leverage the decision analytics capabilities of the DMS. And that, in turn, requires data on which to compute these analytics. The more important your decision, the more important that you measure its performance early.
Carole-Ann has written about this in the best practices series: Best Practices Series: Business Testing. The earlier you leverage data, and measure the quality of your decision, the better. If you can start with data, then the definition of the metrics you will use to assess the quality of the logic will put you in a much better position to implement decisions that won’t need to be corrected.
Starting with some sample data
Using sample data
You may start building a decision without any prior data and only referring to the schema for the data. But such an approach does not let you measure the quality of your decision –you can only be sure the decision is consistent with the schema, and consistent with the written requirements. However, that is not enough. The decision may be properly implemented from a technical perspective but totally fail from a business perspective. For example, the logic for a loan application may end up sending too many cases to manual review.
Furthermore, business analysts think in terms of logic on data, not schemas. Having data available to interact with as you develop the logic keeps you in your mindset, and does not force you to change to a programmer’s mindset.
For example, you will have some simple test cases which will help you in the implementation of your first few rules. If you already have lots of data, take a subset that would be relevant for the decision at hand. When test cases are small (in the tens of thousands of records at most), then having the DMS manage the data makes sense –in particular if that data is only used for decision development.
As the construction of the automated decision progresses, you will want to add more data for functional checks. You will then perhaps uncover new cases requiring more business logic. The DMS will ideally allow you to associate multiple such data sets to any decision.
Consequences for the DMS
To support this incremental build-up of the automated decision, the DMS will:
- provide support for managing data sets associated to decisions
- add new data and data sets on the fly
- support data formats commonly used in the enterprise (such as CSV, XML or JSON)
- provide decision analytics facilities to verify the quality of the decision using the data sets
One key challenge with using data is that data changes. We view that as an opportunity –in general, data changes because new data items are discovered and used to enrich it. Those new data items create further opportunities to implement better and richer decisions. It is thus very important that the DMS support easy updating of the data.
Moving forward with large data sets
Using large data sets in simulation and decision analytics
Once the implementation of the automated decision gets to a stable state, you will need to have access to more and more test cases. You will also want to determine whether these test cases are successfully executed.
When large data sets are available, the simulation capabilities of the DMS will verify the behavior of the automated decision, and give you relevant quality information through decision analytics. Usually, you will do this to determine how the decision behaves in general. Different variations of the same automated decision may also compete against one another to find out which variant behaves best. Leveraging these, you can ensure your decision improves in quality, or that your champion-challenger strategy, for example, is safe.
These data sets typically come from your data lakes, potentially fed from operational data. They may consist of large enriched historical data that you keep around for reporting, analysis, or machine learning purposes.
Consequences for the DMS
For such large data sets, you will want the data management to remain in the data lake, data mart or enterprise data environment. Duplicating data management for large data sets is expensive and potentially runs into security or compliance issues.
Thus, the DMS will ideally provide means to integrate with these without copying it or managing it within the DMS. Predefined connectors to databases, or data lakes can be useful for simpler access to existing stores. But a generic means to access data, by means of a web service, or using any standard data format through the FTP or http protocols, will guarantee access to anything.
Furthermore, the data sets can be very large. The DMS will ideally provide a simulation and decision analytics environment where the decisions and the metrics are computed without imposing boundaries on the size of the data set. For example, by providing a map-reduce and streaming simulation and decision analytics facility.
The DMS will:
- provide mechanisms to access enterprise data on-the-fly
- provide scalable simulation and decision analytics facilities that can cope with enterprise-size data sets
The enterprise will:
- manage large data sets relevant to the decision
- use the DMS facilities to leverage these large data sets to verify and enhance decisions
Improving the decision using large operational data sets
Using operational data
When the DMS executes an automated decision in a production system, you will want to collect interesting data points. You will then use them at a later time to determine why some results were obtained. You will also use them to improve these results by updating the decision.
Typically, your enterprise environment will include operational data stores, and data lakes where the data is merged for reporting, analysis and machine learning purposes. The more sophisticated enterprises will also include decision outcome databases and correlate business outcomes with decision outcomes in the data lakes.
Take the example of an application that offers promotions to an existing subscription customer. A good decision is such that its outcome is correlated to the fact that the customer:
- opened the offer
- accepted the offer
- is still a customer 6 months down the road
- has not had negative interactions with tech support in the 6 months following the offer
Using this data, you will be able to keep improving your decision and its value for the business. You can also use machine learning tools and extract knowledge from the accumulated data and incorporate it in your decision.
Consequences for the DMS
The DMS will:
- support storing decision outcomes
- provide mechanisms to access data lakes, operational data stores on the fly
- offer simulation and decision analytics facilities that scale
- ideally support model creation and/or model execution
The enterprise will:
- manage large data sets relevant to the decision
- use the DMS facilities to leverage these large data sets to verify and enhance decisions
This blog is part of the Technical Series, stay tuned for more!
In a later blog post, we’ll cover the various strategies to pass data to decisions at run time, including the retrieval of additional data while the decision executes.
ETCIO (an initiative of The Economic Times) has interviewed KM Nanaiah, country manager at Equifax. The article highlights the details of the tooling that is now available to financial institutions. They will see dramatic improvements in customer acquisition and loan decisioning.
A key benefit of using a Decision Management System is to allow the life-cycle of automated decisions to be fully managed by the enterprise.
When the decision logic remains in the application code, it becomes difficult to separate access to decision logic code from the rest. For example, reading through pages of commit comments to find the ones relevant to the decision is close to impossible. And so is ensuring that only resources with the right roles can modify the logic.
Clearly, this leads to the same situation you would be in if your business data were totally immersed in the application code. You would not do that for your business data, you should not do that for your business decision logic for exactly the same reasons.
Decision Management Systems separate the decision logic from the rest of the code. Thus, you get the immense benefit of being able to update the decision logic according to the business needs. But the real benefit comes when you combine that with authentication and access control:
- you can control who has access to what decision logic asset, and for what purpose
- and you can trace who did what to which asset, when and why
Of course, a lot of what is written here applies to other systems than Decision Management Systems. But this is particularly important in this case.
Roles and access control
The very first thing to consider is how to control who has access to what in the DMS. This is access control — but note that we also use authorization as an equivalent term.
In general, one thinks of access control in terms of roles ans assets. Roles characterize how a person interacts with the assets in the system.
And the challenge is that there are many roles involved in interacting with your automated decision logic. The same physical person may fill many roles, but those are different roles: they use the decision management system in different ways. In other words, these different roles have access to different operations on different sets of decision logic assets.
Base roles and access control needs
Typically, and this is of course not the only way of splitting them, you will have roles such as the following:
The administrator role administers the system but rarely is involved in anything else. In general, IT or operations resources are those with this role.
- Decision definer
The decision definer role is a main user role: this role is responsible for managing the requirements for the automated decision and its expected business performance. Typically, business owners and business analysts are assigned this role.
- Decision implementer
The decision implementer role is the other main user role: this role designs, implements, tests and optimizes decisions. Generally, business analysts, data analysts or scientists, decision owners, and sometimes business-savvy IT resources are given this role.
- Decision tester
The decision tester role is involved in business testing of the decisions: validating they really do fit what the business needs. Usually, business analysts, data analysts and business owners fill this role.
- Life-cycle manager
The life-cycle manager role is responsible for ensuring that enterprise-compliant processes are followed as the decision logic assets go from requirements to implementation to deployment and retirement.
More advanced needs
There may be many other roles, and the key is to realize that how the enterprise does business impacts what these roles may be. For example, our company has a number of enterprise customers who have two types of decision implementer roles:
- General decision implementer: designs, implements the structure of the decision and many parts of it, tests and optimizes it
- Restricted decision implementer: designs and implements only parts of the decision — groups of rules, or models
The details on what the second role can design and implement may vary from project to project, etc.
Many other such roles may be defined: those who can modify anything but the contract between the automated decision and the application that invokes, etc.
It gets more complicated: you may also need to account for the fact that only specific roles can manage certain specific assets. For example, you may have a decision that incorporates a rate computation table that only a few resources can see, although it is part of what the system manages and executes.
Requirements for the Decision Management System
Given all this, the expectation is that the DMS support directly, or through an integration with the enterprise systems, the following:
- Role-based access control to the decision logic asset
- And ability to define custom roles to fit the needs of the enterprise and how it conducts its business
- And ability to have roles that control access to specific operations on specific decision logic assets
This can be achieved in a few ways. In general:
- If all decision assets are in a system which is also managed by the enterprise authentication and access control system: you can directly leverage it
- And if that is not the case: you delegate authentication and basic access control to the enterprise authentication and access control system, and manage the finer-grained access control in the DMS, tied to the external authentication
Of course, roles are attached to a user, and in order to guarantee that the user is the right one, you will be using an authentication system. There is a vast number of such systems in the enterprise, and they play a central role in securing the assets the enterprise deals with.
The principle is that for each user that needs to have access to your enterprise systems, you will have an entry in your authentication system. Thus, the authentication system will ensure the user is who the user claims, and apply all the policies the enterprise wants to apply: two-factor authentication, challenges, password changes, etc. Furthermore, it will also control when the user has access to the systems.
This means that all systems need to make sure a central system carries out all authentications. And this includes the Decision Management System, of course. For example:
- The DMS is only accessible through another application that does the proper authentication
- Or it delegates the authentication to the enterprise authentication system
The second approach is more common in a services world with low coupling.
Requirements for the Decision Management System
The expectation is that the DMS will:
- Delegate its authentication to the enterprise authentication and access control systems
- Or use the authentication information provided by an encapsulating service
Vendors in this space have the challenge that in the enterprise world there are many authentication systems, each with potentially more than one protocol. Just in terms of protocols, enterprises use:
- OpenID Connect
- and more
Additionally, enterprises are interested in keeping a close trace of who does what and when in the Decision Management System. Of course, using authentication and the fact that users will always operate within the context of an authenticated session largely enables them to do so.
But this is not just a question of change log: you also want to know who has been active, who has exported and imported assets, who has generated reports, who has triggered long simulations, etc.
Furthermore, there are three types of usages for these traces:
- Situational awareness: you want to know what has been done recently and why
- Exception handling: you want to be alerted if a certain role or user carries out a certain operation. For example, when somebody updates a decision in production.
- Forensics: you are looking for a particular set of operations and want to know when, who and why. For example, for compliance verification reasons.
A persisted and query-able activity stream provides support for the first type of usage. And an integration with the enterprise log management and communication management systems support the other types of usages.
Requirements for the Decision Management System
The expectation is that the DMS will:
- Provide an activity stream users can browse through and query
- And support an integration with the enterprise systems that log activity
- And provide an integration with the enterprise systems that communicate alerts
There are many more details related to these authentication, access control and trace integrations. Also, one interesting trend is the move towards taking all of these into account for the beginning as the IT infrastructure moves to the models common in the cloud, even when on-premise.
This blog is part of the Technical Series, stay tuned for more![Image Designed by security from Flaticon]
Decision Management and Business Rules Management platforms cater to the needs of business oriented roles (business analysts, business owners, etc.) involved in operational decisions. But they also need to take into account the constraints of the enterprise and its technology environment.
Among those constraints are the ones that involve integrations. This is the first series of posts exploring the requirements, approaches and trade-offs for decision management platform integrations with the enterprise eco-system.
Operational decisions do not exist in a vacuum. They
- are embedded in other systems, applications or business processes
- provide operational decisions that other systems carry out
- are core contributors to the business performance of automated systems
- are critical contributors to the business operations and must be under tight control
- must remain compliant, traced and observed
- yet must remain flexible for business-oriented roles to make frequent changes to them
Each and every one of these aspects involves more than just the decision management platform. Furthermore, more than one enterprise system provides across-application support for these. Enterprises want to use such systems because they reduce the cost and risk involved in managing applications.
For example, authentication across multiple applications is generally centralized to allow for a single point of control on who has access to them. Otherwise, each application implements its own and managing costs and risk skyrocket.
In particular, decision management platforms end up being a core part of the enterprise applications, frequently as core as databases. It may be easy and acceptable to use disconnected tools to generate reports, or write documents; but it rarely is acceptable to not manage part of core systems. In effect, there is little point in offering capabilities which cannot cleanly fit into the management processes for the enterprise; the gain made by giving business roles control of the logic is negated by the cost and risk in operating the platform.
In our customer base, most do pay attention to integrations. Which integrations are involved, and with which intensity, depends on the customer. However, it is important to realize that the success of a decision management platform for an enterprise also hinges on the quality of its integrations to its systems.
Which integrations matter?
We can group the usual integrations for decision management platforms in the following groups:
- Authentication and Access Control
- Implementation Support
- Management Audit
- Life-cycle management
- Execution Audit
- Business Performance Tracking
Authentication and access control integrations are about managing which user has access to the platform, and, beyond that, to which functionality within the platform.
Implementation support integrations are those that facilitate the identification, implementation, testing and optimization of decisions within the platform: import/export, access to data, etc.
Management audit integrations enable enterprise systems to track who has carried out which operations and when within the platform.
Life-cycle management integrations are those that support the automated or manual transitioning of decisions through their cycles: from inception to implementation and up to production and retirement.
Similarly, execution integrations enable the deployment of executable decisions within the context of the enterprise operational systems: business process platforms, micro-services platforms, event systems, etc. Frequently, these integrations also involve logging or audit systems.
Finally, performance tracking integrations are about using the enterprise reporting environment to get a business-level view of how well the decisions perform.
Typically, different types of integrations interest different roles within the enterprise. The security and risk management groups will worry about authentication, access control and audit. The IT organization will pay attention to life-cycle management and execution. Business groups will mostly focus on implementation support and performance tracking.
The upcoming series of blog posts will focus on these various integrations: their requirements, their scope, their challenges and how to approach them.
In the meantime, you can read the relevant posts in the “Best Practices” series:
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.
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.