1. S-Cube Learning Package
Business Transaction Modeling, Analysis, and
Customization Across Service Networks
Lero- the Irish Software Engineering Research Centre
Rafiqul Haque & Noel Carroll
www.s-cube-network.eu

2. Learning Package Categorization
S-Cube
Business Transaction Language
Analysis of Service Network
Modeling and Analysis Business
Transaction in Service Network
© Rafiq & Noel

3. Learning Package Outline
 Background
 Business transaction – Requirements
 Research Problem
 Research Contribution
 Discussion
 Conclusion & Future Works
 Further Reading
© Rafiq & Noel

4. Background: Service World
 Develop an understanding the operations of service networks:
– Adapt to ever-changing business environment
– Agile Service Networks
 Dispersed complex service eco-systems
– Monitoring performance becomes a difficult task.
 View a service network as a specific set of linkages
– Set of actors: properties can characterise the linkages which
influence service behaviour.
– Modelling service operations and analytics to enhance service
requirements
– Need to Introduce:
- Business Transaction Language (BTL)
- Service Network Performance Analytics (SNPA)
- Social Network Analysis (SNA)
© Rafiq & Noel

5. Background: Service Environment
 Complex business interactions
 The World is Flat!
 Service Science: need to investigate the contributory
value of business processes and its IT-enabled influence
on service performance.
– Exchange of resources
– Application of competences
– Value co-creation through interactions
 Technological advances continue to act as a driving force
for ‘making new patterns and a new elevated level of
value creation possible’ (Normann, 2001; p. 8)
– Need to understand how process patterns influence service
performance.
© Rafiq & Noel

6. Background: Service Science - Interaction
View
 Unite two disciplines:
– Service computing
– Service management
 Performance is often influence by
external entities causing structural
variability across a service eco-system
– Enhance service management decision-
making tasks (service management),
– Feed performance information into service
requirements engineering (service
computing).
 Significant gap in our ability to bridge and
advance our understanding of technology
and management in this so called
‘service-dominant’ business environment.
© Rafiq & Noel

7. Background: Defining Service
Science
 “Study the application of the resources of one or more systems for the
benefit of another system in economic exchange” (Spohrer et al., 2007;
p. 2).
 Define how and why services generate value.
 Four key observations about these disciplines:
– Heavily resource dependent
– Tend to integrate or coordinate resources
– Measuring performance is very important.
– Disciplines incorporate the word “service”, e.g. service engineering.
 Develop methods to extend the availability and accessibility of business
processes.
 Improving manager’s ability to:
– Predict risk
– Estimate their effects
– Reduce uncertainty through modelling value-exchange
© Rafiq & Noel

8. Background: Evolution of Business
Transaction
“We
cannot
solve
problems
by
using
the
same
kind
of
thinking
we
used
when
we
created
them”
–
Einstein
© Rafiq & Noel

9. Background: ACID – The Four
Commandments
The
notion
of
transaction
begun
with
four
commandments..
 “
You
shall
commit
when
all
other
has
committed
otherwise
you
shall
sacrifice
thyself
”
-­‐
Atomicity
 “
You
shall
not
commit
wrongdoing,
you
shall
maintain
integrity”
–
Consistency
 “You
shall
wait
for
other
to
be
completed
first”
–
Isolation
The Tablet of
 “You
shall
not
keep
things
unsafe”-­‐
Commandments
Durability
© Rafiq & Noel

10. Background: example of classical ACID
transaction
A
transaction
is
T
={T1,
T2,
T3,
and
T4
}
can
be
completed
successfully
only
when
all
of
its
sub-­‐transaction
is
committed
successfully
.
© Rafiq & Noel

11. Background: ACID – is suitable in business
transaction?
Is
ACID
suitable
for
Business
Transaction
?
ACID
Burns
Long
Running
Business
Transaction
© Rafiq & Noel

12. Background: example of ACID in
business transaction
© Rafiq & Noel

13. Background : Definition of Business
Transaction
 A business transaction is a series of collaborative
activities distributed across multiple partners and
performed as a single unit of work (in a flexible manner)
by accomplishing the commitments agreed upon by the
partners.
 “Commitments” is the specification of functional and
non-functional obligations that guide to achieve the
(common) business goals. Formally, it is called
Agreement or Contract.
© Rafiq & Noel

14. Background: Example of collaborative
Business Transaction
© Rafiq & Noel

15. Background: Characteristics of Business
Transaction
 In a networked business environment, business
transactions -
– are performed collaboratively involving multiple participants.
– incorporate real-world business elements such as business
and compliance policies, Quality of Services (QoS), critical
business activities, and Service Level Agreement (SLA).
– commits independently because they are autonomous.
– are long-running takes days, months or sometime years to
complete one transaction cycle.
– prone to failure because they traverse numbers of distributed
business resources (applications) hosted at different locations;
additionally, service based business is highly dynamic where
demands scale up and down erratically.
Note: We have extracted these characteristics through extensive analysis on business
cases(some fictitious, some real) taken from [Schimchi-Levi et al.]
© Rafiq & Noel

16. Background: Correlation between
business elements and transaction
© Rafiq & Noel

17. Learning Package Outline
 Background
 Business transaction – Requirements
 Research Problem
 Research Contribution
 Discussion
 Conclusion & Future Works
 Further Reading
© Rafiq & Noel

18. Business Transaction– Requirements
 Transaction model that aligns the real-world business
elements so that they can be defined/designed and realised
during processing transactions.
 Technique/method/means to support the transactions
involving distributed and autonomous applications.
 Technique/method/means to support the transactions in
various situations including dynamic, variable, and
uncertain situations. In other words, handling these situations
successfully by avoiding total failure of transactions .
© Rafiq & Noel

19. Learning Package Outline
 Background
 Business transaction – Requirements
 Research Problem
 Research Contribution
 Discussion
 Conclusion & Future Works
 Further Reading
© Rafiq & Noel

20. Research Problem – Scenario 1
© Rafiq & Noel

21. Problem Description – Scenario 2
Implementation
Independent
Can
I
use
any
of
these
technologies
for
BPMN,
ebBPSS,
Lets
Dance
define
proposed
business
transac1on
model
?
Implementation Specific
No,
these
technologies
do
not
BPEL4Chor,
WSCDL
adequately
to
model
business
I
want
to
define
business
transac1on.
Why?
Standard Protocol
transac1on
from
global
perspec1ve
BTP,
WS-­‐AT,
WS-­‐BA
• Implementation independent languages cover minimal scope of business transactions.
• Implementation specific languages are too complex and do not facilitate specifying
transactional properties. Note that, they may allow specifying quality attributes in particular,
response time which is a business oriented transactional property.
• Protocols are merely for coordinating business transaction. Coordination is not the
specification of business transaction but a runtime activity that manages transactions across
multiple partners.
© Rafiq & Noel

22. Problem Description – Scenario 3
Do
exis1ng
modeling
languages
facilitate
Graphical Languages
modeling
business
transac1ons
?
BPMN
Par$ally
yes
but
Completely
No.
Why?
Let’s
Dance
UMM
I
want
to
define/model
business
transac1on
using
Graphical
nota1ons
cause
I
am
expert
in
technologies
• None of the graphical language facilitates specifying transactional properties but
allows specifying some basic properties including processing time and response
time. For instance, BPMN has timer event that can be used to specify processing
time of an activity in the process.
© Rafiq & Noel

23. Learning Package Outline
 Background
 Business transaction – Requirements
 Research Problem
 Research Contribution
 Discussion
 Conclusion & Future Works
 Further Reading
© Rafiq & Noel

24. Research Contribution
 A Flexible Business Transaction Model that can serve as a blue
print to describe the structural and behavioural aspects of
transactions in a services network.
 Develop a Business Transaction Language (BTL) that:
– Incorporates real-world business entities
– supports granular business process interactions of transactional nature that
can address the highly fragmented nature of modern service-based
applications that comprise end-to-end composite services.
– supports managing and monitoring service-based applications from a
business transaction perspective
 A reference model for customising business transactions to adapt
dynamic requirements that evolve while a transaction process is
running
 Modelling the socio-technical dynamics of service environments
– Social Network Analysis
– Actor Network Theory
© Rafiq & Noel

25. Learning Package Outline
 Background
 Business transaction – Requirements
 Research Problem
 Research Contribution
 Discussion
 Conclusion & Future Works
 Further Reading
© Rafiq & Noel

26. Solúbtha – A Flexible Business
Transaction Model
 Solúbtha describes the structural and behavioural aspects of
transactions in a services network.
 Structural aspect deals with building the structure of
transactions so that the transactions can perform operations
in a meaningful and coherent manner.
 Behavioural aspect of a business transaction model deals
with
– the operations that performed by transactions
– transactional properties that stem from the two very
different domains entailing business and system and
– the logical interactions between and among transactions
– the transition of transaction states
© Rafiq & Noel

27. Solúbtha – Conceptual Model
© Rafiq & Noel

28. Solúbtha – Overview of Structure
 DEFINITION: From structural point of view, Solúbtha transaction
model is a transaction process graph such that TPG = (T,L) where T
and L are nonempty sets of finite number of Transactions (vertices)
T= {T1...Tn} and Links (edges) L= {L1....Ln}. The figure below is an
example of Solúbtha transaction structure.
Insurance
Seller T3
L1 L6
L4
Customer T5
L2
T1 T2
L3 L5 Bank
T4 3rd party Logistics
Provider
© Rafiq & Noel

29. Solúbtha – Overview of Structure
 Connections:
– Transactions in a G are connected each other through the
links.
– The underlying structure of a TPG is similar to wrapped
butterfly [Gross & Yellen, 1999] network architecture where
each transaction is connected with one to multiple transactions
in the model. T3
L1 L8
L7
L4
T1 T5
L2
T2
L6
L3 L5
T4 L9
© Rafiq & Noel

30. Solúbtha – Overview of Structure
• The transaction set T in a TPG can be partitioned into many
subsets S1, S2...Sn that contain elements such that TPG(T,L)=
{S{tn,lm} where n≥1 and m≥1. Because of this multiple
partitions, the transaction model is also called as multi-partite
graph.
T3 Subset 1
Transaction Set L1 L9
L8
L6
L4
T1 T5
L2
L7 T2
L3 L5
Subset 2 T4 L10
© Rafiq & Noel

31. Solúbtha – Structural Characteristics
• The intersection of subsets in a TPG contains the elements that
belongs to each of the intersected subsets in a graph. This
means, one transaction associates or connected with multiple
transactions in a TPG. The figure below demonstrates an
intersection between two sets S1 and S2 such that T1⋲ S1 ∩
S2 .
T3
L1
L9
L8 Subset 1
L6
L4
T1 T5
L2
L7 T2
L3 L5
Subset 2 T4
L10
© Rafiq & Noel

32. Solúbtha – Structural Characteristics
 A TPG cannot be empty. This can formally be expressed as
TPG(T, L) ≠⌀
• For a complete graph, a transaction set in a CTG contains
transactions associated with links such that a Complete
TPG(T,L) = {Tn, Lm} where n≥2 and m ≥1.
• A TPG contain neither open transaction nor open link (an
open transaction is defined as a transaction without any link
associating it where as Open link refers either head or tail of
a link is not connected with any endpoint). This can formally
be expressed as
TPG(T,L) = (¬Topen ˅ ¬L open)
© Rafiq & Noel

33. Solúbtha – Structural Characteristics
• The links in a TPG are directed from one transaction
(vertex) to another transaction in either backward or
forward sense.
• The transactions are mutually reachable when the links
are in bidirectional (both backward and forward) sense.
• For a complete TPG, each link associates with at least two
transactions. This means neither head-point nor tail-point
of a link can be null.
• Each link associates utmost two transactions in a TPG.
• TPG may contain self-loop link which joins a transaction
by itself. Self-loop indicates that a transaction operations
may need to be performed recursively under certain
condition.
© Rafiq & Noel

34. Solúbtha –Structural Operations
 A TPG may need to be extended and trimmed during the
lifetime of a collaboration. Note that the lifetime of a
collaboration is determined by the period of the agreement
between/among the partners that is, Collaboration Lifetime =
(Expiry Date – Starting Date)of the agreement .
 Transactions in a TPG may also need to be replaced to
optimise the performance or to avoid the failures of
transactions in uncertain conditions.
 Three operators including add, prune, and replace are used to
perform extension and pruning of TPG and replacement of
transactions in a TPG.
© Rafiq & Noel

35. Solúbtha –Structural Operations
 TPG Extension
- Transaction Addition: A TPG can be extended by adding new
transactions such that,
extended TPG(T,L) = {TTPG, LTPG} ∪ {T’TPG}
- The newly added transactions should be connected using links with the
pre-existing transactions in a TPG to ensure that it is reachable to the
pre-existing transactions in the graph. Thus, adding transactions
requires adding links in the graph as well. This can formally expressed
TPG(T,L) = {TTPG, LTPG} ∪ {L’ TPG}
- In some cases, all the pre-existing transactions in a TPG may require
to be connected with the added transaction.
- Sometimes, one to many pre-existing transaction in a TPG may require
to be connected with the added transaction but not all.
© Rafiq & Noel

36. Solúbtha –Structural Operations
 Pruning Transaction Process Graph
– Pruning a transaction graph denotes eliminating
transactions and links from the graph.
– A transaction may need to be pruned from a TPG for
different reasons such as transaction has failed to satisfy
expected service level.
– Pruning a transaction from a TPG means pruning the
whole process and/or an organisation from the
collaboration as well as the network.
– A transaction can be forced by other transactions to be
pruned permanently from a TPG. We call it force pruning.
© Rafiq & Noel

37. Solúbtha –Structural Operations
 Pruning Transaction Process Graph
– Transactions in TPG should be pruned along with their associative
links because TPG does not allow any open link in the graph. The key
idea is similar to dead path elimination.
Pr(TTPG,LTPG) = [Pr(TTPG) ˄ Pr(LTPG)] ˄ ¬[Pr(TTPG)]
– A link can be pruned without pruning a transaction that it
associates. The can be formally expressed as
Pr (TTPG,LTPG) = Pr (LTPG)
– A link cannot be pruned without adding another link if it is
the only link associating a transaction in a TPG.
© Rafiq & Noel

38. Solúbtha –Structural Operations
 Transaction Replacement in TPG : Transactions in TPG can be replaced
by other transactions. There are two types of replacement:
– Permanent Replacement: A transaction in a TPG can be replaced
permanently by another transaction. This requires pruning and adding
transactions and links in the graph simultaneously,
PR(TTPG, LTPG) = [Pr(TTPG,LTPG) ˄ ADD(TTPG,LTPG)] ˄
¬[Pr(TTPG,LTPG) ˅ ADD(TTPG,LTPG)]˄
˄ ¬[ADD(TTPG)˅(LTPG)]
¬[Pr(TTPG)˅(LTPG)]
– Transient Replacement: A transaction in a TPG can be replaced
temporarily for a specific instance or to deal with uncertain events,
PR(TTPG, LTPG) = ADD(TTPG,LTPG) ˄ ¬Pr(TTPG,LTPG) ˄ ¬
[ADD(TTPG)˅( ADD(LTPG)]
© Rafiq & Noel

39. Solúbtha –Structural Operations
- In transient replacement, a transaction is added without pruning the
existing transaction that implies the former one still exist in the
graph.
- The former transaction delegates its operations to the transient one;
this implies the former transaction becomes inactive while the
transient one is active.
© Rafiq & Noel

40. Solúbtha –Overview of Behaviour
 Business transaction behavior can be classified into
Flexible and Atomic behavior.
 Atomic behavior relies on “all or nothing principle”. Flat
and Closed Nested transaction models adheres this
principle.
 Flexible behavior relies on “all vital or nothing”.
 To achieve flexibility we extend the semantics of classical
atomicity and isolation properties to the followings:
– Eventual Failure Atomicity
– Relaxed Isolation
© Rafiq & Noel

41. Solúbtha – Eventual Failure Atomic
Behaviour
© Rafiq & Noel

42. Business Transaction Language -
Overview
 Business Transaction Language (BTL) is a declarative
language to model transactions at design-time.
 BTL describes what to implement not how to implemented
 It facilitates specifying transactional properties derive from
business elements.
 It comprises of constructs of three perspectives including
business, functional and technical.
 It is platform agnostic language, which means the model
defined in BTL can be implemented regardless the type of
platform that integrate specific technologies.
 BTL facilitates interoperable transaction fragments because it
is lingua-franca XML based language.
© Rafiq & Noel

43. BTL – Keywords, Operators, and
Primitives
Business Transaction Language
Keywords Logical Operators
precede,
succeed,
SplitOrder,
jointOrder,
AND, OR, EOR
AnyOrder,
Boolean,
check,
require,
composite,
atomic,
trigger,
jumpTo,
transient,
permanent,
local,
global,
hard,
soR,
con1ngent,
vital,
nonVital,
compensa1ng,
loca1on,
route,
means,
delegateTo, refundTo,
returnTo,
payTo,
deliverTo,
shipTo
Primitives for coordinating BT at runtime
Commit , Cancel, Wait, Retry, Suspend, Postpone, Ignore,
Penalize, Delegate, Return, Terminate, Resize
© Rafiq & Noel

44. Modelling Business Transaction –
Service Network (SN)
SLA 2: supplier-3PL
SLA 1: supplier-retailer
© Rafiq & Noel

45. Modelling Business Transaction –
Handshaking(Service Level Agreement) in SN
Service Level Agreement/
Master Service Level
Agreement
© Rafiq & Noel

46. Modelling Business Transaction –
BPMN Model of End-to-End Transaction
© Rafiq & Noel

47. Modelling Business Transaction –
BPMN Model of End-to-End Transaction
Business
policy
T8 = Payment Confirmation
Retailer
Auto Inc.
Quality of
Business
Service Delivery Security policy Quality of
policy
Lead Time is 2 Payment must Service
days be Payment must
acknowledged be
acknowledged
within 24 hours
T6 = Delivery Processing T7 = Payment Processing
© Rafiq & Noel

48. Modelling Business Transaction –
BPMN Model of End-to-End Transaction
Auto Inc.
DHL Cargo
© Rafiq & Noel

49. Modelling Business Transaction –
BTL Representation
© Rafiq & Noel

50. Modelling Business Transaction – BTL
Representation
© Rafiq & Noel

51. Modelling Business Transaction – BTL
Representation
© Rafiq & Noel

52. Business Transaction Architecture
© Rafiq & Noel

53. Service Network
 Supports business
transaction, where a
business transaction is
implemented through a
service networks.
- For example: a service
network that delivers a
mortgage service
 A service eco-system is a
collection of service
networks – equal to a group
of business networks
© Rafiq & Noel

54. Service Network Analysis
 One of the key concerns centres on the need to visualise
business transactions and model resource exchange.
 Another Approach: Social Network Analysis (SNA)
 Service Network Performance Analytics
- Service Dynamics Analysis: key focus in service science
(Lero@UL)
 Interaction supports performance
- Networks produce patterns which present service blueprint
– Analyse what transactional patterns tell us about service structures
• Q: How does service structure impact on performance?
• Developing Service Network Performance Analytics
- Service Network Metrics
- Evaluation Framework
© Rafiq & Noel

55. Value of Service Network
 Reporting on the value of service network
relationships is critical
- Value may be referred to as “the adaptability
and survivability of the beneficiary
system” (Vargo et al. 2008; p.148).
- Determine service value through relational
exchanges
 Loosely coupled value proposing social,
technological, and economic actors
interacting across service eco-systems:
1. Co-produce service offerings
2. Exchange service offerings, and
3. Co-create service value
© Rafiq & Noel

56. Social Network Analysis
 Set of techniques which studies the
exchange of resources among actors.
 Patterns of relations among nodes
- people, groups, organisations, or
information systems, etc.
 Demonstrates the value of ties and
relationships
 Mathematical representation of
interaction and exchanges which
influence behaviour.
- Deeper insight of how structural
regularities influence behaviour
© Rafiq & Noel

57. Social Network Analysis(Cont.)
 Supporting partnership and alliances
 Assessing service strategy execution
 Improving strategic decision
– Accessing ASN
 Integrating networks across core processes
- promote innovation
 BTL can benefit from the application of SNA
- Support BTL to discover business process dynamic behaviour
while identifying where strengths, weaknesses, opportunities, and/
or threats lie across a service network using SNA concepts.
- Provide valuable insight on the operating status of a service
network and determine whether change may be required
- SNA allows us to graphically capture service interaction
© Rafiq & Noel

58. SNA Graphs
 Graphs….
– mathematical structures used to model relations between
objects.
- nodes to represent objects (actors)
- edges to express relations (communication paths)
© Rafiq & Noel

59. SNA Graphs(Cont.)
 Undirected
– to represent (only) symmetric
relations
 Directed
– to represent asymmetric
(directed) and symmetric
relations
 Weighted
– to represent intensities,
distances or costs of relations
© Rafiq & Noel

60. Service Network Metrics?
Need to compare Graphs with other
Graphs
 Service networks: Need Graph
Metrics!
 Properties of graphs to compare
 Static graphs
– graph properties at a given point in time
(snapshot)
 Dynamic graphs
– graph properties observed over a
period of time (i.e., service evolution)
© Rafiq & Noel

61. Service Network Performance Analytics
 Identify issues which may present opportunities or threaten
service sustainability.
– SWOT-like analysis (strength, weaknesses, opportunities, and
threats) of the service environment
– Adopting the balanced scorecard critical success factors; financial
results, customer satisfaction, learning and growth, internal
processes, staff satisfaction, and community and environment.
 Freeing up resources to develop value-added information is
critical to managerial activities (e.g. rapid decision making and
execution).
© Rafiq & Noel

62. Performance Indicators
Performance Measure Explanation
Key Result Indicators (KRIs) Determine how service has
performed in the past, for example,
sales last month.
Performance indicators (PIs) Inform what you ought to do.
Key Performance Indicators Prescribes what you ought to do to
(KPIs) increase performance.
© Rafiq & Noel

63. Service Network Performance Analytics
© Rafiq & Noel

64. Business Transaction Customisation -
Overview
 Customisation denotes fine-tuning a generic business
transaction process to be reused to satisfy special
requirements.
 The key purpose of customising business transaction is to
optimize the transaction performance by adding required
attributes that are extracted through analysis.
 Customisation of business transaction model lessen
development cost and effort.
 It enhance reusability business transaction.
 Having the ability of customising business transaction at
runtime enables a system to adapt dynamic environment.
© Rafiq & Noel

65. Business Transaction Customisation –
Reference Model
© Rafiq & Noel

66. Business Transaction Customisation –
Reference Model
 Business transaction customisation reference model
comprises of two layers namely Transaction-view
Segmentation Layer and Transaction Customization
layer.
 Transaction-view segmentation layer consists of task
view, control view, quality view, and policy view.
 A generic transaction process is segregated in views at
transaction-view segmentation layer.
 Tailoring of a transaction process is carried out at
customisation layer in three phases that produces three
solutions including meta-reference, reference , and final
solution.
© Rafiq & Noel

67. Business Transaction Customisation –
Cloud Based Architecture
This work is in progress and therefore we do not provide much details about how to link
this architecture with transaction architecture.
© Rafiq & Noel

68. Learning Package Outline
 Background
 Business transaction – Requirements
 Research Problem
 Research Contribution
 Discussion
 Conclusion & Future Works
 Further Reading
© Rafiq & Noel

69. Conclusion & Future Works
 Business transaction for a large scale end-to-end processes
in collaborative business environment is highly complex.
 The classical ACID principles for business transaction is
decidedly not suitable and thus, models that rely on ACID
cannot be employed for business transactions.
 Business transactions need greater flexibility to sustain all
potential failures.
 Business requirements also should be realised while
executing transaction, thus transaction models should involve
real-world business elements.
© Rafiq & Noel

70. Conclusion & Future Works
 Existing transaction models provide minimal flexibility and not able
to encapsulate any business data so that the runtime engine can
realise those data.
 This research propose a transaction model named Solúbtha which
intertwined business elements with transaction model.
 Solúbtha facilitates designing a transaction not only from
application perspective but also from business perspective which
leads better monitoring of business level performance indicators
along with process performance indicators at runtime.
 To define the model, this research proposes an XML based
language named business transaction language.
 Employ SNA to examine BTL developments.
© Rafiq & Noel

71. Learning Package Outline
 Background
 Business transaction – Requirements
 Research Problem
 Research Contribution
 Discussion
 Conclusion & Future Works
 Further Reading
© Rafiq & Noel

72. Further Reading
Noel Carroll, Rafiqul Haque, Ita Richardson, and Eoin Whelan: Modeling Business Transaction Across Service
Supply Chain Network. 20th International Conference on Information System Development(ISD), 2011.
Edinburgh, Scotland.
Francois Hantry, Mike P. Papazoglou, Willem-Jan van den Heuvel, Rafique Haque, Eoin Whelan, Noel Carroll,
Dimka Karastoyanova, Frank Leymann, Christos Nikolaou, Winfried Lamersdorf, Mohand-Said Hacid:
Business Process Management. Service Research Challenges and Solutions for the Future Internet:
Towards Mechanisms and Methods for Engineering, Managing, and Adapting Service-Based Systems.
Heidelberg, Germany: Springer, 2010. pp: 27-54
Yehia Taher, Rafiqul Haque, Michael Parkins, Ita Richardson, Eoin Whelan, and Willem-jan van den Heuvel. A
Multi-Layer Approach for Customizing Business Services. 12th International Conference on Electronic
Commerce and Web Technologies(ECWEB,2011) Toulouse, France. 20th May, 2011. Status: Accepted
but yet to be published.
Carroll, N., Whelan, E., and Richardson, I., (2011). Exploring the Implications of IT-enabled Relational
Structures on Service Performance, Understanding Complex Services through Different Lenses
Conference, Cambridge Service Alliance Group, University of Cambridge, England
Carroll, N., Whelan, E. and Richardson, I., (2010). Applying Social Network Analysis to Discover Service
Innovation within Agile Service Networks, Journal of Service Science, Volume 2, Issue 4, pp. 225-244
© Rafiq & Noel

73. Further Reading
Carroll, N, and Wang Y., (2011). Service Networks Performance Analytics: A Literature Review. Cloud
Computing and Service Science Conference (CLOSER 2011), Noordwijkerhout, Netherlands.
Carroll, N., Richardson, I., and Whelan, E., (2011). Service Science: Introducing The Need For Performance
Analytics for Service Networks Evolution, Cloud Computing and Service Science Conference (CLOSER
2011), Noordwijkerhout, Netherlands.
Carroll, N., Whelan, E. and Richardson, I., (2010). Understanding the Value of Business Process
Configuration. 3rd International Conference on Business Process and Service Computing (BPSC2010),
Leipzig, Germany, September 27-28.
Carroll, N., Whelan, E., and Richardson, I., (2010). The Discovery of Agile Service Networks through the Use
of Social Network Analysis, International Conference of Service Science (ICSS2010). May 13-14, 2010,
Hangzhou, China.
Carroll, N., Richardson, I., Whelan, E., (2010). Applying Social Network Analysis to Monitor Web-enabled
Business Processes. 6th International Conference on Web Information Systems and Technologies
(WEBIST), Valencia, Spain, April 7-10.
Carroll, N., Whelan, E. and Richardson, I., (2010). Application of Social Network Analysis to Service Networks
Performance Analytics: A Literature Review. Lero Technical Report (Lero-TR-2010-06), University of
Limerick, December 2010.
© Rafiq & Noel

74. Acknowledgements
The research leading to these results has
received funding from the European
Community’s Seventh Framework
Programme [FP7/2007-2013] under grant
agreement 215483 (S-Cube).
© Rafiq & Noel