Managing the meta time zone
Three principles to consider when designing global BPM applications.
Orloj clock (source: Pixabay)
It’s Monday morning at Chez McKinty, and the conversation over breakfast started as usual…
Me: What’s your week looking like? Anything special?
Him: No, all the usual stuff. But the hour changed yesterday in the US so all my 9am meetings are at 5pm instead of 6pm.
Learn faster. Dig deeper. See farther.
It was only later that I realized how strange this would have sounded not very many years ago! We live with a permanent awareness of three time zones: where we live (CET), where our close family is and where my favorite radio station is based (GMT), and his work’s center of gravity (PST) where meetings are scheduled. Or maybe that should be six time zones, counting CDT, BST and PDT as well.
While writing Designing Efficient BPM Applications, my co-author and I struggled with the time zone issue for a couple of reasons. One was technical: we were using very early versions of new software still in development. This was exciting because we could influence the direction, but also frustrating because inevitably there were times when things did not work. The date picker widget used to input dates on forms was particularly difficult. The second reason was the problem that faces anyone developing a global application: how to use system time internally and the user’s own time zone in the user interface display. We finally decided that because the time zone issue is not specific to BPM we would just assume that everything happens in a single time zone, UTC. This removed a lot of complexity that was not related to the main topic of the book.
So, the time zone issue is not specific to BPM, but here are three design considerations that can help you create a more efficient BPM application.
Prefer durations to due dates
It is a characteristic of an efficient BPM application that it sends reminders or that tasks must be completed within a certain time. If you define these using durations (“respond within 24 hours”) instead of targets (“do this by COB tomorrow”) you do not need to make any conversions between system time and display time. Of course, there will always be some tasks that have a due date, such as checking a monthly report. To avoid problems with the specified date not being in the working week, define these with a logical condition such as “the last Friday of each month” rather than an absolute date such as “the 28th of each month.”
Use dynamic task assignment at runtime
In a critical support helpline application, you need to assign trouble tickets to a technician who can work on a problem and respond to the client within the time defined in the contract SLA, such as “respond within 2 hours”. If you are providing 24×7 support, you probably have teams at several sites (or maybe several shift-work teams at one site), and you need to assign the task to the relevant active team based on when the ticket is opened. To do this, you need to specify a placeholder in your process design. In BPM terms, this is the Performer. Then at runtime when trouble ticket is received, you need to map the performer to the team. In Bonita BPM, performers are called actors. You can store time zone or shift pattern information in the custom user information and use this in the actor mapping to direct a ticket to the active support team.
Distinguish between operational data and application data
Operational data is the business data that is input or output for the application. Application data is either configuration data that controls application behavior or is tracking data recording activity. It can be particularly difficult to distinguish between these types of data for date and time data, not least because tracking data always includes dates and times. In the Tahiti vacation management example from our book, the vacation start and end dates are operational data. There is a timer of seven days after which a reminder is sent for any unreviewed request. This is application data. In this case, the distinction is clear. However, suppose you have an application that controls payments of bills. The payment terms are different for each of your suppliers, so the timer that controls the delay between receiving a bill and paying it is operational data. In this case, you use operational data to control the behavior of the application.
Today everyone lives in a much more connected world and we all take our round-the-world connections for granted. “Internet time” doesn’t just mean we expect things to happen quickly. It also means that we partly live our lives in some “meta” time zone where it is always “now” but we do not need to be aware of time zone differences. I can send email, leave voice mail, write a note in a forum, or send an instant message expecting a reply when it is convenient for my correspondent, without caring where in the world they are or what time it is for them. So everyone is at the same time more aware of time zones, and less constrained by them, which means we need to follow a practical set of guidelines when building our BPM applications.