Fusion5 has developed specific offerings to
assist clients to firstly, recognise their technical debt reduction
opportunities and secondly, actively reduce them. The reduction of technical debt allows
clients to be more agile and stay code current at a reduced cost.
This white paper explains what technical
debt is, strategies to reduce it – and of course how Fusion5 can help.
Getting your JDE code back to vanilla is
exactly what we’re aiming for.
This is a project that you can take on anytime and dedicate any number of resources to. A project like this is going to save you money - so perfect to take on at a time like now (pandemic).
Not only that, we recommend that our
clients make it their favourite flavour too!
What am I talking about? Keeping your JDE code as vanilla as
possible. Only change standard code if
it’s going to make a strategic difference to your business.
The cost of a modification grows and
grows. If you look at your
modifications, especially if you are modifying core objects – retrofit is going
to continue to cost you money going forward.
This is more apparent when you modify an object that changes often.
Let’s look at those with a free dashboard
we have created:
For example, P42101 has been updated 10
times since 2016. If you have made
modifications to this object, then this is going to cost you 10 x the retrofit
costs. Or at least a factor of the
original costs every time you try to be code current (which is the new normal).
|
Hours
|
Cost
|
|
Original Modifications
|
15
|
$3,000.00
|
|
retrofit after JN12140
|
7
|
$1,400.00
|
|
retrofit after JN15493
|
6
|
$1,200.00
|
|
retrofit after JN16709
|
5
|
$1,000.00
|
|
retrofit after UN3
|
4
|
$800.00
|
|
retrofit after UN4
|
5
|
$1,000.00
|
|
TOTAL
|
42
|
$8,400.00
|
My very simple example above shows that the
original cost of the modification might have been 3K, but the ongoing
maintenance of this has cost an additional 5.4K – nearly double the original
modification cost. These are big round
numbers for illustrative purposes – but you get it.
This is also an inhibitor to change (X
factor or something hard to measure), instead of taking all of the latest changes
– we tend to hold off because of the impact to the business.
The lesson is simple, we need to reduce our
modifications, period.
We like to categorise
modifications in 4 distinct categories.
|
Category
|
Description
|
|
Modify standard
object
|
Any changes to a standard object will
continue to require retrofit. These
are generally identifiable using the C flag in F9861. A more advanced method
is looking into OMW history to ensure that the modification is real. The Super advanced method is comparing
code.
|
|
Copy standard
object
|
If you have created a custom object – R5542565
to do the job of a standard object – this can cost you. The caveat is, will you ever want the new base
functionality in your copied object? You
need to be smart with cat codes to make this decision. If objects are clearly marked as “bespoke –
don’t care about upgrade / update” – this simple annotation is going to save a
lot of money. In general, if you copy a
standard object, this is going to cost money moving forward – as you’ll want to
copy and retrofit again when the base object changes. These are generally identifiable by name (hopefully
a copy of the original), name and system code conflict (if the original system
code was used) and finally looking into OMW logging history.
|
|
Bespoke
with standard hooks
|
It’s yours but it is called by or calls
standard objects… It might read
standard tables and rely on standard inputs.
If these change in an ESU – then there is going to be a roll-on
effect. These are identified by name
and system code (hopefully) and also cross reference for seeing whether there
are standard hooks in and out.
|
|
Bespoke
|
It’s yours and it does not matter what happens
around it – bulletproof! These are identified
by name and system code (hopefully) and also cross reference for seeing whether
there are standard hooks in and out. There
should be no references to standard objects.
|
Once you have categorised your
modifications like this, you can begin to determine which ones need to be kept,
and which ones can be converted to a debt free mod.
A debt free modification
is one that is stored as configuration
(not code). In general,
these are created “on the glass” and
survive updates and upgrades. There have always been
ways of creating configuration-based modifications. Grid formats for example
were a classic way of customising your
environment without making development changes. This type of “citizen
developer” customisation has matured into the
UDO User Defined Objects that we have
today.
We all need to be experts in UDOs to really
take advantage of them. It helps when
developers know when not to write code, and when functional people know when to
engage developers. We recommend training
your team to ensure that they know about UDOs and have the ability to implement
them.
You can get a jump start on learning by
watching some quick videos and then trying things out for yourself.
In terms of converting your modifications
to configuration, unfortunately there are no super easy ways of doing this
analysis – quite often it’s a lot of hard work.
There are a number of techniques to assist you though, which we are
going to cover.
Firstly, your development team should be
able to assist. Start with your changed
objects and work backwards. Really, you
only need to worry about APPL, UBE, NER and BSFNs – as they are going to occupy
90% of your retrofit time.
High level categorisation (as opposed to
knowing or inspecting every object) is super beneficial to understand the scope
of a project to either retrofit or convert to configuration.
There is some help from Oracle.
Tools Release 9.1 Update 2 (TR 9.1.2) introduced two new utilities in an aim to simplify the upgrade and patching
process by reporting on “what’s changed” in your environment. The Customization
Object Analyzer provides summary and detailed level reports on customisations made
to JD Edwards EnterpriseOne objects such as applications, UBEs, business functions
and business views. The Application Configuration Analyzer compares two environments
and reports on the differences in UDCs, Processing Options, and Versions.
The Customization Object Analyzer utility can
be used to list EnterpriseOne objects that have been customized. This information
is then used to determine the impact and level of effort needed to retro-fit the
customizations into a newer application release of JD Edwards EnterpriseOne software.
The Application Configuration Analyzer is a
set of reports which identify differences for processing options, data dictionary
(DD) items, and user defined codes (UDCs) between releases or environments.
Tools Release 9.2.3.3 introduced the JD Edwards EnterpriseOne Decustomizer
Analysis Report which enables you to identify the UI customisations that can
be replaced using the personalisation and extensibility framework.
This document lists the concepts, requirements
and available information on Customization Object Analyzer, Application Configuration
Analyzer and the Decustomizer Analysis Report.
Some additional observations of debt
reduction are below:
|
Sample
modification
|
Technical
debt reduction technique
|
|
Form exits and row exit customisation
|
Form extensions and form personalisation.
|
|
New button or exit
|
You must use the new orchestration
functionality to associate a button to an orchestration.
|
|
Hiding fields / simplification
|
Security for form personalisation. Grids.
|
|
Pre-populating fields
|
Advanced Queries
|
|
Showing additional information from other
JDE screens
|
Cafe1
|
|
Bringing external content to a page
|
Cafe1, orchestrations and form
personalisation.
|
Any modification that you convert to
configuration is going to pay you back double.
You’ll be able to take change more rapidly and you won’t need to worry
so much about mobilizing a development team.
You must understand all configuration options available to you and cross
reference them with your modifications.
When you are into the mechanics of
technical debt reduction, this program is going to be your friend.
This is an often-forgotten gem when it
comes to retrofit, and it does have links to the latest functionality, in that
you can get to the “Object Customizations
Data Load Report” and xref and other functionality quicker. You’ll notice a theme here; this is
exactly how we’ve categorised our modifications earlier.
- Refresh All - calls BSFN to refresh
the F96UCUST data based on the merge modification flag in the F9861 table.
- Load COA Data - launches batch versions
for the Report R9840DL - Object Customizations Data Load Report.
- Launch XRef - will launch the entry
point form of the cross reference application in order that the end user may
gather more information about the currently checked in object.
- Launch OMW - will Launch OMW (P98220)
where more actions can be taken on the object and project as needed.
At Fusion5, this is ground 0 for our
retrofit efforts.
There are two things we do:
1.
Reporting - to let you know
what is possible.
2.
Converting – remove technical
debt and standardise documentation.
We’ve created our turnkey solution that
enables the best results for our clients to visualise their technical
debt. We have developed custom queries
and dashboards over the last 15 years which allow us to understand
modifications intimately and then make specific recommendations to remove them.
We extract data from a series of tables in
JD Edwards and load this into the cloud.
We run custom reports and also load these into the cloud for easy and
interactive reporting. We load up cross
reference too, so the results are complete.
At the end of the exercise you’ll have a
complete macro and micro view of every object in your system and how you can
take these back to vanilla (where possible).
We can even extend this service to work
with you on each modification to understand whether this has been included in
an ESU or ASU, and retirement of the change is easy.
You will feel empowered to see how your
technical debt can be reduced and therefore make you more agile in your
capability to react to change and stay code current.
Just reach
out and ask about our technical debt reduction reporting packages.
These projects can run all of the time in
the background. A technical debt
reduction project can run with a single developer, using the reporting from
step 1 and converting code to configuration.
At the end of the day, everything should continue to work as it
did. The technical and functional specs
are easy, and the test plans are easy – things just need to work – as they did
before.
You can work through objects
methodically. You could select a system
code at a time, which would allow for better ESU application for particular high
traffic modules. The only goal of the
exercise is going through changed objects and taking out the modifications
where possible. And if that’s not
possible, using category codes and documentation to ensure that this IS easy
next time it occurs.
Fusion5 will focus on these affected
objects and ensure that the modifications are as debt free as possible.
Debt reduction programs can be done by
object, or can actually run as an agile project, which would be based upon how
many modifications could be retired in a 1 week sprint, and continue.
The added advantage of this project is that
it will save you money as it runs – it will save more than it costs – some nice
ROI.
Fusion5 has invested heavily in code and
knowledge around reducing their clients’ technical debt. We’ve designed programs to make it easy to
identify and educate our clients on technical debt reduction.
Our capability in this space is sure to
leapfrog your ability to adapt to change, to change quicker and ensure that
change does not cost too much money in JDE.
Our goal is to enable our clients to be on the latest code all of the
time, and take advantage of what Oracle is putting into their product.
If you want to start the code conversion
journey, please get in contact so that we can assist you.
You can download this as a PDF here:
