Improving Supply Chain Operations performance by
using a collaborative platform based on
a Service Oriented Architecture
Rubén Darío Franco, Ángel Ortiz Bas, Víctor Anaya, Rosa Navarro
Research Centre on Production Management and Engineering (CIGIP)
Polytechnic University of Valencia
Ciudad Politécnica de la Innovación, Edificio 8G, Planta 1
C.P. 46022 – Valencia, Spain
Abstract. Every new technology promises to solve a lot of problems inside
companies and to achieve unforeseen performance improvements. Nowadays,
Service-Oriented Architectures begin to be promoted as new balsam where
companies may realize their visions and put all their new strategies in practice.
Initially focused on intra-organizational integration efforts, they begin to be
used when supporting inter-organizational business processes engineering in
networked organizations. Although these kinds of initiatives in most of cases
are lead by major companies, the INPREX project (Spanish acronym for Inter-
operability in Extended Processes), here presented falls out this category. By
contrast, this is an undergoing initiative leaded by a Small and Medium Enter-
prise (SME) and founded by a local government in Spain. In this work, we in-
troduce the IDIERE Platform which has been designed for supporting three ma-
jor requirements of networked enterprises: openness, flexibility and dynamism
when deploying and executing distributed business processes
1 Motivation
Collaborative Networks (CN) are enabling new ways of conducting business transac-
tions and functional alignment between their members [7]. As organizational form,
they tie together two or more companies that had understood the benefits of conduct-
ing win-win partnerships coming from such collaborative environments (([2], [6]).
When adopting this emerging approach, extended functionality needs to be de-
signed and deployed to reach such levels of interaction. Collaborative, Extended or
Distributed Business Process are terms used to name a set of activities that, in such
context, need to be carried out in order to accomplish some commonly agreed busi-
ness goal.
New technologies, mainly those related to the Internet are enabling the deployment
of global business processes and facilitating, at the same time, the interoperability of
the information systems in which they are supported [8].
The INPREX Project is an undergoing initiative founded by the Ministry of Educa-
tion and Science of the Spanish Government. One of the main objectives is the de-
Darío Franco R., Ortiz Bas Á., Anaya V. and Navarro R. (2005).
Improving Supply Chain Operations performance by using a collaborative platform based on a Service Or iented Architecture.
In Proceedings of the 2nd International Workshop on Computer Supported Activity Coordination, pages 56-65
DOI: 10.5220/0002576300560065
Copyright
c
SciTePress
ployment of a platform (called IDIERE) that, taking advantage of web services and
their orchestration, enables the engineering, deployment, execution and monitoring of
distributed business processes in a network of companies surrounding one SME
stamping firm in the automotive sector, located in Valencia, Spain.
In this work, we are going to present the architecture and main components of the
platform and how it has been used to improve the coordination and information visi-
bility in a distributed business process inside a network of companies surrounding a
stamping firm in the automotive sector.
The paper is structured as follows: Section 2 depicts how the service-oriented ar-
chitectures support Distributed Business Process Management. Then, in Section 3, the
IDIERE Platform is presented, that is, its architecture and the software components
that implement the architecture. In Section 4, how it has been applied for improving a
Production Planning Business Process and, finally, in Section 5, we state some con-
clusions that we are gaining when developing this project.
2 Distributed Business Processes Management and Service-
Oriented Architectures (SOA)
2.1 Introduction
Relaying on emergent Internet technologies, Service-Oriented Architectures (SOA)
[3] are allowing to conceive the Internet not merely as a communication channel but
also as support of more complex activities tied, for instance, to purchasing, personnel
recruiting or customer service support.
Business process management’s requirements and the Internet are moving towards
a third stage of evolution [9] where the applications that support business processes
are conceived as a single user graphic interface (based on web browsers) but whose
functionality is composed of computational capabilities on the client side combined
with a set of invocations to third-party provided services ([1]).
The main changes provided by SOA are:
The capability of narrowing down the gap existing between the modelling and the
operational phases of the business process engineering, by means of intermediate
languages like Business Process Execution Language (BPEL) to link the business
process modelling world and the web-services world. BPEL is explicitly designed
to work with Web services and provide coordination and integration of business
services into higher-level business processes.
The emerging web-services technologies (mainly XML, SOAP, WSDL, UDDI and
BPEL4WS) supporting the service-oriented architecture are wide-spread and well-
accepted by service-oriented tools.
Web Services allow a loose decoupling between process’s functionality and execu-
tors [4] so they provide a higher dynamicity
57
When these concepts are applied to collaborative networks (CN) they gain additional
advantages related to information sharing policies and visibility. SOA-based applica-
tions orchestrate and compose invocations of computational capabilities by means of
service interfaces. This mechanism allows companies to keep as independent as they
want by only providing the information that could improve the global performance of
the CN.
Based on those principles, has been proposed [4] that web services interfaces are
able of encapsulating activities, or sub-processes, of a business process definition, and
then, support composition and execution of their instances.
2.2 Web Services extended
The term Web Service is used by various groups to describe widely differing con-
cepts. From a technological perspective, they have been defined as [11].
A Web service is a software system identified by a URI [uniform resource identifier], whose
public interfaces and bindings are defined and described using XML. Its definition can be dis-
covered by other software systems. These systems may then interact with the Web service in a
manner prescribed by its definition, using XML based messages conveyed by Internet protocols.
By contrast, in a more business-related context, web services are also considered as
pieces of business functionality that companies provide (offer, rent or sell) to third
parties by using Internet-related technologies.
Despite the technological complexity that may be related to this technology, most
companies can be able of start providing services in a short period of time. This has
caused that service offering rate had increased quickly but without much order.
Although web services are not distributed objects [10], applying object oriented
computing principles may help when engineering software applications based on
SOA. Looking for such order, some attempts in the right way have been carried out
[5] where an extension of web service’s concept has been proposed in order to create
an upper-level entity which provides a unique access point for a set of web services
belonging to the same domain.
2.3 Supporting distributed business processes
Distributed business process can be conceived as a set of activities which are assigned
to different members of a CN in order to be accomplished to achieve a common goal.
When modelling this kind of processes, is not always possible to keep the same ab-
straction level for each activity/role. In fact, depends on how much detail can be gath-
ered. More, initial steps in process modelling always begin with a more or less clear
picture but without so much detail.
In the scope of this work, these two interrelated concepts will be introduced:
Definition 1: an Execution Unit is a work package that may be com-
posed of a single activity, a sub-process or a whole process and that
could be assigned to some executors which have the proper knowl-
edge and capacity to accomplish the task for the global process”
58
From the information flows management perspective, the execution unit can be
seen as a computational function (ws) which maps some Data Inputs into Data Outputs
through some internal logic not accessible by others (in a black box way).
This led us to the concept of service and service provider. If each execution unit is
wrapped under some interface that can be located and consumed by third parties, it is
possible to consider it as a service that may be provided by some service provider.
Then, service providers or executors can be defined as follows:
Definition 2: executors are those service providers (organizations
or their resources) that are capable of accomplish some execution
unit for the global process by providing and consuming third-
parties services.
And relaying on SOA principles, it could be convenient to add:
“...by means of web services interfaces and a supporting data
model.”
We consider executors as some extension of the object web service concept. They
represent a conceptual unit that will be used as functional/computational building
block when assigning some execution unit for accomplishment. They have the follow-
ing structure (See Figure 1):
Data Model layer: this data model is specific for the business domain within
which executor works and it’s devoted to provide the interoperability foundations
from the information flows perspective.
Internal Logic layer: the data model represents the external interface to be ex-
posed in terms of information. If some additional computation is needed or exist-
ing system must be integrated, the internal logic layer is the mechanism to be
used.
WS Layer: the internal logic may use several mechanisms to feed up the data
layer, even web services. Despite this, this layer is devoted to provide a set of
web services that will be offered to external applications. This layer is also de-
pendable of the executor’s interaction scenario.
There is no one single definition for executors. Instead of this, like when defining
classes in Object Oriented Programming, it could be better to define as many types as
needed.
Then, it’s possible to consider as executor to all organizational resources that may
provide some services to a global process by means of their WS interfaces. In this
sense, whole organizations, organizational units, systems, machines or devices (which
can be used for human interaction) being able of run web services instances may fall
under this definition.
Fig. 1. Executor’s Architecture
59
In order to completely define the execution model, we must create the execution units
(eu) which represents the atomic building blocks used to compose inter-organizational
business processes. Each eu represents a complete piece of work that will be assigned
to executors in order to be accomplished.
The proposed Execution Model is based on execution units’ assignment and moni-
toring to different executors. This facilitates a loose coupling of execution units and
the corresponding executor, enabling either early or late binding (at process runtime)
between them (See Fig. 2).
Fig. 2. The Execution Model assigns EU to executors and maps business representations with
process interfaces at runtime
3 The IDIERE Platform
The IDIERE Platform relays on SOA capabilities in order to automate business proc-
ess execution and monitoring. The platform provides a set of components allowing
users to be involved in several business process instances of execution.
The principle is straightforward: it works as any business process system does but,
at the same time, it provides different levels of automation when needed. Such levels
of automation are supported by corresponding web services interfaces.
IDIERE Platform is the information system that supports distributed business proc-
ess management capabilities by providing a set of components that allows creating and
maintaining a centralised set of repositories of processes, executors and exchanged
messages in each process’s instance.
3.1 The IDIERE Architectural View
The IDIERE Platform, is based on a traditional client-server architecture that is de-
ployed over the Internet. Inside the platform it’s possible to identify:
The IDIERE Server: it supports two major phases: process engineering and execu-
tion. It allows defining collaborative business processes structure, storing them in a
common repository, registering executors, assigning execution method and execu-
tors to individual activities or sub processes, monitoring delegated activities, de-
ploying a set of indicators for performance measurement.
60
Client-side: in terms of users, there would be a set of nodes which may be con-
nected to the platform in order to notify each assignment’s status. Each node repre-
sents the instantiation of one executor for each process instance. Correspondingly,
each deployed thin client, will act as Task Manager for the system (in the tradi-
tional workflow sense) but having some extended functionality.
Initially, we have defined three different kinds of users that will access the plat-
form that is, users that will interact with the platform in order to: manage processes,
accept or reject assignments, or status reporting. The types of user identified are:
Organization: this user initially will act as any company that provides some ser-
vice to a process. By means of its Task Manager, it will provide a service inter-
face that may be located and accessed by the server some eu accomplishment.
When Workers users are present, work items can be delegated.
Workers are nodes belonging to an Organization. A Worker is a Task Manager
also but with a simplified functionality in terms of capabilities for delegating
tasks or accepting offers, for instance. Organization is able of adding their work-
ers by registering them into the system. Once this process has been completed,
tasks can be delegated to these nodes to be internally processed.
Individual: finally, it represents individuals not belonging to any organization
but, once registered, may conduct transactions inside the platform.
3.2 The IDIERE Software Architecture
Major components of the platform are shown next (software modules, applications
and databases) and how they are interrelated.
Fig. 3. The IDIERE Architectural View and its Major Components
On the server-side, the architecture is mainly composed of:
A Business Process Modelling Tool: it’s devoted to model business processes in a graphi-
cal way. Definitions are stored in three repositories:
A Centralised Business Process Repository (CBPR) which will store business process
definitions. This repository can consider processes appearing in reference mod-
61
els as SCOR, or in standard documents as the ISO series; business processes de-
fined by a user as a template and finally business processes induced from web-
services by an inducer tool.
A repository with all the business object documents that will give support to he
definition of information and control flows.
The Network model configuration module is devoted to configure all those top-
ics related to the network deployment. That is, the organization model, execu-
tors’ permissions or additional parameters.
The Business Process Engine is responsible of executing and monitoring proc-
ess’ instances. Consequently, it considers the enterprise models released by the
business process modelling tool and it is able to execute and monitor them. By
assigning each execution unit to the corresponding executor.
Web Services Portfolio within which all active web services definitions that may
be used to compose a business process will be registered. There will be three
kind of services: sub-contracted with third parties (outside of the CN), internally
deployed (owned by the core members) and additionally those services that the
CN will able to provide to third parties to be consumed.
The inducer engine is capable of inducing business process templates from exist-
ing web-services definitions.
4 Case Study: an SME stamping firm in the automotive sector
4.1 Business scenario
The IDIERE Platform has been deployed inside a network of companies surrounding
an SME (which is a 1
st
-tier Supplier, and high level sub-assembly supplier, for one
Original Equipment Manufacturer (OEM) in the automotive sector. The company is
responsible for its own logistics and independently chooses its own suppliers (2
nd
-
tiers), the components of its products, etc.
The network, as it is now, has a relatively low degree of synchronization and col-
laboration. Generally, although the production plans of the company that is directly
connected with the demand are those who launch the supply chain’s production, cer-
tain information that needs to be drawn upstream is held up and sequentially the cycles
of planning and production decrease, and therefore the delivery time of the final item
is significantly affected.
Currently, this information flow is relatively restricted. The SME receives OEM’s
demand planning and makes its production plans and attendant orders to 2nd-tiers
according to it. But when small- scale changes and variation in demand coming from
the OEM arrive, SME’s production plans and order needs change, but the sub-tiers are
not informed on time and thus do not have the time they may need to change their own
planning, if this is possible.
62
4.2 Proposed solution
We have applied the IDIERE platform principles in order to achieve a successful
reengineering of the Production Planning Process (PPP).
After conducting a BP Analysis, PPP was identified as the most critical and conflic-
tive one. Due the company’s raising trend of outsource part of their production activi-
ties, more information visibility and co-ordination of such activities was needed.
Three kinds of executors were identified and their services modeled:
1. Productive: they transform some inputs (raw material or components) into out-
puts (components) by performing of some activity (stamping, painting, welding
or similar). Finished or semi-finished goods are packaged in specific containers.
2. Transport: this kind of executor moves containers between productive executors.
3. Warehouse: they stores finished or semi-finished goods
Fig. 5. Organizational resources have been modeled as executors
Once executors have been modelled, supporting services were developed for each
kind of executor. Then, there is a set of services belonging to each one of them. For
instance, productive executors are able of notify stocks, capacities, enact their Bill of
Material, receive demand, put orders and so on.
Table 1. Supported services (non exhaustive)
Executor ServiceName Description
NotifyDemand() It allows knowing which the demand for
some reference is.
NotifyStock() It returns stock of some reference
BillOfMaterial() It returns those references which compose
other one
Productive
Capacity() Notify agreed capacity about some refer-
ence based on signed contracts
Input() Register receptions of material
Output() Register material consuptions
Warehouse
Stock() Notify availability
Load() Load some package into the transport
Unload() Unload packages
Transport
Move() Move them between executors
63
After that, we modeled the production process of each reference (almost ninety) as a
business process within which each activity (stamping, welding, and painting) is asso-
ciated with the corresponding executor and its services.
Subcontract or
Assembler
Raw Material Supplier
Subcontratista
Proveedo r
Fig. 4. Composing business processes by using executors and services
By using this set of services we provided the SME with a complementary module
running in the platform: a collaborative planner who checks SME’s plans feasibility
after analyzing the information gathered from each executor and, complementarily,
traces plan’s execution.
5 Conclusions
In this work we have presented advances in the work carried out within the INPREX
Project. We have introduced the IDIERE Service-Oriented Platform, and have defined
the main components that implement it. The project looks for a low-cost, flexible and
extensible platform that companies can use in order to design and execute inter-
organizational business processes by composing a sequence of services invocations.
We strongly rely on Service Oriented Architectures as a medium for enabling Small
and Medium Enterprises get involved in this kind of initiatives. By adopting standards
related to the Internet (Web Services stack for Communications, current initiatives
like OAGIS for content and BPMN/BPML for modelling) we have composed a
framework that is open, flexible and dynamic.
64
Regarding the project, it could be convenient to point out that currently there are a
lot of initiatives concerning business process management by using web services com-
position, but real undergoing implementations being carried out by SMEs are not so
usual. Currently, we are at the development stage of major components.
Acknowledgments
The INPREX (Interoperability of Extended Enterprise Processes) is project founded
by Ministry of Education and Science under the FEDER Program.
References
1. Britton, C. (2001). IT Architectures and Middleware: Strategies for Building Large, Inte-
grated Systems. Addison-Wesley.
2. Camarinha-Matos, L. and Afsarmanesh, H. (2001). Dynamic Virtual Organizations, or Not
So Dynamic? BASYS Proceedings pp 111-124.
3. Erl, T. (2004) Service Oriented Architectures: A Field Guide To Integrating XML and Web
Services. Prentice Hall.
4. Franco, R.D., Ortiz, A., Anaya, V. and Lario F.C. “IDR: A proposal for managing inter-
organizational business processes by using service oriented architectures". To be published
in PRO-VE ’04 Proceedings. Kluver Academic Publishers.
5. Kraft, R. (2002). "A Model for Network Services on the Web". The 3rd International Con-
ference on Internet Computing, IC 2002, 3:536:541, June 2002, Las Vegas
6. Mowshowitz, A. (1999). 'The switching principle in virtual organization', Virtual Organiza-
tion Net eJOV, vol. 1, no. 1, pp. 6-17
7. Ortiz, A., Franco R.D. y Alba, M. “V-CHAIN: Migrating from Extended to Virtual Enter-
prise within an Automotive Supply Chain”. PROVE’03 Proceedings. Processes and Foun-
dations for Virtual Organizations.
8. Rust, R.T. and Kannan, P.K. (2002) E-Service: New Directions in Theory and Practice. ME
Sharpe, Armonk, New York
9. Smith, H., and Fingar, P. (2002) Business Process Management: The Third Wave. Tampa:
Meghan-Kiffer Press, 2002.
10 Vogels, W. (2003). Web Services are not distributed objects. IEEE Internet Computing
Magazine. November/December 2003 (Vol. 7, No. 6)
11 World Wide Web Consortium (W3C), available at http://www.w3.org/TR/2002/WD-ws-
gloss-20021114/
65