Business Analysis: The Case for a Business Rules-Driven Approach

Business Rules are nothing new in the discipline of Business Analysis. For years, major software projects have been analysing, assessing and defining their stakeholders’ Business Rules. They do so for the specific purpose of implementing changes to the automated business processes that implement the Business Rules. How well do they do this? Too often the analysis of Business Rules is relegated to a secondary activity; one that is performed in order to trace the software requirements back to something tangible within the business.

This article will argue that Business Rules should be defined, leveraged and managed as an Enterprise Asset. Business Rules are the structural facts that define a business, and the decision logic that guides the operations of that business. Extracting Business Rules from the implementation considerations of a software project enables those Business Rules to be recognised, validated and owned by the true stakeholders of the business, without the obfuscation of technical detail or solution trade-offs.

Business Rules in Today’s Solution Delivery Lifecycle

The traditional Business Analysis approach focusses on eliciting Business Requirements from the strategic Goals and Objectives of the organisation, and then decomposing those business requirements into Stakeholder Needs and lower level requirements such as System Requirements by identifying gaps in the current capabilities owned by the organisation. It is only then (if at all) that the Business Rules implicit in the organisation are documented and agreed, so that the solution can be shown to correctly implement the Business Rules.

This approach has some significant drawbacks. The focus on requirements means that the Business Rules are often not examined until very late in the analysis process. This can lead to re-thinking the approach agreed with the stakeholders, uncovering additional requirements, or a realisation that the Business Processes that have already been designed will not implement the rules in a consistent way. All this can impact your project delivery schedule, incurring additional costs, and risk losing critical resources from your project.

One large NZ company we know of was trying to change its customer origination process to better manage credit risk. It had never before undergone a structured review of this process, and the existing Business Rules had not been comprehensively defined or kept up to date. The company was attempting to run a short development cycle, and was defining its “to-be” business process while in parallel engaging technology vendors to configure the supporting systems. It only then emerged that the subject matter experts put forward to help define the new business process did not have a clear and common understanding of all the existing Business Rules governing customer origination, let alone an agreement on the new Business Rules that would lead to improved risk management outcomes. The project fell into a death cycle as the stakeholders failed to agree on exactly what Business Rules the system should implement.

This is not an uncommon scenario. In fact many large software development programmes run into the same difficulties. By not defining their Business Rules clearly up front, they risk delivering a gold plated system that does not deliver the true business benefits that their stakeholders sought.

A Business Rules-Driven Approach

An alternative approach has been developed by Ronald Ross and Gladys Lam of Business Rule Solutions. The change is to make Business Rules into, as they put it, ‘first class citizens’. Under this approach, the Business Rules are defined first, before any detailed definition of the system requirements is undertaken. Any contention between business stakeholders is addressed early on, and conflicting Business Rules do not make their way into the requirements specification, or even the code.

The key to elevating business rules into a first class citizen is to start with Business Strategy. A business initiative that is not directed by strategy is like a boat without a rudder. By analysing the strategic outcomes required by the business in terms of its Goals and Objectives, a set of policies can be derived. Policies are directives that guide business behaviour towards achieving strategic outcomes, by mitigating specific risks to those outcomes. In our example above, the Goal may be to minimise losses from bad debts. A Risk< to achieving that goal would be the acquisition of high risk customers. The customer origination Policy may be to only accept applicants who have an ‘acceptable’ credit report.

Policies in themselves are not actionable. They merely state intent. In order to enact the above Policy, we would have to determine what ‘acceptable’ means. Will we accept customers with previous payment defaults? If so, how many and what type of defaults are acceptable? In the case of a joint application, do both applicants need to fit our criteria? What if we are unable to obtain a credit report for the applicant?

By scoping all of the variables and then applying the intent of the Policy to each business scenario we can derive a number of Business Rules, elicit rule decisions from our stakeholders, decide what action to take when a Business Rule has been violated, and design a comprehensive business process to implement the Business Rules. Does this sound like a lot of effort? Once we have stakeholder agreement on the Business Rules and how they will be implemented, defining a functional requirements specification for the resulting software changes becomes a straight-forward and non-contentious task. By deriving Business Rules from business strategy instead of from requirements, a comprehensive set of Business Rules can be defined – one which is not constrained by solution thinking or by technical scope. This enables a direct link between business Goals and Objectives, and the Business Rules that a system must implement to achieve those Goals and Objectives.

Conclusion

A rules-driven approach does not necessarily mean a complete redesign of the solution delivery lifecycle, or of traditional analysis frameworks. Rather the approach is to remove Business Rule definition and authoring from the role of a system delivery team, and place the Business Rules back in the hands of subject matter experts from the business, with support from business-focussed analysts, or even into the hands of Business Rules specialists. This helps to shift the focus of the overall Business Analysis effort from just delivering a project to ensuring the right business outcomes.