LOGiCOM
Putting Workflow and BPM
standards into context
Sharon Boyes-Schiller
UK Country Chair
Workflow Management Coalition
e-Science Workflow Services, Edinburgh
3 December 2003
Standards and Understanding
LOGiCOM
“Very little work has been done
in order to define a precise semantic
for inter-organizational business modeling.”
Dussart, Aubert, Patry (2002)
LOGiCOM
I need you to listen
– Deliberately controversial
I need you to think
– What will be the impact of this on you?
My assumptions may not be true
– If not why?
Big money on being spent on this area of technology
– Big egos, Big IQs, Big jobs
Putting it all in context
Standards Adoption
– How many standards do you
need?
The problem the user faces
The technologies involved
What you don't need
What you should do
LOGiCOM
Standards Adoption
LOGiCOM
How many “universal” standards are fully adopted?
Think about their implementation
– What they do
– Infrastructure-based or application
– What do those that are adopted provide?
The Problem
LOGiCOM
1995
– One standards group for process technology (workflow)
– Reference model + 5 interface standards
– Size of the average specification ~ 40 pages
Workflow
Business Process
Management
Collaborative
Organizational
Processes
Model
e-Commerce
Web
Services
Wasn’t XML supposed to make our life easier?
2003
– 10+ standardization groups with interest in workflow
– 7+ standards for process models alone
– Size of the average specification ~ 100 pages
LOGiCOM
The problem with standards?
There are so many to choose from ☺
Established Standardization Players
Workflow Management Coalition
– Workflow Process Definition Language
(WPDL/XPDL)
– Workflow Process Interchange (IF 4/Wf-XML)
Object Management Group
– OMG Workflow Facility
– Process Definition RFP (bom/99-10-03)
– Extension of UML for Workflow Modeling
National Institute for Standards and Technologies/MIT
– Process Specification Language (PSL)
– Process Interchange Format (PIF)
LOGiCOM
Recent Standardization Players
LOGiCOM
Business Process Management Initiative
– Business Process Modeling Language (BPML)
– Business Process Modeling Notation (BPMN)
– Business Process Query Language (BPQL)
Electronic Business XML (ebXML)
– Business Process Schedule Specification (BPSS)
OASIS
– Business Transaction Protocol (BTP)
HP Labs / W3C
– Web Services Conversation Language (WSCL)
SUN/BEA / W3C
– Web Services Choreography Interface (WSCI)
IBM
– Web Services Flow Language (WSFL)
Microsoft
– XLANG
DARPA
Business Process
Execution Language for
Web Services
(BPEL4WS)
– DARPA Agent Markup Language – Services (DAML-S)
Standards options
LOGiCOM
Minimum Approach
– Design a set of complementary standards
– Example: IBM/Microsoft
• BPEL4WS
• WS-Coordination
• WS-Transaction
• WS-Security
Maximum Approach – one size fits all
– Design one all-encompassing standard
– Example: BPMI
Distributed Process Model
LOGiCOM
Process Models
Business Process Analysis,
Modelling & Definition Tools
Build Time
- Hierarchical Subprocess
- Chained Subprocess
- Parallel Synchronised
Process View E2E
Process
Fragment
Process
Fragment
Process
Fragment
Local
Resources
Local
Resources
Run Time
Process Execution
Environments
Local
Resources
Process Control Interactions
Message / Data Interactions
Process Fragment - “black box” with internal behaviour typically invisible & boundary behavior defined in
terms of interactions with other processes
Process Fragments - typically enacted in separate organization domains using heterogeneous product /
technology
Scope of existing standards
Process Notation Standards
LOGiCOM
Process View E2E
BPMN
Process
Fragment
Process
Fragment
Process
Fragment
Local
Resources
Local
Resources
Local
Resources
Process Definition Standards
XPDL
BPML
BPEL4WS
Process Interaction Standards
Wf-XML
WSDL
SOAP
Scope of Choreography
LOGiCOM
Choreography - The specification of the ordering of potential
interactions between BPM systems
Process View E2E
Emerging Standards
WSCI
(BPEL4WS)
Process
Fragment
Process
Fragment
Process
Fragment
Local
Resources
Local
Resources
1
4
XPDL + proposed
extensions?
2&3
Local
Resources
BPEL4WS – Interaction mapping to Wf-XML
BPEL4WS
•<receive>
•<reply>
•<invoke>
•<assign>
•<throw>
•<terminate>
•<wait>
•<empty>
•<sequence>
•<switch>
•<while>
•<pick>
•<flow>
•<scope>
•<compensate>
Specification
LOGiCOM
Wf-XML
[Blocking wait]
Response
Request-reply functionality
Create Process Instance
Set context data
[Exception conditional Transition (XPDL)]
Change Process Instance State
(Handled by conditional expression)
(Null Op e.g. Get Process Instance Data)
(similar to inline block)
(Conditional Transition)
(Conditional Transition)
(Conditional Transition)
(Conditional Transition)
[partially overlaps with exception condition]
(modelled as separate activity called by exception condition)
Runtime Interaction
WSCI Elements
WSCI
LOGiCOM
Wf-XML
Interface
Selector
Correlation
Process Instance Id (Key)
Correlation properties
State, context result data
Model
Actions
Operations e.g. Start process
instance
Wf-XML Runtime Operations
LOGiCOM
XML Data Elements
Create Process Instance
Observer key, Context data
Provider
Process instance key
Requester /
Observer
Get Process Instance Data
Result Data Set
Result Data
Notify
Event Context Data
Change Process Instance State
To – State [& context data]
State entered
Process Instance State Changed
State, Result Data
Process Instance State Changed
State:Completed, Result Data
Optional
What standards are relevant?
Process definition
– XPDL
– BPML
– BPEL4WS
Process Choreography
– WSCI
– (BPEL4WS)
Process execution support
– Wf-XML
Supporting areas
– SOAP
– WSDL
– UDDI
LOGiCOM
LOGiCOM
The Reference Model
Process Definition
& Modelling Tools
Specification 1
Do you need more than
Interoperability and Audit?
Process Definition
Specification 5
Audit Data
Specification 2
LOGiCOM
Specification 4
Process Management
Engine
Performer
Interface
Application
Interface
Clients
Invoked
Applications
Process
Interoperability
Specification 3
Other
Process
Management
Systems
LOGiCOM
Standards are a good thing!
?
Need to ensure a real
business benefit
Business Owner Benefits
Reduced risk & investment protection
Long term integration
Better partner relationships
Extend the reach of the business
LOGiCOM
User responsibility
LOGiCOM
We get the standards we deserve…
Lack of input from Business Users means that there is
the potential for technologists to misunderstand the
business requirements.
BUSINESS USERS NEED TO BE
INVOLVED IN STANDARDS DEVELOPMENT !!
The problem we’re trying to solve!
LOGiCOM
Look again at this
LOGiCOM
Vendor assumptions been made
Vendor assumptions
LOGiCOM
We will need a common platform
We will share processes and IP
We will run processes outside of our
organization
We will restrict our needs to fit standards
The business users will pay for these
standards…
Converse assumptions
LOGiCOM
Let’s assume that:
–
–
–
We won’t need a “standard” platform
We won’t use “standard” procedures
We won’t use Web Services outside the firewall
•
–
–
–
–
Unless it is process driven
We won’t share our intellectual property
We want widest exposure
We want investment protection with max agility
We want total control
•
Processes change depending on usage
What do you need?
LOGiCOM
If our assumptions are correct…
(based on Jon Pyke’s 15 years experience at Staffware and WfMC’s 10
years as the standards leader)
What do business users need?
–
Standard notation say – BPMN
–
Interoperability – I/F 4 from WfMC (Wf-XML)
–
Audit capability – I/F 5 from WfMC
–
Process query (possibly) – BPQL
–
Business to Business Interaction BPEL
• To run a procedure for someone else
What you don’t need
LOGiCOM
We don’t need:
– Complex standards that don’t deliver
– Dominant vendors dictating technology
direction
– Standards based on theory
•
•
Of how business works
Of how procedures work
The cost
But who is going to pay ?
Are the standards free and unfettered?
Do business users pay a royalty?
Are business users prepared to pay for
something that:
–
–
–
They may not need
Free alternatives available
No business value
What do you think?
LOGiCOM
What do you do?
LOGiCOM
Get involved in the Standards debate
– Or else we will not develop what’s
needed
Don’t delay in moving forward
– Retrofit standards later if you need them
– Waiting is going to cost you
– Good standards will always give you
interoperability.
Demand, demand, demand
And remember
LOGiCOM
Standards only have value if:
They are useful
They deliver business benefit
They are simple to use
They are adopted
…and that depends on you, the user and the vendor
LOGiCOM
Thank you
WfMC Material provided by Layna Fischer, General Manager & Jon Pyke, Chair
Thanks also to:
zur Muehlen, Michael: Workflow Modeling Languages for B2B Processes.
SAP Innovation Congress 2003, Miami, FL, February 15-27, 2003.
Slides 3, 5, 6, and 7