Hello, my name is Jamil Spain, Developer Advocate with the IBM Cloud.
As a technologist, everyone has that opportunity to build that first large scale application.
For me, that's been almost 14 years ago.
The first challenge that I encountered where I had to do this task all by myself, a single
coder of one, was actually an online admissions application.
Now doing that process, which is way, way beyond any "hello world", I had to actually
have the opportunity to put in business logic into the application as I was developing it.
Well, there's actually a term for that, and it's my topic for today, "Business Rules".
So, what exactly are business rules?
If I had to simplify this for you, let's just say that it is the everyday logic that gets
program into actual applications.
Not to be confused with business requirements, which really that's the output of what you're
developing the application for, we can call it kind of the success criteria.
So the business rules are really the way you formulate that business logic in.
And this usually done in many different circumstances, but let me pose a situation for how it came
to be that you kind of work through now.
Now when you think about it, in your existing applications, whereas when I approach that,
this is generally how that design actually occurred.
I started with application code.
And at some point, my immediate goal was to get me over to the actual data store, of course.
Now, at some point, I am building workflow algorithms, as you may call it.
Particular patterns that I must follow, what happens when someone signs up, what happens
when they want to register for a class, you know, all of these type of things in my mind,
I was trying to picture, how do you symbolize those and how does it work?
So I'll just take two arrows here.
But I wanted to kind of formulate that there are many, many decisions and functions and
methods that must be programed to work.
Clearly, all my data is inside my database, so I'm doing a back and forth, this can actually
be a two-way street here.
But what I noticed and when I think about when I first started development, I really
attached my logic into these individual flows.
So here I may have other functions that actually ran different logic, and they were just kind
of all over the place.
Functions here, functions there, kind of as I started to approach them or another business
requirement came up, or something I had to do that had to be a part of this workflow.
I just kept piggybacking and band-aiding on to processes.
All right.
And it kept on going and kept on going.
And naturally, when I had to make changes or update or something evolved, I had to try
to go back in and Band-Aid.
And let's hope that there weren't two types of similar operations that had to occur in
both of these workflows.
I had two or more places to kind of go here.
So this is where exactly where it comes in.
The context of where I'm talking to you today is formulate that into business rules.
So you'll have a secondary engine: code classes, some type of interface that you want to kind
of code into.
Well, naturally, a lot of your data flows in through here and then flows out ...
... maybe to your database has that process here, and this gives you that one place where
you can start to formulate things to have one particular area that data has to flow
through.
And then this gets me back to why business rules are really important.
So we said it's the everyday logic, and you can actually know that that's symbolized by
your your syntax that we usually do for a lot of decision trees.
So you have your, what I like to call the "Ifs", all right.
So, this would be expressing logic.
And we said the ifs, so that's the ifs of the thens, only, if, else, and naturally,
I have other conditions when something happens, this should happen, and maybe I'll only do
this particular piece of logic if and only if so, you can tell it gets really kind of
your basic structure that gives you a big formal way of kind of working with that.
Now you may say why, as I like to do it, any technology or as a technology, anything I
want to implement, I have to ask myself that question: Why do I actually want to do this?
There are obvious benefits that I want to spend my time in re-architecting the application.
And as I started to work through this video concept here, I actually thought about ways
I could improve my original design if I actually went with this kind of architecture way back
then.
But let's talk through those and they're very, very important to cover here.
The first is efficiency.
I definitely add it point there.
Because naturally, you can always see there's only one place I have to make changes.
All right.
And that really helps with anything that I want to kind of assimilate, and do I have
one place to make the code changes?
I also say for consistency, there's definitely going to be a plus in that area as well, naturally,
now with all these different workflows, you think about the context of an application
for an emissions from maybe any type of institution that has to require an application for emissions.
As you have many different departments, I have one consistent way to represent my workflows.
And I may have, you know, maybe for the emission criteria, I may have better ways to give to
the scholarship committee to understand how we make decisions on admission.
So it gives you kind of a consistent process that you can use to really help formulate
a particular workflows there as well.
And then the last we have efficiency, we're going to be consistent: the complexity.
So not increasing complexity, but we have a way to definitely decrease complexity, because
now we have a easy way to represent how we can take apart a business workflow and break
it up into constraints and parts that, you know, we can simulate it for how it should
work here.
And now we have a template that can actually be used for the next business practices and
the next business process.
And quietly, this is really the foundation of entering into actual automation, and we
get a lot about that.
Please check out the process mining video.
We talk about how a lot of these activities really parlay you into that particular context
here.
Well yeah, definitely obvious ways that you can kind of get direct benefits out.
Let's go back to the logic here though, we mentioned some of the basic control structures
that works.
But this also goes by there's there's even a discipline for classifying how these rules
apply.
Now they can be constraints, and I think of constraints as things that immediately happen.
I already know a condition that's there, so I know things that I want to do, so we'll
call that a "yes" criteria.
I met something so I can immediately jump here.
And so for admissions, do you have a certain GPA?
Yes, we can go there.
You can also do pre and post conditions, what must happen when the data comes in and out
just to make sure two conditions are set and things that flow from there.
And then there's other types of inference will say.
All right, scribbled on in there, we least got it in, the word is "inference" here.
And that's really based upon two particular context here.
I can also say whenever I have some facts that I know.
That I can make decisions on.
For instance, the I mentioned like a particular GPA or certain SAT scores, I can make different
factors there.
And then we have the things that we can calculate these type of numerical facts or conditions
here.
I just do "calc" and then those computational things can actually allow me to get to certain
facts here as well.
I remember at one point we were evaluating the applications.
I had to build a workflow that helped with evaluation.
If you did this on your, if you input this from your scoring your essay, you've got this
many points where a number of activities, GPA, all those things.
So I have certain facts that I can then make decisions over to know you're in a final group
of there.
Just theorizing here as well.
So we've kind of moved through on how you kind of start out and how you should have
an architecture to take proper implementation of business rules.
We know the logic that's applied in different, really different situations that you can build
a lot of the workflows to gain these obvious benefits.
Just to bring it on home here.
Let's talk through a couple of use cases that, really, I can kind of see besides this that
can really be useful for you to use.
Now, the first I did mention here, I kind of gave that one away, but we said the first
was definitely applications.
Now, I'm not saying that every actual Web application project requires business rules,
but we are talking some of the large scale applications that you want to build.
Definitely anything that requires an application.
You have ways that you can apply definite criteria to work.
And also a lot of these situations, let's say in that situation where we had the application
I was building.
I also had to prove how applications were evaluated.
So for regulations and compliance.
[00:10:30] You also can have a track record of how you went through and made a decision.
You know, it wasn't just if these were just loose rules like here, it has an opportunity
that it could not have gotten picked up or one particular piece of code could not have
done the particular constraint that we wanted to apply.
But since everything rinses through, we have a great opportunity to show how it was evaluated
and showed that kind of check and balance here.
[00:10:56] Let's say also for e-commerce.
So, an e-comm, let's think about the opportunity when you do purchases and returns.
And throughout the pandemic, we know that we bought a lot of things online and been
numerous products that have been ordered.
We definitely always want to make sure when we go back and return, has it been the 30
days?
Has it been the 14 days?
And most a lot of applications I've going through and use or return products, you have
to request a return authorization.
Somebody's got to ask you, when did you purchase this?
And so that first iteration, I have an opportunity to say it's been plus or minus 30 days or
14.
And if I would like to, that's a great opportunity for me to go ahead and send back a rejection,
sorry has been passed that time here.
But definitely give you a way to help evaluate different pieces there and also think about
purchasing.
There's a great opportunity to interact with other systems of inventory moving inventory
around.
We all know that there's been a lot of inventory issues as of yet that we've come through.
And last but not least, one that I love, I want you to definitely pay attention to, and
I think this is great in today's many of today's architectures here, and it's the, all right,
scribble that out, "personalization".
So, a lot of these engines, everything is personal to you, and I love it when I actually
go to, I get to browse the site.
I may be able to come, come back.
So let's say you have the opportunity of new visitors and returning.
So if I'm a new visitor, have a great opportunity to put you into my new visitor workflow.
Here are my featured products that I want you to pay attention to.
Here are my deals, the specials that I have.
But let's say I'm a returning user, I'm just coming back to a website.
This can be an opportunity to show me what I've been looking at or to correlate.
I actually personally love the engine where I'm able to say other people who are looking
at this, they bought this.
Maybe you should look at these options as well.
Because it's all about diving deep into the specifications and understanding what's the
option of "why should I buy this over that?", especially when it comes to all the gadgets
that I love here.
So, we've done a lot today, we talked about business rules, the logic, the rules that
are required.
The obvious benefits that you can use to really implement this type of architecture and some
use cases that you can kind of immediately jump out to.
I've always wanted to do this, but this is a formal, sturdy way of actually implementing
this type of logic in your application.
If you have any questions, please drop us a line below.
And if you want to see more videos like this in the future, please like and subscribe.