modify std vs clone std vs create new

Zaki Ahmed

Well Known Member
We are going through new implementation of JDE and IT is strong about NOT making any changes to standard JDE applications. They want to set a precedence that std applications shouldn't be modified as it is high cost of retrofitting for IT during ESU updates and upgrades and such.

However, there's a big push from business to include some functionality that doesn't exist in std. application. Some developers have opted for cloning standard applications such as P4210 to P554210 - even for minor modifications such as adding a URDT field to Grid. But I personally think it is a very bad idea cloning applications such as P4210 due to following factors

1. Get processing option business function has hard coded value of "P4210" to retrieve PO. That means, if I clone P4210 to P554210 and create a version against P554210 and link it to other applications, then those apps wont' be able to retrieve PO of P554210. So I will then have to create a similar version against P4210 to refer to that. Messy!
2. Cloning to P554210 doesn't fulfill the desired result of reducing retrofitting effort. As if a fix/esu comes from Oracle, that ESU will have to merged into P554210 if there's a desire. And it's more difficult to merge ESU code into P554210 than to merge our custom code into P4210 after ESU is applied

I am all for creating new applications, but it impacts user experience, as they have to toggle between applications to do different things, that would otherwise be done in one screen.

I guess, what I am asking here is, how do you guys make a decision of Modify std app VS. Clone std app VS. Create a new app. Do you have any corporate strategy around this? Or it's all under the domain of JDE developer - how he/she seems fit. What drives your decision making in the respect.
 
3rd reason not to clone: There are LOTS of places that link (Row exits, etc) to P4210. Now IT has to clone those programs to point to P55410, then they have to clone the programs that link to the programs that link to P4210 ...
 
IT is strong about NOT making any changes to standard JDE applications. They want to set a precedence that std applications shouldn't be modified as it is high cost of retrofitting for IT during ESU updates and upgrades and such.

Core applications should be modified, not cloned. IT department should support the business , if they want to reduce the cost of upgrade they need to be smarter, track each customization and adopt best practice in the development process. Be sure the cost of bad programming and change management is much higher then cost of customization.
 
Hi Zaki

I always customize, cloning involves a lot of work, as as you says, an ESU could modify a bsfn that is called from the original application, and the original application is then adapted to handle this new functionalities of the bsfn, if you duplicate you will be getting errors on these callas

In the current versions with the compare mode and the new tools for retrofiting, this is very easy to re apply customizations.

More on, I NEVER merge, always replace, then use the compare mode vs my PD environment and I re apply all the customizations, going to the copy mode is a not a good way, you don't get the new functionality of the ESUs and don't benefit for the fixes unless you duplicate all the ecosystem and this is not doable

Regards
 
We almost never copy and mod but instead modify the pristine object. There are the occasional times were a copy and mod is appropriate - each case should be looked at individually to see what makes the most sense. Generally these are things like reports. I can't remember the last time we copied and modded an APPL.

Organizations that adopt the policy to copy and mod rather than modify pristine think they are mitigating risk and making ESU/upgrade retrofits easier when in fact they are doing the exact opposite. We had the same philosophy when we first implemented JDE and we quickly realized that it was the wrong approach. Even so we had a few applications that retained their copy as the application used in PD (luckily P4210 was NOT one of those... we quickly learned that would not work at all). The copied applications gave caused us so much pain and grief that when it came time to upgrade from Xe to 9.0 we transitioned away from the copied applications and made modifications directly to the pristine objects.
 
With a few rare exceptions I have found it better to modify existing instead new or cloned applications for many of the same reasons stated already. Actually many years ago when working at a new organization not affiliated with my current employer I was challenged on this philosophy and during the discussion found out the organization did this because upgrading was easier. Come to find out in a lot of places they were running custom copied applications based on an older releases code. In essence they had not upgraded at all in those parts of their system!

Also documentation of the modifications is key both to clearly mark them and then have documentation of what and why the modification was made so you can properly evaluate the need for the modification on the next upgrade.
 
Thanks for your feedback. I am along the same lines as you all folks are. Therefore, I am in the process of building a decision flow model of when it would make sense to go for each of the options and will make that part of our JDE Development Standards Document. This will then help our developers/consultants to take more of a black & white approach rather than making their own decisions.

Following is the narrative I came up with: Any input is greatly appreciated!

Modifying an Existing Object (Cloning Vs Modification)
If there’s an approved business requirement that doesn’t exist in standard JDE functionality and an enhancement or modification to a standard object can fulfill that business requirement then such a modification or enhancement should be done in accordance with best development practices, such that retrofitting during an ESU or an upgrade is minimal.

If there’s an approved business requirement that deviates from a standard JDE functionality, but technically, it saves time to clone/copy the code from standard application, then the application/report should be cloned/copied as long as it is done under the presumption that the cloned application will not be retrofitted for any ESU fixes or upgrades.

Modification:

Complex Core applications such as P4210 and P4310 should be modified not cloned. IT department should support the business, if they want to reduce the cost of upgrade they need to be smarter, track each customization and adopt best practice in the development process. Be sure the cost of bad programming and change management is much higher then cost of customization.

Reasons where Modification to Standard Application applies:
1. Application is very complex and has thousands of lines of codes such as P4210 and P4310
2. Application is linked through dozens of other applications through Form Exits or Row Exits
3. Routine ESU updates impact such applications
4. Retrofit effort is less than 24 hours
5. Enhancements/modifications don’t impact the core functionality of application or report.
6. Modifications/enhancements are going to be utilized by all business segments.


Cloning:

In JDE it is common to utilize existing applications as a baseline for new development or enhancements. This process is called cloning. Cloning occurs when an object is copied to create a duplicate with a different name or identifier. There are several reasons why cloning is an acceptable and common practice:
1. Applications are cloned as either a starting point to create a new application that has a similar architectural structure
2. Applications are cloned to extend the functionality of the existing application while preserving a version of the original code.
3. Cloning a report for the purpose of creating a completely new and different report is technically very safe. The reason for cloning in this case is to increase the efficiency of creating a new report by copying an existing one. From this point forward, the reports are managed independently from one another.
4. Cloned application or report will be immune to any ESU fixes or upgrades.
5. Cloned application or report will no longer be linked to any previous report/form/row interconnects against which the std application was linked
6. The application that is to be cloned isn't hard-coded in other standard JDE business function or report/form interconnects, (i.e., if the cloned application will replace the standard application)

Before cloning developers should consider the following:
• Object management and maintenance or upgrade
o Changes delivered by JD Edwards EnterpriseOne for maintenance or upgrade would be defined for the original object, not the cloned object.
o Merging these changes to a cloned object would be difficult to plan since the level of complexity would be unknown until the merge is in progress. In addition, specification changes are not identified by the merge tool.
 
Last edited:
Back
Top