I delivered a presentation at the Australian user group the other day (infocus) on a future plan to make JD Edwards upgrades easier… Or was it more simple… Or was it better.. Perhaps all three.
When CNC people get together at the pub, they don’t talk about their families, wife's or girlfriends… They talk about package builds, JDBj timeouts and enterprise servers. They trash talk AS/400’s until the bloke that loves them starts crying and goes back to his shandy… I do however recall one night talking about upgrades and why they are no shipped as ASUs. Honest…
I thought it would be simple enough to ship the update as one massive ESU, or ASU and then clients could apply that nice and easy. We no longer have an exact correlation between tools release and application release, so why not just ship us the ASU and not force us into the DD merges, spec merges, control table merges etc – ESU’s are much easier [I know they still merge, but they do not create ol920, dd920 etc). Or so the psyche tells us.
So it seems that what might be in release with 9.2 is a better way to upgrade.
Everything will still work the same in terms of all of the steps (Doh!), but instead of using the 9.2 central objects as a base, they’ll use your central objects as the base. Okay, so lets think about this… How are they going to know what you’ve modified and hence what to replace… Well, this is where it starts to get funky, they are going to run a manifest of code changes between 9.1 and 9.2, a total list of changed objects. Okay, following me? So then, they are going to determine what of THESE objects your might have had your sticky fingers in and blast some pristine 9.2 code over the top.
Of course this will not take into consideration the ESU’s that you’ve applied, but at the end of the day – this will just mean your mods are closer to 9.2, and that the retrofit will be easier… What’s the less, try and stay code current!
Are you still with me? So this means that instead of blasting over the top of EVERY object that you’ve modified, they are only going to change the ones that have changed between 9.1 and 9.2 [as per the manifest]. This is going to mean less retrofit and this is also going to mean less testing and perhaps less training – because things are not going to change as much.
Wow, that is pretty cool. I’ve never met a CNC person that has ever been concerned about the speed of the R98700 either, and the funny thing about this UBE, is that it generally only gets run once, the first time. You might run it again if you did not have your modifications identified properly when you ran it the first time (not speaking from experience at all there)… So perhaps not quicker upgrade, but quicker upgrade project.
The oracle laboratory tells that this might mean some crazy savings for some clients (95%) and reasonable for others (45%). Save 45% on retrofit, yes please.
This coupled with all of the other nice things that are out there is going to make for a much better upgrade. We must remember that if this makes it to GA, we need to entice our clients with leaner estimates on retrofit and smaller numbers of objects to be affected. So, all we need is the manifest and then we’ll be able to do some sort of impact analysis on this to work out what we want to retrofit. We can then demonstrate downstream savings too, with less change there is less testing, less rework etc.
Please note that this is not GA and I’ll not be held responsible for you entering into contracts on the basis of the information supplied in my blog… haha, my safe harbour statement.
A little picture of the planned change
No comments:
Post a Comment