- The Wonder of Flowcharts
- Today's Workflow Scenarios
- Introducing Windows Workflow Foundation
- Windows Workflow Foundation Engine Architecture
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Today’s Workflow Scenarios
Key scenarios that use the flowchart model, branded as workflow, in software include the following:
Document lifecycle management—Historically, managing the content within documents across multiple users has been ad-hoc and other than versioning tracking within documents themselves the collaboration process required to produce a particular document has not been recorded. More recently, driven either by compliance to regulation, such as Sarbanes-Oxley, or the need to accelerate traditionally paper-based processes, more and more businesses are looking to document lifecycle management. Document lifecycle management includes key workflow aspects such as tracking the people involved, and often enforcing a particular interaction pattern among multiple participants across a piece of content. The most common document lifecycle management scenarios include expense report and absence report submission where a document is submitted to a workflow involving roles, such as the manager role, which approve the content before it flows to another system.
Internal application workflow —Several ERP, CRM, and other LOB vendors implement workflow within their applications to describe specific business processes that are executed within the applications. An example of this is the inventory process inside PeopleSoft. Vendors typically embed workflow to enable their end-users, sometimes developers and sometimes business users, to customize the LOB application. One of the vendor challenges associated with intra-application workflow is that each LOB vendor has to create its own workflow engine and technology rather than using a widely available common technology and as a result customers end up interacting with multiple workflow concepts, styles, and designers across multiple vendor products. Another challenge for customers is that at a business level a workflow may transverse multiple systems, which leads to the requirement to create a workflow that is external to all LOB systems and interacts with them.
Business process management (BPM) —Business process management is the category of products that provide externalized business process and workflow to a set of pre-existing applications. BPM’s goal is to drive control back to the business and enable agility in terms of how software responds to changing business requirements and processes. Most often business process management is layered on top of traditional integration technologies that connect prepackaged applications such as SAP and Siebel as well as businesses to other businesses across the Internet to manage the asynchronous stateful aspects of integration.
Page flow —Traversing a user interface often involves navigating across a set of linked pages or views with a subset of the variables shared between the views. Commonly this navigation functionality, or page flow, and the state it requires are intermingled into the user interface layer. By intermingling the navigation functionality with the user interface, there is limited reuse of the navigation functionality and multiple files need to be modified when a navigation change is made. Several vendors have recognized this problem and applied the model-view-controller approach to user interface design separating out the page flow element as a distinct controller element from the user interface. This has been most typically applied to websites with technologies such as the Java struts framework and BEA WebLogic PageFlow, but it is equally applicable in principle to rich user interfaces such as Windows Forms, as demonstrated by the Universal Interface Process block from Microsoft Prescriptive Architecture Group for both WinForms and websites.
All of these scenarios are similar in that by using workflow they achieve greater flexibility for the designer, greater visibility into the running program, and the ability to manage state across multiple steps. Although workflow has been and will continue to be important in these scenarios, workflow has not been generally accepted into program design. Some of the historical challenges with using workflow, such as the expense of an additional layer of abstract in terms of CPU cost, are no longer relevant. Other challenges such as enabling a running workflow to be modified in-flight to provide greater customization have not been well solved in workflow software until today. What if this workflow technology was broadly available for use in all programs?