Nowadays, all of enterprises are nnder ever increasing pressure to deliver their products more quickly and with higher levels of quality and provide their service more effectively and efficiently. Consequently they have to face the increasing rate of change in the socio economic envirornnent. Even if they are best poised today to leverage the opportunities of the global marketplace, some envirornnental, regulatory, or market change will occur that will change their reality and thereby, require them to respond to that change. It is generally recognized today that success in a rapidly changing envirornnent is closely tied to how the enterprise proactively manages and evolves its business practices as part of an efficient implementation of its overall strategic plan and how quickly and effectively the enterprise leverages new opportmrities. We have, in fact, entered the age of Business Process Reengineering (BPR).
Today's challenge to BPR is determining how to effectively respond to and manage
change, especially customer requirement change that is heart of enterprises
viability. In the mid-1980's enterprises began to recognize that being technology-driven-
the practice of creating new technologies and then trying to find markets for
them was an inefficient approach to managing innovation and led to many failed
efforts. As a result, momentum shifted to the customer-driven movement, which
required enterprises to first nnderstand what the customer wanted before investing
in the creation of a new product or service.
Logically, focusing on the customer-driven makes good sense, as it requires enterprises to listen closely to customers-but this practice has two major drawbacks: First, customers do not know what types of information are needed to create better products and services so they voice their requirements in a language that is convenient to them-e.g., solutions, specifications, needs and benefits-but not appropriate for the creation of breakthrough products and services. Second, because many enterprises apply the customer-driven so literally, they use the exact statements customers make as inputs into the innovation process-without recognizing the differences between the types of inputs they are likely obtaining. As a result, they often fail to consider how these different inputs may affect the way they identify opportunities, segment markets, generate and evaluate ideas, position products and services, measure customer satisfaction and perform other strategic development and marketing activities (Anthony, 2003). That is to say, customers cannot actually express generalizations that are powerful, precise and explicit, but they can discern which design they not want.
In the present study, we present an Integration Customer-Driven Scheme of Business
Process Reengineering (ICDSBPR) for building a prototype to promote cooperation
between enterprises and customers, through which customers can gradually amend
what they want and enterprises can have a reliable requirement analysis. First,
business process is described by BPEL4WS (Martin et al., 2004; Curbera
et al., 2003) as common gronnd for their cooperation in terms of customers'
requirement. Furthermore, when customers' requirements vary with an in-depth
requirement analysis, business process, if necessary, will make corresponding
change, that is business process reengineering based on customers' requirement.
Finally we will generate a prototype based on ICDSBPR scheme to transform BPEL4WS
to a software system that can provide early immediate experience for customers
to refine on the requirement. Consequently enterprises and customers can iterate
ICDSBPR scheme nntil satisfying results are obtained.
Business Process Execution Language for Web Services (BPEL4WS) is a specification
that represents a convergence of the ideas in the XLANG and WSFL specifications
and provides a language for the formal specification of business processes and
business interaction protocols. By doing so, it extends the Web Services interaction
model and enables it to support business transactions. Furthermoreit defines
an interoperable integration model that should facilitate the expansion of automated
process integration in both the intra-corporate and the business-to-business
spaces (Curbera et oZ ., 2003).
BPEL4WS is layered on top of several XML specifications: WSDL 1.1. XML Schema
1.0 and XPathl.O. WSDL messages and XML Schema type definitions provide the
data model used by BPEL4WS processes. XPath provides support for data manipulation.
All external resources and partners are represented as WSDL services.
ICDSBPR scheme IS based business process reengineering and composed of two
modules. One aims at refining requirement based on BPEL4WS and the other aims
at automatic generation of code and construction of database. as shown in Fig.
1. BPEL4WS. WSDL and XSD document are extracted from process model built
by toolkit describing customers' requirement, such as WSAD-IE (Osamu et al
., 2003). which provide graphical interfaces in integrated envirornnent
for customers to describe business process, thus customers and enterprises accomplishing
requirement analysis in manner of what they favor.
Automatic code generation module include:
||Process/data relationship analyzer is used to build corresponding
data relation between process model and data model, thus identifying data
access flow. With input of BPEL4WS document describing process model and
XSD document describing data model, it can implement automatic name-matching,
creating view in terms of rules, modifying type of field and default value
in database, designating type of an active data access in process model
and non-fnnctional requirement and connting active frequency. Finally process/data
relationship file is built according to XML Schema.
||Data access component builder analyses process/data relationship file,
automatic aligning data type in data access flow, mapping relation between
business item and database, etc., thereby automatic generating data access
component with appropriate granularity, such as storage process, EJB, JavaBean,
||Data access optimizer analyses operational type of data access,
active frequency, etc, on the basis of which index is created. Furthermore,
there is a pattern library in toolbox guiding building data access component
and optimization of data access. Experiencem development of software IS
summarized as pattern.
Having determined requirement, customers can generate prototype and verify
their implementation by described earlier module.
RELATION BETWEEN PROCESS MODEL AND DATA MODEL
Generation of data access component and optimization of data access are based
on conventional techniques, as well as XML parser can completes parse of relationship
model. Relation between process model described by BPEL4WS and data model is
illustrated in Fig. 2.
The BPEL4WS process itself is a kind of flow-chart. where each element in the
process is called an activity. An activity is either a primitive or a structured
||Relationship of data between BPEL4WS document and database
operation in BPEL4WS
The set of primitive activities contains: invoke (invoking an operation on
some web service), receive (waiting for a message from an external source),
reply (replying to an external source), wait (waiting for some time), assign
(copying data from one place to another), throw (indicating errors in the execution),
terminate (terminating the entire service instance) and empty (doing nothing)
In analysis ofBPEL4WS document, we will find part concerning data access such
as invoke operation (Fig. 3), namely data access point, which
ought to be consistent with operation on database (Fig. 2).
Figure 4 shows a toolbox developed to generate data access
component according to ICDSBPR scheme. To verify ICDSBPR scheme, we apply it
into practice. A scenario of travel agency (Fig. 5) specializing
in travel bookings that require reservations of a flight and hotel is designed
to illustrate its advantage (Peter et al., 2004). After customers described
requirement in WSAD-IE, corresponding prototype is generated, including data
||Toolbox for generation of data access component
||Basic outline ofthe travel agency
Then customers can nm code as if business process has been accomplished. As
long as customers encmmter dissatisfactory service, they can adjust requirement
and restart ICDSBPR scheme.
CONCLUSIONS AND FUTURE RESEARCH
A good requirement is a good start. In this study we proposed to use ICDSBPR scheme to develop prototype for refining requirement. The scheme fills the gap between requirement-refining and customer driven approaches. The result is a methodology for producing a BPEL4WS based application. which completely reflects the customer requirements and minimizes the ammmt of code development required. But business process reengineering is still at early stage of development; many researchers are improving on it (Mayer. 1997). The present study absorb more achievements, making ICDSBPR scheme more perfect.
Our thanks to the IBM China Research Laboratory (CRL) in Beijing for helping
us investigate the challenge. We specially owe thanks to investigation participants
for their ideas and efforts, including Guanqun Zhang (IBM).
The present study is supported by IBM University Joint Research Project (Process/Data Orchestrated Solution Design). 2005.