Flemming T Christensen on Quality Collaboration

About this blog:
This blog focuses on software quality in general, and IBM Collaboration Solutions offerings in particular. The author is an IBM employee, but expresses his observations and opinions as an individual here. The purpose of the blog is to nurture a conversation with our customers and partners about continuous improvement of our software based offerings. ~FTC.
.

Users are not all local to your time zone. They may be spread across the globe. Not only that, but - even if they were all local - different subscribers have different usage profiles. Many office workers use their systems primarily 8-5. And software developers all night it seems :-). Retailers often use systems until 9 or 10 pm. Entertainment industry users may need their system well into the night. And realty and mortgage companies tend to use systems intensely on the weekend, when home buyers are most active. We have customers in all of those categories. This continuous system workload is another effect of both multi-tenancy and the global dispersion of the user base. There is never a good time for a maintenance window, not even on the weekend, if ‘maintenance window’ means an outage of the services. We deal with that - as do all cloud service providers - by minimizing the need for maintenance outages, so we can accomplish most updates without an outage, and only need to take the system off-line briefly in case updates need to be made to a database schema. (PS: For larger enterprises, this challenge applies in their on-premises environments as well. Only smaller enterprises operating in one or a few contiguous time zones have a workload variation with slow periods suited for a maintenance outage. In the cloud, there are no slow periods).

The Lotus Notes calendar, for example, has built-in information about time zones and the associated Daylight Saving Time (DST) definitions. When those change, we supply an update (a 'fix') to ensure customers can continue to rely on accurate knowledge of time zone differences and what dates DST starts and ends in each time zone. I have noticed how very seamlessly Notes handles those differences for me, when I schedule meetings with teams around the world, and I'm not 100% sure exactly what day each country switches to or from DST. I've never had an issue with a misunderstood meeting time. But that seamless performance is only as good as the underlying knowledge of Time Zone and DST definitions (whether based on the operating system or the application), so when governments decide on changes - and some times that happens with literally just a few weeks of notice - we do our best to respond quickly to keep our customers' scheduling accurate.

If the change is known far in advance, say over a year, it's pretty easy to apply fixes to change the definitions in the operating system and/or the application. The problem comes when the change of definition happens with such a short notice, there is already a number of appointments in the calendar during the time period affected. For example, when the US accelerated the onset of DST by three weeks in 2007, users who already had calendar appointments in that three week span needed to make a decision on whether to adjust them or not. There is no easy logic to make that decision. If you had an appointment with your dentist 10 am standard time, that would naturally shift to 10 am DST after the government decides to apply DST on that date, because you are both in the same, affected time zone. But if you had a conference call with a major customer overseas, whose time zone definition did not change (different government), then the appointment would probably stay at 10 am standard time, which will now be 11 am DST for you. The calendar cannot distinguish which appointments to adjust, and which not to adjust. Human intelligence is still needed. Fortunately :-)