Web Dynpro Java – Is it SAP’s latest modern legacy technology?
The decline of Web Dynpro Java ( WDJ – Java. Web Dynpro Java – Thats a bit of 007 ) as SAP’s preferred UI technology is well documented. From the Teched in which SAP basically disowned WD Java, we WDJ developers have been fighting hard to keep it alive( That really makes me feel like a soldier 😎 ). I have myself written blogs to enthuse faith in this technology and also retain the belief in its latent potential. However, its time for me to resign to the fact that WD Java could seen be a thing of the past.
Divine Intervention or Internet-inspired intervention: Modern Legacy Systems
During a random internet surf, there was a video on Modern Legacy systems. The presentation basically highlights the importance of a legacy system. It also suggests a change in our attitude towards a legacy system. We are required to appreciate the need and usage of legacy system for in this ever changing world, it does not take long for a system/technology to become legacy. Well, it tingled my SAP love interest – WD Java 😳 .
WDJ is a stable UI technology. Now, even its alternatives by SAP seem more motivated by non-technology factors. So, agreed WDJ may not be used in the new systems but there is no reason for it be replaced in the existing systems. Re-writing the apps may sound simple but they are far more expensive than maintaining the existing ones. Re-writing may not always produce the desired effect and soon that could also become legacy, so why do it? Finally, its about the trade-offs.Is it worth the effort? Does it make life better? and at what cost?
Now, as WDJ developers we have an obligation to leave a good legacy behind. That’s is critical for its survival. Well, my intention is to suggest the we need to retain the necessary unless a suitable/viable/disruptive alternative arrives.
Some pointers to leave a good leavcy:
1. Documentation – Now that’s a surprise!
– We need to document all the aspects of the existing system from the user lists, dependency lists, fail-over/backup plans, system dependencies, architecture diagrams and more. Remember: Code cannot speak for itself. We need to write it down.
2. Tests – Document the tests
– Not just automated unit tests but all possible/probably testing phases to be performed and well-documented.
3. System Design documents
My resolution: Hopefully to leave a good legacy and wish you one too.
My request: Leave a good legacy behind, for legacy is not only about old.
All the best.