"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:
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:
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.