1. Aligning Software Systems with Business Operations
Marlon Dumas
Institute of Computer Science University of Tartu

2. Bridging IT and Business Value
Information
Technology
Business
Value
Enables
Yields
Process
The efficiency of the business processes determines the value of IT.
Change
Index Group (1982)

3. Bridging IT and Business Value
Business Process Management
Business Value
Service-Oriented Architecture
IT Capability

4. BPM: What is it?
Methods and techniques to design, analyze, execute and monitor business operations involving humans, software, information and physical artifacts using process models.

5. BPM: Why should we care?
“The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.”

6. BPM: Value Proposition
Increase transparency along business processes
understand and appreciate ‘new’ options for improvement
processes – involved resources – documents/products – technology
reduce processing & wait time
reduce processing costs
increase customer satisfaction
align business and IT

7. Business Process Modeling: “As-Is” vs “To-Be”
Strategy / Goals
Achieving
As Is
Issues
Barriers
Overcoming
(Weaknesses
Opportunities)
Guidelines
Capabilities
Utilising
(Strengths
Enablers) IT
Knowledge
People
Ability to change
Culture
To-Be
Best Practice
Learning
Reference
Models
Bench
marking
Ideal
models
Study
tours

8. Business Process Lifecycle
Process Modeling Tools
Process Management Systems
In the following we will specify the process modelling task. Especially, we will understand the characteristics of a model, the difference between a meta and a reference model, and how the event-driven process chains (EPC) can be used to design process models.

9. Example: Fragment of “As Is” Model

10. Business Process Implementation

11. Business Process Implementation – Technology Options
Plain Java or .Net
Process Programming Environments
Tightly Integrated with programming languages and development environments
e.g. Windows Workflow Foundation, jBPM
Business Process Management Systems
Integrated modeling and execution
e.g. Websphere, BizTalk, Oracle BPEL, YAWL

12. BPM System: Classical Architecture

13. Case Study –YAWL in the Film Industry
Preparation
Pre-production
Production
Post-production
All aspects related to the practical production needs of the project
The most expensive stage where the actual shooting is conducted
All steps that have to be done btw. production & final delivery
Concept
Development
Finance

14. Film Shooting Process Model

15. Worklist Handler

16. Sample Human Task Interface

17. BPM is not all blue sky
Limited scope: coordination-intensive scenarios
Addresses business logic integration, but not data or technology integration
May require heavy application re-architecting
Ad hoc adapters all over the place

18. SOA: What is it?
A Service-Oriented Architecture is a structured collection of software services.
A software service:
Is an asset that is owned and maintained by a provider for use by one or multiple clients
Shares contracts and standards and nothing else!
Is business-oriented and reusable
Software Service ≠ Web Service

19. SOA: Value Proposition
Organise systems into standardized services with explicit dependencies and contracts
Understand the value of each service, its touch-points, interactions, performance metrics, contract violations...
Increase external transparency
Reduce integration costs
Increase agility

20. Components of an SOA … … App-1 App-2 App-N Front-end Applications
Service Bus
Service Description
Repository
Service-1
Service-2
Service-M
Services …

21. The Service Bus
Connects services, front-ends and repositories in an SOA
It is not a software product (even though some vendors would like to sell it as such!):
Needs to support a variety of technologies & communication modes
Needs to be cross administrative domains…

22. Types of Services
Basic
service
Are the foundation of the SOA. They represent the basic
elements of the vertical domain. Include both data centric
and logic centric services.
Intermediary
service
Include technology gateways, adapters, facades and
functionality-adding services. Are both client and server
in a SOA. They are stateless.
Process
centric
service
Encapsulate the knowledge of the organization’s processes.
Typically both client and server in a SOA, and maintain the
process state.
Public
enterprise
service
Provide interfaces for cross-enterprise integration.
Thus they are of coarser granularity and have appropriate
mechanisms for eg decoupling, security, billing or robustness.

23. SOA & BPM go hand in hand
System Silos
Integrated Systems

24. Technology Options – Web Service Stack

25. SmartEDA: Integrated Land Development Application System

26. Danske Bank: Customer Package Process
© Steen Brahe, 2007
Juni 2003
August 2003
October 2003
December 2003
Marts 2007
Introduction of Customer packages.
Word template to collect info

27. Danske Bank: Customer Package Process
Juni 2003
August 2003
October 2003
December 2003
Marts 2007
Backoffice group created
Handles the creation process

28. Danske Bank: Customer Package Process
Juni 2003
August 2003
October 2003
December 2003
Marts 2007
Case Transfer System
Automatic validation and transfering

29. Danske Bank: Customer Package Process
Juni 2003
August 2003
October 2003
December 2003
Marts 2007
Workflow enabled creation process v. 1
Automatic process control, 0% automated activities

30. Danske Bank: Customer Package Process
Juni 2003
August 2003
October 2003
December 2003
Marts 2007
Workflow v. 6
80% automated activities

31. Executable Business Process
Danske Bank SOA
Executable Business Process A1 A3 A2 A4
WSDL A1
WSDL A2
WSDL A3
WSDL A4
Service Bus
App1: COBOL
App2: PL1
App3: Java
App4: C#
© Steen Brahe, Danske Bank

32. BPM/SOA Lifecycle and Roles
Developer
Solution Architect
Tester
Business Analyst
Continuum between business stakeholders and IT stakeholders.
Administrator

33. The Ideal Picture Business Stakeholders Services Business processes
IT Stakeholders

34. Reality: Danske Bank’s Experience
For a typical process:
Business analyst’s model: 12 activities
Solution architect’s model: 36 activities
Developer’s model: 200 activities
Models not in sync!
Hundreds of services, thousands of operations:
How are services related to business processes?
How to make the most out of these services?

35. Danske Bank’s Experience (cont.)
Mismatch between business & implementation models:
Business model focuses on “normal path”  implementation must deal with all faults
Business model does not capture all dependencies
Business model contains activities not relevant to implementation and vice-versa
Some activities in the business model break down into multiple activities in the implementation
Business model and implementation model in different notations (e.g. BPMN vs. BPEL)

36. Cannelloni or Spaghetti?
<process name="salesBP"...>
<partnerLinks>
<partnerLink name="salesPL" myRole="provider"
partnerRole="requester" partnerLinkType="salesPLT"/>
</partnerLinks>
<variables>
<variable name="rfQ" messageType="rfQMsg"/>
<variable name="quote" messageType="quoteMsg"/>
<variable name="order" messageType="orderMsg"/>
<variable name="cancelOrder“ messageType="cancelOrderMsg"/>
<variable name="rejectRfQ" messageType="rejectRfQMsg"/>
<variable name="goodsAvailable" type="boolean"/>
</variables>
<correlationSets>
<correlationSet name="salesCS" properties="rfQId"/>
</correlationSets> …

37. One step closer, but still a long way…
Business Stakeholders
Intuitive process models
KPIs, customer touch-points, issues, opportunities, risks…
Communication, simulation, activity-based costing…
IT Stakeholders
Executable process models
Data types, transition conditions, data mappings, fault handling…
Integration, testing, deployment…

38. Challenge: Achieving Alignment
Generating code from high-level process models
E.g. BPMN-to-BPEL, BPMN-to-Java
Propagating changes from high-level process models to implementation and vice-versa
Measuring alignment between process models and their implementation
By comparing execution logs against process models

39. A First Step: BPMN-to-BPEL Mapping
BPMN: Business Process Modelling Notation
Flowchart-like notation for business processes
BPEL: Business Process Execution Language
Block-structured language for executable processes
BPMN2BPEL
Transforms BPMN models into BPEL
Based on an algorithm to detect structured, quasi-structured and minimally-unstructured BPMN fragments
Allows implementation details to be added without breaking the link between BPMN and BPEL models.

40. Sample BPMN Process Model

41. Identification of Structured Fragments

42. Generated BPEL code <sequence>
<invoke “check stock availability” …/>
<switch (…) …/>
<case “reject”> <invoke “order rejection” …/> </case>
<otherwise>
<invoke “order acceptance” … />
<flow> <invoke “invoicing” … />
<invoke “ship goods” … />
</flow>
</sequence>
</otherwise>
</switch> </sequence>

43. Process–Process Alignment: Open Issues
One-way mappings are not enough
leads to misalignment
Refinement is not an appropriate notion
unrefined model contains information that the refined model does not contain
refined and unrefined model evolve independently
Need methods and tool support for business process model co-evolution

44. Another Step: Conformance Checking
Services
abstract
BPEL
process
Services
Services
Conformance?
SOAP
Messages
Translation 1.
Monitoring /
Correlation 2.
Petri net
model
Conformance
Checking!
Event Log

45. From BPEL to WF-nets

46. Petri net-based Conformance Checking
Objectives:
quantitatively measure conformance
locate deviations
Conformance?

47. Conformance Checking – Fitness

48. Conformance Checking – Fitness

49. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 0
consumed tokens
produced tokens
= 0
= 1

50. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 0
consumed tokens
produced tokens
= 1
= 2

51. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 0
consumed tokens
produced tokens
= 2
= 4

52. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 0
consumed tokens
produced tokens
= 3
= 5

53. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 0
consumed tokens
produced tokens
= 5
= 6

54. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 0
consumed tokens
produced tokens
= 6
= 7

55. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 0
consumed tokens
produced tokens
= 7

56. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 0
consumed tokens
produced tokens
= 9

57. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 0
consumed tokens
produced tokens
= 9

58. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 0
consumed tokens
produced tokens
= 0
= 1

59. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 0
consumed tokens
produced tokens
= 1
= 2

60. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 1
= 0
consumed tokens
produced tokens
= 2
= 4

61. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 1
= 0
consumed tokens
produced tokens
= 3
= 5

62. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 1
= 0
consumed tokens
produced tokens
= 4
= 6

63. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 1
= 0
consumed tokens
produced tokens
= 6
= 7

64. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 1
= 0
consumed tokens
produced tokens
= 7
= 8

65. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 1
consumed tokens
produced tokens
= 8

66. Measuring fitness: Log replay analysis
missing tokens
remaining tokens
= 1
consumed tokens
produced tokens
= 8

67. Measuring fitness: Log replay analysis

68. Measuring fitness: Log replay analysis

69. Conformance Checking - Appropriateness
100 % fitness
but not sufficiently
specific from
behavioral point of view.
100 % fitness
but not represented in
structurally suitable way.

70. Trend: Service Ecosystems
Service marketplaces controlled by a single entity (e.g. SalesForce AppExchange, StrikeIron, Amazon Web Services, SOATrader).
Open service communities built around services provided by a single entity (e.g. Google mashups).
E-Government service marketplaces (e.g. BizDex, DirectGov).
Mobile Service Marketplaces (e.g. Intel Digital Communities Initiative, Fortumo.com?)

71. Web Service Ecosystems – Example
Taleo
SPS Commerce

72. Drivers for Service Ecosystems
Technology
Web service technology
moving into mainstream
Increased maturity of hosted
applications technology
Increased use of web service intermediaries – e.g. PayPal has 100 million customers
Pilots,
Ventures
UKOnline / National E-Markets
German Texo project
US Govt pervasive government services strategy
$3-5 billion investment South China eGov
Bay Area
Digital Communities
and HomeCare
European
Media Home
Platform
Business
3rd party services average 30% to 80% of F1000 annual corporate expenditure (Gartner, IDC, Aberdeen)
Software-as-a-service growth rate at 20-30% per annum (IDC, Gartner)

73. Web Service Ecosystems - Architecture

74. Web Service Ecosystems – Challenges
Service discovery – Google of Services
Service contracting – How to make it precise and easy?
Management of evolution and compliance
Heterogeneity  semantic integration

75. Summary
Modern software engineering strives to achieve higher levels of business–IT alignment
SOA & BPM are one step, but there’s a long way to go…