Blog – Business Rule Framework

BRF+ at the centre of your excellence

February 26, 2020
by Isard Haasakker

It has been a trend in the past decades to outsource your IT department to external suppliers. This has as a consequence that the employees working at the company running SAP are lacking even basic SAP configuration and development skills. This lack of experience makes the company too dependent on IT service suppliers, not being able to assess whether the solutions proposed are the best solution for the company.

Wikipedia describes the Centre of Excellence as “a team, a shared facility or an entity that provides leadership, best practices, research, support and/or training for a focus area”. I would imagine your company has such a team as well. The question is whether they are mostly consisting of outsourced resources. If so, are you sure this is the most cost-effective approach?

I have seen extreme cases where even the simplest of decisions, like flagging obsolete customers in SAP for deletion, takes several months to get the management approval.

In another example, an external IT supplier is more focused on selling as much billable hours as possible. The company running SAP is then flooded with expensive managers who are competing against each other to show they add value to their client.

The original idea to outsource your knowledge is to save money. The IT service suppliers are very persuasive with making promises where in reality they will underdeliver. But after the company running SAP goes down the outsourcing path, then it takes a lot of conviction to regain control in-house. The Business Rule Framework can be the tool to start the journey back into building your Centre of Excellence.

As from this week, the Michael Management training course “IC 1142: Business Rule Framework (BRF+) Introduction” will guide you in understanding the enormous cost-saving potential BRF+ can bring to companies running SAP ECC or S/4 HANA. There is a secret you need to unlock and some training for your analysts and developers. But that journey will be reaping the benefits very quickly.

The Business Rule Framework is a secret for two important reasons:

BRF+ is hidden within the DSM tool (Decision Service Management), which requires a licence. SAP would, therefore, prefer you to buy DSM when the engine of this tool is BRF+. However, BRF+ itself is free and only needs activation in your system.
BRF+ replaces the need for coding power, supplied by the IT service suppliers, reducing the number of billable hours.

So, do not expect SAP or your IT service provider to promote BRF+, as it is not financially beneficial to both of them.

Instead, listen to the advice provided in the Michael Management course, supplied by an independent consultant who wants your company to save several $100,000 annually on your IT budget.

You can approach this training course as a summary of all the blog posts on this website that is aimed at business leaders and management. They are the key people to realise that you can regain control and become less dependent on outsourced resources.

It takes only one hour to get the message and then you can plan how to implement what you have learnt. Obviously, keep an eye on future blog posts on this website. Also, a hands-on training course will be published on the Michael Management website. This is aimed at analysts responsibly to deign the complex decision making for custom-built solutions in your SAP system. More about that course in a future blog post.

Practical Advice

IDOC monitoring triggering BRF+ requirements

February 19, 2020
by Isard Haasakker

When you are in the middle of a project go-live, providing first-line hyper care support, within the chaos surrounding you, requirements for BRF+ complex decision making will emerge.

Many clients are not aware of the Business Rule Framework, therefore not considering this tool to prevent chaos mainly because the focus is on “going live” as fast as possible, often bypassing proper user acceptance testing and cut-over testing. Especially interfacing will be difficult to test as it requires assistance from the third parties connecting their test environments to yours. The more external systems and different types of interfaces, the more likely all pray that “all will be fine” in a production environment. The level of panic will only emerge when customer orders cannot be registered, and you need to hire temporary staff to process them manually. Also, manual activities in the system will be required when communication to and from the distribution centres are triggering loads of errors.

The faults when processing interfaces can have root causes in many, sometimes unexpected, areas. Here a list of potential reasons why interfaces cannot be processed successfully:

Missing system configuration
Incomplete master data
Incorrect mapping rules
Misaligned transactional data between sending and receiving system

When moving stock from A to B, then you need to configure the system these locations are set-up to store the inventory. You might initially point to missing master data, but also system configuration requires attention. Absent customising probably emerges when you want to execute intercompany billing transactions. These are easy to fix, but requires immediate action and testing in quality assurance environment before deploying into the production system. This delay might prevent solving the blocked transactions before month-end closing. So you can avoid this obstruction by analysing sales orders, purchase orders and production orders and predict the required system configuration to allow flawless completion of the end-to-end business process. You can use BRF+ to design an early warning system to enhance missing settings before the stoppage in processing the intercompany billing will occur. This usage of BRF+ will only add value within a rapidly expanding business.

Almost all SAP ERP system will struggle with incomplete master data, so the power of the Business Rule Framework comes into its own. Preventive master data checks based on transactional data is easy to implement. You can run overnight batch jobs to analyse the recorded transactions in the system and check if potential issues could occur soon. Think of missing packing material for an end product, allowing creating the sales order and delivery but blocking post goods issue and customer billing. Also, you can expect problems with batches when you perform a stock transfer when no batch master data exists for the receiving distribution centre, preventing goods receipt.

Unnecessary complex mapping rules within interfaces can occur when doing mergers and acquisitions. No SAP system is the same, because you can easily extend the standard with custom-built solutions. When you buy a division within a large organisation, you also inherit complex decision making within the legacy SAP system. This complex decision making will be within the mapping of the interfaces. When you do not allow sufficient time to analyse the existing legacy mapping rules, then you can get some surprises. These issues are especially challenging to interpret because the decision making within those mapping rules is not related to your SAP system configuration. Integrating BRF+ within the interface mapping rules can add value, allowing you to be flexible to re-evaluate the inherited mapping rules. In time you can construct the BRF+ functions in such a way that the old mapping rules become obsolete.

A common issue is the misalignment of stock data between the ordering system and the stock storage systems. It is not always that clean-cut to assume that the stock storage system will have the most reliable data, even though you expect that data to be accurate and complete. You also struggle with an always moving target, as stock movements happen throughout the day, especially on a 24/7 operating warehouse. You can take snapshots of stock between two systems and then validate the stock levels, assuming that all goods receipt interfaces are processed successfully. Keep a close eye on those products for which less stock is available for sales in the ordering system, as that is the most likely reason for goods issue interfaces to fail. The Business Rule Framework is an ideal tool to analyse the snapshots of stock levels from both systems. You can quickly react to new insights when interpreting the available data. You can also identify products in high demand and isolate them to fix potential stock differences, avoiding interface failures.

The robust simulation capabilities within the Business Rule Framework, and the ability to collect data directly from the SAP database, allows you to build programs very quickly to test the complex decision making. You do not need a lot of resources from developers to create prototypes. You can quickly transform these prototypes in stable definitive deliverables you can deploy into the production system.

Get Informed

Why your business is not aware of BRF+

January 22, 2020January 22, 2020
by Isard Haasakker

I would like to share a real business case why the Business Rule Framework is ignored as a tool that can save your company a lot of money.

I use the “five why” technique. This method is very effective when analysing a specific problem. As you answer the first “why” question, you diver deeper and get closer to the root cause. Quite often you need to ask “why” five times to discover the true root cause. Then you can find potential solutions to solve the issue.

Let us imagine that we are attending a steering committee meeting. Sarah, the CIO, is examining the productivity of the SAP team, lead by Mark. The key performance indicators show her that there is a larger deviation between the estimated and actual development lead time. One specific change shows that it is more than nine months overdue. She received complaints from the user community about this delay and there is no workable solution in sight.

The following discussion between Sarah and Mark leads to the following realisation:

Why is the lead time so much greater than initially forecasted? Because the more complex changes are difficult to predict.
Why is this change so complex? Because every time new test scenarios were added for the acceptance testing, proving that additional changes were necessary.
Why are there new test scenarios added afterwards? Because this change has an impact on many different business processes.
Why is it not possible to know all affected business processes beforehand? Because we have no overview of the core business processes that we can use as a checklist.
Why do we have no overview of core business processes? Because the knowledge previously documented was never updated, and therefore outdated.
Why is the documentation not up-to-date? Because there is no process step that prevents deployment when the documentation is not updated.

The next months they resolve the omission in the deployment process, but still, this specific change keeps on getting postponed. Now the analysis takes a totally different turn:

Why is the lead time so much greater than initially forecasted? Because the more complex changes made the code unstable.
Why is the code unstable? Because the many different business cases make it almost impossible to translate into code that developers can understand.
Why is the code difficult to follow? Because too many exceptions to the rule need to be built in?
Why can’t we handle these exceptions in code properly? Because they need to be addressed in many different locations in various different programs.
Why can’t we make the handling of these exceptions more efficient? Because we can’t.

This ended with an unsatisfactory conclusion. Sarah and Mark do not know how to tackle this predicament.

But months later you heard about this status quo. And you are aware of the Business Rule Framework. This free SAP tool can solve the stalemate by providing a different answer to the question “why can’t we make the handling of these exceptions more efficient”?

Because you can with BRF+.

Use the tool to make functions, in which the complex decision making is done outside the regular ABAP code. You can easily add all the exception handling within BRF+, without the need to change a line of code in the calling program, as long as the input does not need adjusting. The developers need to assume that the returned result is always correct so that they only need to take care of the processing of that result. The responsibility for the decision making is in the hands of the functional SAP consultant, who can simulate the decision making with the key users to ensure that the outcome will pass the acceptance testing. The key users will get more involved, also learning how complex the solution will become when you add a lot of exception handling. But still, being able to see the decision-making results during simulation sessions will boost the confidence that the resolution will be fit for purpose.

So now the discussion between Sarah and Mark changes:

Why is the lead time so much greater than initially forecasted? Because the have not integrated the SAP tool, called the Business Rule Framework, into our process.
Why is the tool not yet used? Because we just only became aware it exists?
Why did we not heard of this tool before? Because SAP is not actively promoting this tool?
Why is SAP not promoting the Business Rule Framework? Because it is a free tool, not triggering licence income for SAP.

Get Informed

BRF+ avoids technical debt

January 8, 2020
by Isard Haasakker

One of the bugbears that I have encountered during my professional career is the ability for managers to accept a lousy solution. They even coined a specific term for it: technical debt.

Let me explain how this works. The business users want a new feature in the system. Let us say for the sake of argument that it is the automation of specific tasks when saving a sales order. In the beginning, the requirements are straightforward and seem like a small development. The proposed solution is extending an existing user exit when saving the sales order, triggering a specific program as a batch job to perform the various automated tasks.

From the start the scope was limited, only focusing on creating a production order and a stock transfer order when the production plant differs from the delivering plant.

Luckily the transformation of a sales order item into a production order already has a dedicated custom transaction, so the new program to automate this step was to execute this transaction, when applicable.

So far, so good.

That project started over one year ago, and it was still not deployed. So what happened?

First of all, the requirements change all the time. It is a moving target. Every time you believe you covered all possible business processes, a new one surface and impact the existing code.

Secondly, the choice to use job scheduling backfired. As you only have limited slots to run batch jobs (for example 15 batch jobs can run at the same time), during busy hours, there are not enough slots to create the production order as soon as possible. Quickly a queue builds up in the system, triggering a delay.

Furthermore, when also a stock transfer was required, the timing to generate this purchase order is essential. The requirement is only to create this procurement document when the production order exists. This dependency is vital because you want to calculate the correct lead time to arrive at the delivering plant. Creating the purchase order too early triggers unreliable delivery dates in the sales order.

Finally, things can change. After creating the production order, capacity planning can force a change in the estimated finish date of production. Whereas initially, the development of this entire solution focuses on the “blue sky” scenarios, the nitty-gritty business cases for changing dates until production is released triggers delays in acceptance testing of the whole solution.

As time passes, and both business users and IT support team lose the momentum to create a reliable and robust and flexible solution, the IT manager approved the imperfect current for deployment into the production system. In the meanwhile, new insights emerge for a better approach, and a new project starts to make improvements.

The deployment of a flawed solution happens all the time at every company. The incentive to deploy a superior resolution does not always get delivered. As time goes by, and the business users learn how to deal with imperfections, the need for a better solution becomes less critical. The day-to-day struggles take over and fixing the incomplete deployed solution consume the IT team resources. Before you realise what is happening, handling defects triggered by a lousy solution counteracts the ability to build a superior solution.

Now, how can the Business Rule Framework avoid the deployment of faulty custom solutions?

One observation is that the IT team underestimated the overall business requirement, not asking upfront all the potential scenarios in scope for acceptance testing. It would have highlighted the various day-to-day struggles to acknowledge to the client when the ordered goods will arrive at their warehouse. The interaction between the sales, manufacturing and procurement departments will then become more evident when there are capacity constraints when planning production.

You deal with a continually changing environment, where the sales order, production order and purchase order have to change. As soon as you realise this, then trying to capture shifting dates due to specific events within the ABAP code will become messy and potentially impossible to control. It is much better to deal with the necessary flexibility with BRF+ functions. Let the ABAP code outsource the decision making and only manage to supply of data and handling of the returned result.

Simulation is one of the powerful tools of the Business Rule Framework. You can build a prototype and discuss all possible acceptance test scripts with the business users before a single line of code is written. You might conclude that you change the estimation for the effort required to deploy a fully workable solution.

Decision making via BRF+ has as an advantage that it can execute its functionality when ABAP code is accessed. When you realise that job scheduling is not the preferred method to perform a task, then you can easily switch to trigger an event with workflow tasks instead. The decision making remains identical, just the technical approach to execute the functionality differs.

Embracing the Business Rule Framework will save you time and will prevent the likelihood of deploying technical debt.

And if a wrong solution exists in your SAP system, BRF+ is the perfect tool to implement a superior alternative much faster than the traditional development strategies that got the technical debt deployed in the first place.

Training Courses

Visualising BRF+ expressions (part 2)

December 12, 2019December 16, 2019
by Isard Haasakker

Previous blog posts explained that the ABAP code triggers the Business Rule Framework functionality by calling the BRF+ function. You supply the input parameters to expect a returned result. The function has at least one ruleset with an optional precondition and additional variables supporting the decision making. The ruleset comes with a rule with the IF-THEN-ELSE condition.

	Function
	Function input
	Function result
	Ruleset
	Ruleset precondition
	Ruleset input
	Rule input

The previous post introduced the expressions for the formula, table operation and case.

	Expression: Formula
	Expression: Table operation
	Expression: Case

You have a BRF+ function DAY_IS_WORKING_DAY checking whether a date is a working day. You can use that to call in another function NEXT_WORKINGDAY to determine the next working day.

First, you verify if the current date is a working day. If not, then check if the next day is a working day. You keep on repeating this until you find a working day. You can achieve this by using the function call and loop expressions.

Expression: Function call

Modular design expects that you can re-use objects. That also accounts for functions. You can call a function within a function. Make sure the calling function can pass all the required input parameters and store the result.

The function DAY_IS_WORKING_DAY requires CALENDARS, PLANT and DATE as input. At least make sure that the NEXT_WORKING_DAY also have that input either via the function signature or ruleset. Use the returned result WORKING_DAY to verify whether it is a working day. If not, the most logical approach to increase the DATE with one extra day and check if this is a working day. You use a formula to add a day to the date via the formula function DT_ADD_DAYS.

Use a loop to keep on adding days to the date until you found a working day.

Expression: Loop

ICON FOR LOOP

Various types of loops are possible:

Loop x times, or
Loop for every row in a table, or
DO something UNTIL you pass a condition, or
DO something WHILE you have a specific status is valid.

The simulation of this expression is essential to avoid an indefinite loop.

The rule within the function NEXT_WORKING_DAY checks if the supplied date is a working day. If so, then we found our WORKING_DATE, else we loop to find the next working day. This loop uses a formula to get the next date and a function call to check if this is a working day.

Training Courses

Visualising BRF+ expressions (part 1)

December 11, 2019December 16, 2019
by Isard Haasakker

Previous blog posts explained the Business Rule Framework visualisation for functions, rulesets and rules. It gives you sufficient detail to make straightforward decisions within BRF+, using the available context.

The context exists of the function signature, function result and the additional variables defined within the ruleset.

	Function input
	Function result
	Ruleset input

For example, a rule returns an error message when the combination of the material type and material group is not allowed.
You see that these types of validations are simple and do not take advantage of the capabilities within the Business Rule Framework tool.
You use expressions to add complexity in the decision making.

Expressions allow you to use the context to enrich the data within the BRF+ function, ruleset or rule. They are the foundation for modular development.

This blog post uses SAP calendars as an example of how to work with expressions.
The BRF+ function DAY_IS_WORKING_DAY exists to check if a specific date is a working day.
The result is the boolean element WORKING_DAY, returning either a true or false value.
Three types of input exist. The table CALENDARS contains all entries of the SAP table TFACS. The structure PLANT includes the configuration data of a specific plant from the SAP table T001W. The element DATE consists of the date to be checked and linked to the domain DATUM in the SAP data dictionary.

You only need one ruleset, named DETERMINE_WORKING_DAY.
Within this ruleset, you only want to check if the date is a working day.

You start with extracting the year, month and day from the DATE. New ruleset variables YEAR, MONTH and DAY are required. The expression for the formula fills the variables with a value.

Expression: Formula

You determine a value for a field using specific formula functions allowing you to play with mathematical equations, string manipulations and also date conversions.
You extract the year, month and day from a specific date via the formula functions DT_PART_YEARS, DT_PART_MONTHS and DT_PART_DAYS.

You continue with selecting the specific calendar for the plant, using the table operation expression.

Expression: Table operation

You can select a specific row in the CALENDARS table and store it in the new structure CALENDAR_SELECTED.
The selection criteria are the factory calendar of the plant, available in the field PLANT-FABKL and the YEAR from the date supplied.

You proceed with selecting the month of the selected calendar, utilising the case expression.

Expression: Case

The calendar details store the working days month-by-month in a specific field within the structure CALENDAR_SELECTED. The field MON01 represents January and MON12 December.
You use the MONTH from the DATE to select the calendar month in the CALENDAR_SELECTED and store the result in the new element DAYS_IN_MONTH.

The element DAYS_IN_MONTH contains a string of 0 and 1 values, each character representing a day. The first day of the month is the first character, and the last day the last character. The value 1 identifies a working day.

You can now create a new formula to determine the new DAY_IN_MONTH element, using the formula function SUBSTRING and element DAY to locate the working day indicator.

You now have all the information for a simple IF-THEN-ELSE statement.
If the DAY_IN_MONTH has the value 1, then WORKING_DAY is true, else WORKING_DAY is false.

Visualising this BRF+ function has the following result:

Training Courses

Visualising BRF+ rules and rulesets

December 10, 2019December 11, 2019
by Isard Haasakker

The Business Rule Framework uses rules to determine a result based on an IF-THEN-ELSE structure.

The IF statement defines a condition that can be either true or false. When the IF statement is true, you set the actions in the THEN section. Otherwise, you use the ELSE section to list the tasks when the IF statement is false.

You have the ruleset to group the rules within a function by setting a sequence.

A function must have at least one ruleset that consists of at least one rule.

	Ruleset
	Rule

The ruleset can have a precondition. You want to use this to skip the rules within this ruleset and speed up the function processing time.

The rules will use data to determine the result. The data supplied in the function signature is available for decision making. When additional data is required, then define other variables within the ruleset.

The sequence in which variables added in the ruleset is essential. For example, when you have two additional variables, A and B, for the ruleset. When the value of A is needed to determine B, then define variable A before B.

	Ruleset precondition
	Ruleset input

The input parameters in the function and ruleset are also called the “context”. The context is an overview of all the data accessible to make a decision.

Imagine you want to select a specific factory calendar influencing a decision in a rule. You can supply all calendars as table CALENDARS via the function input parameters. The ruleset will define a new variable that filters all supplied calendars to only keep those linked to a specific factory calendar into CALENDARS_SELECTED.

The table CALENDARS uses the structure CALENDAR linked to the SAP data dictionary TFACS.

You cannot use the structure CALENDAR again to define another BRF+ table. Instead, you need to create a new structure CALENDAR_SELECTED, also linked to TFACS, as the basis for identifying the table CALENDARS_SELECTED.

The context contains two tables CALENDARS and CALENDARS_SELECTED and two structures CALENDAR and CALENDAR_SELECTED.

The table CALENDARS can contain all calendar information in the SAP database and passed to the BRF+ function. Then the ruleset can decide how to filter the data. One ruleset might filter on the plant, whereas other rulesets use the customer unloading point or shipping point.

The rule can have unlimited statements to get to a final result. The sequence of the steps within the THEN or ELSE section is important.
When the rule has two steps then they are processed sequentially top-down.

Assigning values to the context is done via expressions, explained in another blog post.

Training Courses

Visualising BRF+ functions

December 9, 2019December 11, 2019
by Isard Haasakker

Understanding the inner workings of the Business Rule Framework might be daunting for many. Some find a visual representation of the BRF+ components beneficial and increases the likelihood to embrace the tool to become more efficient and productive.

Visualising BRF+ is done via several blog posts, and this will be the first in the series, focusing on the function.

BRF+ function

The function allows you to communicate between the ABAP program and the complex decision making with the Business Rule Framework.

The function contains a signature, that consists of:

	Function input
	Function result

You can offer many types of data objects as input:

	Element: A single value.
	Structure: Collection of single values.
	Table: Rows of data with the same structure.

Often the data object is linked to the SAP Data Dictionary. Then changes made in this dictionary are also applied to the BRF+ data object when they are updated.
For example, a BRF+ structure relates to the SAP Data Dictionary. The structure is updated in the SAP system (via transaction code SE11). This change is also applied within BRF+ when you refresh the structure definition.

Use the following icon to identify that the data element refers to the SAP Data Dictionary:

SAP Data Dictionary object

Only one result is returned, which could be:

	Element: A single value.
	Table: Rows of data with the same structure.

Returning only one result is very important to realise. Imagine you want to determine a packing material for a specific product. You also know that finding a suitable packing material might not be possible due to data errors in the database. When you want to validate the data and also return the identified packing material, then two BRF+ functions need to be created. At first, you check data quality via the first function and issue messages. When it passes the data validation, then the second function will supply the packing material.

For example, your system makes a distinction in packing materials based on whether it is second-hand. The material type and material group are used to identify second-hand materials. The incorrect combination of a material type and material group can exist for second-hand materials. This bad data can result in inaccurate packing material. Therefore, you only want to return a packing material after it passed the validation of data in your database. You need two separate BRF+ functions because they have two different purposes.

You can activate a function after identifying the signature, with at least one input parameter and the return parameter. The code template becomes available, and the developer can cut and paste this into the ABAP code. However, you get no result when you execute the program because you are missing the complex decision making. Next step is to define rulesets in your function to analyse the input to generate a result.

That is a topic for the next blog post for the visualisation of BRF+ components.

Be Prepared

BRF+ requires creative problem solving

December 6, 2019
by Isard Haasakker

Applying the Business Rule Framework to solve complex problems are not easy to achieve. The tool allows rapid application development, turning configuration into code by the press of a single button. Setting up the data objects, functions, rulesets, rules and expressions can be a frustrating process. Therefore you need to imagine that several iterations are required before you have a working prototype. Often we have to start over and avoid mistakes in previous versions that lead to a dead end. Eventually, you will conquer the challenge. Just takes persistence and a good dose of creativity.

You might convince yourself that you are not creative. Seeing complicated BRF+ functions for the first time could be daunting. You probably believe you never can master that level in BRF+. However, practice is what you need. Add the hours trying to get to a working prototype. It is like any new skill where theory can be tested using multiple-choice examination, but practice makes perfect.

Creative problem solving is essential, and you can teach yourself this skill. All famous inventors like Da Vinci and Edison mastered this skill. If they can, you can as well. They focused on the problem and found all the ways possible to solve it.

The process starts by asking “the five whys”, ideal for verifying the business requirement. You need to discover the REAL problem, often not the one initially identified.

Continue with asking challenging questions with each question highlighting a single issue. Try to solve each problem one-by-one. You discover each item refers to a BRF+ object, like an expression or rule. Make sure you try to address each issue in various ways, as there always are multiple ways to reach the end goal.

Link all questions and see how they fit to answer all of them at the same time. You understand that this will become a set of BRF+ functions that are related.

Continue with the simulation of the functions and verify if all scenarios pass the tests. Organise a meeting to let everyone challenge your solution to see if it requires fine-tuning.

Forget about “first time right”. Keep an eye on making progress and eventually delivery a solution that handles all complex decision making. It often requires several cycles of trial and error. Stay on the journey and take any criticisms as input to make the final deliverable foolproof. As soon as you reach that point, deploying this solution will be fast from then on.

Want to read more about creative problem-solving? Then read this articles:

Problem Solving Process: https://innovationmanagement.se/imtool-articles/the-basics-of-creative-problem-solving-cps/.
The five whys: https://en.wikipedia.org/wiki/Five_whys.

Practical Advice

Documenting BRF+ deliverables

December 5, 2019
by Isard Haasakker

When you decide to embrace the Business Rule Framework for complex decision making, then no technical specification is required. The tool generates all object-oriented ABAP code automatically. Apart from reducing the deployment lead-time, avoiding the need for documentation will be a blessing for many.

Face it, writing documentation is not a favourite activity for many. Even though this action is part of the job for a business analyst and developer, the lack of enthusiasm often reflects in the delivered quality. Writing is a skill you need to cultivate.

Still, up-to-date and accurate and complete specifications are vital to achieve and support a stable system.

Any change in the system starts with business requirements, converted into a functional and technical specification. Each document has its purpose, supported by approval procedures.

That is a beautiful theory, but reality looks so different.

Luckily you can document within the Business Rule Framework. The GENERAL section of every BRF+ object has its dedicated DOCUMENTATION tab. If you agree to have that filled in and validated, then you already safeguarding that anyone with minimal BRF+ knowledge can understand the purpose of the object.

You can write documentation for a function, ruleset, rule, expression and data object. Your mission is to add enough content to allow any colleague to understand its purpose. Spend special attention to WHY the BRF+ object exists and the expected result.

Remember to avoid repeating yourself. When a rule is using an expression, avoid explaining the details for the expression while describing the rule.

Documentation for a function can focus on the signature and the result, and even highlight what happens after you return the result. Also, list the rulesets and list the reason for the priority.

The ruleset documentation can highlight the need for a precondition. Besides, list the additional variables and the expression to fill the initial value (when applicable). Finally, describe the details in the rule and highlight the reason for using expressions.

Continue with each expression, detailing its specific purpose.

Remember, only feed the information required to the consultant analysing the BRF+ object.

Test the quality of your documentation by asking for a second opinion. Let a colleague analyse a BRF+ function and all its components by only reading the explanation stored for each object. Verify if the content makes sense and whether the actual configuration reflects the instructions.

Just sit back and observe how someone interprets the available information. Make adjustments where there is ambiguity. Then decide whether to update the functional specification, pasting as much content in the DOCUMENTATION tab as possible.

Following this advice will increase the quality of the required documentation before you deploy the BRF+ application changes into the production environment.