EnterpriseOne Security, Upgrades & Dual Maintenance
Tags: Dual Maintenance, EnterpriseOne, JD Edwards, Security, Upgrades, UX One
Why is Security such a big deal? This seems like an obvious and unnecessary question but you have to qualify the context of the question. Security is essential to the survivability of a business and everyone agrees that it’s a serious topic. The most common definition is “measures taken to guard against espionage or sabotage, crime, attack, or escape”. However, the context for this discussion is implementation of security for an upgrade and not why we have security.
Many customers have thousands if not tens of thousands of security records setup in their EnterpriseOne release. Furthermore, most customers do not understand that with the release of Applications Release 9.2 and Tools Release 9.2.1, many security changes have occurred with the addition of new records specific for the new functionality and/or industry compliance requirements. Lastly, the customer is adding new 9.2 type records as they progress through the setup of the new release during the pre-production phases of an upgrade. Combined, these three factors (extensively established security records + new 9.2 security records + adding new 9.2 records) create a challenge for upgrade projects and usually necessitates a dual maintenance requirement for the duration of the project.
Customers commonly request to periodically bring over their previous release’s security records as part of multiple data refreshes or mock cutovers but there is no easy or straightforward approach because the EnterpriseOne upgrade tools do not provide a clean method to merge changes only. The options are either a wholesale copy & replace from previous release to new release or dual maintenance. Therefore, it’s advised when planning an implementation that careful consideration be given to understand and emphasize the importance for dual maintenance.
What about scripts? Sure, elaborate scripts can be created or complex procedures devised to try and accomplish security refreshing but these require more effort and costs than the benefits. Most of these efforts would be implemented through custom coding and/or database triggers which are not preferred. Custom coding and database programs should be the last resort to accommodate an upgrade task if dual maintenance is an option. Dual maintenance provides the benefit of control of the security changes within both releases plus the repetitive familiarization of how security changes are performed and their impact in the new release.
Therefore, when planning your implementation make sure you discuss and revisit the new security changes that are introduced with the new release and stress the requirement for dual maintenance. Establish and agree upon a well thought date that the previous release’s security will come over to 9.2 and then start dual maintenance from that point forward during the duration of the upgrade project. If the customer understands all the moving parts between the old and new security setup, then performing dual maintenance will facilitate simplicity and increase the proficiency of security management in the new release.