A huge number of my projects are platform upgrades, and every time I ask my customers why they haven’t applied a single published fix for any of the products involved since the system was built (sometimes upwards of 7 years ago). They usually reply with a variation on the old trope, “If it ain’t broke, don’t fix it!” I of course launch into a sermon about the ways regular maintenance will save them from the pain of multi-version upgrades in the future, protect their data and users and save money by avoiding extended support contracts (see ATMs still run Windows XP).
Reading a recent Flash (Alert) from IBM brought this perennial conversation into clear focus. I think it’s a perfect example of why keeping up with the patches is absolutely critical. IBM’s Enterprise Content Management products, as a whole, have Java Applets in their front-end applications for viewing and annotating images and a bunch of workflow features (design, administration, configuration, simulation, etc.). These Applets rely on the user having the Oracle JRE installed on their workstation, which, of late, has been a moving target in terms of security requirements. The latest versions (1.7.0_51 and above) will block most of IBM’s Java Applets because they were developed to older standards. As the Flash indicates, a series of Fix Packs and Interim Fixes have been released to address this issue.
Let’s consider some scenarios:
- What if you have a P8 v4.5.1.0 system with WorkplaceXT 1.1.4.0 as your primary front end (albeit a configuration that will only supported until April 30, 2014)?
- Content Engine needs Fix Pack 7 and then Interim Fix 2
- Process Engine needs Fix Pack 4 and then Interim Fix 4
- WorkplaceXT needs Mod Pack 5, Fix Pack 2 and Interim Fix 1 (although this can be done in only 2 steps)
- And that’s not counting any problems with custom applications that might arise as a result.
- What if you have IBM Content Manager v8.4.2.0 with the matching version of eClient as your primary front end (there is no announced end of support for CM v8.4.x)?
- You have 2 choices, just update eClient or update the whole platform
- Only updating eClient will require Mod Pack 3, Fix Pack 3 and an unpublished Test Fix
- Updating the whole platform will require the same steps for all components (Library Server, Resource Managers, II4C and eClient). The Test Fix only applies to eClient, though.
What these scenarios show is that without regular maintenance to all components of a platform, urgent fixes for major user facing problems can become a large undertaking very quickly. If these systems were up-to-date on their patches, the fix for this JRE change would be simple and low risk.
I generally recommend that Administrators subscribe to IBM’s support and product announcement alerts to maintain awareness of what’s new, what’s changing and when. I also recommend that organizations apply the latest patches to all levels of their system stacks at least twice per year. All levels of the system stack is the key word. Most organizations are religious about Operating System patching, but RDBMS, J2EE Servers and ECM/BPM platforms are often left behind.
Keeping up with Fixes is a substantial time commitment; but, when major changes or bugs come down the line, you’ll be ready to get them patched and secured quickly and with ease.
This is the end of the post, below are some musings on generally related topics.
Errata:
- My example scenarios are completely hypothetical and both start and end with presently supported configurations (as of March 24, 2014).
- eClient v8.4.3 is to be the final version of eClient. Content Manager v8.5 ships with only Content Navigator as it’s front end, although it will be supported for the moment with eClient v8.4.3.x. No further Fix Packs have been announced for v8.4.3 (FP3 is the latest). See my prior post for more information about Content Manager v8.5.
- I intentionally chose P8 4.5.1 as an example because it’s support is ending quite soon. Customers who aren’t up-to-date who try to apply these interim fixes after April 30, 2014 will need to have purchased extended support to get help if something goes wrong. Newer versions of P8 are also perfectly good examples,
- The alert services for support and product announcements take some finesse to configure, take your time, it’s well worth it. The alerts come one or two times per week and list any product releases, updates, technotes, etc.
- An additional scenario to consider is IBM Content Manager v8.3.0.3 (unsupported), where the path would include at least 2 steps prior to those for v8.4.2.0, more for starting on 32 bit, non-Windows systems. Since v8.3.x is unsupported, and its Fix Pack 4 is non-cumulative (requires exactly v8.3.0.3.5 for update), the process becomes even more complex. Also, the mandatory switch to 64-bit systems for non-Windows installations could increase the cost due to hardware needs.
- For P8 considering the improvements to the Process Architecture with P8 5.2, maintenance in general has gotten easier since Process Engine is no longer a discrete component. See my prior post form more information about Process Architecture Improvements in P8 5.2.
- When planning your patching cycle, I strongly suggest you look to the historical data regarding fix release dates. While IBM will not share fix release schedules, they do tend to release fixes on a fairly regular schedule that varies by product and can be extrapolated from historical data. That said, there’s no guarantee they won’t change the schedule. They tend to release anywhere from 1-4+ fixes per product per year. WebSphere Application Server, for instance, will have many more. IBM Content Manager will be much more minimal. The alerts I’ve mentioned will keep you apprised of new fixes.
- Changing behavior in organizations requires strategic shift—extremely difficult to achieve. See Wikipedia and Perficient for some ideas and resources.
