This document discusses business rules and processes as ways to separate business logic from code. Business rules represent knowledge as logical implications that can deduce new facts from existing ones. Rules engines evaluate facts against rules and optionally execute actions. Rules are useful when logic changes often or domain experts are non-technical. Business processes capture activities with a specific goal as a workflow. A process workflow is executed by an engine and can be visualized, analyzed, and monitored. Processes are useful when components can be reused and composed together or for long-running processes. Both rules and processes allow dynamically changing business logic externally without changing code. They provide benefits like centralized management, easier understanding for non-technical users, and adapting systems through

1. Doing Enterprise Business with
Processes & Rules
Srinath Perera, Ph.D.
Senior Software Architect
WSO2 Inc.

2. Next 45 Minutes
● Leave you with the Big picture
– Why Rules and Business Processes?
– For both: What? How does it work?
What can I do with it? When to and not
to use it?
– Rules and Business Processes in real
world

3. What is the Secret of
Success for Organiza-
tions?
How to survive fierce competi-
tion?
War and Business are two primary com-
petitions we know in history!
Many parallels between war and Business
Art of War is thought in Business school

4. Value of Knowledge
If you know your
enemies and know
yourself, you will
not be imperiled in
a hundred battles
-- Sun Tzu

5. Business at the Speed of Thought
● In Internet scale, we can not
do business manually!
● We delegate to Computer
● Computer is accurate, fast,
(unfortunately or rather fortu-
nately) can not think
● It is crucial to
– embed your knowledge
into computer sys-
tems
– know what to decide
yourself.

6. But Nothing is Forever
Everything that has
been created is subject
to decay and death.
Everything is transitory.
● Any advantage that you hold will disappear over time
● You competition will
– Buy, Steal, Invent, Figure it out,
Evolve, or Copy

7. Natural selection
In the struggle for sur-
vival, the fittest win out
at the expense of their
rivals because they suc-
ceed in adapting them-
selves best to their en-
vironment.
--Charles Darwin

8. OODA Loop (Boyd Cycle)
● Loop is Observe, Orient,
Decide, and Act
● But sooner or later
everyone will follow OODA
Loop
● Boyd said one win by
getting inside others
OODA loop
● Which means you have to
change fast.

9. Adaptation
An organization's abil-
ity to learn, and trans-
late that learning into
action rapidly, is the
ultimate competitive
advantage.
--Jack Welch

10. Agile Organizations
● Even organizations are susceptible to theory
of Evolution
● Organizations have to change fast.
● In the digital age this means agile organiza-
tions which can adept (who can best adept
their systems) has the best chance.

11. Point Is
● Knowledge (how we should act) is the greatest
assert of an organization
● Agile organizations who can understand and
best adopt themselves (knowledge) has best
chance of survival
● In the digital age
To change fast, you have to be able to
to quickly change knowledge embed-
ded within your systems!

12. Business Logic
● In a Organization, we call this
Knowledge Business Logic
● It is how you do things, your under-
standing, process, formula, al-
gorithm, recipe, methodology,
query (minus implementation de-
tails)
● It the decisions we take
–Should we give him a evalu-
ation account ?
–Should we make a partner-
ship with X?
–Should we give him Free
Shipping?
–What is the best Prize?

13. Business Logic Separation
● Business logic changes much faster than rest
of the system
● If your code and logic are mesh together, it is a
nightmare to change them.
We need to sep-
arate the Business
logic from code

14. Typical Architecture
● Mash all together architecture
● 3 tire architecture
● Even with 3 tier architecture still logic is buried in the code
within services
● Good luck in locating and changing them.

15. What do we need?
● Separated Business logic
● Store and manage (edit, share, delete) them in a one
place and through one User Interface.
● If possible in easy to understandable form
● Edit them Visually when possible.
Let's discuss two ways
to implement this separ-
ation:
Rules and Business
Process

16. Business Rules

17. What are Rules?
You must always
drive from the left
(or was it right?)
You should not Eat
Chocolates (Then
pass me a ice cream
please!)

18. What are Rules? (Contd.)
● It is a knowledge representation. (usually partial
knowledge)
● Four types
1)Derivation or Deduction Rules – Each rule
express if some statements are true, another
statement must be true. Called logical
implication. E.g. Prolog
2)Transformation Rules- transform between
knowledge bases, e.g. theorem proving
3)Integrity Constraints – verification rules
4)Reaction or Event-Condition-Action (ECA) Rules
– includes an actions in addition to inference.
e.g. Drools

19. How do Rules work?
● Data represented as Facts
● Knowledge represented as Rules
● A Rule engine evaluates Facts against Rules, and optionally
carry out specified actions. (e.g Drools, JESS)
Two types of Rules Engines:
● Forward Chaining – starts with
facts/data and trigger actions or
output conclusions (Drools)
● Backward chaining – starts with
goals and search how to satisfy
them (e.g. Prolog)

20. Why Rules?
● Externalize the business logic (which are too dy-
namic) from comparatively static code base
● Simplify complicated requirements with declarative
logic, raising the level of abstraction of the system
● Intuitive and readable than code, easily under-
stood by business people/ non technical users
● Create complex interactions which can have
powerful results, even from simple facts and rules.
● Different approach to the problem, some problems
are much easier using rules.
● Fast and scalable when there is a data set that
changes little by little

21. When to use Rules?
● To separate code and business lo-
gic
● When the logic changes often
● When Domain experts are none
technical.
● When all else failed! (When there is
no satisfactory traditional program-
ming approach to solve the prob-
lem! Rules are good in solving prob-
lems that are not fully understood).

22. When NOT to use Rules?
● It is slower than usual code most of the time, so unless there
are obvious benefits
● Complexity of logic is hard to tackle, and one mistake could
change the results drastically and in unexpected ways (e.g.
recursive rules)
● More effort for testing and debugging is required, so if results
are hard to be verified, it should not be used.

23. Rules in SOA
● As a Service (e.g. BRS), As a Mediator (E.g. WSO2 ESB)
● Stored in a registry and referred, so they can be edited and
found in one place, versioned, reverted back, tested separ-
ately

24. Rules in Action?
● Decision tables – in a bidding system, map the bidding rules
to a Decision table implemented with a Excel file. Business
analysts can change the Excel file and change Business logic
of the system.
● A Domain Specific Language that interfaces with rules are
used to describe when free shipping offers should be given to
the user. Business analysts change the DSL scripts stored in
the registry, and Business logic of the system changes.
● Rules are used to route documents between several de-
partments to increase the processing efficiency. When a new
pattern is observed, it can be easily added.
● Rules are used to detect error conditions in a complex de-
ployment and it is easy to add new error conditions by adding
new rules.

25. Business Processes

26. What is Processes?
Baking A Cake?
Production Line
Conduct a Orchestra

27. What are Processes?
● Process captures a set of activities designed to
achieve a specific goal.
● It is a formula, or algorithm, recipe etc.
● Unlike rules, activities in a process are very well con-
nected with each other (a clear flow).
● Examples
– Adding a new employee: Sign the contract, create an
account, assign to a team, give permissions, assign
a seat, order hadrware etc.
– Release a Product: Design, develop, test, market, ..

28. Sample Business Processes
● Nodes (services) are connected via dataflows (dependencies)
or control flows (If, then, while).

29. How do Business Processes Work?
● Business process is described using a Workflow language
(e.g. BPEL, BPMN, Python, Java Script)
● Just like a java script runtime executes java scripts, a workflow
engine executes the workflow description.
– e.g. Apache ODE, WSO2 BPS, MS Workflow Founda-
tion, Dryad by MSR etc.
● It is a programming language:
● Support messaging, asyn-
chronous invocations etc. as
first class
Real difference lies in the
Curiosity is good,
●
level of abstraction.
unless you are a cat

30. Why Processes?
● Abstract out the business logic
● A different level of abstraction to
manage the logic
● Special features
– Can be visualized, analyzed, and verified
– Execution can be monitored
– Execution can be hibernated and resumed
– Failed workflows can be recovered
– Can visually composed
– Workfows can be manipulated at runtime

31. When to use Processes?
● To abstract out the Business Logic
● When there are many reusable com-
ponents (services) that can be com-
posed together (Mathlab like environ-
ments)
● Easy way to evolve the logic (edit)
● For long running processes where
monitoring, recovery, hibernation are
expected.
● When we want to track how business
process evolution took place (through
provenance)

32. When NOT to use Processes?
● Workflows are often slower than normal code
● Add dependency to new tools (workflow engine), complex to
setup and harder to debug.
● When logic is too complex (consider implementing complex
parts as services)
● Do not use unless there are clear benefits

33. Business Process Execution
Language (BPEL)
● A programming abstraction that allows developers
to compose multiple synchronous and asynchronous
Web services into an end-to-end business flow
● Constructs:
– Messaging: invoke, receive, reply, assign,
– Structured: sequence, flow, if, while, repeatUntil
– Exception handling: fault Handlers (throw catch)
– Event processing: onMessage, onAlarm
● Human Task extensions: Let workflows interact with
humans
● BPMN (Business Process Modeling Notation)
– a visual notation for workflows.

34. Processes in Action
● A Service composition Environment: Expose
a set of tools as services and use workflows to create
an environment where users can compose (mash)
them to create interesting processes.
– E.g. Science toolkit
● Governance workflows: Workflows to capture
processes associated with services in a registry dev-
>test->production environment
● Modeling Internal process of an organiza-
tion as Workflows
● Long running business processes: (ability to
hibernate, recover, and monitor executions)
– e.g. Long running scientific worklflows.

35. Rules vs. Processes
Processes are
for well under-
●
stood problems
● where sequence
of actions get us
into expected
state. (e.g. Cook-
ing)
Rules are for partially under-
stood (AI like heuristic driven)
problems. e.g. Chess

36. Conclusion
● Knowledge (Business Logic) is the greatest
assert to a organizations
● Organizations that can adept themselves to
change have the best chance of survival
● Separating the Business logic from the code
enables Business logic to evolve and man-
aged separately
● Business Rules and Business processes are
two ways to extract out business logic.
● We discussed them and their applications with-
in Enterprise Architecture.

37. Questions?