Last week I posted an article on Using Decision Requirements Models to scope BRFplus and NW DSM. This introduced the idea of Decision Requirements Modeling as a way to scope your SAP business rules project, whether you are using BRFplus or the new SAP NetWeaver Decision Service Management product.
In the article I referenced a great post by lee.chisholm. Lee followed up his article on how to scope BRFplus projects with a series (Parts 1,2,3,4, 5 and 6) on how to Blueprint a BRFplus project. This was a great series so I am going to reference it as I walk through how Decision Requirements Modeling, and our product DecisionsFirst Modeler, helps you with Blueprinting. Even more than in scoping, using Decision Management and DecisionsFirst Modeler in the Blueprint phase offers great benefits.
EDIT: Here's a recording of our webinar: Managing and Evolving Decisions with DecisionsFirst Modeler and SAP NetWeaver Decision Service Manag....
There's also a great paper on Social Benefit Determination with SAP NetWeaver Decision Service Management available on SCN.
In part 1, Lee begins by pointing out that you need the right tool for the job. Our experience is that whatever tool you pick for blueprinting your rules, beginning with a Decision Requirements model will make all the difference. Because we are starting Blueprint with a live database containing a decision requirements model, not just a piece of static documentation, we have access to our scope in a form that we can evolve and extend as we need to.
We have:
- The business objectives and metrics/measures that the project is targeting.
We have these described and we have them linked to the decisions that will contribute to meeting these objectives or improving these metrics. As we continue with our Blueprint effort we can refine and extend the metrics if we learn more and we can keep linking each new element of our understanding back to these original objective. - High level decision points and an initial decomposition.
This shows us which decisions we are going to implement and how we think those decisions will be made. As we continue with the Blueprint we are going to add a lot of detail to these models. Because the model is live and in a shared database accessible for anywhere, we will be able to keep adding to and extending our model. - Information sources for each decision
These show us what information each piece of our decision-making will require and give us the ability to effectively scope and manage our terminology and vocabulary. - Knowledge sources for each policy, regulation, expert or analytic
These show us where we are going to harvest our rules from.
All of this information is cross-linked, ensuring we can navigate from one of our project objectives to the decisions that have an impact on it to the knowledge sources that contain the rules we need for that decision.
One aside. Our experience is that in large, complex organizations there is a huge risk for any BRFplus or NW DSM project if it does not consider the structure of the organization and organizational dynamics. DecisionsFirst Modeler allows you to specify the organization structure, down to the role level, and then map this to your decision requirements. You can show which organizations care about which of the project's objectives, who thinks they "own" a particular decision, who makes a decision and who else cares. Understanding these dynamics, being able to make sure that the organizations driving or using a decision agree on the best way to measure that decision, seeing mismatches between the decision structure and the organization structure will help make sure you address these concerns during the Blueprint phase rather than simply coming unstuck during implementation.
In part 2 Lee discusses the importance of vocabulary in building business rules. Many projects will have a fairly fixed vocabulary as the objects involved are those in a particular system or part of a system. Regardless of how fixed or known your vocabulary is it is definitely worth agreeing on it and coming up with business-friendly labels for the objects and attributes you are going to be manipulating. In DecisionsFirst Modeler you can import a list of business objects as Information Sources so that you have a clear link from the Decision Requirements Models to the information being manipulated. When you build your vocabulary you can tie it back to these same objects and use the URL link from each Information Source to link to the right set of vocabulary definitions. Thus the Student Information Source shown above would be linked to, say, the Wiki page for Student where the details of the terminology as it relates to student information are defined. Alternatively the URL could link to your master data management system, to existing documentation or to an entity diagram - whatever works best for you.
Next up, as Lee discusses in part 3 is collecting or harvesting business rules. To successfully implement decisions you will need to develop an accurate specification of the business rules in those decisions, what Lee calls a rulebook. When it comes to developing a rulebook a Decision Requirements Model really helps. Just like a good table of contents helps you navigate a real book or a Word outline helps you navigate a large document, a decision requirements model gives a structure to your rulebook. If you use tools like Word or Excel, even a wiki or a rulebook management system, while focusing on a single large scope you end up trying to boil the ocean. You can create what we call "a big bucket of rules." Lots of rules, each individually accurate and executable, but managed in a large bucket with minimal structure – perhaps tabs in an Excel spreadsheet or sections in a wiki.
In contrast DecisionsFirst Modeler allows you to focus on decision modeling first. This means you can take a top-down approach to your rules. You can specify your decision making in an increasingly granular way, laying out the sub-decisions, adding specificity to your decision-making at each stage. Once you have a solid break down of your decision-making you can then link each specific sub-decision to a small set of rules – just the rules required to make that one, small decision.
There is a critical difference between a Decision Requirements Model and the approach Lee lays out. In a Decision Requirements Model you are specifying dependencies that imply sequence: if a decision is identified as requiring another decision then that decision must be made first. In our example, for instance, we must decide what costs a student is incurring and what resources they have before we can decide how much money they need. At execution time we will probably make one of these to decisions before the other but that is a design-time choice and NOT a requirement. By using a dependency-based approach rather than a flow-based approach we specify the actual dependencies while leaving ourselves the maximum amount of design/implementation flexibility. Experience shows that this works much better.
Doing rule harvesting based on a defined Decision Requirements Model has a number of benefits:
- It focuses your rule harvesting and design on a series of small areas, helping you get all the rules defined for that area.
It's much easier to tell you are 80% or 90% done with the rules for something focused like "What costs is the student incurring" than for something like "Should we give this student money" - It clearly defines both the inputs (information available) and the actions the rules can take (allowed answers)
These are defined for each decision so you can easily tell when the rules you are finding are drifting off topic and refactor them to the correct decision. - It allows a different degree of precision in different areas
Decisions that are highly regulated might be analyzed very carefully while a decision that is constantly updated by the marketing department might be analyzed more lightly, focusing on some solid example rules only. One size of rule harvesting does not fit every situation. - Vocabulary and terminology is very important when writing rules and a strong context really helps.
Knowing that a set of rules implement a decision that uses specific information, specific business concepts, represented as Information Sources focuses the terminology and vocabulary building you have to do.
As Lee says a tool for managing these rules such as a wiki or rulebook management software is better than Excel primarily due to better vocabulary management and consistency checking. Whether you use a wiki, rulebook management software or even stick to using Excel, all of them work better when they linked to decisions and where the decision structure groups and focuses the rules. DecisionsFirst Modeler allows you to link every decision in the model to a set of rules (or example rules or notes about the kinds of rules involved) using a URI. One user of DecisionsFirst Modeler, for instance, has over 2,300 rules for annuities management defined. But these are linked into a robust decision requirements model with over 250 decision nodes. Each decision is linked with a URI to its own decision table or list of rules and these are straightforward, clear, almost "normalized" sets of rules that are easy to write, easy to validate and will be easy to implement. The decision requirements model in DecisionsFirst Modeler provides the structure and allows for rapid navigation and reuse of the rules.
It's worth reiterating that one of the benefits of a model is the ability to track the goals and objectives of the project and keep these in a database so that everything links back to them. The model allows you to go from objective to decision to sub-decisions and make sure this is staying on track. As Lee notes, it's important to keep your business objectives front and center.
DecisionsFirst Modeler also allows you to link your decisions to the business processes that need them. You can create or import your business processes, add process maps for clarity and define the explicit decision-making tasks that are linked to decisions defined in the model. This is critical as it is decisions, and not rules, that show up in a business process. By focusing the process on the decisions it needs made and then describing those decisions in detail in a requirements model, you keep the process clean and focus business rules on decision-making.
This avoids a couple of key problems that companies run into when thinking about processes and rules. First it avoids the problem of smearing business rules through the process like peanut butter, focusing instead on specific decision-tasks. Instead of lots of tasks in the process with just a few rules each, with trying to use the process model to capture decision making as well as processing and then hanging rules on to the resulting over complex structure, you create a clean separation. Second, as noted above, you describe decisions in terms of their dependencies, something much better suited to declarative rules, rather than with a sequential process-oriented model.
In Part 4 Lee discusses business rules harvesting in more detail. This is all good stuff and I would just reiterate that harvesting rules is much easier when have a Decision Requirements Model. It gives you a clear focus, you know what the information involved is and where the rules are coming from.
You also know what the allowed answers are, keeping rules coherent. For instance we might say that we need to decide if we need additional documentation for the student. Such a decision clearly should have a yes/no answer. However as we write rules it is clear we want to specify the rules for which documents are required. So the decision to which these rules relate is really "which documents are required for this student." We can the either refactor our Decision Requirements Model to use this decision instead or we can add a new decision relating to which documents are required and integrate it into the model, perhaps like this. Note that when we add the new decision we also move the knowledge source to reflect the changed model.
You can also identify business events that cause some decisions to be re-made – for instance the decision Does the student need to send in documentation might be part of the overall decision AND made in response to an event like "piece of documentation received."
In parts 5 and 6 Lee lays out the things you need to track and wraps things up. A few last comments on how a Decision Requirements Model changes things here:
- Knowledge sources give you rule source documentation
- Business process mapping shows you the associated decision-making tasks
- The decision requirements model itself shows you the top level decisions that will need to be in functions and the initial decomposition shows you the likely rulesets
- Any additional information can be linked using URLs to a wiki, Excel document or other requirements tool
- You can document which organizations and roles should be involved to make sure you get the right people engaged both to find the rules AND when it comes time to deploy them
- You can model where your rules fit in terms of your process, event and system landscape
- and much more.
Plus of course DecisionsFirst Modeler is multi-user, you can see who is working on what, what was changed recently and comment on anything.
EDIT: Here's a recording of our webinar: Managing and Evolving Decisions with DecisionsFirst Modeler and SAP NetWeaver Decision Service Manag.... And remember you can evaluate DecisionsFirst Modeler for free - just sign up.
- SAP Managed Tags:
2 Comments
