How to Blueprint Your BRFplus Project: Part 6

[Former Member]

In my final blog on blueprinting your BRFplus project I want to finish by addressing the other considerations you must take before starting to harvest and document your business rules.  Ultimately I want this series to not only cover how to formally document rules in a rulebook, but to also how to link the blueprinting process into realization, resource considerations and other things.

Who?

What I have been describing in this blog series is how to take the business rules approach with SAP and BRFplus.  I have not yet touched on what kind of people or skills are required to make this approach work yet though.  In actuality, a lot of the work I have described to you right now requires no knowledge of SAP at all.  One of the goals of the business rules approach is to understand the rules in the language of the business and not only in terms of SAP.  This means that the blueprinting process is much more balanced between business and SAP discussion.  Many projects I have been on have made blueprinting an activity where only the very minimum amount of business knowledge is collected so that SAP can be implemented, and they forget about what happens in the long term.

I also see a lot of people today positioning BRFplus beside technical tools such as ABAP WebDynpro and PI, but this is fundamentally wrong.  While BRFplus can certainly be used to implement many system or technical rules, it's use case is first and foremost for implementing business rules which naturally leans closer to functional than technical.  When I get into my blogs on realization we'll touch more on this subject.

All of that said there are in general two types of analysts required during the blueprinting of a BRFplus project.  One is a business analyst who can understand business people and facilitate the harvesting process, and the other is an SAP analyst who can map the logic being harvested from the business into BRFplus.  If either of these skills is missing there will be trouble later.  If business analysts with no SAP or BRFplus experience do all of the harvesting then the rules will likely look great and represent the business perfectly but they will be impossible to implement within SAP.  If SAP analysts with little business analysis experience do all of the harvesting then the rules will probably fit into SAP really well but they won't actually represent the rules of the business.  A balance of business and SAP skills is required to make your rules project a success.

Do Your Rules Time Travel?

When documenting business rules we usually default to the happy path for initial understanding.  This usually entails analyzing business rules from a present-day perspective only.  I.E. How much money is a student eligible for based on our rules today?  However in many businesses, the rules need to be able to fire off in their past state as well.  Take the following example:

Last year a student applied for a student loan and says they are single.  The loan organization grants them $10,000.00 dollars based on their financial need.  However, an auditor discovers today that the student was actually married and didn't tell the loan organization.  This means they got a lot more money than they should have.

To remedy this situation the business rules must be executed against the student's application again except this time considering their marriage.  To do this correctly we need our rule engine to fire off last year's rules against the student again.  The reason we need to use last year's rules is because the current rules might not be the same as they were last year, and to make a fair recalculation of the correct loan amount the exact same rules must be available.

Technically speaking BRFplus has a few options to allow this (for a later blog), but the expected time traveling behavior must be documented in the blueprint before getting into realization.  Your rule repository must also support versioning in order to see the changes in rules as they mature over time.

Logging Decisions

When a business process executes, there could be hundreds or thousands of business rules executed.  It's important to know up front how the business wants to keep track of the decisions being made by the rule engine.  Is a simple message log sufficient, or do decisions need to be stored in a more reportable format?  In some cases decisions must be stored in a data warehouse so they can be used for predictive analytics later on.  In early business rule projects most organizations will not be too advanced with their decision logging as they are just coming to terms on how to optimize the benefits of their rules approach.  However over time when the business becomes more mature with rules the use case for advanced logging will emerge.

Rule Prototyping

So we have documented a bunch of business rules, but how do we know if they are even right?  Some business rule methodologies suggest you take an agile approach which involves building the rules in the system as they are harvested.  This would allow you to see quickly what works and what does not so that you don't harvest a bunch of rules which are impossible to implement.  At the same time you will likely have a lot more throwaway work since the understanding of business logic in the beginning will definitely change before you exit harvesting.

A simpler way to validate your business rules is to just model them in spreadsheets while harvesting.  This is a business friendly way to walk through the harvested logic, without having to get into the system yet.

A middle approach between both of the above would be some rule prototyping in BRFplus during the harvesting process.  This would still involve more effort than using spreadsheets, but it would find more roadblocks since you are in the system building executable rules.  Of course, the prototyped rules will almost certainly not match final state and prototyping takes a lot of effort too.  Experience shows that a certain amount of prototyping is always required, and a comfort level between spreadsheet validation and prototyping must be reached during blueprinting.

Business Readiness

Taking the business rules approach is a very large endeavor for a project or organization.  An unfortunate trend in almost all rules projects I've seen though is a shortage of subject matter experts (SME's) who really know the rules and can participate in the rule harvesting process.  Resource agreements on the business side should be made well in advance of a rules project to ensure there the required people are always available to harvest the rules.  The SME's should also be very clear on what the business rules approach is before beginning the harvesting process.

Once we finish creating our shiny new rulebook with everything we need for realization to begin, does that mean we should jump into BRFplus and start cranking out rules?  Absolutely not.  Before jumping into realization the business has to spend time making sure they totally understand the rules they harvested.  In many cases the blueprint process will not capture every single rule.  This means it's important for the business to take their time to review the harvested rules and ensure they are comfortable and on board with everything before proceeding to realization.

Landscape Considerations

As realization gets closer the discussion of server landscape must happen.  With BRFplus there is currently two ways to deploy and manage your rules.  One way is to model your rules on the same server as the SAP application, and the other is to create a separate system which is BRFplus only.  The benefit to the latter is that you can upgrade the system as much as you want to get the newest version of BRFplus, but you lose out on performance, integration and you assume some more risk with system outages.  Currently experience shows that the best practice is to treat BRFplus like customizing and have the rules live on the same server as the business application.

Please note however that there is some big changes coming to BRFplus in 2012 which may totally change the landscape considerations for BRFplus.  Keep a look out for carsten.ziegler blogs on this.

Future State Change Process

Finally we need to consider the desired future state change process.  Most likely right now a user submits a ticket to a help desk, and a programmer grabs the ticket and begins changing code or customizing in the system.  By taking a business rules approach however the business takes a bigger role in changes than simply submitting a ticket.  Changes now will likely begin with the business updating the processes and rules documentation (which they are the owners of now).  Once the changes are documented in the process and rule repository they can be implemented in the system.  While there will be variations of this for different businesses, the business people will always take a much bigger role in rule changes and ownership after go live.  Having the business and project team understand the desired change process after go live will help reinforce the goals of the project.

In Summary

So at the end of blueprinting we should have a nice shiny new rulebook with all of our business rules functionally and technically documented and linked back to the calling business processes.  The subsequent implementation and maintenance in BRFplus will now be highly agile as our rules are documented in a very similar fashion to how they will be implemented.  Most importantly the business now plays a bigger role in the rule creation/change process and has taken back ownership of logic which is rightfully theirs.

Stay tuned for my next series on how to realize your BRFplus project, where you will see how to use your rulebook to create beautiful rules in BRFplus.

How to Blueprint Your BRFplus Project: Blog Index

• Part 1: Selecting a rule repository for documentation
• Part 2: Vocabulary and relationships
• Part 3: Harvesting rules from business processes
• Part 4: Rule decomposition
• Part 5: Business rule metadata
• Part 6: Other considerations for blueprinting