jBPM and Spring - Spring Enterprise Recipes: A Problem Solution Approach - page 406

in even slightly larger business processes, though! For example, imagine the new-hire process at a large
company. Beyond the initial process of interviewing and a background security check, there's the
provisioning that's required to get the new employee installed. The IT department needs to repurpose a
laptop, image it, and install an operating system. Somebody needs to create a user account for that
employee and ensure that LDAP and email are accessible. Somebody needs to ready a security card so
that the employee can use the elevator or enter the building. Somebody needs to make sure the
employee's desk station or office is cleaned, that remnants from the previous occupant are gone.
Somebody needs to get forms for the health insurance or benefits, and somebody needs to give the new
employee a walk around the office, introducing the employee to staff.
Imagine having only one person to do all of that for each employee! In a bigger company (such as a
bank, for example) this process would soon become overwhelming! Indeed, many of the tasks
mentioned themselves have many steps that are required to achieve the goal. Thus, the main
process—integrating a new employee in the company—has multiple sub-processes. If all the tasks are
performed concurrently by many people, however, the process becomes manageable. Additionally, not
all people are suited to doing all of those tasks. A little specialization makes for a lot of efficiency here.
We see that processes, and the understanding of those processes, are crucial to a business. It is from
this revelation that the study of business management emerged, called Business Process Management
(BPM). BPM originally described how to best orchestrate technology and people to the betterment of the
business, but it was a businessman's preoccupation, not a technologist's. As it became apparent that
businesses were already leveraging technology, the next hurdle was to codify the notion of a business
process. How could software systems know—and react to—what the immovable enterprises and
unbending market forces demanded? BPM provides the answer. It describes in higher-level diagrams the
“flow” a given process takes from start to finish. These diagrams are useful both to the business analyst
and to the programmer, because they describe two sides of the same coin. Once a process is codified, it
can be reused and reapplied in the same way a programmer reuses a class in Java.
Software Processes
Thus, the unit of work—that which is required to achieve a quantifiable goal—for a business is rarely a
single request/response. Even the simplest of processes in a business require at least a few steps. This is
true not just in business, but in your users' use-cases. Short of simple read-only scenarios such as
looking at a web page for the news, most meaningful processes require multiple steps. Think through the
sign-up process of your typical web application. It begins with a user visiting a site and filling out a form.
The user completes the form and submits the finalized data, after satisfying validation. If you think
about it, however, this is just the beginning of the work for this very simple process. Typically, to avoid
spam, a verification e-mail will be sent to the user. When the e-mail is read, the user clicks on a link to
confirm the intentions of the registrant, and that the registrant is not a robot. This tells the server that
the user is a valid user, and that a welcome e-mail should be sent. A welcome e-mail is then sent. Here
alone we had four steps with two different “roles!” This involved process, when translated into an
activity diagram, is shown in figure 11-1.