The document discusses the challenges of robustness in process management, particularly the effects of coding on system performance during peak usage. It emphasizes the importance of proper exception handling, transactional consistency, and the distinction between business processes and system architecture. Additionally, it notes the role of etiquette in organizational processes and provides insights on using simulation to optimize workflows.

1. Keith D Swenson
May 2015
@swensonkeith
Robustness in Process
http:// www.slideshare.net / kswenson / mribp2015

2. 1. Coding Effect on Robustness
2.Process and Transactions
3.Transactions and Messages
4. Distributed Scenarios
5. Etiquette

3. APPLICATION
DISK SPACE ….

4. The Day the Application Stood Still
 Application built and deployed
 Works fine with some number of people, say 50
 CPU is around 2%
 Memory and disk IO is reasonable
 Above that number of people
 CPU spikes to ~90%
 Users complain of frozen screens
 Disk IO and memory usage spike
 Becomes impossible to do the simplest tasks
 What is going on?

5. The Beast
...
try {
InitialContext cxt = new InitialContext();
String dataSourceJndi = mapComponentSettings.get("AssocDataSource");
DataSource ds = (DataSource) cxt.lookup(dataSourceJndi);
privateAssociations.setDataSource(ds);
}
catch (Exception e) {
log.error("Unable to load JNDI data source from context.");
}
...

6. Don’t Swallow
Exceptions

7. ...
try {
InitialContext cxt = new InitialContext();
String dataSourceJndi = mapComponentSettings.get("AssocDataSource");
DataSource ds = (DataSource) cxt.lookup(dataSourceJndi);
privateAssociations.setDataSource(ds);
}
catch (Exception e) {
log.error("Unable to load JNDI data source: " + e.toString());
return null;
}
...

8. Don’t Swallow
ExceptionsYou Don’t Know
what the
Exception
will be!
ADD the
Current
Context
& RETHROW
Don’t Log
IT!
Callers
Don’t test
For NULL

9. Normal
Situation
Error
Situation
Error
Situation
Error
Situation
condition
condition
condition

11.  Started at Netscape in 1990’s
 Input to Java team
 Informed by projects from iFlow
and Interstage BPM in 2000’s
 While the purpose of error
reporting is to assist in solving
the problem.
 There is a problem
 The system can’t handle it
 The more completely the problem is
described, the faster it is resolved,
the happier users will be.

12.  Throwing an exception should never be used to return a "normal" value
back to the caller.
 Describe the current scope! Not what you think caused the exception.
 Use a single monomorphic exception class.
• Every method (that throws) should declare throwing java.lang.Exception.
• Every catch block should catch java.lang.Exception
 Do not assume that there is only one possible exception to be caught.
Always test for the exact exception class and the exact message key
before handling the exception in any other way than wrap and re-throw.
 Don’t worry about making catch blocks efficient. Instead, design them to
be easy to maintain and easy to verify that the exception correctly
handled.
 Act as if LOG files are not accessible

13. https://agiletribe.wordpress.com/

14. TRANSACTIONS

15. 3GL Code
Data Sources

16. Resting state Transaction
Occurs
Resting state

17. A transition is a transaction
Transaction
Data Sources

18. Transaction Rollback … User View
Transaction
Rollback
Data Sources
Fail

19. Data Sources
Error State
Resting state
(error mode)
Transaction 1 Fail
Rollback
Transaction
2

20. Subprocess Scenario
Parent Process
Child Process

21. Subprocess Scenario
Parent Process
Child Process

22. Subprocess Scenario
Parent Process
Child Process

23. Subprocess Scenario
Parent Process
Child Process

24. Subprocess Scenario
Parent Process
Child Process

25. Subprocess Scenario
Parent Process
Child Process

26. Retries are Evil
Retries!
Data Sources

27. BPMN Transactional Notation

29. Transaction 1
Transaction 2

30. A Single
Transaction
Any failure in
either node,
you roll back to
where you started,
and put the process
in error mode.

32. What does this mean?
A BPMN transaction boundary

33. Something like
this might make
more sense …
but not really.

35. Front
1
2
3
Unit 1 Unit 2
Unit 3
4
5
6
Message
Bus

36. Front
Unit 1 Unit 2
Unit 3
Unit 5
Unit 4
Message
Bus

37. Fire and Forget
Front
Unit 1 Unit 2
Unit 3
Unit 5
Unit 4
Fail
Message
Bus

38. HOWEVER…

39. Distributed Systems
One transactionally
consistent enclave
Another transactionally
consistent enclave
You have to deal with the fact that you can not have
transactional consistency everywhere

40. Business Process != System Architecture

41. Business Process != System Architecture

42.  Required configuration in 6 different environments to be
consistent.
 If one got our of sync, it broke the processes.
 Messages were assumed to be reliable, but between reliable
system, they can NOT be reliable.
 Your protocol MUST assume that messages are reliable, and
must deal with that.

43. Gringo
Symposium Process
Reserve
Room
Invite
Speaker
Order
Drinks

44. Gringo
Symposium Process
Order
Drinks
Order Fulfillment
A
B
Infinite Liquors
A reliable message
Transport with
“exactly once”
delivery
“Six cases of
Sierra Nevada
Pale Ale for
delivery.”
2:07 PM 2:07 PM

45. Gringo
Symposium Process
Order
Drinks
Order Fulfillment
A
B
Infinite Liquors
Disk
Crash
2:10 PM

46. Gringo
Symposium Process
Order
Drinks
Order Fulfillment
A
B
Infinite Liquors
2:30 PM
1:00 PM
Backup
2:30 PM

47. Reliable
System
#1
Reliable
System
#2
Always
Consistent
Always
Consistent

48. Reliable
System
#1a
Reliable
System
#1c
Always
Consistent?
#1b

49. Consistency Seeking
Gringo
Symposium
Order
Drinks
Order Fulfillment
A
B
Infinite Liquors
Orders
FOR
Infinite
Liquors
Orders
FROM
Gringo
Compare.
Are these
Consistent?
Take action
To make
Consistent.
Hourly
Poll.

50. Ship Bridge
to Engine Room
telegraph
use the same
principle

51. BPM

52. Roles, and Etiquette
Purchasing Agent Product Development

55. Business Etiquette Modeling
 For each role in an organization, determine:
 each of the services that role might perform
 what must be provided
 what will be produced
 what conditions will decide whether the task is accepted or not
 what contexts all this is valid in
 Use simulation across many roles in the organization to see if
the process is ‘optimal’
 tweak the etiquette rules as necessary
 Record history and track KPIs like normal
 Respond if necessary by tweaking the etiquette rules

59. Cross Company Emergent Processes
Manufacturing Company
Consulting Firm

60. 1. Coding Effect on Robustness
2.Process and Transactions
3.Transactions and Messages
4. Distributed Scenarios
5. Etiquette

61. Workflow Management Coalition
• Standards
• Books
• Awards
• Information

62. Four years running. Four books
Real-life use cases.
Experience with ACM.
http://AdaptiveCaseManagement.org/
Workflow Management Coalition
2014:
Thriving on
Adaptability:
Best
practices
for knowledge
workers

63. NEW!
When Thinking Matters in
the Workplace: How
Executives and Leaders of
Knowledge Work Teams can
Innovate with Case
Management.
http:// ThinkingMattersBook.com

64. Q & A
http:// www.slideshare.net / kswenson / mribp2015

65. Antifragility
http:// www.slideshare.net / kswenson / bpm201446:00

66. We know what
fragility is.
But what is
the opposite?
Fragile

67. ?
Fragile Robust

68. Fragile Robust Antifragile

69. Definition of BPM
Business Process Management (BPM) is a
discipline involving any combination of
modeling, automation, execution,
control, measurement and optimization
of business activity flows,
in support of enterprise goals,
spanning systems, employees, customers and partners
within and beyond the enterprise boundaries.

70. “The System”
Your
Organization
IT
System
&
People
Offices
Agreements
Skills
Expertise
Relationships
Hardware
Software
Data
Desire to
optimize
the entire
system