During the SAP Teched 2010, SAP has caused some commotion when it gave Java Web Dynpro the so called ‘kiss of death’. Basically, active development on the Java Web Dynpro technology will be stopped and the next edition of NetWeaver will be the last major enhancement for Web Dynpro Java. The implicit message from SAP seems to be: the future of Web Dynpro lies in ABAP.
Since a few years, SAP maintains two branches of UI technology, built on totally different technical foundations: ABAP Web Dynpro and Java Web Dynpro. This situation exists for historical reasons, but for me it always made little sense to build and support the same technology twice in different stacks.
Impact on Netweaver BPM
Now that the dust has settled a bit, what does the ‘death’ of Java Web Dynpro mean for Netweaver BPM technology which is just starting to mature?
First and foremost, Netweaver BPM is – just as the other tools in the Composition Environment – Java based. In the near future (when Java Web Dynpro is no longer the technology of choice) you will create a business process in a Java Stack and then create the user interfaces for that business process in an ABAP stack. This means you will need at least two technology stacks just to execute the core of a business process. This will add unneeded complexity in a solution that already is complex enough.
The situation will become worse when developers reuse existing Web Dynpro applications they have built in ABAP. These existing Web dynpros will live in one of the existing backends of that business process and will have heavy ties with that particular backend system! I’d like to call that spaghetti architecture.
Why SAP made this decision
First of all, SAP has downplayed a lot of the buzz and tells us that Java Web Dynpro is here to stay and will be supported at least up until 2018. Of course, in IT, saying that a technology will not be under active development is saying… well, a lot.
As said before, for me it makes no sense to have two similar technologies in different stacks. Despite the different strategic choices in the past, SAP is still very much tied to its ABAP heritage and is again promoting ABAP as the main platform for a lot of its own development activities. Therefore it seems logical to promote Abap Web Dynpro over Java Web Dynpro.
Beyond Java Web Dynpro
The good news is that – in the long term -SAP is planning to replace the Java Web Dynpro technology by new User Interface toolsets. These promise a lot of things like stateless, flexible and lightweights UI’s. Stuff that Java Web Dynpro currently does not deliver.
Good news for anyone developing User Interfaces with SAP technology, but especially good for SAP Netweaver BPM development. After all, Netweaver BPM is about making SAP business logic available to the casual information worker, somebody who rarely sees SAP screens and needs a light-weight and easy-to-use interface.
My advice for SAP Netweaver BPM development? Stick with Java Web Dynpro as:
- Your User Interfaces are then tightly integrated with the BPM layer and not with the backend layer;
- It is still supported for several years.
… and hope that promises of new UI technology will become reality soon!
Hello World! 
Very informative post, thanks. I’ve worked with Java Web Dynpro for a while now and I must say despite its limitations, it is a good tool for rapid development. So I hope its advantages will be preserved with the new planned technology. However, I disagree a little with your judgement of maintaining the same technology in different stacks. Why shouldn’t be a good technology available in different language environments? A Java developer should be able to enjoy the same pleasures as an ABAP developer. Of course, a language-independent framework would be best – something still to invent, isn’t it?
You’re welcome.
I agree with you that – from a developer point-of-view – having more choices is good. However, from a technology vendor point-of-view it will cost more effort to maintain both frameworks. And when the vendor decides to stop development of one of the brances (Java Web Dynpro in this case), the developer is also at a disadvantage. He/She will have to use a technology that will become obsolete, or need to learn another language to achieve the same result.
Ultimately you are right: a technology indedepent UI framework is even better. I have high hopes that HTML5 will bring us closer to that.
Great blog….I would like to touch base with you about co-blogging in various tech areas….If you are open pl. ping me…SAPMDGCurious@gmail.com