My Top 5 PeopleSoft Customisation Tips

So... up-front...let's get something straight. One of the reasons you fell in love with PeopleSoft is that you can customise it.  Not just develop your own fully integrated custom applications but also that you can modify the delivered code.  This blog post is about customisations to delivered code.

Something else we need to understand is that customisations in and of themselves are not evil.  If the customisation saves you money, makes money and/or improves quality of customer service then why wouldn't you do it?  It is this capability that makes PeopleSoft so strong in delivering value to your organisation.  Of course, you do need to do the maths.

[Value Created] + [Quality improved] should be greater than [Cost of build] + [Cost of maintenance]

Cost of Build is usually quite easy to work out (especially once you've finished the work).

Cost of Maintenance (sometimes referred to as Technical Debt https://en.wikipedia.org/wiki/Technical_debt) is not so easy to compute.   This is the cost of your customisation getting in the way of applying updates from the latest PeopleSoft Image.  Like Cost of Build the impact of Cost of Maintenance is easier to compute once you've done it a few times. What I'm saying here is that experience helps in estimating cost of build and cost of maintenance.  To compute this you need to consider how intertwined your customisation is with delivered code, how likely (and frequently) it is that Oracle might change this same code in the future, the level of testing you need to do and the speed and expertise of your people.

What's the maintenance cost?

Value and Quality are outside the scope of this blog post - I hope to share my thoughts on this sometime soon though.

So, we have two principles outlined

    (i) a key strength of PeopleSoft is that you can customise it, and
    (ii) Customisations are not evil if they add value.

So here's my Top 5 Tips for Customising PeopleSoft.

NOTE: I'm assuming you've already discovered that the delivered application does not do what you need it to do and that you need the delivered application do something new in order to make money, save money and/or improve quality.

(1)  Adding a new field to a delivered Record will render the record customised but this is a light touch customisation and very low cost to re-apply (technical debt is small).  Deleting fields or changing datatypes is bad and will incur lots of technical debt with very little payback.  Changing a field length is not as bad as it sounds and still relatively low technical debt.  Don't waste your time creating "shadow" tables with matching keys for your new fields. You're just creating a lot of unnecessary work during build in keeping data in sync and for end users if they ever need to report on the data using Query. (Note: Those who once read my 2008 article in Oracle Scene magazine on Safer Customisations (see item # 3) may notice I've changed my mind on this one).

(2) If you need to add PeopleCode to an event then, if you can, choose an event with no pre-existing code in it.  The rationale behind this is that if the Oracle developers haven't added code to an event then it's likely they won't in the future.  This plays out nicely on Record PeopleCode vs Component Record PeopleCode.  The technical debt is low because it's likely (although not impossible) that your code will never get overwritten during an application update.

QUICK QUIZ. Which event fires first.  Record PeopleCode or Component PeopleCode?  (knowing this can help you decide on (2) above.

Old Code is good

(3) Customising Definitions with an old LASTUPDDTTM becomes safer the older the definition is.  The rationale here is that if Oracle hasn't touched it in years then they're unlikely to in the future probably because a) it's a very stable part of the system and never has any bugs and/or b) Oracle have lost interest in enhancing it.  Either way.... your customisation is going to be safer on an older definition.

(4) Use Event Mapping.  This feature of PeopleTools just gets better and better.  Actually, to be fair this really isn't a customisation top tip as Event Mapping doesn't result in a customisation.  However, one of the things that you can't do (yet) with Event Mapping is to specify that your code should fire instead of the delivered code.  You can specify that it fires before or after the delivered code but you can't define that you want your code to fire instead of the delivered code.  Of course, this could be dangerous but then anyone with Application Designer can be dangerous so let's ignore this issue.  If I want my FieldChange code to fire instead of the delivered FieldChange code I would need to wrap the delivered code in a condition which checked for the existence of an alternative event mapping event.  Something like this...

if not existsAnEventMappingConfig() then /*execute the delivered code*/

   /*...delivered code ...*/

end-if; /*last line of code in the event*/

Yes... i know this is a customisation... and Event Mapping is supposed to eliminate customisations but this is a very light touch custo.  If this got overwritten by an Application Update then it would take all of about 10 mins to re-apply this wrapper.  Got any better ideas?

(5) Pages are the hardest definition to re-apply customisations to.  If you're a developer you know this and if you're not a developer then go ask a developer why (bring coffee as a gift).  So, here's my most popular suggestions for handling page customisations.

Drop Zones in 8.57

(i) Try and control as much as you can with Event Mapping Page Activate code (or just straight Page Activate if you're not on 8.56 yet).
(ii) If you have to drop new fields on the page don't move around existing page fields.  If you move a grid by a few pixels then the compare report will pick this up, the compare report for pages is very hard to read, no one will have documented anywhere that they moved the grid 10 pixels up and 4 pixels left and so re-applying this grid move becomes time consuming and costly.
(iii) if the customisation involves adding new fields on a page then propose these questions to your users. Can they live with all the new fields on a new page in the component?  (technical dept near zero) or  Can they locate all the fields together in a sub-page on the delivered page (technical debt very very low)
(iv) Take a look at Drop Zones once you get your hands on 8.57.
(v) Cloning a page and then customising the heck out of the clone leaves you with the situation that if Oracle delivers a new version of the page then how do you pickup any important differences?  I'm not saying don't clone... just that the technical debt can be quite high.

I'll close with one other observation.  For each customisation you make add up the technical debt. That is... add up the cost of re-applying the changes in the event that all the definitions get overwritten during an Application Update.  Re-application of customisations do not take as long as developing the customisation in the first place. In reality it's a tiny fraction of the build time.  A 4 week development project could quite easily be recustomised in a several hours or less.  The HIGHEST cost of applying an Application Update is the testing time.  Using the techniques above will help reduce this re-customisation effort still further.

If you bump into me at OpenWorld and you agree or disagree with any of this or you have some alternative views then stop me (buy me a coffee) and let's discuss it.  Or ...feel free to post below.

"Happy Safer Customising" ...and just to keep everyone extra happy..."Happy Safer Customizing".