integrated value chains and their implications from a ...cgi.di.uoa.gr/~afrodite/dss.pdf ·...

Ž .Decision Support Systems 29 2000 323–342www.elsevier.comrlocaterdsw

Integrated value chains and their implications from abusiness and technology standpoint

Michael P. Papazoglou a,), Piet Ribbers b, Aphrodite Tsalgatidou c

a INFOLAB, Tilburg UniÕersity, PO Box 90153, 5000 LE Tilburg, Netherlandsb Department of Information Systems and Management, Tilburg UniÕersity, PO Box 90153, 5000 LE Tilburg, Netherlands

c Department of Informatics, UniÕersity of Athens, Panepistimiopolis, Ilisia, Athens 157 71, Greece

Abstract

Unlike previous decades where enterprises prized independence, the next decade will be one of business alliances andcompeting, end-to-end value chains. Enterprise value chains comprised of powerful business alliance partners willexceedingly compete as single entities for customers. Such extended corporations reach out not only with businessrelationships; they must integrate their business processes and information systems. In this paper, we review the business andtechnological requirements of modern extended organizations and explain how adaptive business objects and controlledinteroperability are the key enabling technologies to the challenge of integrated value chains. q 2000 Elsevier Science B.V.All rights reserved.

Keywords: Business-to-business electronic commerce; Value chains; Business models; Business processes; Business objects; Workflows;Business transactions; Interoperability; Change management; Business infrastructure

1. Introduction

To cope with market demands and changes andmaintain their competitive advantage, forward-think-ing companies try to find new ways of workingtogether with partners to provide customers with arange of services that knot together so seamlesslythat they amount to more than the sum of their parts.As a consequence, businesses increasingly integratetheir value chains by redesigning their structures to

) Corresponding author. Tel.: q31-13-466-3020; fax: q31-13-466-3069.

Ž .E-mail addresses: [email protected] M.P. Papazoglou ,Ž [email protected] P. Ribbers , [email protected]

Ž .A. Tsalgatidou .

move from hierarchical — with a focus on manage-ment control — to horizontal organizations — builtaround business processes, teamwork and empower-ment. However, new patterns of cooperation betweentrading partners are necessary to successfully re-spond to new market demands. The concept of sup-ply chain refers to the chain of activities, executedby two or more separate organizations, to fulfillcustomer orders. A supply chain that is fully cus-tomized will start its operations after customers place

w xtheir orders. Jarvenpaa and Ives 16 call this ‘think-ing in reverse’, meaning that organizations shouldbase their production on actual customer demandrather than producing on stock. Several cases arepresented in the literature of how supply chains havebeen redesigned to become more pro-active towards

w xthe customer. As an example, Ref. 17 describes the

0167-9236r00r$ - see front matter q 2000 Elsevier Science B.V. All rights reserved.Ž .PII: S0167-9236 00 00081-6

( )M.P. Papazoglou et al.rDecision Support Systems 29 2000 323–342324

cases of Compaq and Benton to illustrate how theyhave established cooperative strategic partnerships tobecome more pro-active towards the demand of cus-tomers.

w xIn dynamic network organizations 27 quickbuild-up and dismantling of inter-organizational rela-tionships is a pre-condition for success. In this kindof structure, each organization will focus on a lim-

w xited number of core competencies 15 . Each organi-zation ultimately concentrates on those areas whereit may have a unique competitive advantage; othersare outsourced and bought in the market. Concentrat-ing on a limited number of activities offers thepossibility to stay lean and mean, and thus avoidunnecessary overhead. This requires that all partnerskeep a clear view of the coherence of the totalsystem of competencies within the network. All ac-tors should have an insight as to where and howvalue is created and what contribution they can make

w xbased on their own competencies 42 .An encompassing concept is emerging nowadays:

the integrated Õalue system. Value system integra-tion can be defined as the process by which multipleenterprises within a shared market segment collabo-ratively plan, implement and manage the flow ofgoods, services and information along the value sys-tem in a way that increases customer-perceived value

w xand optimizes the efficiency of the chain 8 . Com-pany value chains are transformed into integratedvalue systems if they are designed to act as anAextended enterpriseB, creating and enhancing cus-tomer-perceived value by means of cross-enterprisecollaboration. The concept of integrated system isexpected to have major impact, allowing companiesand ultimately customers, to benefit from reducedinventories, cost savings, improved value addedgoods and services to customers, and tighter linkswith business partners.

What is the role of IT in all of this? The applica-tion of various information-based technologies isboth the cause and the effect of new ways to dobusiness. The convergence of IT and telecommunica-tions, and the availability of bandwidth supports andenables new organizational designs. The networkedorganization, linkages of supply chain partners andalliances exploiting uniquely grouped core compe-tencies are all supported or enabled by modern IT.From a technology perspective, integrated value sys-

tems require a fully integrated framework and infras-tructure support to provide access throughout theentire chain. Moreover, this type of universal accessmust be both transparent and adaptive. This raises anumber of challenges, which must be addressed be-fore integrated value systems become a reality. Thecombined business and technology-driven require-ments, listed below, are four key driving forces thatwould enable successful development and deploy-ment of integrated value system applications.

New business models: Integrated value-chain or-ganizations seek to streamline their processes andimprove customer service through greater connectiv-ity between both business processes and key opera-tional systems. An important business objective ofstrategic alliances with suppliers, channel partnersand service providers is to eliminate supply chaindiscontinuities that produce delays and waste. Enter-prises can only become an effective link in a leadingvalue chain by re-conceptualizing the company as acollection of business operations and processes, byreshaping corporate structures around modern busi-ness processes and by making their internal pro-cesses align with and support the integrated valuechain. This requires that new business models arecreated to offer a new way to deliver value tocustomers. New business models are needed andcurrently emerging.

Cross-enterprise interoperability: Another impor-tant requirement is that integrated value chains takeadvantage of existing and emerging technologies andsystems that can be used to link and enable the entirevalue chain. Information systems play a major part inthis drive for competitive edge as their interoperationallows business allied partners to use informationmuch more effectively in the rapid delivery of goodsand services to customers. The foundation of thisbarrier-free environment is interoperability: the abil-ity of one system to process information from and toanother at a syntactic and semantic level withoutrequiring either system to make changes to accom-modate the other. Thus, improved business processesand interoperability are core requirements critical tothe success of integrated value chain.

Change management: In addition to improvedbusiness modeling and interoperability, it is impor-tant to make sure that critical applications are notobstacles to new ways of conducting business. Elec-

( )M.P. Papazoglou et al.rDecision Support Systems 29 2000 323–342 325

tronic commerce applications and the new frontier ofcustomer interaction require that system incompati-bilities be overcome and that business processes andinformation systems not only harmonize but alsojointly support the ability to react quickly to newopportunities. This requires primarily that businessprocesses are flexible and adaptable to handlechanging business needs. Such issues focus attentionnot only on the need to gracefully accommodateprocess changes but also on how to synthesize abusiness process out of fragments, some of whichmay leverage legacy assets.

Organization infrastructure: The organizations oftoday are confronted with the problem on how tostrike a balance between local needs for differentsystems and overall needs for connectivity andshare-ability of data and applications. Extreme de-centralization of application of IT will hamper busi-ness developments towards process oriented andflexible network structures. Attempts to centralizeddevelopment of IT in Aone fits allB type of applica-tions will be costly to develop and will result insystems, which will not support individual businessrequirements. The solution to this problem is cur-rently sought in a distinction between local informa-tion systems and information infrastructure.

This paper provides an overview of the businessand technology considerations, as well as infrastruc-tural support, that are required to enable the transi-tion of organizations from relative independence andfunctionally oriented business thinking, and tradi-tions, to integrated value chains. We first discussfive representative types of business models and thenwe introduce business objects and core businessprocesses as the enabling technology for integratedvalue systems. Subsequently, we examine the impactof the integrated value systems to business processesand workflows and we discuss business interoper-ability at the cross-enterprise level. Finally, we ex-amine the major factors that drive this transition insome detail.

2. New business models

Global competition, technology advancements, in-dustry deregulation and increasing customer expecta-tions are only a few factors that are placing unprece-

dented demands on business enterprises. Success intoday’s virtual marketplace will depend on creatingnetworks of cross-industry partners to provide prod-ucts and services related to the customer’s basicneeds. In order for companies to be successful, theyneed to evaluate innovative new strategies that capi-talize on both the power of the Internet and thechanges in market demands. It is becoming increas-ingly evident that yesterday’s business models, tech-niques, structures and philosophies are becomingirrelevant in responding to global market require-ments. Thus, it is not surprising that many businessesare forced to rethink their on-line business strategiesand their business models. Businesses hoping toexpand their activities onto the Internet are re-en-gineering or refining their products and services inorder to take advantage of the new opportunities, aswell as face the new challenges, of the medium.

Over the past two decades, businesses had toadapt and transform their organizations. A number ofchange models have been introduced and tried dur-ing that time, but at best, they produced incrementalimprovements on the AfringesB with marginal bottomline results. Many involved change strategies thatlaunched several change initiatives within the organi-zation simultaneously, each narrowly focused onspecific aspects of the organization with little or nopre-planning and coordination. This approach tries tochange the organization’s parts but ultimately resultsin sub-optimizing the whole system for marginalbottom line performance. Constant change is nowpushing into the very core of many corporations withcorresponding new business models emerging fromthe way in which organizations and people worktogether. Any initiative to transform or change anenterprise must consider how that particular enter-prise operates as an integrated whole, and its rela-tionships with its suppliers, business partners andcustomers.

Most traditional seller- or product-driven busi-nesses create value primarily at the product or line-of-business level. In contrast to this, the integratedvalue-chain business model is customer-centric,where value is created at the relationship level acrossproducts and channels rather than at the individualproduct level. One important area of focus in thecustomer-centric model is on bundling differentproducts and services within the same industry to


create solutions. Many companies are adopting acustomer-centric business model, becoming more re-sponsive to and developing deeper relationships withcustomers. Relationships with suppliers, partners andcustomers need to be mediated almost exclusivelyusing Internet technology, and the integration possi-ble is becoming deeper, broader and more seamlessthan was ever deemed possible. Processes and valuechains are evolving rapidly as companies outsourcenon-core activities and capabilities, leading to moresophisticated markets and a wider distribution ofeconomic activity, i.e. the way we do business isundergoing a period of rapid change.

We can distinguish between five representativetypes of business models, which are typical of mostcommon modern IT-based business organizations thatengage in electronic commerce practices. These in-clude:

1. the teleworking model;2. the virtual organization model;3. the collaborative product development model;4. the process outsourcing model; and5. the value-chain integration model.

2.1. Teleworking model

In the teleworking model, large number of indi-viduals or groups work together collaborating withthe assistance of networking and communicationstechnologies. A classical example of the teleworkingmodel is telemedicine which has become a busi-nessrtechnicalrhuman paradigm for the transmis-sion of health related information or services whichmay span university medical centers, hospitals,provider groups, clinics, doctors and nurses, finan-

w xcial and insurance specialists 14 . For example,telemedical services can be delivered by collabo-rating with a radiologist from a remote site overspecialized medical infrastructure or providing psy-chological consulting services to remote clinics orprisons from the medical office.

2.2. Virtual organization model

Effective contracting for complementary capabili-ties through a network of suppliers and subcontrac-

w xtors is a characteristic of virtual organizing 38 . A

virtual organization may be a temporary or perma-nent collection of geographically dispersed individu-als, groups, organizational units, which do not neces-sarily belong to the same organization, or entireorganizations that depend on electronic linking tocomplete the production process.

Organizations like Amazon.com are classical typesof this model. Onsale is another example of such a

Ž .model. Onsale http:rrwww.onsale.com have suc-cessfully created a market-space for not only sellingon-line, but also exploited organizational opportuni-ties afforded by emerging technologies, by building atruly virtual organization where inventory is mini-mal, geographical proximity is not a major issue, andinformation and partnering are of paramount impor-tance. Onsale is an on-line auction house which sellscomputers, chips, peripherals and other computerrelated add-ons through the Worldwide Web. Withknowledge and information around the on-line auc-tioning process being its primary resources, the rela-tively small company gains significantly in size andfunctionality by partnering with other organizationsand outsourcing non-essential activities.

2.3. Process outsourcing model

Nowadays, organizations are starting to realizethey can interact with customers, partners and suppli-ers, exchanging and leveraging knowledge in addi-tion to undertaking transactions. Facilities that wereonce central to the business are now outsourced.Process outsourcing is the delegation of one or morebusiness processes to an external provider who owns,manages and administers the selected processes.

For example, take Ford Motor who decided thatthe manufacture of cars will be a declining part of itsbusiness and instead they will concentrate in futureon design, branding, marketing sales and serviceoperations. Like all modern carmakers, Ford hasoutsourced the supply of entire sub-systems — fromengines and suspension assemblies to car interiors. Insuch situations, suppliers application systems are

Ž .automatically kept abreast of requirements via EDI .

2.4. CollaboratiÕe product deÕelopment model

A classical example of a collaborative productdevelopment model is that used by Ford. Ford re-


cently launched the AFord 2000 programB aimed tomake Ford a truly global company, that could cen-tralize the development of global product categoriesthat would be customized to meet the demands of

w xlocal markets 11 . The company’s central goals forthis program were threefold. Firstly, a company-widereorganization that established vehicle centers to takeresponsibility for the developments of a given classof vehicles and to design, engineer and test newtechnologies. Secondly, the shortening of new cardevelopment times through vertical and horizontalintegration as well as by reducing the variety of partsthat go into its vehicles. And finally, identification ofthe aspects of any car model that can be developedcommonly and those that are best customized for agiven market.

Central to the new organization structure andproduct development processes was the need to coor-dinate disparate product development activities. Thiscalled for flexible information systems and an appli-cation for managing and transmitting design docu-ments across various Ford Centers around the world.Installing such systems quickly meant a move awayfrom the company’s traditionally heavy use of in-house developed mainframe systems to more agilepackaged client-server software and platforms.

2.5. Value-chain integration model

Value-chain integration uses Internet technologyto improve communication and collaboration be-tween all parties within a supply chain. Value-chainintegration is necessary if vendors are to coordinatebetween AupstreamB suppliers, internal operationsŽ .e.g. manufacturing processes , and AdownstreamBshippers and customers effectively. With this model,processes once perceived as internal to the companymust now span the entire value chain. Effectiveservice providers integrate their operations directlyinto the processes of their customers.

With this model, every company in the chainperforms a set or sequence of activities to produce itsproducts. The links between those activities providea prime opportunity for competitive advantage,whether due to exceptional efficiency or some formof product differentiation. This chain of partners thatwork in sequence to create, market and move goods

and services grows even more complex. For exam-ple, take SouthWest Airlines, which have as strategicpartners not only the Boeing with all of their aircraft,but also General Electric, which makes the enginesthat Boeing uses. In addition, the airline has partnersincluding jet fuel makers, travel agents, long-dis-tance vendors and computer hardware and softwaremarkets in its value chain.

Based on the sorts of intimate trading relation-ships central to the integrated value-chain model,modern business partnerships are eradicating dupli-cation, irrelevant hand-offs and rework, ensuring thatprocesses run smoothly and effectively.

It is evident that these new business models havecertain implications on business processes of individ-ual organizations as the latter have to cope with thistransition to a multiple enterprise environment. Busi-ness processes have to be redesigned as they nowcross organizational boundaries and integrate otherhomogeneous andror heterogeneous processes andservices of diverse organizations in order to collabo-ratively achieve the desired result. The followingsection discusses how business objects can be usedas the underlying technology in an integrated enter-prise framework for enabling the required businessprocess interoperability in a value-chain integration

Žmodel. It examines three approaches global, multi-ple homogeneous and multiple heterogeneous busi-

.ness process approach used for realizing cross-organizational business processes.

3. Enabling technologies: business objects andprocesses

Business objects are the key building block in theŽ .re-engineered process-oriented enterprise as they

can realize domain business processes and defaultbusiness logic that can be used to start buildingapplications in these domains. Business objects pro-vide pre-assembled business functionality that can beused to bring together and customize applications.They provide a natural way for describing applica-tion-independent concepts such as customers, prod-ucts, orders, bills, financial instruments and temporalinformation, such as a quarterly earnings period orannual tax cycle. Business objects add value to a


business by providing a way of managing complex-ity and giving a higher level perspective that is

w xunderstandable by the business 25 .Business objects package together essential busi-

ness characteristics such as business procedures, pol-icy and controls around business data. This creates asemantic construct that holds together in a coherentunit the right business policy with the right data andensures that the data is used in a manner consistentwith the business intent. We can separate businessobjects in two broad categories: conventional busi-ness objects, already described in the preceding para-graph, and business process objects. Business pro-

Ž .cess objects are a kind of active or control objectsthat bring together business objects to define a busi-ness process. They are characterized by a set ofinterrelated activities that collectively accomplish aspecific business objective, possibly, according to aset of pre-specified policies. A business object is adata with behavior, while a business process objectŽ .henceforth referred to as business process operateson business objects, i.e. it changes their states andcoordinates their interactions. Business processes in-teract in a predictable, repeatable manner to producea recognized business activity of generic nature in aspecific business domain, e.g. procurement manage-ment, general ledger, etc. Business processes areinitiated by events that trigger activities in the orga-

w x Ž .nization 6 . These events can be internal e.g. rulesŽ .or external e.g. customer requests . The business

processes are initiated on the basis of an incomingŽ .event e.g. a customer request and result in an

Žoutgoing event e.g. the notification that a product is.ordered .

Business processes provide the basic ingredientsthat can be specialized and extended to capturedomain or application specific processes — within aparticular vertical domain, e.g. financial, manufactur-ing — which are realized by a workflow. Workflowmanagement systems support the definition, execu-tion and controlling of the business processes. Work-flow applications rely on an extensive foundation ofreusable components, viz. the core business pro-cesses that form the basis for building new applica-tions. Workflow support for integrated value chainsshould provide the infrastructure to allow businessprocesses to cooperate and execute distributivelyacross enterprise boundaries. Workflow components

will necessary be disparated, they will either beadapted from existing proprietary workflow productsor will be newly developed specifically for the dis-tributed business infrastructure.

3.1. The integrated enterprise framework

The new business objectives demand an inte-grated framework and infrastructure. To meet therequirements of modern organizations, and get betterreuse from software, distributed business object com-

w xputing is the preferred solution 25 . Distributed ob-ject computing blends together the power of clientrserver computing and object-oriented developmentby distributing clients and servers, in the form ofcooperating objects, across an integrated value-chainnetwork. The whole concept of distributed comput-ing can be viewed as simply a global network ofcooperating business objects. Furthermore, missioncritical legacy systems can be AwrappedB and partic-ipate in the distributed object environment.

Fig. 1 illustrates an integrated value-chain enter-prise framework for modeling business applicationsand for developing and delivering enterprise solu-tions. This enterprise framework consists of businesscomponents, processes and workflow applicationsdefined within a specific AverticalB industry, or acrosssuch industries. The integrated enterprise frameworkin Fig. 1 provides a base for the effective encapsula-tion of business practices, policies and tactics inmodular high-level components. The integrated en-terprise framework, described in this section, hasbeen largely influenced by similar enterprise archi-tectures that can be found elsewhere in literature:

w xsuch as the CommerceNet architecture 26 and Sanw xFrancisco 1 . In this sense, the terms business ob-

jects and business processes are slightly differentfrom those proposed by the OMG.

The highest two layers in the enterprise frame-work provide the core business process objects andworkflow applications that can be easily combinedand extended to offer a complete cross-organiza-tional business solution. In particular, the purpose ofthe workflow layer is to allow disparate workflowapplications to interoperate over enterprise-wide net-works and deliver consistent workflow functionality.For example, an order activity in a production plan-


Fig. 1. The integrated enterprise framework.

ning process may start an appropriate order entryprocess at a closely aligned parts supplier. This typeof cooperation can only be achieved if the workflowsystems of the cooperating companies are looselycoupled. This results in the elimination of supplychain discontinuities that produce delays and waste.Distributed workflows use functionality provided bybusiness process and objects and are normally built

w xon a distributed object network infrastructure 32,37 ,such as that provided by the middleware infrastruc-ture layer. At the next level, business objects can beused as a basis for building business process solu-tions. Although interoperation in this environment isachieved mainly at the workflow and business pro-cess level, cross-enterprise applications may scripttogether business objects from different organiza-tions. This allows business objects to effectively

Ž .reuse legacy systems in the form of legacy wrappedobjects. In this way, legacy systems that are criticalto business objectives can participate in the dis-tributed object environment. The lowest layer pro-vides the infrastructure and services that are requiredto built industrial-strength applications by supportingthe functionality of the workflow, business processand business objects layers.

It is noted that the notion of ‘Core BusinessProcesses’ in the proposed Integrated EnterpriseFramework is different from the notion of ‘BusinessProcess Models’ used by current Business Process

Ž . w xModeling Tools BPMTs , such as ARIS 3 or thew xWorkflow Analyzer by Metasoftware 45 . Their

main difference lies in their intended use: BPMTsintend to produce business process models in orderto understand and describe how a business work, and

in order to simulate business process behavior fordemonstration purposes. Their purpose is to detect

Ž .deficiencies andror validate the re designed busi-ness process before proceeding to its implementa-tion. Core Business Processes herein have a differentintended use. They intend to provide the basic ingre-dients for implementing business process applica-tions in a distributed environment by encapsulatingbehavior and data that can be further specialized andextended in order to capture the requirements of areal-world business process in a specific domain. Weare currently investigating how business processmodels produced by current BPMTs can drive, onone hand, the identification of appropriate businessobjects and, on the other, the selection of appropriateCore Business Processes and respective required spe-cializations or extensions. In this way, better work-flow applications can be realized that satisfy therequirements of real-world environment captured inbusiness process models.

3.2. Integrated Õalue chains and business processes

Integrated value chains is the result of strategicalliances between business partners for achievingcompetitive advantage. Such strategic alliances re-quire outsourcing or redesigning the business pro-cesses of the partners. Therefore, the impact of inte-grated value chains on business processes should notbe underestimated. As an example of a businessprocess that is typically outsourced, consider theAassessment of damagesB subprocess of an insurancecompany. Typically, there are multiple loss adjustersthat assess damages in insurance claims, i.e. perform


outsourced Aassessment of damagesB processes. Sim-ilarly, the logistical processes of a company are oftenoutsourced to incorporate new business solutions,such as just-in-time inventory systems or quick re-sponse products for inventory management. Alterna-tively, such processes may be redesigned to elimi-nate the invoice subprocess and incorporate EDItransactions in the requisition management and soon. Therefore, the critical core competency that willallow organizations to achieve competitive advan-

Ž .tage is their ability to rapidly re design not just aproduct or a service but their business processes andthe whole supply chain that supports them.

The requirements of these business processes,which usually cross organizational boundaries, aredifferent from traditional business processes. Theemergence of protocols and standards like the Light

Ž . w xWeight Directory Access Protocol LDAP 21 orŽ . w xthe Simple Workflow Access Protocol SWAP 39

Ž . w xand Workflow Management Facility WMF 47 arealong this dimension. LDAP is a software protocolfor enabling individuals to locate organizations, otherindividuals and other resources, such as businessprocesses, services, files or devices in a network,whether on the Internet or on a corporate Intranet.On the other hand, SWAP and WMF have proposedvariants of a proxy mechanism that provide access tospecific activities located in a different enterprise.However, these interfaces contribute only in crossingvendor boundaries but not organizational ones.

Currently, we can identify three approaches thatŽ .can be used for the re design of cross-organizational

business processes, as is the case with processes inintegrated value chains:

1. the global business process approach,2. the multiple homogeneous process approach and3. the multiple heterogeneous process approach.

These are examined in the following. In order tobetter demonstrate the characteristics and differencesbetween theses approaches, we will use an exampleof a company A that assemblies and sells PCs to itscustomers and outsources the distribution of the PCsto another company B. Thus, company A is the‘requester’ organization since it requests from B thedistribution of its products while company B is the

‘provider’ organization since it provides the distribu-tion service to A.

3.2.1. Global business approachWith this approach, the problem of process

Ž .re design is tackled by assuming that there is asingle global process that is further decomposed intosubprocesses and sub-activities performed by differ-ent players in the integrated value chain. This ap-proach also assumes that all entities and organiza-tions that participate in a strategic alliance haveagreed that they will fully support this global pro-cess. Using the aforementioned example, in thisapproach, there is a global business process modelthat captures and models all related activities includ-ing distribution. Both the ‘requester’ and the ‘pro-vider’ companies A and B are fully aware of thedetails of this process model and have agreed whichparts will be executed by whom. In other words, the‘requester’ and the ‘provider’ companies have notonly agreed upon the result of the requestedrpro-vided service, but also on how this is going to beachieved. Centralized workflow management is usedfor the implementation of such an approach.

A representative example in this approach is thew xwork by Malone et al. 24 . They have developed a

process handbook that can be used to invent radi-cally new processes, to improve existing businessprocesses, to share ideas about organizational prac-tices and to develop software. Their approach alsoincludes:

1. the notion of ‘process specialization’ based onideas about inheritance from object-oriented pro-gramming, and

2. concepts about ‘managing dependencies’ fromcoordination theory.

ŽThe combination of process decomposition a ba-.sic feature of any process description with special-

ization and coordination is very helpful for analyzinga single process in isolation. In their handbook, theseconcepts are applied also to a collection of processes.This provides a framework for storing a large num-ber of processes and for generating a lot of alterna-tive processes and families of processes modeledafter distant cousins and their descendants. Further-more, using this framework, differences and similari-


ties among a collection of related processes can beeasily expressed. Entering a significant number ofprocess descriptions into the system has tested theirapproach.

3.2.2. Multiple homogeneous process approachThe usual case in cross-organizational business

processes is that the ‘requester’ and ‘provider’ enti-ties agree only upon a result but not on how this isgoing to be achieved. This is left to the providerenterprise, which usually does not want to revealdetails about its internal operation. This means thatthe ‘requester’ should not know the internal opera-tion of the provider and the provider can be sure thatinternal organizational or process details are notrevealed. This guarantees the independence, auton-omy and privacy of the involved parties. Also,changes in one party’s internal operation can be donewithout informing the collaborating parties as longas these changes do not affect the results or theinterface agreed. Such requirements of privacy andindependence cannot be supported by the ‘GlobalBusiness Model’ approach, since all participants haveto agree about one global business process model,and thus they know the parts of the process executedby the other parties and the way they are executed.These requirements are handled by the homogeneousprocess model approach and the heterogeneous pro-cess approaches that support integration of multiple

Žprocess models either homogeneous homogeneous. Žprocess model approach or heterogeneous hetero-.geneous process approach . The implementation of

such approaches is by using decentralized workflowmanagement technology.

A representative example of the homogeneousprocess model approach is the work by Ludwig and

w xWhittingham 23 , which addresses the issues ofprivacy, flexibility and organization independence ofparticipating entities. They propose the Virtual En-

Ž .terprise Co-ordinator VEC concept for the setupand management of cross-organizational businessprocesses by using gateways to workflow-enactedprocesses for other organizations. More specifically,the gateways are used to establish a relationshipbetween a process, enacted in the workflow of oneorganization and a subprocess of it performed au-tonomously by another organization on behalf of thefirst organization. These gateways are configured

according to simple agreements on a case-by-casebasis or on a process template basis. In this way,VEC enables ‘provider’ organizations to offer to‘requester’ organizations a controlled way of access-ing their workflow enacted processes while retainingthe freedom to change the internal details of theseprocesses and vice versa. The operations provided bythe organization-external gateway interfaces are stan-

w xdard WfMC 46 operations.Referring again to the example of the ‘requester’

company A that assembles and sells PCs, in thisapproach, there is no global business process model.The main part of the business process is specifiedand enacted by a workflow application at the ‘re-quester’ company A while the distribution service isseparately specified and handled autonomously bycompany B. Communication between the ‘provider’and the ‘requester’ organizations takes place onlythrough standard WfMC operations. Thus, A can‘start’ the distribution subprocess at B which willthus enter the ‘running’ state. A can obtain informa-tion about the distribution subprocess only after thelatter has been completed or terminated.

3.2.3. Multiple heterogeneous process approachThis approach tries to satisfy further requirements

of conversation, control and semantic heterogeneityof requested services. The work by Georgakopoulos

w xet al. 12 belongs in this category. In their approach,they enable the integration of any kind of service,i.e. a business process, a CORBA object, or even alegacy system. Interaction with the integrated ser-vices is supported not only through standard WfMCoperations but also through semantically rich user-defined operations. The model they introduce is

Ž .called Collaboration Management Model CMM .CMM achieves these objectives by introducing ap-plication-specific activity states and operations, ser-vice activities, and service abstractions such as sub-classes and integration processes. The capturing ofapplication semantics by process models is veryimportant as it allows the integration of heteroge-neous services and processes instead of burying themin some integration program. Most of the existingprocess models such as those used in many tradi-tional workflow management systems and proxy

w x w xmechanisms such as SWAP 39 and WMF 47provide only the generic activity states and activity


w xoperations of the WfMC 46 and do not offer effec-tive abstractions for integrating heterogeneous ser-vices. The primitives introduced in the CMM supportthese and allow conversational activities.

w xThe work by Klingemann et al. 19 could be alsoconsidered in this category. Integration of heteroge-

w xneous services is also allowed here as in Ref. 12 ,w xwhile gateways are used, as in Ref. 23 for compen-

sating heterogeneity between service providers, e.g.differing naming schemes for the same service. Theauthors extend the activity model for services andprovide control and notification events. Controlevents can be sent by the service requester to theservice provider in order to influence the processingof the service. Notification events are used to informthe service requester about the state of the processingof the external service. However, they do not supportapplication-specific states and conversational coordi-nation of services as it is the case with the CMM

w x w xapproach 12 . It has to be noted in Ref. 19 that theimplementation of a service by a provider is onlypartially autonomous. Providers declare which activi-ties will support from a global workflow; this is animplicit promise that they will also support the de-pendencies between the declared activities, therefore,the implementation autonomy is restricted and theautonomy preservation claim does not hold to its fullextent.

Using again the same example, we note that themain differences of this approach from the homoge-

Ž .neous process model approach are that: 1 the re-quested distribution service need not be executed bya workflow management system at the site of the‘provider’ company B; this can be anything: a sub-process, a legacy system, a computer program etc.

Ž .and 2 the interaction with the requested distributionservice is supported not only through standard WfMC

w xoperations; in Ref. 12 , this is also supported throughsemantically rich user-defined operations and con-versational activities. Thus, the ‘requester’ companyA does not have to wait till the completion or thetermination of the distribution activity in order to getresults; it can request information about the status ofthe distribution service while the latter is still execut-

w xing. In Ref. 19 , notification events are used toinform A about the state of the distribution service,e.g. the parcel with the PC has been loaded on thetruck. Furthermore, company A can influence the

distribution service being executed at company B bysending control events that cancel, interrupt or speedup the distribution.

4. Business interoperability at the cross-enterpriselevel

Workflow technology in integrated value chainsmanages long-running, process-oriented applicationsthat automate business processes over enterprise-widenetworks. The workflow can be perceived as a scriptprescribing the combination, and subsequent interop-eration, of business processes and objects to reach ajoint business goal. The approach taken here is to

Ž .develop possibly distributed fragments of businessprocess with the relevant application functionalityattached. These fragments are then combined on thefly, as required, to suit the needs of each application.Rather than having to compose ever more complexend-to-end offerings, the enterprise can leave it tothe application developer to choose those elementsthat are most appropriate, combining the processfragments into a cohesive whole. At run-time, theworkflow management system manages the flow ofcontrol and data between the business processes,establishes transaction boundaries around them asdefined in the script and makes certain that theproper business process units of the enterprise utilizethe services provided by the various business objects.

Workflow-enabled business processes can tracktransactions across department, company and enter-prise boundaries. This type of distributed workflow

Ž .layer see Fig. 1 provides the sequence of businessactivities, arrangement for the delivery of work tothe appropriate organizational resources; tracking ofthe status of business activities; coordination of the

Ž .flow of information of inter- and intra- organiza-tional activities and the possibility to decide among

w xalternative execution paths 28 . Workflow activitiesmay invoke components from existing applications,

Ž .for instance, legacy wrapped objects, and combinethem with newly developed applications comprisingbusiness objects and policies.

A key activity in integrated value chains is thecollection, management, analysis, and interpretationof the various commercial data to make more intelli-gent and effective transaction-related decisions. Ex-


amples include collecting business references, coor-dinating and managing marketing strategies, deter-mining new product offerings, grantingrextendingcredit and managing market risk. Performance ofthese tasks requires involving collaborative comput-ing technologies to support distributed workflowprocesses. The requirements of transactional work-

w xflows have been described in Ref. 37 . Workflowimplementations of business processes can be notonly transactional processes, or classical transac-tions, but also non-transactional processes. Transac-tions as activity implementations frequently appearwhen the business model represents one of the core

Ž .business processes order entry, etc. of an enter-prise. Non-transactional activity implementations are

Žfrequently found within support processes travel.expense accounts, etc. .

An area of growing interest for the distributedcomputing infrastructure in Fig. 1, which providesconventional support, is the integration of Object

Ž .Request Brokers ORBs with Distributed Transac-Ž .tion Processing DTP monitors such as for example,

Encina and Tuxedo. DTPs are important to enter-prise-wide and cross-enterprise applications in whicha business procedure may be broken into a set ofprocesses. DTPs provide an open environment thatsupports a variety of client applications, databases,legacy systems, networks and communications op-tions. Monitors can support large numbers of usersrequesting concurrent access to transaction programsand services, e.g. database, security, workflow; bal-ance local and distributed loads to optimize perfor-mance; and efficiently synchronize data updates tomultiple databases during transaction using standard

w xprotocols 2 .Transactions in the business to business electronic

commerce are usually long-lived propositions involv-ing negotiations, commitments, contracts, floatingexchange rates, shipping and logistics, tracking, var-ied payment instruments, exception handling andcustomer satisfaction. Business transactions havetwo basic distinguishing characteristics. Firstly, theyextend the scope of traditional transaction processingas they may encompass classical transactions, whichthey combine with non-transactional processes. Sec-ondly, they group both classical transactions as wellas non-transactional processes together into a unit ofwork that reflects the semantics and behavior of their

underlying business task. In addition to these basicrequirements, business transactions are generallygoverned by contracts and update accounts and mayinclude the exchange of bills and invoices, and ex-change of financial information services. As a conse-quence, business transactions must provide modelingsupport and mediate communication, interaction, andcoordination among collaborating people and busi-ness activities within and between organizations.Hence, business transaction characteristics are betteraddressed by a process-centered approach to transac-tion management that supports long-lived concurrent,

w xnested, multi-threaded activities 20,28,37 .Business transactions usually operate on docu-

ment-based information objects such as documentsand forms. A document is traditionally associatedwith items such as manuals, letters, bids and propos-als. A form is traditionally associated with itemssuch as invoices, purchase orders and travel requests.Both these media are arranged according to somepredefined structure. Forms-based objects are closelyaligned with business transactions, which have nu-merical content, while document-based objects areassociated with contracts or bids. This allows busi-ness transactions to interchange everything fromproduct information and pricing proposals to finan-cial and legal statements.

Business transactions exhibit two broad phases:construction and enactment. Construction involvesthe collection of information based on catalogs andbrokerage systems to locate sources; agreement lead-ing to terms and conditions through negotiationmechanisms; and engagement resulting in a formalcontract. Enactment involves deployment across thegroup of participants in the transaction; service exe-cution in the context of the contract and managementof exceptions; and termination involving validationand closing the contact across all participants. In theworld of electronic commerce, traditional databasetransactions are replaced with long-lived, multi-levelcollaborations. It is thus not surprising that theyrequire support for a variety of unconventional be-haÕioral features, which are summarized in the fol-lowing:

1. General purpose characteristicsŽ .a who is involved in the transaction;Ž .b what is being transacted;


Ž .c the destination of payment and delivery;Ž .d the transaction time frame;Ž .e permissible operations.

2. Special purpose characteristicsŽ .a links to other transactions;Ž .b receipts and acknowledgments;Ž .c identification of money transferred outsidenational boundaries.

3. Advanced characteristicsŽ . Ža the ability to support reversible compensat-

. Ž .ible and repaired contingency transactions;Ž .b the ability to reconcile and link transactionswith other transactions;Ž .c the ability to specify contractual agree-ments, liabilities and dispute resolution poli-cies;Ž .d the ability to support secure EDI, e.g. SET,transactions that guarantee integrity of informa-tion, confidentiality and non-repudiation;Ž .e the ability for transactions to be monitored,logged and recovered.

Integrated value chains demand advanced transac-tion paradigms that relate to their business processes.An important requirement of business transactionswhich deserves mentioning is business commitments.Business commitments comprise the AglueB thatbinds businesses and other organizations at theirboundaries. A business commitment is the result ofan agreement between business parties that maybring about contractual agreements. Business com-mitments, viz. contracts, mandate certain outcomesthat are to be produced by the business. They have astrong recursive element that says that agreementsare composed of more granular agreements such asterms, conditions and obligations, viz. conditions offulfillment and conditions of satisfaction. It is impor-tant for a distributed workflow application to be ableto express varying types and extents of businesscommitments. It is therefore convenient, as shown in

w xRef. 43 , to represent such commitments as specialpurpose transactions including their own semanticsand communication protocol. Termination of thesecontracts may be a long-lived activity as these mayinclude ongoing service agreements with on-line cus-tomer service delivery and other complex aspects ofoverall customer relationship management. Much of

the workflow structure and the partitioning of workcan be driven by an understanding of the businesscommitments.

5. Change management

The new business reality in many industries isdominated by change. As Rowan Gibson puts it inARethinking the futureB: AThe fact is that the futurewill not be a continuation of the past. It will be aseries of discontinuities. And only by accepting thesediscontinuities and doing something about them willwe stand any chance of success and survival in the

w xtwenty first centuryB 13 .Change is directly affecting company competitive

agendas. Companies are being squeezed betweenfundamentally contradictory pressures. Firstly, cus-tomers are increasingly enforcing their individualpreferences and requirements so that businesses arechallenged to tailor their products and services tospecific requirements of every individual customer.

w xPine 34 calls this mass customization, which refersto the ‘production and distribution of customizedgoods on a mass basis’. Mass customization requires,

w xas Peppers and Rogers 33 point out, a ‘one to oneorganization’, whereby a company that practices 1:1marketing must track customers individually, interactwith them and integrate the feedback from eachcustomer into its behavior toward that customer.

Secondly, the rules of competition are dictated bytime to market. Time to market refers to the time thatelapses from the moment an opportunity or ideadevelops and the moment a corresponding service orproduct is available in the marketplace. Time tomarket also refers to short and reliable delivery leadtimes, which customers expect. Thirdly, the market-place forces enterprises to offer their products andservices at highly competitive cost levels. Thesepressures exert contradictory demands to the enter-prise as internally they enforce efficiency, planningand stability, while externally they impose respon-siveness and flexibility.

Change is also affecting the composition of thecompetitive arena. Industries used to be in stablecompetitive settings. Industries were known, andone’s position in an industry could be analyzed withrespect to existing rivalry, known suppliers and cus-


tomers and possible new entrants and substitutes.1

Today, companies are confronted with the questionof what their industry in the near future will looklike. In other words, who will be their competitors,real potential new entrants and substitute products,customers and suppliers of tomorrow? As Prahaladw x36 states, Athere is absolutely no way, in the evolv-ing marketplace, that you can know exactly who thesuppliers, customers, competitors and collaboratorsareB.

How can organizations cope with these chal-lenges? Obviously, the answer is more in beingprepared for change than in trying to predict andadjust to change. Enterprises need flexible, modularbusiness processes that can easily be configured tomeet the demands of business, e.g. market require-ments and technology changes. When developingapplications based on business objects and processes,

Ž .it is important to address two factors: a the linkingof business objects with legacy information systems

Ž .and b requirements for change so that businessinformation systems can evolve over time. Thus, weview change management dealing with these twoessential and interrelated aspects. Any new environ-ment must leverage investments in legacy systems; itmust also allow its business processes to adapt tochanges enforced by new corporate goals or policies.

5.1. LeÕeraging legacy assets

In an enterprise framework, there is a pressingdemand to integrate Anew generationB business pro-cesses with legacy perspectives, processes and appli-cations. Legacy systems are systems that are criticalfor the day-to-day functioning of an organization,they normally comprise monolithic applications thatconsist of millions of lines of code in older program-

Ž .ming languages e.g. COBOL , are technically obso-lete with a poor performance and hard to adapt and

w xmaintain 5,40 . However, they are valuable assets ofan organization that can be leveraged and integratedinto next generation business systems. The break-upof monolithic business units and processes from abusiness perspective requires a restructuring of the

1 w xRefer to Porter’s framework 35 of five competitive forces.

applications that support them and, at a minimum,finding a way to integrate them. Additionally, thenature of many of these new processes means thatthey must be integrated at the transaction level, notjust via replication and batch transfers of data.

We can identify various types of legacy systems,ranging from highly decomposable legacy systems to

Ž . w xmonolithic non-decomposable systems 5,40 . Thehighly decomposable systems can be decomposed inuser interface components, application componentsand database components. However, it is not likelythat most of the legacy systems will meet theserequirements. Needs for legacy componentizationcould be met by either depending upon the businessobjectives. These may include:

Discarding: This strategy should be followed incase the legacy system has a low business value anda low technical condition, for example, if the legacysystem is non-decomposable.

Replacement: Allows the implementation of thewhole or parts of the legacy application to be up-graded or replaced at the component level, withouthaving impact on other components.

Enhancement: The function of the legacy applica-tions must be changed to meet new requirements.

Separation of concerns: Separates the service acomponent provides and determines how to invoke itvia its interface.

SelectiÕe integration: Makes it easier to integrateparts of the legacy application into new systems.Reusing the services locked inside the legacy maynot require reworking the existing application, justthe ability to access it and integrate it into newsystems. This option can be used if one wants to useŽ .part of the legacy system in current and futureimplementations.

The tactics used to leverage existing investmentsin legacy systems by including them in a new com-puting environment can be summarized in the fol-lowing:

Ø Identify the logical content of the existing systemin term of its data content and functionality.

Ø Restructure the source of the legacy into separatecomponent interfaces and express them as ab-stract interfaces that exclude implementation de-tails.


Ø Publicize the interfaces and direct new applica-tions to access this interface rather than the legacysystem.

Object wrappers are a successful technology forcombining business objects with legacy systems. Ob-ject wrapping is the practice of implementing asoftware architecture given pre-existing heteroge-neous components. It allows mixing legacy systemswith newly developed applications by providing ac-cess to the legacy systems. The wrapper specifiesservices that can be invoked on legacy systems bycompletely hiding implementation details. It providesexternal applications a clean legacy API that sup-ports a host of abstract services irrespective of thecomplexity of internal representations of the legacysystems. This legacy API is the software access pathto the legacy implementations’ supported functions.Wrapping provides an opportunity to include a sys-tem’s semantic contents and patterns of usage in thepublic definition of the system. The advantage of thisapproach is that it promotes conceptual simplicityand language transparency.

This technological advancement can be achievedby harnessing the emerging distributed object man-agement technology and by appropriately compart-mentalizing existing software and applications. Forexample, a simple layer of software mapping thelegacy APIs to, for example, CORBA IDL, providesfor broader system interoperation and distribution oflegacy system services through CORBA. Encapsula-tion is used to partition and componentize legacysystems. Each component can be objectified sepa-rately, and then the system can be re-integrated usingobject-based messaging. The benefits of this ap-proach are that each component can be reused andsystem upgrades can happen incrementally. A de-tailed study of how legacy relational databases canbe transformed to semantically equivalent representa-tions accessible via object-oriented interfaces can be

w xfound in Ref. 30 .

5.2. Adaptability of business processes

To remain competitive, organizations must beable to move fast and quickly adapt to change.Moreover, they must be able to reconfigure their keybusiness processes as changing market conditions

dictate. Enterprises must respond to new require-ments quickly without interrupting the course ofbusiness. Such changes must be mapped to the busi-ness object level and related to already existingenterprise models. A particularly important objectiveis the extent to which new business function needs

Ž .are reflected in the current and restructured wrappedcomponents. New business requirements might re-quire new processes and workflows to be imple-mented, but the existing business rules and data inlegacy systems may only be partially reusable. Usinga purely bottom-up approach is not desirable, al-though many commercial systems support it, as thedanger is that we simply perpetuate legacy ways ofworking.

In the enterprise framework described in Fig. 1,we take the classical organizational view that busi-ness changes are initiated by changes to businessgoals. This is in accordance with approaches towardslinking the organizational goals to business activitiesthat have been identified in the research literaturew x22,48 . It is only natural to expect that these changeswould become AvisibleB at the workflow level. How-ever, it is virtually impossible for workflows topredict in advance all potential exceptions and pathsthrough a business process. Most workflow productsrequire all exceptions to be predicted and built intothe process definition. Rather than insisting that allexceptions are predicted in advance, workflow sys-tems must allow users to change the underlyingprocess model dynamically to support a particularcase of work. To achieve this degree of businessprocess adaptability, each case of work must berelated to a distinct and corresponding process frag-ment. A critical challenge to building robust businessapplications is to be able to identify the reusable and

Ž .modifiable portions functionality and data of anexisting business process or object and combinethese with Anewer generationB businessprocessesrobjects in a piecemeal and consistentmanner. These ideas point towards a methodologythat facilitates pro-active change management ofbusiness objects that can easily be retrofitted toaccommodate selective functionality from legacy in-formation systems. We refer to objects exhibitingsuch characteristics as adaptable business objects. Inthe following, we summarize the essential features ofthe Binding Business-Applications to LEgacy Sys-


Ž .tems BALES methodology that concentrates onparameterizing business objects with legacy data and

w xfunctionality 41 . The same methodology can besuccessfully employed for coping with changes toexisting business objects and processes.

5.3. Managing changes at the business object leÕel

One important characteristic of business objecttechnology, that also contributes to the critical chal-lenge described above, is the explicit separation ofinterface and implementation of a class. Businessobjects technology takes this concept a step furtherby supporting interface eÕolution in a way thatallows the interfaces of classes to evolve withoutnecessarily affecting the clients of the modified class.This is enabled by minimizing the coupling betweenbusiness components. Client and server classes arenot explicitly bound to each other, rather messagesare trapped at run-time by a semantic data object thatenforces the binding at the level of parameter pass-

w xing semantics 9 .The BALES methodology, that is under develop-

ment, has its main objective to parameterize businessobjects with legacy objects. Legacy objects serve as

Ž .conceptual repositories of extracted wrapped legacy

data and functionality. These objects, just like busi-ness objects, are described by means of their inter-faces rather then their implementation. A newer gen-eration business object interface can be constructedby selecting a chunk of an existing business, orlegacy, object interface. This partition comprises aset of appropriate attribute and method signatures.All remaining interface declarations are masked offfrom the business object interface specification. Inthis way, business objects in the BALES methodol-ogy are configured so that part of their specificationis supplied by data and services found in alreadyexisting business or legacy objects. This means thatbusiness object interfaces are parameterizable to al-low these objects to evolve by accommodating up-grades or adjustments in their structure and behavior.

The core of the BALES-methodology comprisesŽ .the three phases see Fig. 2 : forward engineering,

reÕerse engineering and meta-model linking. To il-lustrate the BALES mapping methodology, a simpli-fied example is drawn from the domain of mainte-

Ž .nance and overhaul of aircrafts see Fig. 2 . Theupper part of this figure illustrates the results of theforward engineering of the business domain in termsof workflows, business processes and business ob-jects. As can be seen from this figure, the enterprise

Fig. 2. Developing an enterprise model by means of reusing legacy processes and objects.


model is enacted by a Request-Part workflow, whichcomprises three business processes: Request, Prog-nosis and Issue. The Request-Part workflow is initi-ated by a maintenance engineer who requests partsŽ .for maintaining aircrafts from a warehouse. TheRequest process registers the maintenance engineer’srequest in an order list. This list can be used to checkavailability and plan dispatch of a specific aircraftpart from the warehouse. The Request process uses

Ž .the business entity objects Part and Warehouse forthis purpose. Subsequently, the workflow initiates

Ž .the Issue process see Fig. 2 . The Issue processregisters administrative results regarding the dis-patching of requested part and updates the part in-ventory record by means of the Part-Stock businessobject. The Prognosis process uses information fromthe Part and Warehouse business objects to run aprognosis on the basis of the availability and con-sumption history of the requested part.

The lower part of Fig. 2 represents the result ofthe reverse engineering activity in the form of two

Žprocesses wrapped applications and related.databases , Material Requirements Planning and– –

Purchase Requisition. These processes make use of–five legacy objects to perform their operations. Fig. 2also indicates that the enterprise workflow draws notonly on AmodernB business objects and processes,

Ž .but it also leans on already existing legacy data andfunctionality to accomplish its objectives. For exam-ple, business processes such as Request and Issue, onthe enterprise model level, are linked to the legacyprocesses Material Requirements Planning and Pur-– –chase Requisition by means of solid lines. This–signifies the fact that the processes on the businesslevel reuse the functionality of the processes at thelegacy model level. In this simplified example, weassume that problems such as conflicting namingconventions and semantic mismatches between theenterprise and legacy models have been resolved. A

w xsolution to this problem can be found in Ref. 29 .To formally describe the interfaces of business

and legacy objects, we use a variant of the Compo-Ž .nent Definition Language CDL that has been de-

w xveloped by the OMG 7 . CDL is declarative specifi-Ž .cation language a superset of OMG IDL that is

used to describe composite behavior of communitiesof related business objects. A specification in CDLdefines business object interfaces, structural relation-

ships between business objects, collective behaviorof communities of business objects and temporal

w xdependencies 7 . An object defined using CDL canŽ .be implemented using any legacy programming

language as long as there exists a CDL mapping forthat language.

The forward engineering phase defines a concep-tual enterprise model into CDL and transforms thisCDL definition to a Meta-CDL Enterprise Model.This meta-model serves later as a basis for compari-son between business and legacy enterprise models.During the reverse-engineering phase, legacy objectand process interfaces are again represented in termsof CDL and are used to instantiate a Meta-CDLLegacy Model. The Meta-CDL descriptions of boththe forward- and backward-engineered models arethen compared to each other in order to ascertainwhich parts of the legacy object interfaces can bereused within new applications. To achieve this, werepresent and store both business and legacy Meta-CDL specifications in a repository system. Duringthe meta-model linking phase, queries are used toinfer potential legacy components that may be linkedto business components. For instance, we can iden-tify business object attributes andror operations thatcan be constructed out of legacy object attributesandror operations. To ensure type safety on methodarguments and method results, we require the use of

Ž .argument contraÕariance expansion and result co-Ž .Õariance restriction .

The BALES methodology can also be used tow xcombine standard ERP packages like SAP Rr3 6

w xor San Francisco 1 with legacy and other businessobjects. ERP objects can also be defined in CDL. Adetailed description of this methodology can be found

w xin Ref. 41 .

6. The role of the infrastructure

IT and business developments have influenced theIT management practices. Throughout the computerage, businesses developed IT management practicesbased on centralization. For the first 30 years, theemphasis was on technology management, and themajor challenges focused on getting the technologyto work reliably and as efficiently as possible. As aconsequence, information technology developed and


was managed as a centralized resource in most com-panies. In the 1970’s and 1980’s, most businesseshad adopted centralized, bureaucratic, strict func-tional structures with little or no needs for lateralcommunication between functions. This organizationstructure became the logical basis for many informa-tion systems. Functional departments developedAstove pipeB-like information systems, which did notallow any exchange of data between them, leading toan Aisland perspectiveB.

More recently, personal computers began to focusattention on the users, and on the spread of decentral-izing technologies. The 1980’s produced new tech-nologies for the end user, and the 1990’s confirmedtrends to end user computing, with communicationemerging as a critical technology to disperse infor-mation throughout the enterprise. Local networks,enterprise networks and nationwide networks serveto make it easier to move information around withinand among enterprises and their components. A pri-mary reason for the dispersion of information tech-nology throughout the enterprise is cost. The historyof information technology is characterized by con-stant reductions per unit price and substantial in-creases in capabilities. A second more importantreason for the strength of IT’s dispersion into theenterprise is the business requirement for IT-enabled

w xsolutions to competitive and marketing pressures 4 .Also, business conditions changed. Market and

customer demands for flexibility, responsiveness,quality, time-cycle reduction, and cost reductionshave produced a considerable range of enterpriseresponses. Many of them have taken the form ofbusiness innovations described with terms like busi-ness process focus, lateral organization, networkedorganizations etc. These typical enterprise responseshave the general effect of breaking down the hierar-chical organization in fundamental ways. Enterprisesmove to a larger number of smaller business units orlegally independent businesses, unconnected to thetraditional hierarchy. Changing the organization fromthe traditional structure to a more responsive lateral,process oriented structure was in most companiesseverely hampered by the existing information sys-tems architecture based on functional AislandsB.

In the late 1980’s, the alignmentrimpact modelwas developed, which described the relationships

w xbetween the business organization and IT 31 . This

model acknowledged that business strategies couldbe supported or even be changed by applying IT inline with market demands on the business. Becausedifferent lines of business within a company operatein different markets with different requirements, thisnotion has lead to a widespread decentralization ofIT management to lines of business. Informationtechnology and business organizations had character-istics leading to a widespread proliferation of differ-ent IT solutions throughout the company.

In the second half of the 1990’s, an increasedemphasis on the customer instead of on the product,confronted many organizations with fact that infor-mation systems across lines of business were notcompatible. For example, insurance companies sell-ing different services or products to the same cus-tomer were not able to get an overall view of therelationship of that customer with the company. Theproblems of lack of connectivity and compatibilitybecame even more apparent when independent com-panies began to cooperate on a more permanent basisand the need for external integration came up.

The organizations of today are confronted withthe problem on how to strike a balance between localneeds for different systems and overall needs forconnectivity and share-ability of data and applica-tions. Extreme decentralization of application of ITwill hamper business developments towards processoriented and flexible network structures. Attempts tocentralize development of IT in Aone fits allB type ofapplications will be costly to develop and will resultin systems which will not support individual busi-ness requirements. The solution to this problem iscurrently sought in a distinction between local infor-mation systems and information infrastructure.

Information infrastructure describes the basic in-formation systems elements intended to be common.Infrastructure is intended to support common needsand not individual needs; infrastructure is intended tobe a relatively stable provision. Traditionally, infras-tructure is related to hardware, physical networks,data base management systems etc. We propose abroader view. We define information infrastructureas relatively permanent, and commonly available ITresources and arrangements. This definition covers

Ž .different types of information infrastructures: 1Ž .common hardware, physical networks, e.g. the or-

ganization uses one type of servers, PCs and network


Ž . Ž .the traditional view ; 2 common information, dataand data definitions; examples are data about cus-

Ž .tomers, products like product definitions , resourcesŽ .etc; 3 common applications and application compo-

Žnents, not only standard software packages like SAPor MS office, when used as the application in the

.company but also application components or ob-jects. Commonly available standard software compo-nents are infrastructural resources, which can be used

Ž .by decentrally operating development teams; and 4common organizational arrangements and proce-dures, for example, security and log in procedures.

There is no such thing as one common infrastruc-ture. Infrastructures offer solutions for connectivityand commonality of systems. Industry-wide andcompany wide infrastructure support connectivity andcommonality on a company and industry level. Asnot all information and communication demands needto be solved on a company or industry level, theremay be infrastructures different organizational levels.For example, what is available as a departmentalinfrastructure is not necessarily infrastructure for an-other department. What is infrastructure for one busi-ness unit, may not be infrastructure for another.EDIFACT is more or less the generally acceptedEDI message standard for Europe, and as such aEuropean IT infrastructure element; it is not for theUS, where ANSI is the accepted standard. In otherwords, infrastructure is a layered concept: there aredifferent layers of infrastructures. For example, thehigher-most layer in the integrated value chain couldbe collaborating industry networks. The lower mostcould be an intra-company enforced for EDI applica-tions.

Dependent on the layer, different stakeholders,with diverging objectives, are involved in the plan-ning and implementation of IT infrastructures. Infras-tructures require negotiation, coordination and com-mitment. Also, the benefits of infrastructures are notimmediately clear; they are dependent on the use,which is made of it. Infrastructure projects are, al-most by definition, difficult not necessarily from atechnical point of view, but from an organizationalpoint of view and for that reason costly. The higherthe layer, the more difficult and costly the infrastruc-ture is to build. For this reason, it would be wrong toassume that the infrastructure approach will result inAheavyB centralized systems.

Infrastructures can be classified by the conceptsw xof Reach and Range 18,44 . Reach refers to the

Ž .locations and the number of people the infrastruc-ture is capable of connecting. Reach can extend froma departmental layer, to the business unit layer, tothe enterprise layer and even to national and interna-tional layers. Range refers to functionality in termsof business activities that can be completed andshared. Range can extend from simply sending mes-sages and receiving messages, to accessing storedinformation, to ultimately executing complex trans-

w xactions 44 . Every information infrastructure is acombination of a specific reach and range.

New business models, based on cross-enterpriseŽ .and cross-functional interoperability, depend highlyon the availability of infrastructures. New businessmodels and cross-enterprise interoperability, thus,can be differentiated depending on the concept ofReach and Range. Implementing right combinationsof reach and range is crucial for different types ofintra- and inter-company cooperation. For example,an electronic commerce application supporting sim-ple transactions and exchanges of data may be real-ized on a global scale. But to what extent is thispossible for an integrated value system comprisingcomplex supply chains and manufacturing pro-cesses? Is an Integrated Enterprise Framework appli-cable on a global scale? From systems theory, it isknown that increased coordination requirements go

w xtogether with an exponential cost curve 10 . Agree-ments on complex functionality with many partici-pants seem very difficult and costly to accomplish.Obviously, different types of ‘doable’ infrastructuresemerge. Simple electronic commerce transactions canbe supported by low range and high reach type ofinfrastructures; complex value system integrationseems doable on a more restricted scale and thus byhigh range, low reach type of infrastructures. Typi-cally, these types of infrastructures will be foundbetween companies that are each others major busi-ness partners.

7. Summary

Enterprise computing is about consolidating andharmonizing the many islands of disparate businessprocesses and information systems scattered through-out an organization and its partner enterprises into a


unified whole. Nowadays, company value chains aretransformed to integrated value chains if they aredesigned to act as an Aextended enterpriseB, creatingand enhancing customer-perceived value by meansof cross-enterprise collaboration. Companies thusface a variety of changes ranging from streamliningbusiness processes to enabling outward facing infor-mation systems.

In the previous discussion, we have given a de-tailed account of the business and technology consid-erations, as well as infrastructural support, that arerequired to enable the transition of organizationsfrom relative independence and functionally orientedbusiness thinking to integrated value chains. Weargued that the combination of new business modelswith controlled cross-enterprise interoperability andchange management are the driving forces that willeventually transform relatively independent organiza-tions into cooperating enterprises. We also illustratedhow adaptive business objects and processes are thekey components of these enabling technologies.

References

w x1 S. Abinavam et al., San Francisco Concepts and Facilities.International Technical Support Organization, IBM, February1998, SG24-2157-00.

w x2 J.M. Andrade et al., The Tuxedo System, Addison WesleyPublishing, Reading, MA, 1996.

w x3 The ARIS Product Suite and Trade, http:rrwww.ids-scheer.com.

w x4 R.J. Benson, Infrastructures, architectures and utilities, in:Ž .J.A.M. Oonincx, P.M. Ribbers, C.A.Th. Takkenberg Eds. ,

Organisatie, Besturing en Informatie, Samsom, Alphen aande Rijn, 1996.

w x5 M.L. Brodie, M. Stonebraker, Migrating Legacy Systems:Gateways, Interfaces and the Incremental Approach, MorganKaufman Publishing, San Mateo, CA, 1995.

w x6 T. Curran, G. Keller, A. Ladd, SAP Rr3 Business Blueprint:Understanding the Business Process Reference Model, Pren-tice-Hall, New Jersey, 1998.

w x7 Data Access Technologies, Business Object ArchitectureŽ .BOA Proposal, BOMr97-11-09, OMG Business ObjectDomain Task Force, 1997.

w x8 J.H. Dobbs, Competition’s New Battleground: The IntegratedValue Chain, Cambridge Technology Partners, 1998. http:rrwww.ctp.com.

w x9 P. Eeles, O. Sims, Building Business Objects, Wiley, NewYork, 1998.

w x10 J.C. Emery, Organizational Planning and Control Systems,MacMillan, New York, 1969.

w x11 Ford Motor, Collaborative product development via webtechnology, http:rrhaas.berkeley.edurciturbriefingsrfordbrief.htm.

w x12 D. Georgakopoulos et al., Managing process and servicefusion in virtual enterprises, Information Systems, SpecialIssue on Information Systems Support for Electronic Com-

Ž . Ž .merce 24 6 1999 429–456.w x Ž .13 R. Gibson Ed. , Rethinking the Future, Nicholas Brealey

Publishing, London, 1997.w x14 R.K. Goodnow, Bringing Telework Home: Working Beyond

the Frontier, TDG Publication, 1998. http:rrwww.teleworkllc.comrintro.htm.

w x15 G. Hamel, G. Prahalad, The Core Competencies of theCorporation, Harvard Business Review, Watertown, MA,1990, May–June.

w x16 S.L. Jaarvenpaa, B. Ives, The global network organization ofthe future: information management opportunities and chal-

Ž .lenges, Journal of Management Information Systems 10 4Ž .1994 25–57.

w x17 J.C. Jarillo, H.H. Stevenson, Cooperative strategies — theŽ . Ž .payoffs and the pitfalls, Long Range Planning 24 1 1991

64–70.w x18 P.G.W. Keen, Shaping the Future: Business Design through

Information Technology, Harvard Business School Press,Watertown, MA, 1991.

w x19 J. Klingemann, J. Wasch, K. Aberer, Deriving service mod-els in cross-organizational workflows, Procs of the 9th Inter-national Workshop on Research Issue in Data EngineeringŽ .RIDE-VE ’99 , Information Technology for Virtual Enter-prises, March 23–24, Sydney, Australia, 1999, pp. 100–107.

w x20 F. Leymann, D. Roller, Workflow-based applications, IBMŽ . Ž .Systems Journal 36 1 1997 .

w x21 Light Weight Directory Access Protocol, http:rrwhatis.comrldap.htm.

w x22 P. Loucopoulos et al., Using the EKD-Approach — TheModelling Component, Techn. report, WPrT2.1rUMISTr1,UMIST, April 1997.

w x23 H. Ludwig, K. Wittingham, Virtual enterprise co-ordinator— agreement-driven gateways for cross-organizational work-flow management, Procs of the International Conference on

Ž .Work Activities and Collaboration WACC ’99 , Feb. 22–25,San Francisco, CA, 1999, pp. 29–38.

w x24 T.W. Malone et al., Tools for inventing organizations:toward a handbook of organizational processes, http:rrwww.fso.arizona.edurdickportfoliordissertationrchangerccswp198.html.

w x25 F. Manola et al., Supporting cooperation in enterprise scaledistributed object systems, in: M.P. Papazoglou, G. SchlageterŽ .Eds. , Cooperative Information Systems: Trends and Direc-tions, Academic Press, London, 1998.

w x26 S. McConnel, The OMGrCommerceNet Joint ElectronicCommerce White-paper, ECr97-06-09, Object ManagementGroup, July 1997.

w x27 R.E. Miles, C.C. Snow, Causes of failure in networkedŽ .organizations, California Management Review 1992 53–72,

summer.w x28 M.P. Papazoglou, A. Delis, A. Bouguettaya, M. Haghjoo,


Class library support for workflow environments and applica-Ž . Ž .tions, IEEE Transactions on Computer Systems 46 6 1997

June.w x29 M.P. Papazoglou, S. Milliner, Content-based organization of

the information space in multi-database networks, in: B.Ž .Pernici, C. Thanos Eds. , Procs. CAISE’98 Conf., Pisa,

Italy, Springer-Verlag, Heidelberg, Germany, 1998.w x30 M.P. Papazoglou, W.J. van den Heuvel, Leveraging legacy

Ž .assets, in: M. Papazoglou, S. Spaccapietra, Z. Tari Eds. ,Advances in Object-Oriented Modeling, MIT-Press, Cam-bridge, MA, 2000.

w x31 M.M. Parker, R.J. Benson, Information Economics: LinkingBusiness Performance to Information Technology, Prentice-Hall, New Jersey, 1988.

w x32 S. Paul et al., Essential Requirements for a Workflow Stan-dard, OOPSLA’98 Business Object Workshop III, At-lanta, October 1997, 1997, . http:rrwww.jeffsutherland.orgroopsla97.

w x33 D. Peppers, M. Rogers, Enterprise One-to-One: Tools forBuilding Unbreakable Customer Relationships in the Interac-tive Age, CurrencyrDoubleday, New York, 1997.

w x34 B.J. Pine, Mass Customization: The New Frontier in Busi-ness Competition, Harvard Business School Press, Boston,MA, 1993.

w x35 M.E. Porter, The Competitive Advantage of Nations, TheFree Press, New York, 1990.

w x36 C.K. Prahalad, Strategies for Growth, Rethinking the Future,1997.

w x37 M.T. Schmidt, Building Workflow Business Objects,Object-Oriented Programming Systems Languages Applica-tions,OOPSLA’98 Business Object Workshop IV, Vancou-ver, CA, October 1998, 1998, . http:rrwww.jeffsutherland.orgroopsla98.

w x Ž .38 P. Sieber, J. Griese Eds. , Organizational Virtualness andElectronic Commerce,Procs. of 2nd Int’l VoNet Workshop,Zurich, Sept. 1999, 1999, . http:rrwww.virtual-organization.net.

w x39 Simple Workflow Access Protocol, http:rrwww.ics.uci.edurietfswap, 1999.

w x Ž .40 A. Umar, Application Re Engineering: Building Web-basedApplications and Dealing with Legacies, Prentice-Hall, NewJersey, 1997.

w x41 W.J. van den Heuvel, M.P. Papazoglou, M.A. Jeusfeld,Configuring business objects from legacy systems,Procs.CAISE’99 Conf., Heidelberg, Germany, Springer-Verlag,1999, June.

w x42 H. Van der Zee, P. Van Wijngaarden, Strategic Sourcing andPartnerships, Addison Wesley-Nolan Norton Institute, 1998.

w x43 E.M. Verharen, M.P. Papazoglou, Introducing Contracting inDistributed Transactional Workflows, HICSS-31: Hawaii Int’lConf. on System Sciences, IEEE Computer Science Press,1998, Jan.

w x44 P. Weill, M. Broadbent, Leveraging the Infrastructure HowMarket Leaders Capitalize on Information Technology, Har-vard Business School Press, Watertown, MA, 1998.

w x45 Workflow Analyzer, http:rrwww.metasoftware.com.w x46 Workflow Management Coalition, http:rrwww.wfmc.com.

w x47 Workflow Management Facility, Revised Submission, OMGDocument Number bomr98-06-07, Object ManagementGroup, July, 1998.

w x48 E. Yu et al., From organization models to system require-ments: a Acooperating agentsB approach, in: M.P. Papa-

Ž .zoglou, G. Schlageter Eds. , Cooperative Information Sys-tems: Trends and Directions, Academic Press, London, UK,1998.

Biographies

Michael P. Papazoglou is a Full Professor and Director of theInfolab at the Univ. of Tilburg in the Netherlands. His scientificinterests include cooperative information systems, heterogenousdatabase systems, object-oriented systems and modelling, dis-tributed computing, digital libraries, electronic commerce wherehe has authored approximately 100 journal articles and refereedconference papers and edited 10 books. He has chaired severalprestigious conferences and serves on several scientific commit-tees and advisory boards for international journals. His researchhas been funded by the European Commission, the AustralianResearch Council, the Japanese Society for the Promotion ofScience, and Departments of Science and Technology in Europeand Australia. Papazoglou is a golden core member of the IEEEand a recipient of the prestigious IEEE Certificate of Appreciationfor his contributions to computer science as distinguished visitorof the IEEE.

Pieter M. Ribbers is a professor of Information Management atTilburgh University, School of Economics and Business Adminis-tration, The Netherlands, where he chairs the TIAS PostgraduateSchool of Information Management and the Department of Infor-mation Management. His interests span management of informa-

Žtion technology in particular questions related to alignment and. Žinformation economics , inter-organizational systems in particular

.electronic commerce and the strategic and organizational conse-quences of the use of Information Technology. He is active asresearcher, lecturer and consultant. He has contributed articles inthis field to professional national and international journals and

Ž .has co- authored several books. He is an active speaker atconferences in both Europe and the United States.

Aphrodite Tsalgatidou is a professor at the Department of Infor-matics of the University of Athens, Greece. She holds a degree in

Ž .Chemistry from the University of Athens 1982 and an MScŽ . Ž .1985 and PhD 1988 from the University of ManchesterŽ .UMIST , UK. Previous positions include Software Engineer at

Ž .the Hellenic Telecommunications Organisation OTE , Director ofthe Office Automation Dept. of Elvil, SA and Director of Re-search & development of 01P SA. She is currently on Sabbaticalleave at the University of Jyvaskyla in Finland working in the area¨ ¨of mobile electronic commerce and transactions for mobile billing.Her research interests include requirements engineering, businessprocess modelling and reengineering, workflow management, vir-tual enterprises and electronic commerce.

integrated value chains and their implications from a ...cgi.di.uoa.gr/~afrodite/dss.pdf ·...

Documents