More Requirements

Today, we have a system in place that provides users with a ranked list of worker assignments for a job. It's pretty good at coming up with a useful list, but it's a little slow and "mysterious. "

Mysterious?

Users want to know why the system gave out the suggestions it did and why it didn't give out some other seemingly obvious ones. Our support team fields questions like this all the time:

• I know there's a worker right around the corner from this job site. Why didn't the system put him on the list? Possible Answer: This worker doesn't have the proper certification to do a job of type X.
  
  
• Why was Worker A ranked lower than Worker B? Worker A hasn't done a job for a bit, but Worker B just completed one. Possible Answer: Worker A was too far away from the job site and would have to start work late.
  
  
• What are the differences to the business between selecting Workers A, B, and C? Is one choice more profitable than another one?
  

So, the new system will be required to explain itself. Why did it select and rank the workers as it did? Why did it not select some seemingly obvious workers? And, what are the key attributes about potential choices that affect the business?

The Problem at Hand

So, this isn't really the problem, but it's close enough...

We assign workers to jobs at various client sites around the country. Although we learn about some of these jobs a few days ahead of time, most are rush jobs -- "How soon can you get here?" sorts of things. And, these jobs are specialized. Not all workers can perform all jobs. Special equipment is often required as are various worker certifications. Fairness matters too -- workers who haven't done a job in awhile get first dibs.

Does this sound like a problem for a rules engine yet?

Even though there are a lot of hard-and-fast rules, my client's employees still need to exercise some discretion when making assignment choices. So, our goal is to provide a ranked list of workers appropriate for particular jobs. Speed is important. Users won't wait for us to compute a list of workers each time they want to contemplate a decision. A half second is probably all the compute time we can tolerate.

This leads me to discuss the scale of our problem. We have about 500 jobs starting every day and about 1000 workers. While these numbers don't seem large at first, we're looking at half a million potential assignments at any given time. Some of the rules for assignment are straightforward: If the job requires the worker to have a particular certification, he or she must have the certification. However, many of the rules are more computationally intensive: How long will it take the worker to drive to the job site, and will he be able to start on time? A call out to our routing server takes a couple of seconds, and that alone is way beyond our SLA for our users.

We're Piloting Drools

Hi. I'm Steve Shabino, and this is my first post on this blog. I'm a software consultant based in Cleveland, Ohio who works with Java technologies.

For the past couple of weeks, I have been working on a pilot project with my client where we are building a decision support system using Drools. In the following weeks, I will document our progress so that others may learn from our efforts. While these posts will be technically accurate, I will obfuscate the problem domain to protect my client's privacy. Although I'd really like to share details, I think I can represent all the important parts via the "fake project."