Rule-based Design. Managing complexity!

48
Rule-based Design Dia 1 Managing complexity! HU Summer School 2016 - Business Process Management & IT Rogier van de Wetering, PhD The Open University of the Netherlands August 8 th 2016, Utrecht

Transcript of Rule-based Design. Managing complexity!

Rule-based Design

Dia 1

Managing complexity!

HU Summer School 2016 - Business Process Management & IT

Rogier van de Wetering, PhD

The Open University of the Netherlands

August 8th 2016, Utrecht

Dia 2

Short introduction

Professional experience

• 2015-now Assistant Professor, Management,

Science & Technology, Open University

• 2005-2015 Manager at Deloitte Consulting

• 2010-2013 External lecturer, medical

informatics, Utrecht University

• 2007-2011 PhD research, Utrecht University

Education

• PhD research (‘11), Faculty Mathematics & Computer

Sciences, Utrecht University (A Strategic PACS Maturity

Approach)

• Information Sciences (‘05), Utrecht University, Melbourne

University

Dia 3

1 Rule-based Design

‘An introduction’

09.00-09.50

BREAK

Formalizing

‘From natural

language to

relation

algebra’

10.00-10.50

BREAK

Practice

‘Do it yourself’

11.00-12.00 2

3

The path we will follow this morning….

Rule-based Design

Dia 4

Dia 5

Organizations can in essence be viewed as complex, adaptive socio-

technical systems

Familiar Complex Adaptive System…

Dia 6

Adls, (2013), Charting the Changes [ONLINE]. Available at: http://s3-ap-southeast-2.amazonaws.com/adls-

media/8725730/financialmarkets.jpg [Accessed 7 July 2016].

Dia 7

Familiar Complex Adaptive System…

Shutterstock, (2013), Biomimicry [ONLINE]. Available at: https://s3-eu-west-

1.amazonaws.com/static.nextnature.net/app/uploads/2013/07/ant-bridge_2302146k-640x400.jpg [Accessed 29

June 2016].

Technologies and practices that enable innovation and deal with

environmental turbulence

Dia 8

Business Rules

Ro

bo

tics

Internet of

Things Big data Cloud-computing

Social networks

Mobile /

app

Collaborative

networking

Cyber

security

Co

mp

lex A

dap

tive

Syte

ms

Digital strategy &

innovation

Data-driven

business model

Open data ecosystem

IT-enabled Dynamic

Capabilities

Adaptive Enterprise

Architectures

Watson

Business analytics

What do you really need to know about Rule-based Design

Dia 9

Design systems

and processes

Better

communication

Business/IT-

alignment

Rule-based Design

Make IT

manageable

Flexible

organization

Reduce

complexity

Dia 10

Business Rules, some definitions:

1

2

3

Business rules represent the primary means by which an

organization can direct its business, defining the operative way to

reach its objectives and perform its actions (Wikipedia)

Statement that defines or constrains some aspect of the business... [which is]

intended to assert business structure, or to control or influence the behavior of

the business. It cannot be broken down or decomposed further into more

detailed business rules. (Business Rules Group)

Business rules formalize mutual agreements between stakeholders,

commitments of managers, rights and obligations of employees, etc.

into ‘laws’, intended to serve the purpose(s) of an organization

(Joosten)

Dia 11

Business Rules: verifiable statements

Business rule definition:

“A business rule is a verifiable

statement that some stakeholders

intend to obey, within a certain

context.” ………as intended by the

Business Rules Manifesto

Dia 12

Mantra of Business Rules Manifesto

Mantra:

“ Rules build on facts, and facts

build on concepts as expressed by

terms.”

Dia 13

Mantra of Business Rules Manifesto

Mantra:

“ Rules build on facts, and facts

build on concepts as expressed by

terms.”

Client, Bill, Supplier, etc.

Bills are sent to

customers.

Every sent item (to a

customer) must be

billed.

A. Our policies are transparent to the outside world

B. Rogier goes to bed in the evening and gets up in the

morning

C. E = mc2

D. Johan Versendaal went to the club last night

E. Pascal is an expert on BPM

Dia 14

Question: Are these examples of ‘Rules’?

Rule examples

Dia 15

Banking and insurance

Every application gets a decision

IT service desk

Every (customer/client) call

involves at least one hardware- or

software component

Order management

An order contains no other kinds

of plant than the combined pick

orders

Consumer business

Every sent item must be billed

Dia 16

Business Rules Manifesto: Principles of Rule Independence

Articles 1-5

1. Primary Requirements, Not

Secondary

2. Separate From Processes, Not

Contained In Them

3. Deliberate Knowledge, Not A

By-Product

4. Declarative, Not Procedural

5. Well-Formed Expression, Not

Ad Hoc

Articles 6-10

6. Rule-Based Architecture, Not

Indirect Implementation

7. Rule-Guided Processes, Not

Exception-Based Programming

8. For the Sake of the Business,

Not Technology

9. Of, By, and For Business

People, Not IT People

10.Managing Business Logic, Not

Hardware/Software Platforms

• Business rules actually define the business process

• Signal violations (in real time) and act to resolve them

• Business rules are sufficient as an instrument to design

compliant business processes and information systems

• The role of information technology is to help maintain

business rules

• If any rule is violated (perhaps temporarily), a computer can

signal that and prompt people to resolve the issue

Dia 17

Business rules can be used to manage and control business

processes

Dia 18

There are several important categories of business rules:

1 2

4 3 5

Event-condition-action-rule

Computation / Derivation rule

Invariant rules

Imperative rules

Condition-action-rule

Dia 19

Business Rule Management; dealing with various challenges

Complete and consistent

Getting stakeholders

to commit

Communicate with right

stakeholders

Balance between

‘Rules’ and ‘People’

Alignment with business goals

Key challenges

Some challenges

Dia 20

Rule-based Design draws on research on business rules, software

engineering, relation algebra, and design methodology

• Puts functional requirements at the focal point of the design of business

processes and information systems

• Elicit requirements from various audiences, helping these audiences to make

their wishes concrete

• This requires communicative and advisory skills

• Requirements engineer must interpret requirements to select or write business

rules

• This requires technical insight in information systems that support business

processes

• Requirements engineer must help stakeholders with solutions rather than

endless questions

• Rule-based Design helps requirements engineers with tools that automate large

parts of the design process

• Systems and people together form a system that lives by rules; this leads to

compliance

• Business process management (BPM) is in fact also included: BPM is all about

handling cases

• Cases are governed by a set of rules (e.g. the credit approval procedure)

• When all rules are satisfied (no violations) the case is closed: rule based BPM!

• There is a big difference: workflow based approaches derives actions from

workflow and process models

• We define business rules declarative; invariant rules

Dia 21

Rule-based Design vs workflow based approaches

Dia 22

Within Rule based BPM any violation of a business rule may be used

to trigger actions

• If rules are found to be violated, the

detector signals a process engine

• The process engine distributes work

to people and computers, who take

appropriate actions

• Follows the Plan-Do-Check-Act cycle

• Actions are not specified, but derived!

• Use business rules to define business

processes

• You define the process

• Common basis for data and process side of IS/IT

• Requires formal method

• System boundaries can be articulated

• Functional behavior of the system is defined

• Proof that the system meets specification

Dia 23

The Rule-Based design approach has some important implications

Designer’s perspective for rule based process management

Dia 24

Design artifacts

Rule base

IS development

environment

Dia 25

Rule Maturity: Five Steps to an Agile Enterprise

Dia 26

10 min.

Formalizing Business Rules

Dia 27

Dia 28

A brief recap: what have we learned

Rule-

based

Design

Business Rules are verifiable statements

Rules build on facts, and facts build on concepts as

expressed by terms

There are various types of Rules

Actions are not specified

Systems and people together form a system that

lives by rules; this leads to compliance

Requires formal method

Dia 29

Concepts and relations

concept identifier verb concept identifier

Employer

Shell

HU

OU

Microsoft

Employee

Joris

Pascal

Rogier

Johan

Mark Rutte

works at

works at

works at

works at

works at

Target Source

Dia 30

Concepts and relations: a conceptual model

Concept

Relation

NO RULES

Dia 31

Concepts and relations: an instance diagram

Dia 32

Concepts and relations: : instance diagram of a composition

Actor possesses at

least one of the

Skills required for the

Role

Dia 33

A client name and call identifier is entered. Are there any violations?

Rule 1: Every call must get an

acceptable response.

Rule 2: Every call is entered by

exactly one client.

Rule 3: Every call involves at

least one hardware- or software

component

Rule 4: Every response

describes at least one problem

solution that applies to at least

one component involved in the

call.

The engine will detect various violations

Dia 34

Formalizing rules from Natural language to computer code

From ‘Natural language’

To ‘Semi-formal language’ (e.g. RuleSpeak and other CNLs)

To ‘Formal notation’ (using mathematical principles, e.g. relation algebra, predicate logic,

Boolean algebra, etc.)

To ‘Application’ (Script language)

Normal sentence

For...(concept)...

Must (not)

be...(...)...if

IF..THEN..MUST

Only plants in stock may be

ordered

if an Order is for a Species,

then some Stock exists such

that the

Order affects that Stock and

that Stock is of that Species

is_for affects ; is_of

Dia 35

Founders of the calculus of relations; relation algebra

Augustus De Morgan Charles Sanders Peirce

Ernst Schröder Alfred Tarski

Rules assertion within relation algebra

Dia 36

Left-expression Right-expression

consequent

..implies.. consequent

Set theoretic perspective

Rules assertion within relation algebra

Dia 37

R S is_for

affects ; is_of

• IF ..R.. THEN..S..

• R implies S • If something exist in R, then that

also must exist in S

General case Specific case

if an Order is_for a Species,

then some Stock exists such

that the Order affects that

Stock and that Stock is_of that

Species

Dia 38

RuleSpeak®: set of guidelines for expressing business rules in

concise, business-friendly fashion

• Omitting a Rule Keyword is not good

Every Business Rule Statement should include “must” or “only”. (An order must indicate the customer who places it.)

• “Can” is not good

A customer may purchase a pesticide from a supplier only if the supplier sells that pesticide)

• Extra words for emphasis are not good

A shipment must have a status with no exceptions.

• “To have” is often not good

A team must have a manager. => A team must be managed by a manager.

• Starting with ‘if’ is not good

If an employee is retired, then he must not be assigned an employment counselor => A retired employee must not be

assigned an employment counselor.

• Plural subjects are not good

Programmers must work on a system.

• Actor subjects are frequently not good

A customer may make a withdrawal only if their account is active =>

A withdrawal for an account may be made only if the account is active

Dia 39

RuleSpeak®: some guidelines

DEMO using Ampersand method RAP2

Dia 40

http://is.cs.ou.nl/rap2/index.php

Dia 41

10 min.

Practice

Dia 42

Dia 43

A brief recap: what have we learned

Relations

Relation algebra / script language

Rules

Business Rules are verifiable

statements

If something exist in R, then that

also must exist in S

Formalizing

Left-expression Right-expression

..implies.. consequent

From ‘Natural language’

To ‘Semi-formal language’

To ‘Formal notation’

To ‘Application’

Dia 44

Assignment introduction for teams

1. Select a case (see next sheet)

2. Select a typical (simple) process (or sub-process)

3. Identify a business ‘problem’ (be creative!) – related to this process, or

as a result of executing this process

4. Define 3-4 concepts and their ‘atoms’ (Course: BPN, EA, RBD, IT-

governance, etc.)

5. Draw a conceptual diagram

6. Define some relations

7. Formulate a couple of ‘Rules’ (e.g. in natural language, CNL,

RuleSpeak, etc.) – Cycle chasing

We will work on this in teams of 4. After 30 minutes, the teams shortly

present their outcomes!

Dia 45

Various cases, pick one!

1. Healthcare: patient registration 2. Education: course registration 3. FSI: loan / mortgage approval

A) HR-process: Bonus payment B) Order management: sending bill IND: application decision making

Ind

ustr

y

Pro

cess / c

ase

Q&A

Dia 46

• Van de Wetering, R., & Bos, R. (2016). A meta-framework for Efficacious

Adaptive Enterprise Architectures, in Proceedings of the International

Conference on Business Information Systems. 2016, Springer International

Publishing: Leipzig, Germany. [download] [download]

• Van de Wetering, R. (2016). Modeling Alignment as a Higher Order Nomological

Framework, in Proceedings of the International Conference on Business

Information Systems. 2016, Springer International Publishing: Leipzig, Germany.

[download] [download]

• Mikalef, P., Pateli, A., & Van de Wetering, R. (2016). IT flexibility and competitive

performance: The mediating role of IT-enabled dynamic capabilities, in the

Proceedings of the 24th European Conference on Information Systems (ECIS).

[download] [download]

• Van de Wetering, R., & Batenburg, R. (2014). Towards a Theory of PACS

Deployment: An Integrative PACS Maturity Framework. Journal of Digital

Imaging, 27(3), 337-350. [download] [download]

Dia 47

Further reading on adaptive principles, alignment and dynamic

capabilities