September 24, 2008

Being First on the Block: Assessing Risks When Implementing new Software

Sometimes I just can't help myself when the Wizards in Seattle or Cupertino magically send a message to my computer - "Updates Available." A flood of excitement wells up inside me and I think, "Oh boy, something new!" or conversely, "Oh no! My computer is exposed! I better download this whatchamacallit ASAP or I'm going to get screwed by the bad guys out there in the Internet cloud!" Yes, this is how my mind works, and I hope you'll admit yours might too.

What that dialog box doesn't tell you is that downloading the upgrade or patch quite often should be done by professionals. For instance, I recently downloaded a series of recommended critical patches to my desktop. Now my Outlook is buggered and no longer integrated with my company's CRM application. Also, I can continue to work, however, Outlook crashes every fourth email or so - not so fun when I send and receive several hundred e-mails a day.

I'm bringing this up because that automatic update of business software on my machine has me thinking about upgrades and patches in general. For instance, I recently met with a customer that upgraded its Adobe Creative Suite from version 2 to 3. A smart thing to do in general, right? Depends. By doing so, that customer broke the integration of Adobe CS with their digital asset management system, which was integrated with their Web content management system, in a way such that content was no longer going to populate a section of their consumer-facing Website. With so much interrelated and integrated software at an organization, merely upgrading one component of it while neglecting the whole picture, or without regression-testing the entire integration, is a dangerous practice. The individual software vendors certainly don't have the resources to test scenarios for interoperability with other vendors' products, and in some cases, even from their own companies.

Think back to that first upgrade from Quark 4 to 5, or 5 to 6. Or QPS 1.12 to QPS 2.01, 2.02, 2.03, 2.04, 2.05, 2.06, 2.07 through 2.10b. Any bad memories there? What about CS 3 upgrades and the resulting patches? SmartConnection version 4 and the resulting half-dozen patches thereafter? Drupal 5 to v6? Vignette 6 to 7 anyone? Documentum 4 to 5? I am not trying to pick on a particular vendor here, although some could have done better in the past with their own quality assurance testing. Others - like Quark, Adobe and so forth - have actually improved dramatically in recent years.

With open-source projects like Drupal, there are more complications, since no central vendor exists to test all components to the upgrade. With the founding of Acquia in the Spring, 2008, the issue of quality assurance on major releases of Drupal software should now be mitigated over time. This is not necessarily so with other open-source projects without a 'parent' company.

The default and NOT the exception is that software vendors will release software with flaws, either major or minor. The marketplace tends to chase out those flaws no matter how well reputed the vendor is. I will often preach to my developers and integration staff at DPCI the following mantra: Discourage customers from being the first to implement software - let the marketplace chase out the first few waves of issues. Once in awhile, staff go forward with that Drupal6 implementation or that InDesign Server CS4 beta project. Sometimes the results are manageable. But most of the time, the projects tend to be more costly and schedules get prolonged in order to resolve issues.

That is not to say that DPCI doesn't serve early adopters of technology. In fact, the majority of our customers are early adopters trying to seize market opportunities with new software. However, if a company wants software, and there is an existing build of it on the market without outdated/end-of-life code, I would usually recommend the most-stable version of the software. Rather than try to chase bells-and-whistles in a build of the software that may destabilize the work environment, it will save the customer time and resources to let others knock the kinks out first.

In cases where new software has mission-critical functionality, I always counsel the customer to add budget and schedule to accommodate any unknown risks that could be happened upon. Like anything, seizing considerable opportunity is not for the faint-of-heart, but the rewards can be quite significant if the risks of not-quite-ready-software are built into the project plan.

Posted at 10:12 am by Joseph Bachana

Add comment

More Blogs From Author:

• So How Much Did Drupalcon San Francisco Rock? A LOT! 04/27/2010 - 14:39
• On Hacking Drupal Core and Contributing Back to the Open Source Community Project 04/20/2010 - 12:12
• On Opentext's acquisition of NStein 02/24/2010 - 09:48
• Why don't we teach project management to school kids? 01/14/2010 - 23:15
• A review of Dana Blankenhorn's blog on ZDNet regarding venture capital backed open-source software vendors not getting acquired 01/09/2010 - 13:31
• Review of article by Bruce Jensen on Folio Magazine's website 01/06/2010 - 18:43
• Review of Bryan Ruby's Blog post re: Drupal Vs. Joomla! 12/18/2009 - 09:24
• re: Jeff Eaton's Blog Rounding up whitehouse.gov Drupal Implementation coverage 11/03/2009 - 15:15
• On Matt Asay's "R.I.P., open-source evangelism" 10/28/2009 - 17:50
• CMSmatch.com comparison matrix of Drupal with EZPublish 10/03/2009 - 17:48

Contact DPCI to learn more about our Web content management systems,
digital asset management solutions, online collaboration software, custom development, multi-channel publishing systems, and workflow management solutions.