Get Informed – Business Rule Framework

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.

Get Informed

BRF+ allows you to fail fast and fail often

November 25, 2019
by Isard Haasakker

Wait a second. It sounds counter-intuitive to highlight failure as a positive feature when using Business Rule Framework. All will be explained.

Unit testing is very important during the development of business requirements. The traditional method of coding complex decision making has some obstacles.

When coding the solution, unit testing is done by the developer. The test cases have been an interpretation of the functional specification, which has been an interpretation of the business requirements. Like Chinese whispers, the developer has the disadvantage to be two steps removed from the extracted result. This allows plenty of room for making assumptions on how to meet the acceptance criteria. Take into account that developers should not have direct communication with key users, all questions have flow via the business analyst. Every exchange will contain noise and makes it less likely that the first version will be approved by the business analyst and key user.

When offering Business Rule Framework to business analysts to prototype the business requirements, the opportunity arises to have close interaction with the key user to evaluate the most fragile part of the delivery. The complex decision making can be prototyped as soon as business requirements are known. Building this prototype has the advantage that the business analyst and key user can sit together and test whether all identified acceptance test scenarios will pass. At this stage, the objective is to break the prototype as soon as possible. Fail fast and fail often to achieve a stable prototype as soon as possible. A reliable prototype that returns correct results for all identified decisions builds the confidence that the key user will receive the functionality requested and underlines that the business analyst has understood the business requirements. Prototyping also offers the business analyst to challenge the business requirements, fine-tuning the original set of demands into a correct system behaviours. You can accomplish all these milestones before a functional specification is documented and a single line of code is written.

Lack of quality data in the development environment is probably the biggest hurdle for developers to conquer. This lack of data quality often becomes a task for the business analyst to resolve, as they should provide detailed instructions on how to unit test the coded solution. It is likely that only a small set of data is suitable for testing, making comprehensive unit testing unlikely. Then unit testing will only cover a subset of all test scenarios and focus more on avoiding system dumps. Then the code is transported to a subsequent SAP environment that contains more reliable data, normally based on a recent copy of the production system. As proper testing is not possible in the development environment, it could trigger a lot of transports to get the code fit for acceptance testing.

Missing good quality data in a development environment also remains an issue when using BRF+. However, the powerful Business Rule Framework simulation capabilities allow you to test with data not available in the system. Of course, it does not check whether the result of the decision making is correctly processed by the calling program that executes the BRF+ functions. Still, decision making can be unit tested in isolation. This is useful when the prototype is built in a different SAP environment and had some minor adjustments to make it suitable to be deployed into the production system. All test data used during the prototyping can be imported and verified without affecting any code. At this time failure is less likely and can be corrected before it is moved to the subsequent SAP environments for further testing.

The conclusion is that failing fast and failing often is an essential concept to deploy error-free solutions as fast as possible. BRF+ is designed to get rid of all mistakes in decision making during prototyping and before development starts. At the same time, the business analyst can challenge the test scenarios for acceptance testing, sometimes triggering fine-tuning of the business requirements. The end result is a faster deployment of changes in the system while reducing the need to fix potential bugs after deployment.

Get Informed

Convert decisions into binary choices

November 15, 2019
by Isard Haasakker

You find that Business Rule Framework is very flexible and can be adapted to fit the most extreme complex decision making. However, there is always a limit as it cannot make all decisions a human can.

Humans are emotional beings, making decisions that seem not logical. Those illogical decisions cannot be made by BRF+.

Imagine you have several routes to visit family. You have the fastest route, shortest route and most ecological route. The decision on making the type of route depends on many factors that is based on logic. For example, road blocks, traffic jams, weather conditions or time of day can influence the decision. By default you would imagine that everyone would select the fastest route. Still, even on a normal day you can select a different route that is not based on any logic. Maybe this time you just take the pretty route because you get bored with always driving the same way to your destination. This is emotional decision, not based on logic. Such a decision making process cannot be replicated within BRF+.

Business Rule Framework can guide you from A to B as soon as you have selected the type of route. You can process all influencing factors that could support the most logical decision. The more data you supply to the BRF+ function the more likely the most logical route is selected. But the result is always pointing to the decision that would make the most sense given the circumstances.

You find that it will be extremely rare that business decisions are of an emotional and illogical nature. That is why your challenge is to challenge the business requirements to get very specific details how decisions are made. Just not accept that you sometimes need to go left when in apparently same circumstances need to a different direction. When a specific person makes a specific decision then dive inside the thought process up to the moment that a binary choice is made. Then try to describe how this core binary decision is made and then work your way back to how this impacts the business process involved.

When you use BRF+ for complex decision making then it is useful to build a prototype as soon as you receive the business requirements. Then use this prototype to challenge these business requirement up to the moment that all binary decisions are identified and approved in the prototype. You might need a lot of information to make decisions, but that is the point of this exercise. You are eliminating potential reasons to fail user acceptance testing at the end of the deployment process.

Get Informed

BRF+ and rapid application development

October 25, 2019November 15, 2019
by Isard Haasakker

Obviously you would like to use standard SAP functionality as much as possible, but there are circumstances where you have business processes that require an enhancement. When you need to build custom solutions then there are decisions that need to be made by the new programs in order to get to the desired result.

Coding decision making is often very complex for many different reasons:

The business requirements are not fully known when you start building the new functionality. This is very common, as it is difficult to know all scenarios up front. Quite often the real requirements appear during testing, or even after deployment.
The scope for functionality expands after deployment. As the world is constantly changing, it is to be expected that business processes will be affected as well. This is especially true for new functionality that is not available in standard SAP. These new processes are bound to change.
New acquisitions trigger new requirements. You might have a stable new process that fits your current enterprise structure. However, when new companies are added to the SAP system, do not be surprised when new rules need to be applied.

The reasons listed above have nothing to do with the quality of the deliverable that has been deployed. Unfortunately you can expect that coding decision making in the first version will undergo changes in the future. If you wonder why coded enhancements become a jungle after many years, then it is simply due to the need to adopt to changing circumstances.

Business Rule Framework is the ideal tool to handle the complex decision making, as you design the solution like it were configuration, you have power simulation to validate the known business scenarios and the code gets generated by pressing a single button.

This tool is especially able to make a huge impact when you have a remote development team in a different continent, as these developers only need to focus on collecting the data for decision making, offering this to the BRF+ function and do the correct action based on the returned result. These tasks are much easier to code and chance of errors are greatly reduced.

Using Business Rule Framework allows you to apply the core concepts of rapid application development:

You can prototype decision making and get business approval before a single line of code is written.
An approved prototype is the basis for the functional specification.
There is no need to write a technical specification for the decision making, as BRF+ generates the code and no developer needs to get involved.
While the developers are coding the collection of data and actions based on decision making, you configure the decision making using BRF+ in parallel.
If new business rules require new decisions and the signature of the BRF+ function requires no change, then developers only need to get involved when new actions need to be coded as a result of decision making.

You quickly realise that BRF+ can reduce the lead time for development enormously. Also the chance to deploy solutions fit for purpose will dramatically increase.

Knowing these benefits, makes you wonder why Business Rule Framework is not embraced by all companies running SAP.