January 7, 2014 By Jason Shueh
It could have been a recipe perfect for disaster. Just five days after Northern California’s Bay Area Rapid Transit relaunched its new Web site, BART.gov, it was hit with its second largest traffic spike of 2013 — a daunting threat, considering the site was placed on an expedited four-month development timeline and was unveiled just as BART's two largest employee unions were embroiled in a pitched labor dispute.
Oddly, however, BART’s Web Services Manager Tim Moore remembers the day — at least from a Web standpoint — being fairly calm. Moore said records show that on Nov. 22, between 7 a.m. and 8 a.m., BART.gov handled more than 20,000 unique visitors due to a major service delay in transit operations. The number represented an impact to the site that was roughly 11 times greater than normal for the hour, a time that typically averages only 1,800 visitors.
This success, which Moore describes as a “trial by fire,” led to a quiet celebration that day as the news media focused their attention on commuter delay updates and the ongoing union dispute. The website’s strong showing and the secret behind its speedy development strategy is noteworthy, not simply within the framework of organizational accolades, but also in the way of lessons learned — lessons that began on day one.
At the beginning of January 2013, Moore said BART received a startling notice from Adobe, the site’s content management system provider. BART’s Web team was told that by the end of 2013, Adobe Publish, the site’s former content management system, would be phased out entirely.
“That meant that we’d lose all of our Web site publishing capabilities, our editing capabilities and maintenance capabilities in less than a year,” Moore said. “So effectively, that’s when the stopwatch started.”
The tight time frame to launch a new website gave BART’s team one month to get through the process of internal evaluation on site design, budgeting, procurement and contracting, then just four months for actual Web development.
“It was no small task getting a public agency like this moving,” Moore said, and credited Ravindra Misra, BART’s CIO, for his quick response, as tasks were immediately delegated and stakeholders called in for feedback.
One of the most game-changing decisions made during the first month, Moore said, was choosing a new content management system, one that was easy to use and yet customizable enough to accommodate BART’s enterprise-level needs. Tasked by Misra to spearhead site development, Moore set about evaluating content management platforms, conducting user interviews, and reaching out to like-sized transit agencies for advice.
Like this story? If so, subscribe to Government Technology's daily newsletter.
In the end, Moore said, “Drupal emerged at the top of the list,” for it’s ability to be managed in-house, its estimated longevity and the backing of a large open source developer community behind it — and BART opted for many sources for future maintenance and support.
If there was one thing to be avoided under BART’s strict deadline, it was finger pointing and accountability shirking. In the often labyrinthian workings of large-scale Web development projects, Moore said it's common to see one team of developers pointing to the other when problems arise from compatibility issues, site feature requests and hosting snags.
Based on BART’s decision to choose Drupal, Moore said, Acquia — a commercial open-source software company providing products, services, and technical support for Drupal — appeared the most logical choice to avoid this challenge.