The Better Business Analysis Institute presence, the Better Business Analysis Podcast with Kenjan Walsh. Hi, everybody, and welcome back to the Better Business Analysis podcast with Benjamin Walsh. And we're continuing our BA Byte series. And today we're talking about business rules and why they're so confusing. Business rules, I find, are one of the areas that aren't talked
about much in business analysis. They don't really have a structured format in terms of how you should follow them or the pattern in terms of how you should write them. And I think they're one of the most misunderstood pieces of the puzzle when it comes to business analysis. So let's dive in. What is a business rule and why it might be different to what you think of business rule is and why you may need to change your mindset when it comes to
business rules. So business rules are scenario rules that come from the business, which are driven by legislation changes or what the business wants, right? And they're defined for the business and then they can translate to how the machine, the business machine operates. So you've got requirements, which of course are requirements either within a change process or for something you're telling or defining what you want the system or solution to do.
These are now scenario rules. Here's an example. A simple example would be a customer needs to be 18 to open an account. That's the business rule, and I like the way that's structured. A customer, one of our actors, needs to be 18, a defined variable to open function, which of course open an account would be a requirement here. And then account, an account is one of our business entities.
That's a really great example of our business rule, and that's actually the format in which you should write it. A more complicated example would be a discount depends on the customer's loyalty tier, and then that could reference maybe Excel spreadsheet, a table or a matrix which had the lists of the discounts and the loyalty tier. Nothing in there is defining how the code should be written. And this is where B as get mucked up.
This is where B as go too low or don't think it's their job to construct business rules or it's the technical team asking for rules to be filled in. Once they're building the solution, they should all be done up front before a solution is defined. In order to make your business rules better, we need them to be. We need to have like some consistent way of defining them. OK. Business rules are things where
decisions can be made. There there there are a a prime point where you should review business rules when you're making a change to a system or a product. And a lot of times actually you may just be changing business rules. An example here would be of a piece of legislation came out that changed how old you needed to be in order to get your driver's license. Let's say, let's say it was reduced from 18 to 16.
That could translate directly to a business rule for the government department that issues driver's license that there may there would might be a change project. Of course there would be a change project to implement. OK, what does that mean? OK, well, this legislation could will go two ways here. One, we've got a business rule and then we've got business requirements off there issuing what we print on the IDs, how we check people's ages, maybe based
on passports or whatever. So all of those which are just the process requirements, which would drop out because it's the process problem and a policy problem. And then the business rule would be OK, we've got a legislation change here from 18 to 16. That's the business rule. So that's a business rule change.
And that's exactly the language we need to use are the benefits of defining a business rule as an explicit statement and maybe even having them in an explicit list so you can pull them out because they exist regardless of the solution that you have put in place. Refer back to them and you can check them from time to time. And you should do that as a business. Business rules provide less confusion, OK, and less waste figures figuring things out. Business rules are really important.
If you document them, then you can really see any legal or regulatory requirements or policy requirements. They generally come from organization or policy requirements or environmental requirements that you need to adhere to. But the business can also adopt their own rules which are hence the word business rules. They help with decision making and it helps everyone understand why behind the decision and when you write them. Here are some key points you need to me make sure that you're
using plain language. Everyone in the business can understand everyone. Probably everyone outside the business can understand. You need no room for interpretation. OK, there are almost terms and conditions here. Clear terms and conditions. I'm not talking about going to the legal department, but sometimes you might need to if you really want to get clear on a point. But then you want to reinterpret that into business language and refer to the document.
If people want to understand what you mean by some of the definitions or some of the terms you're using, you need to focus on outcomes. State the desired result, not the specific steps, OK, unless they are critical in the business rules. So for example, if customer chooses X then Y, if they choose A then then B. But that's the only only if that is affecting the scenario of the business rule. Otherwise state the desired result which has maybe providing discounts to customers.
Test and refine them with your stakeholders and revise them. And actually some of these business rules, not the system, not the product, are things you could test, AB test. You could say, OK, well one of our business rules is we're not going to provide loans to people with bad credit ratings, right? Under a certain threshold that could that's a business rule. And you've applied that into the system. You're like, well, we're testing this.
So you could have a flexible business rule in the system. And then maybe you're like, actually a whole business model will fail business, business model, business rule that we will now open up some loans, a smaller amount of money to people with better credit ratings, but we're not gonna have as high risk. So we're not gonna loan them large amounts of money. And actually we've defined that
we've had our sweet spot. So these business rules need to be malleable and they need to be able to change at some point. I'm going to now talk to you about what business rules are not. So we've talked about that. Business rules are almost Co equal with other requirements such as process model requirements, where a lot of requirements come from, right? They're the rules that govern the process sub process steps or how you carry out the procedure. They are definitely part of the model year.
So you need to put them under your requirements, your user stories, and they do drop out of process steps. So a business rule guides the behavior and the decision making within the organization. So it's what actions can they take under what conditions. Whereas a system rule governs the behavior of the specific system or solution and and B as need to walk a tightrope here. I think there was a term I used
this week. System rules dictate how the system processes datas and performs calculations. Some of the rules are written so in the system, as in we've we've said we want to implement. If someone has a bad credit rating, do the following thing. We've, we've only ever defined that in the system to say, oh, when we hit the system step in the, I don't know, SQL procedure, we're going to pump them out. Business rules can relate to system rules, code code rules, but the business rule comes
first. Do you need, if you've got those, if you're in a current state where you haven't actually defined your business capital B business rules, pull them out. OK, so you can do that with your current state. You can go through and go, hey, look, I'm going to spend the day, I'm going to write up all our business rules. We don't actually have them defined. They're all baked into our code and that's why we're stuck with the system we've got. It's one of the reasons why we
don't have optionality. So I'm going to go through, I'm going to interview the the DBA or the developers and I'm going to pull out some of these rules so they're clearer to our product owners, to the business, so they understand what's baked into our process. This happens often and I'm sure you're in this situation too. Whereas no one actually knows what the rules are that were applied.
It's just legacy. And so by pulling those out and defining them, you can actually take stock and do an audit, a business rule audit, which I think is really good for BAS to do. And the other thing that business rules really talk to is, is flexibility that business rules can change business changes. And things like the fact that we had system rules in place for GST or VAT which were baked into our systems or we had, you know, Y2K like dates baked into our systems.
They were all system rules that were never really defined or explicit as business rules. And if they were then the business, of course, our leadership team would go, what do you, what do you mean our system can't go past the year 2000? Sorry, that's definitely not a
business rule. That might be a system problem that we have inherited because it's, you know, bad code or someone's baked it in or equally, what do you mean we can't change the GST VAT right from 15 to 17% without giving $1,000,000 to SAP to do a change program? So in summary, business rules are from the business, they come from your stakeholders, they come from the owner of the system or product or area in which you are managing the
business owner. So if you're not in a project form, you know, like you have A and you don't have a product owner, that's your business owner. You define them in a list. When you are defining requirements in that change space, in those process change spaces, your scope, you would define them and review them as part of your requirements. And they should be under your user stories. That's probably the easiest way to do it. But I'd also have them in a
defined list. They should be reviewed often and they should be written in a business, easy to understand why in business terms, and they should be really clear and concise. And if they're complex, then you may need to reference, you know, an article or a piece of legislation to explain why the statement exists. And yes, it's your job as ABA to do these. Actually, it's somewhere where B as can shine.
Just like process modelling. Business rules are also an area where the BA, the B and BA comes out on top. I'll see you next week.