by Barry Burke

Best Practice for Upgrading JDE EnterpriseOne 2/5

Executing a JDE EnterpriseOne upgrade

In the previous blog, I spoke about the issues and questions you should consider when you are planning your upgrade.  In his second blog in this series I will focus on the issues relating to executing your upgrade with specific emphasis on the challenges facing developers, project managers and quality assurance.

Before you can begin any upgrade you need to know exactly what has changed in the latest release. Whilst Oracle does provide release documentation, it is not always completely accurate. It does, for example list objects as having been changed, when they have not actually been changed. This can result in additional and unnecessary work for your developers.

More serious, though, is that the documentation can show some objects as not having been changed when, in fact, they have. This can have serious repercussions on your project when your custom code fails to execute correctly, thereby extending project time scales and causing frustrations with your users.

In my previous blog on planning your upgrade, I spoke about how the DWS Dimension Analyze service provided the only accurate analysis of the true impact an upgrade will have on your custom code, as we actually scan the source code and do not rely on the documentation provided.

Now you need to decide on what is the best upgrade approach for your modified code. Do you take the new object and reapply the changes you made? Or do you take your revised objects and apply Oracle changes to your version? How do you decide which will be quicker?

Upgrade Challenges – Developers

There are many issues the developers need to consider and address when executing an E1 upgrade, such as:

• Identifying mods to Standard Objects
• Identifying mods to Copies of Standard
• Obsolete Objects
• Changes to Standard Hooks
• Custom Indexes on Standard tables
• Unicode and Best Practices changes in C business functions
• Obsolete APIs and custom client code
• Client Only Functions
• Table I/O Mismatches
• Version Overrides

In my first blog on planning the upgrade I addressed how you can identify all mods to standard JDE objects and to copies of standard objects. This information needs to be available to your developers when actually carrying out the upgrade work itself.

Turning our attention to Obsolete Objects – How do you avoid missing a custom object that references an std-JDE object that has become obsolete or no longer exists in the future release and becoming an issue during user acceptance testing?

Changes to standard-Hooks – There may be a change in the parameters passed into a function call, which ultimately affects the results of using this function in custom code. Knowing about these changes and the potential impact during the retrofitting of an object, again minimises or even eliminates issues during User Acceptance Testing by enabling you to retrofit the object accordingly first time!

Custom indexes on standard tables – As an example, a custom index has been added to the standard table, let’s call it index 5. In the future release, Oracle has added a new index to the table, also called index 5, therefore causing a conflict. You need to think about how you can check for these types of pitfalls so you can verify and retrofit the use of the custom index correctly during the retrofitting of the object in the new release and, in turn, ensure the consistent behaviour of the custom code and index.

There are a number of other things to consider on this list, but the last one I will draw your attention to today relates to the serious challenge of identifying Version Overrides. Of course, if you have used the DWS Dimension Analyze service in the planning phase, we will already have identified these, thereby eliminating the surprise of finding out about them during User Acceptance Testing.

Upgrade Challenges – Project Manager

I will now consider some of the challenges relating to Project Management, such as:

• Bundling
• Managing Resources
• Status Tracking
• Monitoring Progress

The Project Manager needs to take into account right from the beginning, the requirements of the critical business processes, the dependencies of objects and how to bundle objects together into smaller projects in order to meet defined deliverables and milestones. Being able to do this accurately will enable you to plan resources for testing and in turn deliver the upgrade in manageable bundles – an agile approach – rather than have to wait till the end of the development activity before performing all the testing – known as the waterfall approach.

It would clearly be helpful if the project manager can produce a detailed project plan, providing the visibility and accountability at an object level enabling effective management of resources and tracking the progress of the project.

Upgrade Challenges – Quality Assurance

The third component we need to consider relates to Quality Assurance.

A very important question to ask at this stage is, how do your Quality Assurance people ensure that the code delivered by the developer has addressed all the challenges listed above under the developer challenges?

What tools are there that can help your QA people to provide your end users with the confidence that the upgrade has gone smoothly and that they will experience few problems?

Obviously the key issues for the Quality Assurance Officer is to minimize defects and maximize quality. Part of this is trying to ensure that as much as possible is done correctly first time. Where any reworking is necessary the QA function needs to track this activity and ensure the correct version is included in the uplifted system.

You need to be sure you have an accurate list of all modified code that is still in use to make sure every object still needed is uplifted to the new release and nothing is overlooked.

It would be helpful to have access to a knowledge base of issues such as unknown or missing columns and parameters, known obsolete and retired APIs, tables and other issues that would have been identified by the Dimension Analyze analysis or learned from involvement in previous upgrade projects. Many employees involved in upgrades, though, have little previous experience to call upon.

How DWS can help

So how can DWS assist you with the execution phase of your upgrade?

At the heart of how we go about executing an upgrade is the DWS Professional toolset.

Dimension Professional is a suite of applications that leverages data produced by the Dimension Analyze service that we spoke about in the previous Webinar. It allows DWS to fully manage and fix the price of the modifications uplift component of an EnterpriseOne upgrade. This comprises 3 key components:

• Developer tools
• Project Management tools
• QA Analyst Tools

DWS regularly works alongside the customer’s own developers to deliver an upgrade. If engaged, DWS would provide the customer with full access to the Dimension Professional Tool set.

It is Dimension Professional that enables DWS to complete a fixed price and fixed timescale upgrade, using DWS’s Best Upgrade Approach functionality.

DWS provides Developers, Project Managers and the Quality Assurance team with role-based tools to assist with the upgrade. These tools are key elements of the DWS Dimension Professional Toolset

Dimension Professional is a set of tools created by DWS to enable the Project Manager to create a development project that would be accurate, sequenced to the client’s preference and allow project bundles to be created with full integrity. These project bundles would be self-sufficient allowing the client to start testing these bundles without having dependencies at later intervals. The integrity is built in and the dependencies are taken care of. Dimension Professional relies on the Dimension Analyze Audit and Estimate phases to be done first.

The Project Manager also has full access to the lower, more detailed picture by having access to the same tools the developers use on a daily basis. This tool incorporates functionality that simplifies the upgrade effort for developers and allows them to access information that would not normally be evident to developers at face value. A step by step process is adhered to by the developers to allow them to identify every technical change that needs to be done, leaving no stone unturned. This enables the most accurate upgrade with full integrity.

After the developers have completed their work, this is followed by 2 technical QA processes, which ensure that the objects that are delivered to the client have been effectively been addressed by 3 people. The result of this is that the defect levels that are found by clients (using Dimension Professional) are the lowest in the industry.

Dimension Professional also manages and reports on all the other overlapping items that are critical for the success of your upgrade project such as…

• Having the tools to review stats and the ability to view net changes, which enables integrity.
• Having an audit trail of statuses provides a history of events enabling the tacking of deliverables.
• If DWS create a lab on our DWS servers for a client’s upgrade the tools, it allows for Object Management Workbench integration.
• A central status update & time entry system, which allows for tracking deliverables and actuals versus estimates at a detailed level.

A critical factor, when things may change during the course of the project, is having the ability to view dependencies between objects and how rescheduling the deliverable of an object or a group of objects could have a ripple effect. This allows for adjusting the deliverables and sequencing accordingly to ensure integrity and avoid time wasted.

The cherry on the top is having the ability to identify what we call the Best Upgrade Approach.

But how do you gain access to such useful information when it is not publicly available?

Then, of course, there is the matter of testing, which I will be covering in the next two blogs.

Best Upgrade Approach

When I speak about the Best Upgrade Approach, I am referring to the best way to upgrade each modified object individually, taking into consideration:

• Is it better to take the new and updated Oracle object and re-apply your modifications?
• Or is it better to use YOUR modified object as the starting point and apply Oracle’s changes to YOUR modified object?
• Which will require least effort?
• And how do you know which is the best upgrade approach?
• Do you even know if your modified object is actually affected by the new release from Oracle?

As an example; a std-JDE object may only have say, 2 lines of code added to it in the new release. However, the custom modifications applied may span a hundred lines or more. The ability to see this enables the best approach in retrofitting an object and in turn saving time.

Based on the data provided by the DWS Analyze™ service, Dimension Professional advises you on which will ACTUALLY be the Best Upgrade Approach for each and every object.

 

The Proof is in the Pudding 

This case study relates to an upgrade from Xe SP 23 to E1 9.1 and posed numerous technical and project management challenges.

Using a combination of the DWS Dimension Analyze service and Dimension Professional DWS was able to:

• reduce the modified footprint by 70%
• reduce the upgrade effort from 175 days to 98 days
• complete the project on time and in budget
• deliver a zero defects upgrade

In summary

The DWS Dimension Professional tools enables DWS to:

• Plan the Uplift Workload in the most optimal sequence
• Meet tight delivery timescales on time
• Avoid nasty surprises during the execution phase of the upgrade
• Enable the customer to promote bundles from DV to PY to PD with no issues as Dimension Professional understands all the Dependencies between objects – so our bundles will promote and build without build issues, which could otherwise be a significant problem and time waster on many upgrade projects.

In a nutshell, the tools within Dimension Professional are real gold nuggets and speaking from DWS’s extensive experience, makes the upgrading and retrofitting of objects easier. It also provides a foundation for a focussed and streamlined approach; all contributing to saving time & effort and delivering a standardised methodology.

In this second blog I have addressed executing a JDE EnterpriseOne upgrade and explained how you can deliver your upgrades on time, in budget and with minimal defects by using the DWS Dimension Professional service.

In the third blog I will address the challenges of planning the testing of your upgrade and show you how you can minimize your testing effort by focusing on just what needs testing.

In the fourth blog in this series I will show you how you can automate your testing without the need for expensive technical specialists.

Then in the final one I will address the issues involved in staying code current.

If you would like to register for any of the live webinars that support this series of blogs, or to view any of the event recordings, please use the registration links below.

 

Date Title & Registration
1 January 28th Planning your E1 Upgrade
2 February 11th Executing your E1 upgrade
3 February 24th Planning your E1 Testing
4 March 10th Automating your E1 Testing
5 March 23rd Keeping your E1 code current