by Lee Balsom

We’ve all heard the expression “No pain, No gain”. While it’s not universally accepted as a truism, it sprang to mind when I read the JD Edwards EnterpriseOne Applications Release 9.2 Update 5 announcement.

What was your first thought when you heard about Update 5?  Can you share that below as a comment?  I am interested to read what people have to say.

Whenever I hear about a new update or a new release of any software, I always think of the project that will need to be run in order to take advantage of the enhancements, additions and fixes.  When I think of selling the project to the business, fitting the project into a busy schedule and mobilizing appropriate resource I think of the pain.

What if you could realize the benefits and make the gains associated with having the latest and greatest software without a lot of pain? If there is little or no pain associated with each update project, why aren’t you running more of these projects?

These are questions you will have to answer for yourselves. In the meantime, we can provide you with some insights into the JDE E1 codebase and what’s been happening in recent updates.  Understanding what’s happening to the code is important, because changes to the code can be the source of a lot of pain.  Your perception and expectations in respect of the pain will influence any decisions you take on whether you can, or even should, get and stay code-current.

 

 

 

Chart 1 shows the cumulative change that Oracle has introduced with each update, starting with Update 2 (UN2) through Update 5 (UN5).  These numbers include changes upon changes because the same objects feature in many ESUs within and across Updates.

Note that ‘Mismatches’ indicates that Oracle have made some form of change to an object.  A mismatch may be logic enhancements that span many hundreds of lines of code, new controls on a form or UBE etc, or they may be minor SAR fixes.  Mismatches can occur in any object type, but all are relevant to you in some way.  That relevance might manifest as a retrofitting & testing requirement, or it may ‘only’ require testing if the object is used (but not customized).

What is striking is that the total number of objects, and the number of objects by type, that Oracle changes in each update cycle is not varying dramatically.  This bodes well for anyone wanting to commit to a strategy of continuous innovation based in part on code-currency.

 

 

 

Chart 2 shows the objects requiring attention and potentially retrofitting during an annual code-current change event.  Specifically, it shows the objects that may be impacted during annual projects for a company that is on update 2 to go to update 3, then the next year to go to update 4, etc.

A detailed understanding of what is happening to the Oracle code becomes invaluable as you move from contemplating the pain to implementing a plan. Your plan for introducing any business change, doing any retrofitting and performing testing, will be influenced by:

• your modifications, and how many of those modified objects are likely to have been impacted by Oracle; and,
• the changes that Oracle has made in areas where you have not modified the code, but nevertheless use the objects and therefore must consider as part of the test plan.

Furthermore, it should be noted that with each Update, Oracle deliver considerable numbers of NEW objects/functionality in EnterpriseOne.  Update 2, for example, added a net-new 513 APPLs and UBEs to E920, and a total 2070 new objects overall.  By the time Update 5 appeared on the scene, Oracle had cumulatively added some 830 new APPLs/UBEs and over 3800 new objects overall.  Chart 3 reflects this growth in new functionality that you may choose to take advantage of.

 

 

 

Without going into too much detail, what is important to recognize is that whatever you want to do can be brought together, packaged and presented as a one-off fixed-price fixed-timeline code-current retrofit project or as something more strategic that spans a number of years.

DWS specializes in helping companies look after their JDE E1 code. Using a set of proprietary tools, we’ve built an understanding of how Oracle has been evolving the standard codebase over time. Added to a forensic understanding of our clients’ modified JDE E1 codebases, this allows us to ease the pain associated with staying code-current.  We can provide cost certainty and help you mitigate the risk associated with any update project by taking responsibility for the retrofitting.

Committing to a strategy of continuous innovation (underpinned by cost certainty and regular, low-risk code-current change event projects), enables JDE E1 users to avoid the pain and concentrate on the gains.