Since 2000 I’ve been engaged in deploying a range of technologies, databases, and websites. Typically, I’ve been very hands on configuring the solution, building the database, and learning as I go.
My recent experience building a new website for Olympus Corporation of the Americas’ Medical Systems Group has been different. The requirements are more complex, because there are many more required resources, and their are roughly 50 content owners for the US site alone.
I’ve written about the challenges and mistakes made in securing content, now I’d like to speak to three of the configuration aspects I would have done differently.
First, I should have installed Acquia’s Dev Desktop for the purpose of seeing out of the box Drupal vs. our custom configuration. I’ve worked with WordPress, Concrete 5, Zope/Plone, and some non-profit specific solutions including iMIS, but had not worked specifically with Drupal.
Why didn’t I? I had an IT team that was setting up our server, a creative team that was handling design, programmers who did theming, and we had hired an implementation vendor to deliver what we required.
I regularly reviewed functionality, but wasn’t focused on how the functionality was achieved. Later I had to try to figure it out and didn’t have the knowledge to know or experience to do a good job of reverse engineering.
Second, I would have gotten involved in the Drupal community in general and Drupal Association, specifically, much earlier. The NYC Camp by the Drupal Association, I took after I’d been on the project for close to 18 months. I should have attended more events and gotten as hands on as possible.
Third, I addressed this with content, but it goes for all aspects of the site, we should have more closely followed the workflow and processes throughout configuration. By this I mean, we have an approach and process to code control and the development, staging, production file push that is platform agnostic. Had we have been using this throughout, we would have caught some of the nuances that exist within Drupal, earlier.
Why didn’t we follow these? Speed. We worked in production because the site wasn’t live, we were the only ones using it, and it was much faster to work in production rather than be pushing files from one level to the next.
All-in-all, the site build went well and we were fortunate to have some very good partners, but if you are looking at moving to Drupal I’d definitely recommend getting hands on, getting engaged, and utilizing the workflows you build in.