2013 7th IEEE International Symposium on the Maintenance and Evolution of Service-Oriented and Cloud-Based Systems (MESOCA)

Platform based Approach for Automation of Workflows in a System of Systems

Tarmo Ploom Axel Glaser Stefan Scheit

Integration Architecture Architecture IT Core Systems BPM & Integration Center of
Credit Suisse AG PostFinance AG Excellence
Zurich, Switzerland Bern, Switzerland Telstra Corporation
tarmo.ploom@credit-suisse.com axel.glaser@postfinance.ch Melbourne, Australia
stefan.scheit@team.telstra.com

Abstract—Automation of workflows has been the focus of systems are operational independence of its elements,
much research for more than three decades. There has also managerial independence of these elements, evolutionary
been significant research about the evolution of workflows. In development, emergent behavior, and geographic
this paper we describe how to achieve automation of distribution of the elements [17]. The IT landscape of Credit
workflows, not only in a single application but in an entire Suisse corresponds to all of these properties and its
landscape of applications. How can distinctive types of evolutionary development and emergent properties have
workflow applications be built in an IT landscape? How can been described in [8], [18].
the SOA and BPM perspectives be combined in a very large While there has been substantial research about the
scale system of systems context? We define a platform based
execution of workflows in single applications [19], [20] the
approach for the automation of workflows which is in contrast
execution of workflows on a system of systems scale has
with the classical single application based approach for
workflow automation. Furthermore, we describe the core
been widely neglected.
concepts of our workflow execution platform and provide an With regard to development and an increasing maturity
overview of the results. of SOA in managing system of systems based IT landscapes,
it remains surprising that the automation of workflows as a
Keywords-BPM; SOA; system of systems; workflow complementary concept to SOA has thus far been seemingly
automation; workflow evolution; workflow classification, human left to chance in this wider context. Since the definition of
workflow, case management workflow, process orchestration; workflows in a system of systems scope is still emerging,
federated workflow; central workflow they are currently not designed consciously on that scale.
The SOA approach usually focuses on the integration of
I. INTRODUCTION distinctive components, not on the workflow which
integrates different components in a system of systems.
This paper focuses on the question of how to automate This paper aims to address this gap and describes a
workflows in the large scale global IT landscape of Credit successful approach for automating workflows in Credit
Suisse. The emphasis is not so much on the modeling of Suisse’s large scale IT landscape.
workflows; rather it is on the actual execution of workflows Firstly, we explore the problem of automating workflows
in a large scale IT landscape consisting of thousands of in a system of systems including a comparison between the
applications. federation versus orchestration perspective on workflow
Service Oriented Architecture (SOA) [1]    and Enterprise automation. This includes a proposal of a new workflow
Architecture (EA) [2]    are mainstream approaches for the classification approach which was adopted in Credit Suisse.
management of large scale IT landscapes. Their application After describing the wider workflow evolution perspective,
in enterprise computing has been in focus for many years the inherently required migration aspects of workflow
and is well described [3], [4], [5], [6], [7], [8]. automation are analyzed.
In recent years, the application of workflow execution in Secondly, we outline the core concepts of how a
enterprise computing has gained attention and various   workflow execution platform can be established in a system
aspects   have   been   described   [9]. The focus of enterprise of systems context. This includes details about the logical as
computing has been the layering of workflow applications well as physical layering of components, the platform’s  
[10], transformation of business process definitions between context view, and the service view of the workflow
different formats [11], governance of Business Process execution platform in the large scale IT environment under
Management (BPM) [12], and optimization of executable study.
business processes (workflows) [13]. There has also been Thirdly, our results of the platform based approach for
research on the topic of workflow model evolution [14], [15] workflow execution in a system of systems context are
as well as looking at the aspects of migrating long running presented concluded by a discussion of our main
business process instances [16]. observations.
The current state of very large IT landscapes can be
described as a transition towards more and more sizable
systems of systems. The attributes of such a system of

978-1-4673-4889-8/13/$31.00 ©2013 IEEE

12
Authorized licensed use limited to: RNS Institute of Technology. Downloaded on May 12,2025 at 07:01:07 UTC from IEEE Xplore. Restrictions apply.
 2013 7th IEEE International Symposium on the Maintenance and Evolution of Service-Oriented and Cloud-Based Systems (MESOCA)

II. PROBLEM STATEMENT TABLE I. WORKFLOW CLASSIFICATION BASED ON INTERNAL

FACTORS
A. System of Systems Perspective Workflow Workflow
Main Non-
Characteristic functional
Historically automation of workflows in single isolated Type Model
Requirement
applications has been left to chance. Consequently, Collaborative,
workflows were hidden in the application logic and there Semi- dynamic,
was not a central component which aggregated workflow Case structured, flow information and
Flexibility
logic of various applications. Such an architectural style Management partially defined communication
during runtime intensive,
corresponds to a federated approach in which there is no individualized
central conductor for workflows. Process model Human
Over time a different architectural style emerged by Usability,
Human structured and involvement,
Comprehen-
separating the workflow logic of the applications from the Workflow predefined content can
sibility
rest of the application logic into a central workflow engine (design-time) differ
[19]. Such an architectural style corresponds to the Process model
Fully
Process structured and Throughput
orchestration approach in which a central conductor manages Orchestration predefined
automated,
and latency
the execution state as well as the state of workflow instance transactional
(design-time)
data. As a result, workflows are managed centrally and
regarded as assets as opposed to leaving them in single Case management is defined as a semi-structured,
isolated applications. collaborative, dynamic, and information-intensive process. It
Currently, system of systems based application is driven by external events and requires incremental and
landscapes face similar challenges as initially encountered by progressive responses from the business domain handling the
disparate applications. As such, workflows in a system of case. Several interactions are usually grouped together,
systems are hidden in the underlying connectivity between defined as a case folder, for example patient records, a
networks. Subsequently, the state of the flow of applications lawsuit, an insurance claim, or a contract. Such a case folder
in system of systems is not explicit, nor is the state of the would include all documents, relevant data sets,
workflow instance data. As a result, the majority of cases are collaboration artifacts, policies, rules, analytics, and other
left to chance while they are emerging. This architectural information required to process and manage the case [23].
style resembles the federated architectural style observed for Case management workflows can be regarded as dynamic
single isolated applications in the past. [24], since their flow is eventually defined during runtime as
This poses the question of how could we adopt an opposed to classical predefined workflows whose flow is
orchestration style (contrary to the federation style) in a defined entirely during design-time.
system of systems based application landscape for the Human workflow as a classification type aims to
automation of workflows. This also extends to the problem automate well-defined processes with substantial human
of how workflows across a large number of applications involvement. Human workflows represent predefined
could be managed in a way their flow definition, flow state, workflows and they are defined during design-time of the
and workflow instance states are captured explicitly. workflow.
B. Workflow Classification Perspective Process orchestration, also known as straight-through
processing, categorizes workflows that are fully automated
Historically, workflows have been classified into production processes. They are highly standardized with the
production, administrative, ad hoc, and collaborative goal of supporting high volumes and low latency processing
workflows [20]. This classification has its origin in in business transactions.
specialized workflow automation for particular application Since there are specialized workflow engines for case
domains. For example, production workflows arose from management, human workflow, and process orchestration
streamlining strongly repetitive sequences of steps, whereas available, offerings for specialized workflow engine
administrative workflows originated from office automation corresponding to the underlying workflow types are
products like Lotus Notes or groupware which has been commonly observed. This is due to the fact that such an
developed to support more collaborative workflows [21]. approach supports workflow automation and optimization
In contrast to this, the approach presented in this paper based on the specific workflow type.
has the ambition to execute all workflow types on one However, this raises the question of how to proceed with
workflow platform. Subsequently, the classification of the selection if a combination of case management, human
workflows is based on the internal factors of workflows as workflow, and process orchestration is observed in a system
well as the degree of automation correlating with their of systems. Are all these different workflow engines to be
maturity (i.e. structure and completeness) [22]. integrated into an application landscape? Would this in turn
As a result of this, the classification distinguishes increase the overall complexity of the application landscape?
between the types of case management, human workflows,
and process orchestration. It is shown in Table 1 and the C. Workflow Evolution Perspective
particular types are defined as follows. Selecting a workflow engine based on the workflow type
is a static approach made at a point in time and it does not

13
Authorized licensed use limited to: RNS Institute of Technology. Downloaded on May 12,2025 at 07:01:07 UTC from IEEE Xplore. Restrictions apply.
2013 7th IEEE International Symposium on the Maintenance and Evolution of Service-Oriented and Cloud-Based Systems (MESOCA)

take into account the evolutionary aspect of workflows. becomes essential to establish a foundation by creating a
Evolution continually occurs when workflows formerly platform for these various initiatives.
defined as case management evolve to human workflows or, Over a longer timeframe, the individual optimization of
due to further automation, even to process orchestration. If a smaller sub-workflows would contribute towards the
case management workflow was initially implemented on a automation of the end-to-end workflow. This however
case management workflow engine then its evolution requires a clear vision to be formulated, acknowledged, and
towards human workflow or process orchestration would be driven by senior management. Additionally, it requires
constrained by the underlying platform. As a result, the main stability during execution, since the benefits are reaped only
promise of BPM as a discipline – continuous improvement – after a considerable amount of projects or initiatives have
cannot be facilitated. been successfully implemented.
It is evident that workflows and their lifecycle must be
considered as evolving, and there has been substantial E. Migration of Workflows
research about the topic of workflow evolution [14], [15], Over the past decades there has been significant
[25]. While research has mainly been focused on the advancement in the area of business process definition
evolution of processes within the boundaries of a particular languages [28]. As a result, workflow engines themselves
workflow type (e.g. different levels of maturity in case keep changing and applications, which use workflow engines
management workflows [26]), there has not been much for automation of their workflows, will face process
analysis of the evolution of workflows spanning different migration issues [16] when updating from an older workflow
workflow classification types (in both directions, e.g. case definition languages to a newer workflow definition
management to human workflow, or human workflow to language standard.
case management). How could such migrations be carried out in a system of
Another aspect which has yet to be the focus of research systems context? The efforts for migrating process instances
is the migration and evolution of the workflow platform from an old workflow engine to a new workflow engine
itself. The platform lifecycle might be spanning a longer would have to be regarded as substantial.
timeframe, however it has a significant influence on the In the case of a system of systems, used by many
process evolution and migration efforts involved [16]. different workflow engines, the migration initiatives would
Consequently, if a workflow engine cannot support such become virtually impossible due to the high level of
an evolution of workflows, then its application would be complexity and associated costs. These migration efforts
detrimental in terms of supporting the goal of continuous would inhibit the application of workflow automation
process improvement and optimization. technology in a system of systems.
D. Automation of End-to-End Workflows III. CONCEPTS
End-to-end workflows are defined as workflows which
cross the entire application landscape and as such represent a A. Workflow Platform Concept
cross-section of the system of systems. Given their great In the last chapter the problem domains of automating
importance, it raises the question of how these workflows in a system of systems context were described.
comprehensive and complex workflows could be built. This included the description of the status quo in such an
One answer could be a top-down approach, by designing environment and mentioned issues in relation to the
the entire end-to-end process involving tens to potentially evolution of workflows. This was followed by a description
hundreds or even more applications. However, is it feasible of the difficulties commonly encountered when seeking the
to build such an end-to-end process scope in one project or automation of the entire end-to-end processes.
program which touches the majority of the application Our proposed solution to overcome the previously
landscape? described issues was a workflow platform concept. This is a
Stephan Murer [8] in his book suggests a framework for concept in which a single logical workflow engine executes
the successful long-term management of highly complex different workflow types (case management, human
systems, describing that the only feasible approach to change workflow, and process orchestration workflow). By
a large scale system of systems is by managed evolution eliminating platform boundaries between the execution
[27]. Other approaches in which revolutionary changes are engines of different workflow types, a more seamless
introduced into a productive system of systems are bound to workflow automation and optimization can be achieved.
be unsuccessful because it has to be considered as a socio- Subsequently, there is no need to migrate to another
technical system demanding both of its dimensions – the workflow engine if a former human workflow evolves to
social and technical – have to be developed in parallel. become a process orchestration workflow. This can be
If, due to the impact and size of change, a top-down observed in the automation of workflows within single,
approach for large scale automation of end-to-end workflows isolated applications today.
cannot be accomplished, the remaining option is a sequence The use of a common workflow platform for automation
of smaller, more controllable changes. Since these smaller of various workflows in a system of systems reduces the
changes are less likely to establish common and reusable complexity and minimizes the cost of integration of sub-
integration, development, and deployment standards, it workflows into the landscape. Also, the state of the
workflow and its associated instance data will be managed

14
Authorized licensed use limited to: RNS Institute of Technology. Downloaded on May 12,2025 at 07:01:07 UTC from IEEE Xplore. Restrictions apply.
 2013 7th IEEE International Symposium on the Maintenance and Evolution of Service-Oriented and Cloud-Based Systems (MESOCA)

by the same engine for all participating sub-workflows and cmp Logical Layering

end-to-end workflows. By using the concept of managed

evolution [8] it becomes possible to eventually aggregate Workflow Layer
sub-workflows into the overall end-to-end workflows in
finite timeframes.
The workflow platform concept also minimizes the Orchestration Orchestration
System A System B
migration costs in a system of systems in case there are
migrations related to newer process definitions or even
migration to a newer workflow engine itself required.
B. Non-functional Requirements Perspective
Although the concept of a common workflow platform SOA Layer
for automation of different workflows types in a system of
systems context appears to be very simple, it faces
System C System D System E
significant challenges as the different workflow types have
inherently orthogonal requirements as listed in Table 1.
The main non-functional requirement of case
management workflows is flexibility during runtime. Such
workflow definitions have to allow for changes during Figure 1. Logical layering of system of systems
execution. Non-functional requirements related to workflow
instances per second are not as critical for case management The orchestrator holds the definition of workflows and
workflows. executes them. As a result, the overall system of systems can
Non-functional requirements are however, essential for be classified into orchestrating and orchestrated systems. The
the success of process integration workflows. Throughput, first type of such a system represents the workflow layer,
latency, and transactional integrity are absolutely critical, for whereas the second type is typically represented by the SOA
example, for payment processing on workflow engines with layer which exposes services to the workflow layer. By
thousands of workflow instances being executed per second. following this orchestration model for the automation of
In addition to this, the integrity of the overall workflow workflows, the entire system of systems can be regarded as a
becomes of prevailing importance. directed graph in which the central conductor orchestrates
The predominant non-functional requirements for human the flows between various participating systems.
workflow are geared towards a user-friendly and intuitive
D. Infrastructure Layering View of System of Systems
user interface in conjunction with fast authorization,
escalation, and organizational relationship resolution (based The next point of interest is the question of how the
on roles and organizational units) during runtime. infrastructure for a system of systems is to be built. Should
As such, a common workflow platform executing this be the responsibility of each system, or should there be a
different workflow types on the same workflow engine faces common platform established (see Fig. 2) which offers
significant challenges. Not only are non-functional common functionality and is shared among other systems?
requirements of flexibility and throughput for workflow Historically, common platforms were created for
execution orthogonal, achieving them on the same workflow hardware and operating systems. This was due to the fact
engine is often questioned by the industry practitioners and that the overall complexity could be reduced by using a
vendors. standardized hardware and operating system platform. With
this approach a common hardware and operating system
C. Logical View of System of Systems platform was created for any system of systems. This
A system of systems can be logically described as a development is further enhanced by the emergence of cloud
network of systems in which systems interact with each computing based hardware and operating system platforms,
other. Workflows among these systems are represented by often referred to as Infrastructure as a Service (IaaS) [29].
the sum of such interactions. Without a central conductor
however, such workflows are implicit, hidden, non-
transparent, and their flow state is not globally defined.
In order to use the orchestration approach for the
automation of workflows in a system of systems context, a
specific logical system (or systems) is needed to orchestrate
flows between other systems, see Fig. 1.

15
Authorized licensed use limited to: RNS Institute of Technology. Downloaded on May 12,2025 at 07:01:07 UTC from IEEE Xplore. Restrictions apply.
2013 7th IEEE International Symposium on the Maintenance and Evolution of Service-Oriented and Cloud-Based Systems (MESOCA)

cmp Technical Layering cmp Context View

Authentication Workflow Platform

Log System
Components::Workflow Platform System

Monitoring
Authorization System
System
Components::SOA Platform
Data Warehouse

Organisational
Information
System Reporting System
Components::Application Platform

Archiving System
Calendar Service

Components::Database
Platform
Channel Service Business Rule
System

Components::Runtime Platform Figure 3. Workflow platform context view

All these integration points and platform enabling

functionalities should be established on the platform level.
As a result, workflow based applications are abstracted from
Figure 2. Technical layering of system of systems this level of complexity, whilst increasing consistency and
As the next step in the evolution of platforms, the simplification of workflow application development. Many
emergence of standardized database (storage) platforms common problems like regulatory audit logging, user
based on the IaaS has been observed. This development was authentication, and common performance monitoring are
followed by the establishment of application development encapsulated this way, as a number of standard solutions to
platforms such as .NET or Java Enterprise provided as be leveraged by any workflow-based applications. The
Platforms as a Service (PaaS) [29]. Application development platform services depicted in Fig. 3 are briefly described in
platforms use the functionality of hardware, operating the following sections.
systems, and the database platforms. The authentication component is required by the
With the emergence of the SOA platform [6], the next workflow platform to verify   the   user’s   identity.   In   Credit  
logical step in the evolution of infrastructure platforms for Suisse’s   case, public key infrastructure with X.509
the integration of applications in large scale IT Landscapes certificates is used for both the authentication of interactive
was taken. SOA platforms facilitate the integration of users as well as system users.
applications in a system of systems by standardizing security The authorization system component is fundamental to
aspects, services description, service routing, service control rights and privileges of users on the workflow
monitoring, and service management during runtime. The platform – typically modeled in workflow roles. These roles
SOA platform itself is based on the application development are commonly used in human workflow processes and
platform. correspond to the swim lanes in the process modeling
The workflow platform resides on the next layer of standards. They define the particular access rights as part of
abstraction, on top of the SOA platform and application the end-to-end process flow and invoke specific application
platform. It can be regarded as the natural extension of the services. Given the high change and access rate of the role to
platform development of common infrastructure for system user assignments in a large organization a mechanism for
of systems, since its main functionality is to facilitate the mass replication and additional online synchronization
automation of workflows in the application landscape. This mechanisms have to be put in place to support accurate user
is accomplished by using the services provided by the privileges at any point in time.
underlying platforms. The organizational information system component
provides information about users like user name, email,
E. Workflow Platform Context View phone, job assignment, organizational unit, location, and
The context view of the workflow platform as illustrated deputy (incl. deputy definition timeframe) which are crucial
in Fig. 3 describes how the platform is embedded into the IT in order to dispatch work between different organizational
landscape as well as its common dependencies to other groups and people. Due to the intensive use of this
systems or components. information by case management and human workflow

16
Authorized licensed use limited to: RNS Institute of Technology. Downloaded on May 12,2025 at 07:01:07 UTC from IEEE Xplore. Restrictions apply.
 2013 7th IEEE International Symposium on the Maintenance and Evolution of Service-Oriented and Cloud-Based Systems (MESOCA)

applications it is usually replicated to the workflow platform of invocations of this service the calendar information is also
or can be retrieved from a highly available data store not replicated to the workflow platform.
optimized for read operations (such as LDAP). This The integration with the Business Rules System
information can generally be considered as information with component allows highly complex business rules, in the form
a lower change rate than the authorization information. of multi-variable (and often nested) decision and rating
Regulatory requirements to keep data for a specified algorithms to be externalized whilst keeping the process
retention period and the support of making this data available logic rather stable and robust. The main advantage of this
if required are functions implemented by the archiving component is that it offers specialized languages and
component. This includes exporting and storing of the presentation capabilities to manage frequent changes to such
finished process instances to an offline storage location or algorithms. This is crucial, because these business rules are
converting the audit trail into a human readable PDF format often dependent on external factors like interest rates,
before storing it. competitor actions or regulatory changes.
The channel service comprises of the services to support
exposing  the  workflow’s  activities  or  tasks  to  end  users  and   F. Workflow Platform Services View
partners. This usually includes the workflow portal of the The workflow reference model from the Workflow
platform, integration into other internal portals or news feeds Management Coalition [30] describes five core interfaces
(RSS), email, Internet facing services, and more traditional required by a workflow engine pertaining to (1) process
mechanisms like facsimiles and letters. In addition to this, modeling tools, (2) workflow client applications, (3)
gateways to mobile devices and smart phones are emerging invocation of applications, (4) other workflow engines, and
as essential in the immediate future. (5) administration/monitoring tools.
Another functional component is the aggregation of Interface 2 (workflow client applications) is the main
workflow execution, trace, system, and exception logs of the interface for workflow applications. The workflow platform
workflow platform in a centralized log management services, which are consumed by the various workflow
component. This receives and structures information to allow applications, have to be abstracted from the underlying
developers or operations to analyze error conditions technology. This in turn decouples the applications which
spanning several systems to track an entire end-to-end make use of the workflow technology. This is a crucial
interaction. It also removes the necessity of developers prerequisite for enabling migration capability between
having to access the workflow platform itself. workflow platforms [16].
It is importantly from an operations perspective to The workflow reference model offers ready-to-use
integrate the workflow platform with a comprehensive interface definitions for the mentioned interface 2 [30].
monitoring system. This facilitates monitoring of the overall However, due to the very fine-grained nature of this interface
system health and utilization including the underlying definition, a decision was made not to use it as basis for our
runtime, database, application, and SOA platform as well as workflow platform service definition. Instead, a business
the workflow platform itself. object model (BOM) based service design was adopted to
The use of a data warehouse component offers design the services published by the workflow platform [31].
capabilities for process optimization over long timeframes. The service view of the workflow platform is illustrated
The primary goal is to collect the entire workflow instance in Fig. 4. All of the depicted services are available as
execution information over (very) long timeframes and synchronous services, whereas the services
different process evolution stages. This breadth of “createProcessInstance” and “notifyProcessInstance” are also
information is required to conduct comprehensive analysis to enabled to be invoked asynchronously in order to address
detect or validate significant trends and seasonal cycles. non-functional requirements around batch processing.
Moreover, the data warehouse supports the aggregation of In general, services for the creating and notifying process
historical workflow information with data from other core instances can either be designed generically or
systems which can be used to create data marts based on
various dimensions and factors. class Serv ices View
The reporting platform component is typically fed from
the process execution engine with aggregated information «interface» «interface»
suitable for presentation in form of graphs and charts as part ProcessInstance Activ ityInstance
of dashboards. These statistics are relevant to senior + abortProcessInstance() + abortActivity()
stakeholders such as process owners and display common + createProcessInstance() + checkInActivity()
metrics. Examples include the number of escalated/overdue + reassignProcessInstance() + checkOutActivity()
workflow instances per business area, average durations + notifyProcessInstance() + executeActivity()
+ resumeProcessInstance()
classified by customer group or the standard deviation of + searchProcessInstance()
workflow steps. These are generally used to provide input + selectProcessInstance()
into design-time process model simulations. + suspendProcessInstance()
A globally deployed system also requires information + unselectProcessInstance()
about working days and holiday calendars in different
geographical locations. This information is ideally provided
by a calendar service. Due to the comparably lower number Figure 4. Workflow platform services view

17
Authorized licensed use limited to: RNS Institute of Technology. Downloaded on May 12,2025 at 07:01:07 UTC from IEEE Xplore. Restrictions apply.
2013 7th IEEE International Symposium on the Maintenance and Evolution of Service-Oriented and Cloud-Based Systems (MESOCA)

can specifically be typed for a particular process. As the groups. A committed investment in education and skills was
number of different process types is estimated to be close to the critical success factor to reduce the resistance to change
ten thousand, the generic approach was chosen. in the social system during the introduction of the new
Human interactions with the system rely mainly on get technology.
and search operations of the service to obtain process and
activity instance data. In addition to this, services to support IV. RESULTS
the assignment of process participants were implemented as
well as an operation to execute an (optional) activity of the A. Workflow Platform Evolution
process flow. The first workflow platform we developed was based on
Interface 3 of the reference model describing the services IBM WebSphere MQ Workflow 3.5. This platform went into
invoked by workflow applications is not directly applicable production in 2002 and its end of life will be in 2014.
to the context of the workflow platform, as it is used in the Overall, twenty applications were developed on this first
application context. It is however, facilitated by the platform workflow platform [16].
and its capability to invoke external components using Originally only hosted in Zurich, it was later also
standard integration protocols. deployed to Singapore. It focused mainly on the automation
Interface 4 (other workflow enactment services) of the of human workflows. Case management workflows and
workflow reference model was not required due to the use of process orchestration were out of scope and not actively
a single workflow platform for all process types. supported deployment patterns of this first workflow
platform. From an architectural perspective, this first
G. Deployment View workflow platform used only the runtime and database
Generally, a workflow platform can be either deployed platforms as described in Fig. 2 under section III.D.
centrally or distributed over several locations. This applies to The successor workflow platform went into production in
the whole system as well as its components, if they can be 2010 and is based on the Oracle BPM 10gR3 Engine. It was
integrated via remote services. established following the principles and concepts described
As a result of optimizing for non-functional in the concepts section in this paper.
requirements, as well as the simplification of operation and Currently (as of May 2013) there are twenty eight
maintenance procedures, a central deployment model was workflow applications deployed on this workflow platform
adopted for the workflow platform. across the deployment locations Zurich, London, and New
Provided that a global deployment was necessary for the York, with Singapore to come.
business, the question arose whether to create one global hub
or to deploy the platform on several local hubs in order to B. Non-functional Requirements
achieve a global presence of the platform. A local hub The main difficulty in the implementation of a holistic
approach was chosen to support latency requirements. For workflow platform was to achieve the required non-
example, a synchronous call from Zurich to Singapore would functional attributes on off-the-shelf Solaris hardware, as
take a considerable amount of time due to the physical described in section III.B.
constraints and would significantly increase the latency of Regarding public services exposed by the workflow
the solutions built on the workflow platform. The nominated platform, approx. 100 synchronous web service calls per
hub locations were Zurich, New York, London, and second could be achieved per node. In terms of the execution
Singapore. of macro flows (persistent process steps of six activities) a
maximum throughput of approx. 45 process instances per
H. Organizational Deployment
second was identified. In comparison to that, micro flows
To guide the organizational deployment of the workflow (semi-transient processes with six activities) leveled off at
platform in Credit Suisse’s IT landscape the MIT 90 around 120 instances per second. It was also observed that
framework for technology driven change was used [32]. It nodes could easily be scaled horizontally.
states that new technology can only be introduced into The limiting resource for the service, micro flow and
enterprises when other organizational dimensions in the macro flow throughput, is however the database platform.
enterprises are considered, otherwise the new technology There are several improvements planned to increase the
will be rejected from the enterprise. These dimensions are throughput by approx. ten times, however these are not
often collectively referred to as a social system [34]. implemented nor confirmed yet.
This common resistance in regard to changes has to be Non-functional requirements in terms of flexibility could
actively managed around the technology adoption of a new all be met, which becomes evident by the numbers provided
workflow platform by setting up the organization to adapt in the following section IV.C. Importantly, it was proven to
and support it. New management processes have to be be essential to rigorously follow the architectural style of
designed, strategy and roadmap have to be adapted, and separating workflow definitions from the application logic. If
skills have to be developed within the organization. followed, workflow definitions were found to be easily
The most important factor to reduce resistance to the new changed. Otherwise, by commingling workflow and
technology was education. Courses, webcasts, and events application logic very closely, incomprehensible and hard to
were organized to demonstrate and explain the capabilities maintain solutions emerge.
and benefits of the workflow platform to various stakeholder

18
Authorized licensed use limited to: RNS Institute of Technology. Downloaded on May 12,2025 at 07:01:07 UTC from IEEE Xplore. Restrictions apply.
 2013 7th IEEE International Symposium on the Maintenance and Evolution of Service-Oriented and Cloud-Based Systems (MESOCA)

C. Workflow Application Deployment This is quite surprising, because using a specialized

Of the twenty eight applications deployed in production, engine per workflow type can be regarded as inhibitive of
22 are deployed in Zurich, 4 in New York, and 2 in London. supporting the main promise of workflow automation.
There are still three workflow applications which are yet to Continuous optimization is not really facilitated, since
be migrated from the former workflow platform to the workflows cannot evolve from ad hoc or case management
current standard [16]. This migration is currently underway workflow to human workflow or reaching the fully
and should be finished by the end of 2014. automated stage characterized by process orchestration
By following the workflow classification introduced in workflows.
section II.B, the distribution among the types is: case When comparing this development with integration
management (2 applications), human workflow (22), and suites, it appears to be even more astonishing as these SOA
process orchestration (4). suites generally offer comprehensive capabilities required for
With regard to overall throughput, the workflow platform managing SOA services in an enterprise context. They
currently executes just over one million process instances per clearly follow a holistic approach by supporting the various
month globally. different integration styles and patterns: asynchronous
integration, synchronous integration, B2B integration, and
D. Workflow Application Development bulk integration are all embedded into one suite and product.
With the up-front investment in standardization, This development started in the early 2000s with the
methodology for platform use, and the clear definition of beginning emergence of so called ESB suites, whereas
workflow application types, the following results could be mainly specialized integration suites were in common use
observed. beforehand.
Notably, the clear distinction between the workflow Subsequently, we expect that a very similar development
application types allowed us to define guiding principles and will affect the market of workflow platform suites. As a
standards which were made available to the projects in the consequence, future workflow platform suites will converge
form of workflow modeling guidelines, workflow modeling to mainstream offerings covering the automation of case
patterns, workflow development guidelines, and workflow management workflows, human workflows, and process
reference architectures. These capture solutions of re- orchestration.
occurring problems raised by projects and best practices B. Platform Approach versus single Application Approach
around the use of the platform. Also, this approach supported
the creation of centralized, reusable, and highly robust As there are also other approaches for the automation of
solution components which reduced variability among the workflows in the large IT landscape, we would like to
projects deliverables. evaluate our central platform baseline against different
As a result, the enablement and speed of development of concepts. These can be formulated as each workflow
applications improved significantly. There were cases where application being built independently either on its own
application development (including integration with core platform (often based on a different technology stack) or as a
systems) took only six weeks from kickoff to production hybrid approach which tightly integrates the central
deployment. In another case it took eight weeks to workflow platform’s   engine individually into its application
deployment. In general, by using an iterative approach and logic.
concentrating on the core business requirements (automation Our hypothesis is that a single, isolated application
of workflows) and programming on a highly abstract level approach for automation of workflows in a system of
(business process) the time to market of workflow systems context does not scale and is bound to underperform
applications in a system of systems context could be the centralized approach. It results repeatedly in too high
significantly reduced. integration efforts (technical and organizational) for all
These effects were desired and fortunately emerged as a individually introduced workflow engines/platforms. The list
result of the highly integrated workflow platform approach. of technical dependencies mentioned in section III.C just
Our second workflow platform corresponds to some degree serves as one example. Furthermore, where an end-to-end
with the software product line approach [34], as it resembles workflow would have to be integrated with many different
a factory which uses a highly abstracted programming level localized workflow applications – each being built based on
to design executable enterprise applications. their proprietary workflow engines – it becomes virtually
impossible to resolve the federated, overall state and apply
V. DISCUSSION efficient mechanisms to control the end-to-end flow
effectively.
A. Comparison with Integration Suites Development Interestingly, and based on a different incentive for a
First of all we would like to share the observation that in workflow platform, Amazon Simple Workflow Service [35]
the current workflow engines market only a few vendors released a platform based approach for the automation of
offer a centralized platform around a truly single logical workflows as part of their EC2 Internet cloud services. This
process execution engine (e.g. Polymita Technologies and can be seen as a logical extension of the platform approach
Oracle). However, there are roadmaps available to converge whilst adopting the principles as described in section III.D,
towards such an offering by other big vendors such like which   were   naturally   more   focused   on   the   company’s  
IBM. internal capabilities.

19
Authorized licensed use limited to: RNS Institute of Technology. Downloaded on May 12,2025 at 07:01:07 UTC from IEEE Xplore. Restrictions apply.
2013 7th IEEE International Symposium on the Maintenance and Evolution of Service-Oriented and Cloud-Based Systems (MESOCA)

C. Workflow Execution in a System of Systems (process) which can also be performed by less skilled
As previously noted in section II.A, the execution of workers. This can be explained by the fact that business rules
application-crossing workflows in the system of systems of these processes will be better understood over time. This
context is left to chance the same way as it was historically knowledge can be extracted and effectively automated so
the case for workflow definitions in a single application: they that human workflows start incorporating elements of
were simply embedded in the overall application code. process orchestration.
We see it as the next logical step that workflows in a It is interesting to note that we have not noticed any
system of systems context will equally be extracted from backwards development in practicality, e.g. from human
application logic into specific execution engines as it workflows towards case management workflows or process
occurred for single isolated applications in the past. As a orchestration towards human workflows. Workflows are
result, a separate workflow layer can be established with the clearly developing mainly towards a higher degree of
focus on orchestrating the flow and state between different automation and their definition becomes more static. This
applications. This centralized approach has the potential for also corresponds to the process maturity model defined by
eliminating many of the drawbacks existing in complex Curtis [22].
landscapes: unknown state of the end-to-end process, F. Further Work
necessity of complex integrity controls [36], impossible
As the established workflow platform continues
optimization of the overall workflow, and non-transparent
developing over the coming years, we would like to focus on
process definitions. It allows us to focus on value creating
three additional areas of interest.
activities (automation of end-to-end business process)
First of all, we would like to pursue the exercise of
instead of fixing challenging side effects by adopting
increasing the throughput of our workflow platform
federated workflow applications in the system of systems
significantly. It is expected that the centralized approach will
context.
greatly support us in determining and controlling the
D. Automation of End-to-End Workflows measures required.
Our hypothesis is that a pure top-down approach starting Another key aspect is the proliferation of automating
with the definition and subsequent implementation of an entire end-to-end workflows in which all involved process
entire end-to-end process definition including its sub- chains from the initial customer request to the ultimate
processes contained in single applications does not work. A response are orchestrated in a workflow definition context.
system of systems has to be regarded as a socio-technical In accordance to this, we envisage a potential new workflow
system. In order to drive changes, both the logical factors as type or pattern which allow us to tap into already existing
well as the organizational factors have to be considered. The sequences. These are usually implemented as part of
latter usually require a longer change cycle. established applications that are less likely to be transformed
Instead, a hybrid approach should be adopted. This into workflow application types. The requirement of such an
entails the definition of a top-down strategy of setting up a end-to-end process monitoring or overseer workflow
workflow platform, which requires up-front investment and application type would also correspond with the maxim of
buy-in from senior stakeholders. Over time, components of managed evolution [8].
the end-to-end process can be automated in phases while In parallel, we would also like to define more descriptive
implementing quick wins first. Later on, an increasing and tangible reference architectures for building end-to-end
amount of end-to-end process components can be joined to workflows in the system of systems context. Through our
resemble the overall flow. As this requires the definition of learning, it became evident that clear guidance and best
clear interface points among the workflow components, the practices pay off in terms of increased quality of
senior leadership becomes crucial. implementations of end-to-end workflows and they are a
This approach has also similarities with the Gartner strategic driver for transforming the way an IT landscape can
Business Process Maturity Model [37], which proclaims that evolve towards a process-oriented system of systems.
the automation of sub-processes precedes the automation of ACKNOWLEDGMENT
enterprise-wide.
We would like to thank Claus Hagen, Manoj Das, Barry
E. Evolution of Workflows O’Reilly,   David   Read,  Peter  Birri,  Bernhard  Joos,   Stéphane  
Our observations in real enterprises supports the view of Heck, Iain Last, Wolfgang Schulze, Peter Küng, Derek la
processes evolving over time (scale of years) from e.g. case Salle, Rupert Thurner, and Stefan Hüsemann for reviewing
management workflows to human workflows. Moreover, due this paper and providing valuable feedback.
to further improvements and automation efforts these human Most of all we would like to express our appreciation for
workflows can subsequently be optimized to execute as fully the continuous support of our senior adviser Stephan Murer
automated process orchestration workflows – a development and Chief Architect Stephan Hug in implementing this
which generally represents the commoditization of business workflow platform concept and for providing us with
processes. Initially, case management workflows are carried guidance throughout the concept and realization phases of
out by comparably higher qualified knowledge workers; this approach.
however over time these workflows attract more
standardization efforts and become eventually a commodity

20
Authorized licensed use limited to: RNS Institute of Technology. Downloaded on May 12,2025 at 07:01:07 UTC from IEEE Xplore. Restrictions apply.
 2013 7th IEEE International Symposium on the Maintenance and Evolution of Service-Oriented and Cloud-Based Systems (MESOCA)

REFERENCES doi:10.1002/(SICI)1520-6858(1998)1:4<267::AID-SYS3>3.0.CO;2-
D.
[1] S.   Murer,   “13   Years   of   SOA   by   Credit   Suisse,”   Keynote,   ECOWS,  
[18] J. Lankes, F. Matthes, and T.  Ploom,  “Evaluating  Failure  Propagation  
Lugano, Switzerland, 14-16 September 2011, [Online], Available:
in the Application Landscape of a Large Bank,” Comparch 2008,
http://ecows2011.inf.usi.ch/ECOWS2011-keynote-Murer.pdf,
Industrial Experience Report Track, Karlsruhe 2008.
doi:10.1109/ECOWS.2011.32.
[19] S. Jablonski, M. Böhm, and W.   Schulze,   “Workflow   Management:  
[2] J. W. Ross, P. Weill, and D.  C.  Robertson,  “Enterprise  Architecture  
as  Strategy:  Creating  a  Foundation  for  Business  Execution,”  Mcgraw- Entwicklung von Anwendungen und Systemen. Facetten einer neuen
Hill Professional, 2006. Technologie,”  dpunkt.verlag,  1997.
[3] T. Koch and S.   Murer,   “Service   Architecture   integrates   Mainframes   [20] F. Leymann and D. Roller,   “Production   Workflows,   Concepts   and  
Techniques,” Prentice Hall International, 1999.
in a CORBA environment,” IEEE conference on Enterprise
Distributed Object Computing, 1999, pp. 194-203, [21] J.   F.   Chang,   “Business Process Management Systems: Strategy and
doi:10.1109/EDOC.1999.792063. Implementation,” Auerbach Publications, 2006.
[4] W. Froidevaux, S. Murer, and M.   Prater,   “The   Mainframe   as   high- [22] B.   Curtis,   “Overview   of   the   Process Maturity Model (PMM),”
available, high scalable CORBA platform,” Proceedings of the 18th SASPIN, 2004.
IEEE Symposium on Reliable Distributed Systems, 1999, pp. 310- [23] C. Le Clair and C. Moore, “Dynamic   Case   Management   - An Old
315, doi:10.1109/RELDIS.1999.805115. Idea Catches New Fire,” Forrester Research, December 28, 2009.
[5] B. Liver and K.   Tice,   “SOA   Service   Design   and   Governance:   [24] M. M.   Kwan,   “Dynamic workflow management: a framework for
Experience at Credit Suisse,” 2011 IEEE World Congress on modeling workflows,” Proceedings of the Thirtieth Hawaii
Services, 2011, pp. 81-82, doi:10.1109/SERVICES.2011.73. International Conference on System Sciences, vol. 4, 1997, pp. 367-
[6] A. Hsiung, G. Rivelli, and G.  Hüttenegger,  “How  to  Design  a  Global 376, doi:10.1109/HICSS.1997.663409.
SOA Infrastructure: Coping with Challenges in a Global Context,” [25] M. Reichert and B.   Weber,   “Enabling   Flexibility   in   Process-Aware
Web Services (ICWS), 2012 IEEE 19th International Conference on, Information Systems: Challenges, Methods, Technologies,”  Springer,  
2012, pp. 536-543, doi:10.1109/ICWS.2012.22. 2012, pp 253-295, [Online], Available: http://www.process-
[7] D. Krafzig, K. Banke, and D.   Slama,   “Enterprise   SOA:   Service   flexibility.com/fileadmin/user_upload/reading/PAISBook_Reichert_
Oriented   Architecture   Best   Practices,”   Prentice   Hall   International,   Weber.pdf.
2004. [26] J. Koehler, J. Hofstetter, and R.  Woodtly,  “Capabilities  and  Levels  of  
[8] S. Murer and B.   Bonati,   “Managed   Evolution:   A   Strategy   for   Very   Maturity in IT-based Case Management,” BPM'12 Proceedings of the
Large   Information   Systems,”   Springer   Berlin   Heidelberg,   2010,   10th international conference on Business Process Management 2012,
doi:10.1007/978-3-642-01633-2. pp. 49-64, doi:10.1007/978-3-642-32885-5_4.
[9] D.   Slama,   R.   Nelius,   and   D.   Breitkreuz,   “Enterprise   BPM:   [27] S. Murer, C. Worms, and F. J. Furrer,   “Managed Evolution,”  
Erfolgsrezepte für unternehmensweites Prozessmanagement,”   Informatik-Spektrum, December 2008, vol. 31, issue 6, 2008, pp.
dpunkt.Verlag, 2011. 537-547, doi:10.1007/s00287-008-0290-9.
[10] C. Hentrich and U.   Zdun,   “Patterns for business object model [28] M. Bartonitz, (2013, May 16), “BPM, GPM, BAM, BPMN, BPEL,
integration in process-driven and service-oriented architectures,”   XPDL, EABPM, CMPM,” [Online], Available: http://www.bpm-
Proceedings of 11th European Conference on Pattern Languages of netzwerk.de/content/articles/viewArticle.do?id=d915570e265ad6220
Programs, EuroPLoP, 2006, pp. 1-45, doi:10.1145/1415472.1415499. 1266f515ff902d0.
[11] L. O. Meertens, M. Iacob, and S. M.  Eckartz,  “Feasibility  of  EPC  to   [29] D. S.   Linthicum,   “Cloud   Computing   and   SOA   Converge   in   Your  
BPEL   Model   Transformations   based   on   Ontology   and   Patterns,”   Enterprise: A Step-by-Step Guide,” Addison-Wesley Information
Lecture Notes in Business Information Processing, vol. 43, part 5, technology Series, 2010.
2010, pp. 347-358, doi:10.1007/978-3-642-12186-9_33. [30] D.   Hollingsworth,   “The   Workflow   Reference Model,” Workflow
[12] C. T. Jensen, O. Cline, and M.  Owen,  “Combining  Business  Process   managament Coalition, 1993, [Online], Available: http://
Management and Enterprise Architecture for Better Business www.wfmc.org/standards/docs/tc003v11.pdf.
Outcomes,”   IBM   Redbooks,   2011,   [Online], Available: [31] P. Allen, S. Higgins, P. McRae, and H. Schlamann, “Service
http://www.redbooks.ibm.com/abstracts/sg247947.html?Open. Orientation. Winning Strategies and Best Practices,” Cambridge
[13] P. Küng and C.  Hagen,  “The fruits of business process management: University Press, 2006.
an experience report from a Swiss bank,” Business Process [32] M. S. S.  Morton,  “The  Corporation  of  1990s:  Information  technology  
Management Journal, vol. 13, issue 4, 2007, pp. 477-487, and Organizational Transformation,” Oxford University Press, 1991.
doi:10.1108/14637150710763522. [33] G. Baxter and I. Sommerville,  “Socio-technical systems: From design
[14] F. Casati, S. Ceri, B. Pernici, and G.   Pozzi   “Workflow evolution,” methods to systems engineering,” Interacting with Computers, vol. 23
Lecture Notes in Computer Science, vol. 1157, 1996, pp. 438-455, issue 1, January, 2011, pp. 4-17, doi:10.1016/j.intcom.2010.07.003.
doi:10.1007/BFb0019939. [34] P. Clements and L.M..Northrop,   “Software   Product Lines: Practices
[15] A.  Geppert  and  M.  Kradolfer,  “Dynamic  workflow  schema  evolution   and Patterns,” Addison Wesley, 2007.
based on workflow type versioning and workflow migration,” in [35] Amazon, (2013, March 18), “Amazon Simple Workflow Service,”
Proc. 4rd IFCIS International Conference on Cooperative Information [Online], Available: http://aws.amazon.com/de/swf/.
Systems, 1999, pp. 104-114, doi:10.1109/COOPIS.1999.792162.
[36] B. Liver and H.   Kaufmann,   “Integrity in Very Large Information
[16] T. Ploom, S. Scheit, and A. Glaser, “Methodology for migration of Systems. Dealing with Information Risk Black Swans,” in C.
long running process instances in a global large scale BPM Salinesi, M. C. Norrie, and O. Pastor (Eds.): CAiSE 2013, Lecture
environment in Credit Suisse's   SOA   landscape,” Software Notes in Computer Science, 7908, Springer-Verlag Berlin Heidelberg
Engineering (ICSE), 2012 34th International Conference on, pp. 977- 2013, pp. 641–656, doi:10.1007/978-3-642-38709-8_41.
986, 2-9 June 2012, doi:10.1109/ICSE.2012.6227123.
[37] M. J. Melenovsky and J. Sinur, “BPM maturity model identifies six
[17] M. W. Maier, “Architecting Principles for System of Systems,” phases for successful BPM adoption,” Research Report G00142643,
Systems Engineering, vol. 1, issue 4, 1998, pp. 267–284, Gartner 2006.

21
Authorized licensed use limited to: RNS Institute of Technology. Downloaded on May 12,2025 at 07:01:07 UTC from IEEE Xplore. Restrictions apply.