Business processes and workflow in the Web services world

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Introductory

Margie Virdell (virdell@us.ibm.com), e-business Architect, IBM Developer Relations

01 Jan 2003

In the beginning, there was work to do. Think of the caveperson who made the first wheel. That first wheel was a creation, an invention, a reason to celebrate. The making of the second, third, fourth, fifth, etc. wheels was just work. From those cave-dwelling days, through the time when Henry Ford started producing his Ford automobiles on the assembly line, to today, we've been thinking of ways to get work done better, faster, more reliably, and for less money. Business processes are a great method for accomplishing these goals. This article looks at business processes, their relationship to workflow and Web services today, and the challenges that lie ahead.

Business processes: Yes, they're worth the investment

A business process can be defined as a set of interrelated tasks linked to an activity that spans functional boundaries. Business processes have starting points and ending points, and they are repeatable. This definition doesn't reveal the thought, clarity, detail, and time investment required to produce a useful business process. Useful business processes make and save money for the enterprise.

More importantly, the value of creating business processes for an enterprise is in the intellectual assets that those processes represent. The widgets that a business produces have value, of course; additionally, the knowledge of how to make those widgets has value too. That knowledge can be captured, added to, and improved in a business process. The scope of the widget-making process is important because doing all of the steps ensures quality widgets; doing more or less or different steps results in higher costs or lower quality or both.

It is well worth the time and effort it takes to define and document business processes. There's risk in letting your business's widget-making knowledge exist solely, and walk out the shop door each evening, in the head of your chief widget-maker. With a defined widget-making business process, widget-makers can come and go, and one widget-maker can take over for another at any time because the business process is understood and followed by all widget-makers in the shop. The widget-making business process can be studied, changed, evaluated, and changed again since it is visible to all and not restricted to the chief widget-maker.

Back to top

Workflows: Who? What? When?

Workflow software doesn't create business processes, but applying workflow to a business process certainly brings the details of that process into focus as you lay out the business process definition and add the required business rules definitions. A workflow can be thought of as the implementation of the answers to the questions Who? What? When? in a business process.

Who?

Who are the participants involved in the flow of the business process? What roles do they play? How are they organized? Are the groupings flexible and dynamic? Or more fixed and static? More entities than just people can be workflow participants. Organizations, applications, employees, Web services, and other workflows can be answers to the Who? question. Abstracting participants into roles makes a workflow more robust. For example, instead of risking a bottleneck in the workflow by specifying that EmployeeA or EmployeeB must do a task, or putting up with the maintenance headache of changing the list of specific employees every time there's a relocation or promotion, allowing anyone that has the Supervisor role to do the task lessens that risk and lowers that maintenance cost.

What?

What is it that the participants do? How do they do what they do? Do they approve things? Do they perform transactions? Do they create documents? Track inventory? Call vendors for prices? Execute a campaign? Transfer information to other participants? Some workflows are completely automatic, and some consist of manual tasks that must be performed by people. More and more frequently, workflows are a combination of the two types. For example, calling a vendor for prices could be one in a series of manual tasks that a person performs, but it can become a programmatic call to a Web Service that returns prices based on the vendor and item information provided to it.

When?

How do participants know when to start? When is the work finished? In what order do participants do their tasks? Do they do them sequentially or in parallel? If only sometimes, under what conditions? How long should each task take? Are there hard deadlines or not? If a task is not successfully completed, should it be tried again? When a business process contains tasks that are currently done by people only during the day, and examination of those tasks results in changing them to be automated and performed at any time, the people are then freed up for other tasks and the newly-automated tasks don't have to wait for a person to perform them.

Back to top

Do you speak workflow?

Let's establish some general workflow terminology at this point (see Table 1), taken for the most part from the WfMC's Workflow Reference Model (see Resources for more information).

Table 1: Workflow terms and definitions

Back to top

Workflow's roots

Workflow directions in software have come from two different originating viewpoints: people-based business processes and rules-based automation processes; the two are becoming more complementary all the time.

The roots of people-based workflow software is in workgroup tools and groupware. In workgroup tools applications (office suites like Lotus SmartSuite, Microsoft Office, and Star Office for examples, plus more specialized tools like Autodesk and Autocad), team collaboration and implicit workflow have always been strong features. Groupware is software that purposely makes it easier for people on teams or in groups to collaborate and helps their work flow more smoothly and efficiently. For people-based workflow software that has evolved from workgroup tools and groupware and now explicitly captures and manages workflows, the future is in enhancements to Web services capabilities, along with JSP and portlet support, moving them towards more and more integration within the Java environment.

The roots of workflow automation applications as expressed in Web application orchestration can be found in rules engine applications and the static, step-by-step, rules-based automation of production and manufacturing processes. This kind of workflow is now heading towards supporting people-based workflows as well.

Merging the two viewpoints means that the ability of workflow software to flexibly handle varied and unexpected circumstances becomes very important. Orchestration and choreography of Web services workflows are essential parts of ongoing standards definition work at this time.

We still see the two viewpoints here. Orchestration imposes order and timing individually on a set of Web services and their outputs in order to produce a desired process result, just as a musical director imposes order and timing individually on a set of musicians and their outputs to produce a desired musical result. Variations and errors in the musicians' outputs are frowned upon by the director but do not change the order or timing of the process. Orchestration of Web services reflects workflow's automation roots.

In contrast, choreography, by defining behaviors for handling varied and unpredictable interactions among a set of Web services, is more complex than orchestration in the same metaphorical sense. While a troop of dancers and an orchestra of musicians both perform their "tasks" in a coordinated manner, dancers in a choreographed performance move around in their workspace and physically interact with each other. Variations or errors in a dancer's movement can cause changes in the movement of other dancers, which in turn changes the dance performance itself. Choreography of Web services reflects workflow's people-based roots.

Back to top

Workflow and Enterprise Application Integration

Workflow software should fulfill these four primary functions as a part of Enterprise Application Integration (EAI): act as a component of vertical applications; work well with application integration software; be the "glue" for collaborative applications; and fit into Web services architectures.

As a component of vertical applications for enterprise industries such as Banking and Insurance, a workflow application should increase interaction between Development and Line of Business through intuitive graphical tools shared across organizations. For industries like Manufacturing, workflow applications should enhance production flexibility and enable production system load-balancing. The workflow application should have the capability to update workflows easily when processes and organizations change. Last, but not least, a workflow application should help the enterprise adhere to government and organizational regulations by standardizing and monitoring business processes.

In order to work well with application integration software APIs, a workflow application should provide flexible Java support that allows that workflow application to be integrated with Web applications and other IT applications, and should support integration with existing business applications. For example, the workflow application should be able to support a nested workflow within an external host workflow system.

Workflow applications should be the "glue" for collaborative applications from both of the viewpoints mentioned earlier. Collaborative applications most often refers to applications that are built of other applications/Web services required to perform tasks and that manage all of the interaction and data flow. Collaborative applications can also mean the automating and streamlining of people-based business processes so that the people involved in the workflow become more productive individually and, more significantly, as a team.

Workflow applications should fit into a Web services architecture. Workflows can be made available as Web services. For example, a workflow Web service could be invoked by an outside vendor submitting a request for a price quote. Upon creation of a request, a workflow application could route that submission to the appropriate person(s) after automatically creating and adding links to prior contracts with the submitter that are stored in a document management system, and developing some recommended quotes based on those prior contracts and current market conditions. When the submission is received by the person that is to fulfill the request, everything needed to make an informed decision about what price to quote the vendor is available. A workflow can also control the flow of a set of Web services that make up an application.

Back to top

Have your workflow call my workflow

In a collaborative application built of Web services, where the business process is really a set of tasks whose participants are Web services, workflow control is paramount and interaction of disparate workflows is inevitable. Before your workflow can call my workflow and be understood by it (interoperate), however, we need a standard that describes public process, composition, private workflow, and other common workflow artifacts. That workflow interoperability standard has yet to be decided on, even though there are several proposed workflow standards around. A lot has been written about these various proposals and documents elsewhere. Table 2 shows the various workflow specifications and definitions that have come about in recent years. There is also a list of references to these standards at the end of the article.

Table 2: Workflow specifications

Back to top

Are we there yet?

Why are there so many proposed workflow standards? Some are directly competing, yes, but many take up where others leave off in workflow's onion-like layers and blend together at the layer edges. The definition for a basic process blends into the definition of how one process can work with another. That definition's edge blends into orchestration, etc. Throw in all the possibilities of mixing automated and manual activities... Well, it's a very complex onion.

Is "workflow standard" an oxymoron? An oxymoron is a phrase whose parts seem to contradict each other. The word "standard" implies commonality, simplification, a foundation upon which to build something useful that others can understand. Workflow is usually complex and varied. Start stringing workflows together and the complexity and possible variations grow enormously. Is it possible to distill "workflow" down to a common "standard", or set of standards, that is at the same time complex enough to be useful? A lot of people think so, and are working on it now. It won't be as complete as some would like; no standard is (that's why standards extensions were invented). Maybe that's the stumbling block; we need the workflow standard to be full-grown right now. Wide-spread implementation of Web services is waiting...

Mature and sophisticated business process management as practiced today produces business processes that transform into complex, sophisticated workflows. The standardization of workflow behavior and interoperability is late to this game, trying to standardize everything all at once. Perhaps the standards bodies and their members should focus their efforts on finishing the basic, core workflow standard and not be so distracted by the outer layers. The standards work should "flow" from the center out.

Resources

• Start with the Workflow Management Coalition (WfMC) standards Web page.
  
  
• Learn more about WSFL with this developerWorks article, Introducing the Web Services Flow Language . (developerWorks, June 2001)
  
  
• For more about BPEL4WS, straight from two of its co-authors, read the series of articles starting with Business Process with BPEL4WS: Understanding BPEL4WS, Part 1 . (developerWorks, August 2002)
  
  
• Learn about the IBM WebSphere MQ Workflow.
  
  
• For a good update on choreography and orchestration standards progress, see Stuart J. Johnson's Web Services Wars Take Artistic Turn article.
  
  
• Find out about IBM WebSphere Business Integration.
  
  
• Wf-XML and Workflow Reference Model from the Workflow Management Coalition (WfMC) is an XML-based encoding of workflow interoperability messages.
  
  
• Find out about IBM Holosofx, which delivers a complete integrated business solution with Continuous Business Process Management software designed to identify, integrate, and manage business-relevant data in real time.
  
  
• The IBM Web Services Flow Language is a precursor to the BPEL4WS specification.
  
  
• Microsoft's XLANG is a business modeling language for BizTalk.
  
  
• Business Process Execution Language for Web Services is the cooperative merging of WSFL and XLANG for Web services orchestration, workflow, and composition. BPWS4J is the IBM alphaWorks Business Process Execution Language for Web Services Java Runtime platform that supports and validates BPEL4WS documents.
  
  
• eBusiness Transition Working Group carries forward the definition of workflow conversation and orchestration as part of the ebXML protocol stack.
  
  
• W3C's Web Services Conversation Language is a submission by Hewlett-Packard also focusing on XML document exchange and sequencing.
  
  
• RosettaNet's Partner Interface Process defines business processes between trading partners.
  
  
• CIP4's Job Definition Format is an upcoming workflow specification for the Graphics Arts industry.
  

About the author

		Margie S. Virdell is an e-business Architect for IBM Developer Relations Technical Consulting in Austin, Texas, providing education, enablement, and consulting to IBM business partners. She holds a B.A. in History and a M.S. in Computer Science from Midwestern State University, Wichita Falls, TX, and has been with IBM for 15 years, spending most of that time in the trenches of software development. When not looking for what's next in e-business, she's usually learning more about super-massive black holes and supervolcanoes. You can contact Margie at virdell@us.ibm.com.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top