You Change It, You Own It
Bookmark :
At the 'Ask the Developers' session on Thursday at LotusSphere there was an interesting question asked. How do you make upgrades easier for admins when there have been changes made to a standard template like mail? This is actually a big issue for a lot of organizations, but no one is thinking about it in the right way.
The simple answer is that you don't migrate changes over, at least not directly, you need to re-implement them. Also there are 2 reasons why so many organizations get stuck here. First they are treating this as an admin problem, when it is clearly a development problem. Admins should not be held responsible for ensuring that migrations do not break existing functionality in custom applications, this is a development responsibility. Second, the customized version of the mail template is now no longer an IBM product, but your custom application so you need to start treating it as such. You forked the code base of the mail template to create a new application that, at one point in the past, was based on the standard mail template. Once you do that, you are on your own and, the farther back in time you forked, the harder it is to merge changes. (more)
You are wasting time thinking that you will be able to magically import all of your changes into a new version of the mail template. Besides, chances are pretty good that the places you modified do not even exist any more or have been moved around so you wouldn't even recognize them. Even basic functionality in Notes is notorious for being spread around in a collection of shared fields, subforms, formulas, script libraries and views. The chances are pretty slim that any code changes you made 2 versions ago will even have a place to go in the new template. Even if they did, is the old way really the way to do it? Is there a better way that makes use of the new features of Notes? There is no silver bullet here that will make all your customizations suddenly work or even make sense in a new context.
A maintenance plan for customization to standard templates should be part of the development plan for all work, just like it is for completely custom apps, because that is what they are now. Development needs to start to get involved in the upgrade process and plan out the development schedule for re-implementing the custom features that are still relevant in the context of the new templates. This is where detailed change histories are extremely helpful, if not essential. Looking back on all the changes that were made to a template will give you a clear plan for what needs to be done to the new template. With out this, you have to resort to a standard diff of the two app designs, which is probably sufficient, but you will lack the context and reasoning that the change history comments will provide. Also, it will be very difficult to sift through all the changes pinpoint exactly what yours were between your template and the new one when you also have to sift through changes that IBM made.
So treat changes to the standard templates appropriately. It's unfair to burden the admin team with this responsibility when they already have enough to worry about. Design changes should always a development responsibility and changes to standard template should be no different.
Comments
If you're talking from Notes 6 to Notes 8, sure. If you're talking about Notes 7.0.1 to 7.0.3, nonsense. MRs just don't have that much delta between the designs.
Posted by Nathan T. Freeman At 02:26:27 PM On 02/13/2008 | - Website - |
Posted by Craig Schumann At 03:36:13 PM On 02/13/2008 | - Website - |
And it gives one a chance to re-examine one's code too.
I've done 5 to 6 and 6 to 7 upgrades and on each occasion adding the customisations to the template became easier and teh code became simpler, with some code from R5 not being needed in the R6 template and so on anyway.
Posted by Christian Legg At 12:39:56 AM On 03/06/2008 | - Website - |