OOPSLA'96Business Object Workshop III


A "light" distributed OO Workflow Management System for the creation of Enterprise Architectures in BPR environments

"Copyright 1997, Michael A. Beedle. Permission is granted to copy for the OOPSLA-97 conference."

Michael A. Beedle, Framework Technologies Inc.
Schaumburg, IL 66195
(847) 490-7110
beedlem@fti-consulting.com


Abstract

BPR and object oriented technology are - and have been for the last few years, some of the two most important business and technical currents. However, it is often seen that applications developed independently for each business process result in "system architecture silos". Therefore, the implementation of OO enterprise architectures brings ample business benefits in BPR environments such as: increased "enterprise conceptual integrity", reusability, generativity, and increased business effectiveness (cost, quality, service or speed). However, the simultaneous implementation of OO architectures and BPR also demands many changes in the business organization, its software development organization and its enterprise architecture. This paper briefly presents a "light" OO workflow management system for such an environment, and a brief description of: 1) a "business engineering" method, 2) a collection of business architecture patterns, and 3) a collection of software development patterns, that work together synergistically.

The "light" OO workflow management system presented in this paper is a design - not a pattern. While it may be possible to abstract parts of it to "workflow" patterns in the future, many comparisons among OO workflow management systems should take place before that. Let's start by setting the context of the where the workflow manager operates in the BPR environment.


1. BPR - as the context for Workflow Management

Reengineering as defined by Hammer is:

The fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical contemporary measures of performance, such as cost, quality, service and speed.

The goal of reengineering is to create hyper-productive but enjoyable work environments that promote the growth and human comfort of their employees. A key concept to understand how the business processes of an organization are redesigned is the Business System Diamond. This concept states that the definition of Business Processes lead to Jobs and Structures, which in turn require Management and Measurement Systems, that reinforce a set of Values and Beliefs. Every organization has a Business System Diamond, with the one in reengineered environments shinning brighter. Presenting a pattern language for BPR allows us to show important "organizational constructs" that are typically hidden beneath the artificial process steps of a given BPR method. However, reengineering is pipe-dream if the technologies and applications that enable the business processes are not supplied through an enterprise system architecture.

In a "true" BPR environment the business organization and its system architecture is organized around "processes", which require different roles and applications than those in a traditional business environment. For example the different CoreProcesses of the organization require a ProcessOwner, which in turn are in charge of a collection of CaseApplications, CaseWorkers, CaseTeams and/or CaseManagers [Hammer93]. From the system architecture perspective, each of these BPR constructs require that their enabling applications follow and monitor their process instances through an OO workflow manager (ApplicationFollowsProcess, ReifyTheProces), and that all the process instances in the organization use a collection of SharedBusinessObjects. These and other patterns for the implementation of BPR with OO enterprise system architecture can be found in [Beedle97]. However, while presenting all of these patterns is unfeasible, we can set the context in which the OO workflow management will operate by defining a few business patterns (presented here in pattlet form for brevity - just the problem/solution pairs): CaseWorker, ApplicationFollowsProcess, ReifyTheProcess, SharedBusinessObjects.

Figure 1. PattBPR - A pattern language for BPR.

 

CaseWorker(***)

Problem

The realization of a business process may take several forms. Are there organizational structures that enhance productivity, cooperation, and customer focus but at the same time induce the growth of the company and its employees?

Assembly lines create "systemic" problems such as queues, batches, feedback loops, delays, high inventories and high ratios of checking and control activities vs. value added activities. High "inventory" in creative or intensive human labor environments translates in large amount of idle human resources. What is the best way to organize resources that are capable of fulfilling all the needs of a given process?

Solution

Assign a CaseWorker aided with the proper enabling application (ApplicationFollowsProcess), to fulfill the needs of an entire business activity (process). This solution to the problem of compressing the process has a more "personlized touch" than a CaseApplication. So the choice may be made on the need to be "personable" and the feasibility of the implementation.

The CaseWorker should be trained to become a generalist in the business domain in order to respond to all the business requests assigned to him. There may be many types of CaseWorker s ranging from the very directed, inflexible and guided jobs of telemarketing and customer service; to the very creative engineer, researcher and software designer/programmer positions.

The CaseWorker will have a great deal to learn to become better at what they do. Also they may find very fulfilling to train or mentor other CaseWorker s into their corresponding positions. Also the CaseWorker get a large sense of accomplishment since they are responsible for a whole business activity. Since they will have a direct impact to the bottom line, it is often found that they are remunerated accordingly; not only in good salaries, but in performance bonuses as well.

They also form an integral part in designing new or alternate ways to perform the business process. And as they grow within the company, they can leverage extensively their hands-on business experience and translate their business knowledge into their most valued company's asset.

A definite characteristic of a CaseWorker is that his job will change from single task to multi-dimensional work.

Examples

Ameritech Customer Service Representative in the customer service department

US Spring, MCI, AT&T, American Airlines and most other service oriented organizations.

 

Application Follows Process

Problem

Many applications in corporate environments - whether OO or not, often require "memorizing" the steps to follow in a given application or require jumping across very many different applications to find the information to solve the problem at hand for the customer. In the best case scenario, these applications provide the marginal means to accomplish a given task. In the worst case scenario they represent a bottleneck in process efficiency often compromising the bottom line. A perfect example of this situation is in trading systems where the number of transactions per unit of time is directly proportional to profits.

Solution

Create enabling applications that "follow" the business processes. The applications not only should display "data" that is important to the users but they need to "walk" them through the process instances.

Enabling applications are created through the BusinessEngineering life-cycle, which includes: Business Requirements, Business Design, Business Evolution and Business Evolution.

It is best if these applications are created from a common base - an Enterprise System Architecture. That way, the business logic is reused in creating multiple applications. It is best to choose a technology that directly supports reuse in order to facilitate the delivery of applications, such as object-oriented languages and architectures.

In creating the enabling applications, it important to identify the "hot spots" - places where the business process may change, in order to provide for appropriate hooks for later extensions. This pattern naturally lead to ReifyTheProcess.

Example

Bell Atlantic implemented enabling applications that allow them to reduce cycle time in their CAS process by several orders of magnitude.

Other Known Uses

IBM Credit, Hallmark, Bank of America

 

ReifyTheProcess(***)

Problem

What is the best way to architect enabling applications in a reengineered environment?

Solution

Create an application that contains a "reified" version of the process within the software. That way the process can be managed from within the software, offering the possibility of running multiple versions of it, creating variations on the domain objects that run with it, or saving it's state to be completed at a later time or by a different person or group.

The reification of processes means literally creating an object that represents the process, that way the process steps can also be reified to offer the possibility of applying polymorphic interfaces and design patterns to them. This adaptability is key in the rapid adaptation of the organization to the business environment, and therefore is of "critical competitive advantage" to use this technique whenever possible.

* This pattern sets up the context for the OO workflow manager.

Examples

Hewitt Associates, Action Workflow, American Airlines reservation systems

 

Shared Business Objects

Problem

Lack of conceptual integrity in the System Architecture across business processes.

For a system to work "smoothly", all of its parts need to be coherent. Very often a process in a company claims to be reengineered - because it uses traditional BPR patterns such as a Case Worker, but the application that supports the Case Worker is not integrated with other applications in the organization. A typical example of this situation is large insurance or credit organizations that claim that they "reengineered" their claims processing process, but that can't give you a report across different insurance types such as property, casualty and life for a single company.

As business demands change, timely adaptability is not feasible because of the underlying inertia of the current "incoherent" system architecture. And as a consequence the business may loose market share in a market segment or in the worst case scenario it may run the risk of being completely ousted.

Solution

An OO Enterprise System Architecture makes it possible to share business objects not only as "building blocks" for the development of applications but even as a "live cache" of business objects that are reusable for many applications. Some products in the market like Persistence, are able to do this by wrapping relational databases (INFORMIX, Oracle, SYBASE or SQL Server) as business objects, allowing many advantages such as: increase performance (up to 250 times as fast as relational databases), iterative incremental development and co-existence with legacy systems.

Examples

Boeing BPR effort, Motorola Iridium, Nike Securities, Hewitt Associates (and most other OO architectures), and most other CORBA implementations.

 

2. A "light" OO Workflow Manager

Starting with the idea of "reifying" a process, one can extend it to a composite that has state and ownership among other things:

 

Figure 2. OO Worflow Management System

The typical scenarios that occur on the system are:

  1. A client application "enters" a process because it either a) create a new process instance, b) is viewing a process instance, c) is editing a process or d) is deleting or terminating a process instance. If it creates a process, the WorkflowFactory is used with a paramenter indicating a "registered" Workflow.
  2. The process is initialized with the appropiate business objects. In new proceses the input is taken from the user. In existing processes the input is taking from the "persistence process" data.
  3. Because the applications have a "wizard" look-and-feel the process is executed in the Next and Previous steps. Each process step defines a transaction and has an associated state.
  4. The "master process" has the business rules to navigate through the process and it knows how to iterate the composite workflow.
  5. Each process and process step may have an owner. When the process changes owner, workflow may be "pushed" to the user or may be set in a repository so that a user can "pull" it. Notifications can be done through a messaging system such as Microsoft Exchange.
  6. Owners may have categories which may allow them to "take over" a workflow.
  7. By designing the ownership of the processes and the process steps it is possible to determine the "routing" of work.
  8. The composite workflow can be distributed using CORBA interfaces. That way clients may execute a process in a remote server where multiple participants can be taking part in executing a workflow.
  9. Workflows can be saved (are persistent objects), that way a user can stop at a particular step and continue his/her work at a later time.

3. A Case Study

A variation of the above OO workflow manger is being used in the reengineering of a securities company in Chicago. The enterprise architecture consists of eight Java/C++ client applications - some of them running as INTERNET/INTRANET applications, that use the distributed OO workflow management system using a OrbixWeb/Orbix bridge to connect to a C++ server running Persistence (wrapping an INFORMIX and SQL Server databases). The server provides for a "live cache" of business objects that all the applications use and MAPI client/servers that send and receive messages using Microsoft Exchange.

4. Conclusions

Creating the correct an OO Enterprise System Architecture to be used in a BPR environment has many advantages. When an OO workflow manager is integrated in this architecture the resulting applications have a much higher benefit for its user community, for example:

  1. Applications are easier to use, decreasing training schedules and lowering hiring requirements, which translate in lower costs, and easier mentorship,
  2. Process instance status are kept automatically. Decreasing times in status reporting and research.
  3. Managing and designing work-flows is easier because it can be done in a central location.
  4. Work experiences are more gratifying because work is at a higher level, as opposed to be tracking undocumented or poorly managed steps in a myriad of applications or applications' "screens".
  5. Providing the capabilities of "reified" processes, one can approach the users with a technology and change their thinking of what is possible, therefore the capabilities of the architecture may in fact "generate" BPR environments from the bottom up. This is what the patterns people call "generativity" or Michael Hammer calls "inductive thinking" - first the technology then business change.

In theory it is possible to imagine a tool that serves as a "control panel" that tracks all the process instances of a company as well as historical data, regardless whether these process instances are interactions with suppliers, customers, staff employees, or executives. Therefore it provides for the means for future management systems based on real-time metrics and status, and for real-time forecasts.

 

References

[Beedle97] M. Beedle. BPRPatternLanguage - A pattern language to build agile organizations, (accepted at the PLOP97 conference), August 1997, Allerton Park, Illionois.

[Coplien95] J. Coplien and D. Schmidt, Pattern Languages of Program Design (A Generative Development-Process Pattern Language), Addison and Wesley, Reading, 1995.

[Cunningham95] W. Cunningham, Episodes - A pattern language of competitive Development, Review Draft of August 6, 1995.

[Fowler96] M. Fowler, Analysis Patterns, Reading, MA. Addison-Wesley, 1996.

[GOF95] E. Gamma et al. Design Patterns - Elements of Reusable Object Oriented Software. Reading, MA. Addison-Wesley, 1995.

[Hammer93] M. Hammer and J. Champy, Reengineering the Corporation: A Manifesto for Business Revolution. Harper Collins, New York, 1993.

[Jablonski96] S. Jablonski, C. Bussler. Workflow Management: Modelling Concepts, Architecture and Implementation, International Thomson Computer Press, London, 1996.

[Jacobson95] I. Jacobson et al. The Object Advantage. Reading, MA. Addison-Wesley. New York, 1995.

[Meszaros97] G. Meszaros, K. Brown, A Pattern Language for Workflow Systems, (accepted at the PLOP97 conference), August 1997, Allerton Park, Illionois.

[OMG-BAA95] OMG, OMG Business Application Architecture, White Paper, Framingham, MA, 1995.

[POSA96] F. Buschman, et. al., A System of Patterns, John Wiley & Sons, Chichester (UK), 1996.

[Schwaber97] K. Schwaber, Scrum WebPage, http://www.controlchaos.com/, 1997.

[Sutherland96] J. Sutherland, Scrum Web Home Page, http://www.tiac.net/users/jsuth/scrum/, 1996.


OOPSLA'96Business Object Workshop III