Over use of the term process management by consultants,analystsand vendors has led to some confusion among customers of differ-ent automation technologies.The situation is particularly acutebecause workﬂow engines are often used in the BPM technologystack of middleware and EAI vendors (a relatively recent develop-ment).Systems integrators have also used workﬂow engines forsome years to drive application component behaviour within anenterprise IT architecture.Application vendors are themselvesstarting to pursue the same approach.Workﬂow technologies have been very successful.Many consultingﬁrms have a workﬂow line of service.There are numerous docu-mented case studies showing the beneﬁts of the deployment ofworkﬂow technology and workﬂow will continue to be a focus formany ﬁrms.However,new challenges and new innovations areleading architects to broaden their perspective on the use of“workﬂow” within IT systems.New process technologies andtechniques are allowing systems integrators to develop new valuepropositions for their customers.Whereas the focus of workﬂowdeployment has in the past been automation,there is now agreater emphasis on the use of process technologies to provideoverall business agility.

The use of process automation has become an intricatepart of the enterprise technology stack and is drivingdeeper into the ﬁeld of software engineering

Some see processes as a new development paradigm itself thatmay ultimately displace the object model,referred to as ProcessManufacturing.Others see process data as a new mathematicalform for business assets,which may replace the relational datamodel and create a new breed of Business Process ManagementSystems (BPMS).Their advocates position such systems as the plat-form for the next generation of “process aware” businessapplications.Finally,platform vendors see process engines drivingorchestration and composition of distributed software compo-nents called Web Services.No longer do we think of business processes as being only thoseto be scheduled around people – for example,work that was par-tially done before the person got tired and left – work that iswaiting for a telephone call from a customer – work that has tobe processed at a speciﬁc time (“I will expect your call at 10o’clock),or work that has to be transferred to a different personbecause the person who did the ﬁrst part of the processing gotsick or quit before the task was complete.As Charlie Plesums ofCSC and the WfMC.org points out,“The development and use ofworkﬂow technology has moved from simply supporting the rout-ing of work between people to routing work horizontally betweenresources (where the resource may be a person,but may also be asystem or even a machine) and vertically (controlling steps thatwill be performed at each point in the journey,such as when pro-grams will be invoked by the person,or actually invoking theprogram).And as data is being moved between processes,there istypically integration with the processing systems – which pushesworkﬂow into the Enterprise Application Integration (EAI) arena.”

Demanding process requirements from customers is driv-ing the need for sophisticated process technologies

It has been estimated by several industry analysts that businessesare spending between 20 and 30% of their IT budget integratingsystems and applications,whereas they would like to assume thatthe systems they invest in are interoperable.The situation is unsus-tainable and customers are making this clear to their systemsintegration partners.At the same time,the complexity of systemsintegration is increasing.Client’s integration projects now extendwell into the value chain,resulting in n-factorial points of integra-tion among applications owned by different ﬁrms.In addition,fewcompanies now rely exclusively on a single application image,forexample ERP.Integration projects extend over legacy systems,existing ERP and new best of breed purchases.As well as requiring IT service providers to do more for less,cus-tomers are also demanding that the processes resulting fromintegration projects are fully manageable thereafter.Managementinterfaces must operate end to end,not in discrete applicationdomains.Corporate goals and the practical day-to-day running ofthe efﬁcient enterprise demands complete control over and visibil-ity of the IT environment supporting the operation.It is no longeracceptable for isolated pockets of information or isolated applica-tions to exist standalone.Global ﬁrms are seeking an enterprisearchitecture that solves these issues once and for all,rather thanin piecemeal projects or point-to-point integrations.Joined upthinking and joined up IT is now mandatory and this is driving therequirement for end-to-end processes that are designed from theperspective of the business,most notably the end customer.Thereis a desire to deploy processes top down as determined by thebusiness strategy,without constraint by the existing systems sup-porting functional business domains.Therefore,as the focus shifts from the application to the process,one encounters additional requirements that further stress theability of today’s EAI,B2BI and workﬂow suites.There is often arequirement to maintain a repository of core processes and todeploy custom variants,for different business units,for differentgeographies or different partners,suppliers or customers – according to prevailing business conditions and the reality of localoperations.Failure to build an effective Process ManagedArchitecture to support this customisation results in duplicateefforts or unfulﬁlled projects;and business units are forced towork with processes that were not designed to meet their fullneeds.If this were not enough to cope with,it is now quite com-mon to be given requirements for end user control of deliveredprocesses.Reﬂecting the reality of constant business change,themanagement team is looking for extreme levels of conﬁgurationoptions in the IT environment.It is not uncommon for the business to have been disappointed bythe previous performance of the IT function.Either it under-deliv-ered not meeting requirements,delivered too late andrequirements had changed or over-engineering solutions to prob-lems that did not exist.As Ron Brown,technical director of CSC’s

1

CSC e3 [Ref 5] is a proven open-standards based enterprise architecture thatencompasses middleware,application integration,workﬂow,business integra-tion and process management technology.The predominant entity in e3 is thebusiness process and a central principle is the provision of process changeservices to non-technical business users.

systems integration practice states “The CEO is looking to reducethe turning circle of IT – which is often perceived as a supertanker when one considers it’s responsiveness to new businessrequirements.”This new focus on process adaptation,reuse,localisation andchange,applies not only to human workﬂows,but also to the sys-tems implementation and application integration environment.Whereas workﬂow systems are highly adaptable to changes inwork patterns,they are less useful to supporting change in theapplication environment,particularly if components have to beintegrated at ﬁne grain.With the customer demanding to beinvolved in the subsequent management of enterprise processes,including their continuous improvement,optimisation and tuning,the process coupling to application systems is particularly prob-lematic,since to isolate the business users from the ITenvironment so that process changes can be made safely (withoutoperational failures) demands additional layers in the overall archi-tecture to cope with exceptions.These cannot be programmedpiecemeal,nor can the process design interface be restricted tohuman workﬂow.To do so would generate frustration among busi-ness users since it is often the portfolio of legacy applications thatis the limiting factor for an organisation to move forward toenhanced automation.Often,the introduction of new systems or integrated processes isparalleled in the business by a Business Process Improvement pro-gramme, from either a performance, quality or resourcesperspective.Today,no corner of the business is exempt andprocess improvement extends to all processes,all businessdomains and disciplines and this places huge pressure on IT todeliver responsive interfaces.Whereas commodity processes mayhave been outsourced or implemented through sourced services,the focus of management attention often falls to core processes,those of strategic importance and much complexity.Such process-es are ﬂuid,dynamic and difﬁcult to coordinate across multipleparties.It is precisely here where management demand new ITfacilities that can support enhanced decision making in an uncer-tain business environment.All of these factors add up to an increased focus on process engi-neering and this has led systems integrators to look for newprocess tools beyond workﬂow and EAI.The technical implicationsof the business requirements are extreme.Integrators are facedwith the reality of long-lived,value chain wide,transactional,multi-participant processes.Application services in the form of webservices appear everywhere in the business and must be included,and failure to provide end to end technical systems and processsystems management is certain to lead to failed projects.In short,there is a need for an improved path from process design toimplementation,i.e.to executable code,and for new tools thattreat processes as the focus,not the result of integration activities.The time has come for a radical simpliﬁcation of this environment,since it is simply not possible or practical to believe that we canachieve success using existing workﬂow and EAI technology,nomatter how cleverly embodied in an overall systems or vendor’sproduct architecture.

New developments in process technologies are makinginroads for meeting both new process requirements andthe associated technical challenges

A signiﬁcant step forward is the publication of Business ProcessModelling Language (BPML) by the BPMI.org,together with imple-mentations of a transactional process run time that has nativesupport for any middleware.At a heart of a process-based archi-tecture,such infrastructure software can signiﬁcantly signifysystems and application integration tasks.It offers a direct toimplementation path from a process model and roundtrip processlifecycle management.CSC has yet to ﬁnd a business situation thatcannot be modelled in BPML,reﬂecting the strength of its seman-tics and integration with modern XML technologies.In addition,through the promising technique of process projection many ITsystems can be exposed as BPML processes and managed withinan overall process management system,radically simplifying theinclusion (or view) of applications as process designs for reuse.BPML’s features of end to end process persistence and processlevel transactions can be said to be creating an entirely new cate-gory of IT infrastructure,the Business Process ManagementSystem (BPMS) and we expect such systems to become veryimportant over the next few years.The primary reason for this isbecause the BPMSconsiders business processes as a ﬁrst class citi-zen,in much the same way as an object-oriented programminglanguage would consider objects as ﬁrst class citizens.Within aBPMS,the business process is the core entity that needs to bemanipulated,as opposed to being a “virtual process” and the by-product of manipulations that are operated upon by entirelydifferent entities,such as systems integration tools like EAI.EAIconsiders the Application Programming Interface (API) as it’s ﬁrstclass entity and deﬁnes business processes as sequences of APIcalls and the audit trail of such calls.This is really a cross-applica-tion process,if not a cross-application procedure and does nottruly reﬂect business level process semantics.In the same way,workﬂow technology typically considers the doc-ument it’s core entity,and builds processes from the ﬂow ofdocuments,whether these are interacting with humans or systems.While this reﬂects many processes common in business,it is toorestrictive for being able to support a broad range of processes,some of which could never be represented in the form of docu-ments whether on paper or held in computer systems.By contrast,the focus of BPML and BPMSis upon the interactionbetween participants.All participants are processes with respect toone another;and larger processes are constructed from systemsof participating processes.BPML takes the process paradigm evenas far as the domain of application development.Just as the pro-gramming language Java has a Java Virtual Machine that interpretscompiled Java byte code,so is it possible to develop BPML virtualmachines able to interpret BPML byte code,and we believe thiswill become the preferred way to build BPM architecture.