How To Avoid Killing Yourself During a Web Dynpro Java Implementation
I have spent the last 2½ years reviewing customer Web Dynpro Java implementations, and I have noticed that there are a common set of problems that pop-up time and time again. Therefore, to combat these problems, I have created the following two TechEd presentations:
- CE351: How to Build Low TCO Applications in Web Dynpro Java
- CE352: Getting the Best From the Web Dynpro Framework
These two presentations address different aspects of a Web Dynpro Java implementation project.
CE351 approaches the situation from a semi-technical point of view and deals with how problems can be avoided from the management and architectural perspectives.
CE352 however, looks under the hood of Web Dynpro Java development and describes the design principles that should be followed when writing the actual coding.
These two presentations are designed to function as a pair with the combined objective that the attendees go away armed with a solid set of principles and guidelines so that when they start a Web Dynpro implementation, they will not repeat the mistakes of the past.
These presentations are aimed at helping you build Web Dynpro Java applications that have a genuinely reduced TCO. The bottom line is that if you do not follow the principles of good Web Dynpro design during the Design and Build phases, then when the software enters the Maintenance and Enhancement phase, you will find that a large number of hidden costs are suddenly waiting to bite you!
Where did these costs come from?
They were built into the application during the Design and Build phase because developers either:
- Lacked the experience or understanding to avoid them
- Had to work to an aggressive time line that did allow for training and forced people to cut corners
- Or some other factor such as scope creep increased the quantity of software to be delivered, without allow for extra time and/or resources to deliver it
Whatever the reasons, the result is that a Web Dynpro application is produced that is functional, but rapidly becomes a maintenance nightmare!
All of these situations can be avoided if the principles of good Web Dynpro design are understood and implemented. Then when the software enters the Maintenance and Enhancement phase, the amount of time and effort required to make modifications will be significantly reduced.
Because the software was built to follow known design principles: this means that it does not contain any clever workarounds or redundant complexities (spaghetti code) that do little more then add time, effort and money to an enhancement project.
CE351 and CE352 will help you understand how to get the best from Web Dynpro not just to simplify development, but also to remove the hidden costs and nasty surprises that the software can so often throw at you during the Maintenance and Enhancement phase.
So sign up for these presentations, and I’ll see you in Las Vegas or Munich!