Business rules free companies from the traditional software development life cycle (SDLC), but it does not mean that they get created and deployed without any governance. In my experience, business rules are actually tracked with a finer grain of control. The traceability of these decision logic changes is a huge benefit in the long run. Let me illustrate a few ways that Decision Logic Lifecycle Management is actually used and leveraged in real life.
Starting with low level versioning
This is the most widely available level of traceability. The reason you absolutely need versioning for your business rules is a no-brainer: how would you feel if someone mistakenly deleted all of your business rules? That is why we use versioning in source code management systems, and we even use it in document management systems. We want to make sure that these assets are protected, and if changes happen, we want to know who made these changes, and if bad changes happen, we want to be able to revert back to the original version.
I will have more to say on versioning in a following post. But I would like to focus on more interesting aspects of lifecycle management: how we safely get the decision logic from the authoring environment to Production.
Promoting business rules to the next staging environment
I have seen rare instances where business rules changes happened in the Production environment, but let’s be realistic, you most certainly want to have at least a couple of different environments to separate authoring from deployment. The business rules that you create or modify should be tested before they migrate to your Production systems. IT would not let you make these changes live anyway.
There are a couple of ways that organization go about publishing their business rules:
- Incremental approach
- Packaged approach
In an incremental approach, you can isolate the few rules too add or change, test them, and deploy them independently of the rest of your project. For example, you can use tags to identify these business rules, and use a filter to push only the items with that flag to the current state of the project in your target environment. The benefit of using this approach is that you could work on a number of changes — let’s say 20 rule need to be modified or added — and only select the 6 or 7 rules that are ready to be published (after testing and approval). It does not require the rules writer to work sequentially on these changes.
In a packaged approach, the entire project is tested as a whole, and migrated as a new ‘deployment package’. I am not specific here on what I mean by deployment package as it might be a slightly different concept from architecture to architecture. The idea is that you end up with a new project in your Production system that contains the old rules and the new rules alike. The benefit is that it allows you, or IT, to run all QA tests on what is effectively going to be deployed.
Regardless of your preferred approach to deployment, the publication operation can be tied to automated testing, simulation, and manual approval as needed. This way, you can always review who approved the changes and the associated reports.
Rolling back to the last ‘good’ version of the rules
While changes are tested and reviewed ahead of time, you may occasionally want to backtrack your changes in Production. Why? Let’s say that you only tested the rules based on expected value, and did not have the opportunity to run a simulation with business metrics. The business performance may not align with your business objectives, sending too many applications for manual review as I have seen in a real life project. It might be also because of external changes (new data format for example) that end up being incompatible with the new business rules. There are many reasons why you would want to revert to a previous version of your business rules.
One way to do that is to go back to your authoring environment, and use your low level versioning mechanism to resurrect the last version of the rules in question, and publish them again. While this technique has been used for years, it requires a lot of discipline to make sure that you find and update all the business rules in question, and only these.
Another way to do it is to leverage the publication mechanism. With an incremental approach, it is a little harder. But if you used a packaged approach, you can target the last ‘good’ package, and redeploy it. This has been used more frequently historically because it gives you a fast access to a fully tested package of your business rules.
A better way to handle this ‘time travel’ is to use the notion of releases. For each project, you can create a view of your project, frozen in time, and refer to it for execution. The beauty of this mechanism is that it allows you to deploy different releases in Production simultaneously. Why would you do that? I see two primary use cases. First of all, you may want to roll out the new rules to only a subset of your overall Production transactions. By using releases, you can execute against release 8 most of your transactions, and route a selected sample to release 9. Whether you are doing it as a safety measure or a champion / challenger experiment, you do have this flexibility using release management. The second scenario relates to a cascading environment. If you have different clients, internal or external, of these business rules, you may need to allow them time to upgrade to the new release. For a period of time, you might need to support the concurrent execution of release 8 for your lagging clients, and release 9 for the clients that are ahead of the pack. Once again, release management allows you to run multiple releases of the same project concurrently. I warn you against trying to do that by duplicating your rules though. That might be another topic of this blog.
The nice thing about lifecycle management, and the many techniques I just described, is that they are all compatible. You do not have to rely on a single mechanism, you can layer them per your specific needs and combine the benefits.
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
