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.