Technology Stability in a World of Constant Change
Even though I don’t have any responsibility for a user interface product of SAP these days, somehow the whole Web Dynpro Java (WDJ) Kiss of Death for Web Dynpro Java – The Follow-Up Questions debate for some reason does not leave the forefront of my mind. It may be because it raises a lot of questions on a fundamental level, beyond whether the number of features that SAP will continue to invest will be more than sufficient to ensure the viability of WDJ or actually means a slow but steady decline of the technology.
I’ve seen the story of HTML-based user interfaces at SAP from the very beginning (I actually started it), and I’ve also seen the Java story from the very beginning (I’ve certainly been a very strong proponent of it). With me leading the participation of SAP in standards and open source communities, I also have a keen understanding of how community-based development works. So, essentially, I believe I am entitled to an opinion, but I also want to make clear from the beginning, that because of me not having responsibility for SAP’s user interface products, it is just that: An opinion of a member of the SAP community, and not an official standpoint of SAP’s product development or solution organization. I figure that is what the SAP Developer Network is for, and I’m enjoying that I’m permitted to state my opinion just in the same way that I believe Thorsten Franz has stated and is entitled to his opinion in his now
(in?)famous “Kiss of Death” Kiss of Death for Web Dynpro Java – The Follow-Up Questions.
It would be nice if discussions like these would be about the facts only, but in reality, due to the way the court of public opinion works, it quickly also raises questions that had at first not even been asked, like for example whether the question of the viability of WDJ as a strategic technology is also a question about the viability of Java at SAP. I will get to this.
Flashback to 1999: SAP was under intense pressure to open itself up to the Internet. With technologies like the SAP Internet Transaction Server we managed to build a convenient bridge between SAP’s entrenched ABAP and Dynpro technologies and the Web. But obviously the user interaction model that ITS was able to expose was firmly tied to the programming model supported by the backend; it did not have frontend logic. Experiments such as Flow Logic were too limited, and given the strong presence of Java on the market and its promise of innovations developed by a huge community it did not seem prudent to continue to invest in proprietary SAP technologies. That the SAP’s server technology team managed to integrate an Apache-based Web Sever tightly into the SAP client-server environment and created BSP similar to Java Server Pages (JSP) was a triumph of its incredible engineering skills, but even that success would not change the overall strategic risk that SAP would decouple itself from outside community innovations and always continue to chase after the state of the art with proprietary technologies.
So, I continue to believe it was the right decision to invest in Java user interface technologies, invest in alternative programming models that would move more power to a dedicated frontend system, away from the backend business transaction systems. And it was certainly important to break away from the limits of the Dynpro, however useful it has been for many years and still is for developing SAP’s transactional applications which are the mainstay of the ERP business. Hindsight is always easy, and even though some people today say WDJ was a mistake, I don’t think many back then questioned the decision to develop such model primarily in Java, and then pull behind with an ABAP implementation (WDA). The idea of one model, comparable to the amazing simplicity of the Dynpro, able to execute it in multiple environments, was good architecture and marvelous engineering.
But then I believe we made mistakes. First of all, the promise of community-based innovations did not pan out the way it would be. The Java community and the Java Community Process moved slowly, and were stuck way too long with technologies that were designed by committee and not by the rigorous demands of utilizing technologies to develop applications. As one example, the painful Enterprise Java Beans (EJB) story continues to torment the community. With its strong focus and energy expended on server-based foundational technologies, there was limited interest in UI technologies within the JCP. Java Server Pages (JSP) and Tag Libraries appeared, but there is just a vast difference between general purpose technologies and technologies that can be used to develop form-based applications that fulfill SAP Product Standards (e.g. Accessibility).
So, we had a difficult situation: Progress in community-based development was slow, SAP willingness to contribute and influence the community with its own technologies was limited, and even if we would, I’m not even sure whether we would have been successful. It is just a fact that WDJ is very SAP-specific. Essentially, we implicitly made the decision to develop *in* Java, but not within the Java Community, which may not have accepted our specific requirements anyway. But honestly, we also did not try hard enough. As such, our use of Java was focused on achieving the same type of development productivity as in ABAP, with similar capabilities like in ABAP, but developed in Java.
The second mistake was our insistence on purely model-driven programming models, where every developer knows that an isolated model-driven universe without a way to break out into the world of coding is futile. The divergence of Visual Composer and Eclipse development environment is just one consequence of this decision, even though we have taken steps to remedy the situation.
SAP effectively made a decision for speed of innovation, utilizing whatever was useful from a community that was perceived to have high speed of innovation, yet not in the specific areas that SAP was interested in. In the meantime, Total Cost of Ownership and simplicity of development became more important, and the speed of innovation necessarily decreased as the Web Dynpro model matured. This led to a stronger focus on WDA, which is good.
Suddenly – which must have been around 2006 – the speed of innovation in the HTML and Internet based user interface arena dramatically picked up. AJAX, PHP, Dojo, GWT are just same examples. This was just a stark reversal of what happened before in community-based development, even though many technologies were perhaps tied to the Java Virtual machine as a runtime environment, but not developed in Java. How this happened is interesting. First, it was the emergence of open source as a way for community-based development and fast adoption. Then, the increased power of browsers, ubiquitous Internet speed and wireless technologies led to massively adopted Social Networks and Software-as-a-Service applications whose key differentiator is their easy-to-use human interfaces.
With large parts of the Enterprise Java Community moving to open source (think: SpringSource, Glassfish, Eclipse), the slow committee-based Java Community Process also became less relevant for these fast-moving technologies where Darwinian evolution simply overruled consensus-based processes that are still essential in foundational Java infrastructure technologies. There, you want compatibility. When it comes to user interface, you want speed of innovation, and natural selection when users are voting with their feet whether they prefer one technology over the other.
So, what the heck does this mean for the current debate of whether WDJ received the “Kiss of Death”? My point is that SAP users have to become comfortable with a fast evolution of technologies in the user interface realm. It’s good for them, because it guarantees that they can benefit from the speed of innovation and survival of the best technology not only within the SAP ecosystem, but within the world-wide Internet community. For example, the development of HTML 5 is backed by the world’s leading companies, and if you carefully monitored the press in the last week, the momentum behind HTML 5 just has gotten a whole lot bigger. And the best technology should be just good enough for SAP customers, and particularly for the users of our systems.
But this is also a scary proposition: Change is a constant. Natural selection overrules eternal stability. But it’s not a contradiction for us: SAP guarantees our customers rock-solid technologies and delivers Timeless Software when it comes to the execution of their business processes. But when it comes to user interface technologies, and for that matter also openness in consuming our services, we have to be agile and nimble. Technologies like SAP Gateway are fully based on REST, which provides a subset of the capabilities that WS* delivers with regards to security and reliable messaging over the Internet, but it’s just more practical with the use cases for easy consumption of services that SAP wants to support.
So, I would assert that with SAP always providing a stable core, change in some areas is good. But what does this mean for technologies like WDJ ? Thorsten Franz believes that being stagnant means a slow of decline, which he – even for my taste – called a bit overdramatic the “Kiss of Death”. But Thorsten is entitled to his opinion, and honestly, if he hadn’t done so, we wouldn’t perhaps have such fruitful dialogue. Being controversial in a Democracy is good, and an open ecosystem needs the open exchange of ideas as its lifeblood.
My response to Thorsten would be this: Would it really make sense to continue to evolve WDJ just like it was originally envisioned, and give customers the guarantee that the applications that they have once developed with what used to be the best model at that time would run forever? I would assert that this would be a similar “Kiss of Death” to those applications, because its user interface models won’t keep up with what in the meantime has become best practice that those users expect. I believe new technologies will continue to emerge, and for the sake of their users, applications developed by SAP customers with technologies provided by SAP should adopt as opposed to shy away from change.
Just about how we expect customers to transition to new technologies is perhaps the answer where we still owe specifics, and that is I think exactly what prompted this debate in the first place. Of course SAP will make sure that there is a clear migration path, and if we don’t provide good enough answer, the SAP community is exactly the place to discuss those shortcomings. Let’s just be clear about one thing: WDJ is not just a monolithic piece of technology; it’s a set of principles how customers can be develop forms-based system that comply with SAP Product Standards. And when it comes to preserving these capabilities, SAP has learned its lesson. We will no longer put a SAP technology *next* to the accomplishments of the community in a SAP silo, but will make sure that it integrates well *with* the community. There is no reason why an application that uses Java Server Faces (JSF) could not make use of the rending capabilities that were originally developed for WDJ.
But again, I do believe we owe specifics. Yes, it’s true that Web user interfaces have become much more stateless, and that rendering and even application logic has moved from the server to the client. The use of JSON in Dojo and jQuery has become a new state-of-the art programming model. With its REST support, there is no reason why SAP Gateway wouldn’t be able to replace the RFC connection pooling that is supported in WDJ. But exactly how is what users of WDJ want to know, and I’m looking forward to continuing this dialogue and peel the onion to the next layer of specificity. I know that Thorsten and other SAP customers are not afraid of change, but they want to know how, and understand the roadmap. After having spent time with Thorsten on the phone, that is what I believe is exactly his concern: If WDJ would really be a static piece of technology, incremental feature requests in light of the massive innovations that are still happening in the community would likely mean a slow but steady decline. But with a clear migration plan in place, SAP customers can embrace change and deliver the very best technologies to their users and don’t have to forgo the qualities that WDJ provides in terms of support of SAP Product Standards and a secure and reliable consumption of data and processes from the stable core.
And a final point: I think I have made the case why SAP is committed to engage with the community. When it comes to community-based development, Java is an essential part of the development landscape. Honestly, it is ludicrous to believe that SAP could stop the use of Java. Yes, for TCO considerations as well as simplicity of development, we concluded that for users interfaces developed in the SAP Business Suite, WDA is the primary technology. But this does not mean that we give up on Java altogether. Java is an essential part of SAP’s strategy, and vast parts of SAP technology platform are in fact developed in Java. The Java Virtual Machine is a core runtime component of the SAP technology platform, but it is also true that for development of user interfaces Java is just one option, but not the only technology. For anybody following closely how modern architectures of Internet-based applications look like, that can hardly be a surprise.
What is equally important is that SAP won’t deliver a sort of “SAP Java”, but will critically depend on the community for its Java strategy. This means utilize particularly open source and standard based software assets such as OSGi, Equinox and Virgo (see the recent Eclipse press release) as well as community-based development models such as GIT.
And when it comes to Java governance, it’s still pretty much business-as-usual for SAP. We continue to be a member of the Java Executive Committee, and despite a lot of noise about how the Java Community Process will evolve in the future, let’s not lose sight that all that the JCP aims to standardize are core infrastructure technologies where compatibility is of critical importance. The majority of technologies that we have talked about here are instead developed in other communities like Eclipse, the Dojo Foundation or available through open source licenses. That we can’t take the eye off the ball regarding the risks of a Java Community dominated by only a few players should be self-evident as well.
Of course, we could now also discuss what role open source could play in the evolution of WDJ just like Benny Schaich-Lebek has suggested, but I better leave this for a separate blog. For now, I’m looking forward to your feedback.
Also, I'm happy to see the discussion coming back to UI and not about Java in general: WDJ is only a small part of Java within SAP!
Loong, but great blog!
Michael this blog serves as the model to me of how someone inside of SAP can deal with a controversial topic and actually join in and advance the conversation in ways that are inclusive and forward-thinking. And without defensiveness, expecting rigor and reflection on all sides. I look forward to seeing where this conversation leads.
Really great post and now continued discussion.
Love that kind of engagement.
One reason for this comment is, that I don't want to miss any of the conversation and at the moment you must comment to have the chance to subscribe to a post.
Nevertheless thanks so much for posting Michael, Mark.
P.S. I created an Idea Place suggestion to enable subscription without commenting. Please support that idea: https://ideas.sap.com/ideas/1778
P.P.S. If you are at the idea place, you may want to check out and support my other idea of outlook contact support in the SCN Business Card: https://ideas.sap.com/ideas/1733
Very quick feedback (as I'm busy herding the kids): brilliant blog with lots of food for thought. You have managed to thoroughly capture the many complex dimensions of the topic, provided a wealth of additional context, and, with a few light strokes of the brush, covered the points that I was going to blog about weightily in my response. 😉
For now, you've said it all.
Thank you for this excellent blog. Besides a good fresh and elaborate view on the "Kiss of death" discussion, it was also very interesting to read the flashbacks.
With regards to SAP calling WDJ mature, I also believe that a technology that is stagnant means that it will slowly decline. And if a technology is stagnant for good reasons, e.g. because it simply doesn’t have a future, I would be the last to object.
The thing that I'm still worried about is the investments that customers have made in WDJ applications. It's easy to say that applications developed by SAP customers with technologies provided by SAP should adopt as opposed to shy away from change. However, SAP once promised its customers that web dynpro would 'future proof' their UI investment. I do agree with you, that it may not be easy to keep this promise because WDJ user-interface models won't keep up with what in the meantime has become best practice that those users expect. On the other hand, I don't think customers will easily understand how SAP can just give the "Kiss of Death" to applications that they have sometimes heavily invested in.
If WDJ is really a mature, stagnant or even dead technology and SAP is shifting away from WDJ to the greener pastures of newer HTML5 based technologies, it would be good if SAP would at least show some consideration about investment customers have made in its communication. Of course, it would be really brilliant, if SAP would keep its 'future proof' promise and release a migrator, that allows customers to bring their WDJ applications to these greener pastures of latest and greatest technologies as well.
I'm convinced that there is more between showing compassion and a one-click migration tool, but hope that SAP will at least think about the investments customers have made and will try its best to safe-guard them.
as we have said in multiple places, WDJ is not going away. No customer needs to be afraid of anything, and let's face it that the great world of HTML5, jQuery and Dojo hasn't quite arrived either. Lots of investments happen in new UI technologies, let it be Streamwork, uPods or River applications like Carbon Impact. I think it's wonderful that SAP is pushing the limits, but this is not the point to worry that WDJ is going away and will no longer be supported.
But whether it makes sense to push all of the new paradigm that is beginning to emerge on a technology that was also by now conceived several years back, is is one of the core questions I was trying to convey in my blog. Change is a constant.
I do agree that SAP needs to be more forthright with its migration plan. Just to say "we'll fix the bugs, if there are any" is not the right way, and I also don't think anybody said that. What was said, as far as I can retrace JonERP's video blog is that for now investments are taken to explore a newly emerging paradigm of stateless UIs and taking advantages of a lot of the community-based innovations that have appeared on the scene lately.
How exactly a transition will take place into whatever new paradigm will appear is something that needs to be discussed. I know, a "migration tool" is always a nice idea, but if really a paradigm shift is happening, such migration tool may have limited effectiveness.
But again, I don't think this great new world is just quite there yet. Let's explore together where we go next. I, for my part, have started to seriously look into HTML 5 standardization, and understanding the different point of views that the standard is influenced by. It's a whole new world out there; there is no longer just one browser, there are many equivalent browsers, and users are consuming much more over a mobile device. It's pretty exciting stuff. I can't remember the last time so many things have happened at the same time in this industry, so it's a great time to be a technologist.
this is without doubt one of the best blogs I have ever seen published on SCN. Congratulations!
The depth and breadth of thinking you have captured in this document is amazing. I only wish I could so eloquently convert my thoughts into words in the concise way you have.
Also let me recognise another example of the "New SAP". While the old SAP may have allowed an employee to engage in this open, honest and public way with the community IMHO the employees of the old SAP would have been reluctant to do so.
SAP is changing in amazing and wonderful ways. I have mentioned before that I first detected real evidence of this change at SAP TechEd 09 and I believe the momentum for fundamental cultural change inside SAP continues to build.
My admiration for the way that you continue to engage and lead SAP Community discussions has been enhanced yet again. Like Jon I am looking forward to following this conversation to see where it leads.
Firstly, I want to thank you for taking the time to share your thoughts with the community. This is one of the most interesting blogs that I have read and your efforts to write it are appreciated.
On the topic of Web Dynpro in general, I now wonder about the future of WDA. I understand that WDA is not supported for mobile clients (and yes I know WDJ had some limited support) and to my understanding there is nothing in the roadmap for it to do so. At the same time we see SAP spending significant dollars to acquire Sybase, project Phoenix focussing on HTML5/JQuery, and the introduction of Gateway. I don't think SAP's messages about WDA 'future proofing' the UI investment (similar to the words used for WDJ) apply so strongly as they did. In a sense it feels like the proprietary WDA model can't be developed quickly enough to fulfill the strategic need for a cross-client mobility platform, hence the acquisition of Sybase. At the same time the introduction of Gateway feels like SAP is to some degree relinquishing control of the UI technology, so anybody (eg. iPhone / Android developers) can take advantage of lightweight RESTful services exposed by SAP applications. And if we consider that in the years to come, more people might be connecting to corporate systems via mobile clients than desktops (if Gartner's predictions are correct), then WDA may well become the lesser-used UI technology in the SAP ecosystem, without even discussing WDJ.
Obviously this is just me ranting. Thanks again for your excellent blog.
But think about mobile: The user drives, and an application, network and language boundary is unavoidable. Sure, we could go back to simply render whatever the application server produces in HTML, but I doubt very much that this is what a mobile user these days wants to see. That does not mean that there aren't use cases like this, but I think the majority of mobile apps will look different.
And for that matter, also the majority of collaborative applications (like Streamwork) will be different. It's a simple fact: While technically possible, not in a million years would I want to build Streamwork in ABAP. Streamwork is not about form-oriented transactional ERP applications. It may need to integrate with them, but I can't imagine building the Streamwork framework in ABAP. That's me, simply because we would need to reinvent a lot of the UI tools that already exist in language like Ruby or PHP. Right now, it's a matter of speed of innovation and we should make use of these things. That maybe in a distance future somebody will say that for pure TCO considerations we should move what used to be Ruby code back into ABAP is possible, but I don't see it right now.
I touched upon this in my blog: The reason why we started with Java was an attempt to move more frontend logic outside of the core ABAP application server. I still think this is strategically the right approach, particularely for new, different applications. Whether Java the language is right for that is a different question (Streamwork is built in Ruby). Java in this case may be used for the overall infrastructure, kind of like the Cloud operating system, the lightweight servers etc, but maybe not as a application language. But in any case, UI logic is moved outside of the ABAP server, because it's not the ERP transaction logic that drives, it is the user.
So, different use cases, different technical solutions.
Thanks for your response to my comments. Actually your response is consistent with my views, although I would never have been able to articulate it so well!
I would reiterate Graham Robinson's comment ... "this is without doubt one of the best blogs I have ever seen published on SCN".
Due to the features of the ABAP stack, SAP has a competitive advantage with it's competitors due to the potential simplicity available for smaller customers. That said, they also provide a feature set rich enough for any size company if they so choose. The trick is keeping the simplicity which is predominantly ABAP stack (basis) and code (developer) based as a minimum capability requirement as rightly or wrongly, practically the whole JAVA platform for composition and UI is much more comfortable in software houses or boutique consulting companies rather than within customers even after it being several years since it was introduced as a platform by SAP.
And coming back to Change...predicting accurately more than 5 years into the future is practically impossible so the aim to open up and be flexible with UI is definitely something to build into the core which hopefully Gateway will deliver upon.
In terms of WDJ and the "kiss of death", for customers this has been dying for a few years already in my mind (as a solution architect, there are only a handful of use-cases I would recommend this for). It's the fringe solutions we need to come up with an answer for now going forward and similar to what you say - listening to the community while providing well thought out direction will be key.
while I see where you're coming from I feel obliged to object. For the last couple of years I've done little else than to implement Composite Applications for customers and I see that we are even gaining momentum now with the 7.20 release. The numbers back me up on this...
One of the main problems that I see is that the entire Composition idea was meant as something to introduce at the same time as heading towards an SOA. The additional resource costs are meant to be shared within a company and not be charged to an individual project or LoB. For many reasons (mostly out of SAP's influence) this is still ongoing...
Concerning WDJ... it's been our UI technologie of choice within Custom Development for quite some time now and I would agree to Yariv's statement that it has reached a level of matureness. I see a big variety of usecases/scenarios where it is well-suited. OK, it may not be as slick/sexy as other UI technologies, but custom CSSs can do miracles here.
For me, the entire discussion is about whether or not it would make sense to try to squeeze all the new requirements we see in regards to UI technologies into/on-top of WDJ.
HTML5 seems to be the next standard of choice for the vast majority within IT. So, isn't it a good thing that SAP is out to embrace it as well? What about all that RESTful requirements?
Personally I think it's a good idea to provide complimentary technologies instead of trying (and probably failing) to create that uber-UI that does it all (and little right.)
To wrap it up... I'm completly with you on your last line - "listening to the community while providing well thought out direction will be key." Amen! ... and here I believe that SAP has shown in the past that we got that down! Or to quote a famous saying "It's not your father's SAP anymore!"
Let me paint a different picture and talk about a few key customer issues to explain why customers (and outsourcers) have trouble with WDJ in general within SAP (remembering I did say it was appropriate for composition for boutique or innovative teams like SAP Custom Development which possibly falls into both categories - that it is appropriate)...
Yes - Basically my argument is when you don't have JAVA, selecting it is a big deal. If you have it, and your committed to JAVA development, much, much less of a big deal and still appropriate for some time yet.
And don't get me wrong - In terms of UI, I'm happy to design with and use WDJ, WDA, Dynpro, .NET, BO, HTML5 or whatever tool fits the problem at hand but I typically look at the customer capabilities as a mandatory assessment. Also, a lot of this comes down to skills and I'm very passionate about up-skilling all SAP developers and basis so they understanding their whole tool kit available to them (including how to use it properly).
So what are the issues with WDJ that would make me think hard before I recommend it to anyone. Let's just discuss the JAVA issue first...
Understanding the SLD (they have to get it right to a degree with PI installed at least).
This leads me to NWDI which even having PI installed doesn't mean they use it (it's at least been blogged about how to do this a couple of years ago now). Side note - I'd be interested to see how many Portal implementations there are out there without an NWDI code repository (or any source code version tracking repository for that matter).
Expertise in patching of JAVA stacks (when it goes wrong you need the right "dude").
Basis people understanding SSO, trusted systems, garbage collection and tuning (it's getting better now days, but still an issue).
JAVA skills beyond rudimentary - I mentioned I was impressed with your presentation at TechEd, and if you look at the turn-out, it highlights something quite concerning that if you were a software development house and didn't know about these things...A lot of customer developers attend TechEd too as a point.
So many organisations have WDJ people who don't know ABAP (just like PI people who don't know iDocs/ABAP) and this really taints the decision also. Splitting UI at a developer level without really good separation of concerns is tough.
In terms of the actual WDJ - No real issue with the actual tool, but I've come across few custom composite applications so far in my life which don't rely heavily on one source of back-end data (within ABAP). It's a narrow view, and I'd love to hear more about composition scenarios just to see if I can challenge the architecture or to simplify the support costs.
For true composite applications that are spread out - absolutely, go for the solid background of CE. If developing BPM and need UI's for other systems, go for it...Mobile Web Dynpro - Use the Super Generic Mobile App 🙂 but prior to that - go for it.
For reference, I more recently have come from a governance background which means I get to see how people implement these things and what I can say is unfortunately, I haven't had the pleasure of seeing much code from SAP Custom Development.
I've probably missed your point, but I've had a hectic and tiring family day today so that's my excuse! In terms of the numbers you paint...As long as we're solving the problem with the right set of tools - I'm all for it, but for example, I remember consultants coming in selling SOA to address all their needs, building a whole service enabled process from a single back-end system for no benefit. It was a SAP SOA division of the consulting company who struggled to get clients so that went in to find custom work to use their skill set. Very sad.
ps. Feel free to point out a few customer success stories as the more knowledge I have - the better informed I will be in my statements in regards to customers.
Reading your reply though I feel that we are actually on the same page. It all depends on the customer and his resources/expertise and IT landscape. That's what I was targeting at when I said that the entire Composition idea is something that needs to properly setup across an entire organisation.
Yes, technologies like NWDI or PI (or any other ESB in that matter) require an investment. I'm positive that it pays off in the long run (sustainability) and I guess that's why (paired with the economic crisis in the past) resulted in the fact that adoptation is still ongoing.
For me it somewhat also falls into the discussion about what the EnterpriseGeeks refered to as the "Downhill developer" - software development is a craft, that needs to be properly learned. Even more so true for enterprise software. People need to understand the big picture and that takes time...
Now, with all those MDA tools I think lots of management executives still have that fancy idea that a trained monkey can "click&relate" enterprise software weaving together the most complex processes from multiple systems ... FAIL!
So, yes... I'm with you actually. If the customer has no expertise/resources in a particular technologie and does not want or can invest, it would make little sense to use them.
But that's what I like about SOA and CE. "Think big, start small!" CE ships with a full-fledged Java server and an Eclipse-based UI. You can use OpenSource to adjust/complement it to/with your resources and knowledge both for runtime/designtime.
But we are drifting from the original topic here...
PS: About source code from Custom Development... stay tuned, we are working on getting some out for everyone to see & play around with via CodeExchange.
I think we are all in about the same place, but I just wanted to add something else.
Firstly, Matt (H that is 🙂 ) - I totally see your point on bringing Java into a non Java environment. The unfortunate thing
about this is that without a Java or CE Instance, innovation and its associated business improvements will be limited
based on the existing ABAP installation (lets say 4.7). On a side note, and I know it's something you and I discussed alot,
what happened to the idea of the "Sidecar" ABAP stack (say 7 Ehp1). This would fit well with an ABAP only development team
(although a certain level of upskilling is needed, but atleast were talking the same language). It sounds like this is the model
that Gateway is based on.
Anyway, the point I wanted to make was that even though there is a Technical Skills barrier to getting a CE into a legacy SAP Environment,
and you mentioned many of the issues (to the point that I thought you were channeling A. A. Milne's Eeyore at one stage 😉 ), if done
the right way, there will also be a tangable business benefit. For this I point you to the "Alignment Trap"
(http://sloanreview.mit.edu/the-magazine/articles/2007/fall/49102/avoiding-the-alignment-trap-in-it/?type=x&reprint=49102), which discusses
the contribution of an IT team to a Business based on their Efficiency and their Business Alignment.
The Alignment Trap basically states that an IT department can contribute more to an Organisation by being more Efficent, which is counter
intuitive, as most would assume that the IT Department should be Business Alligned. Of course, the ideal situation is to be very good at
both - and the Alignment Trap discusses how to get to this quadrant.
Anyway, and this is the bit I think we all agree on, we want Developers to be better at their Craft, and I would say that by challenging
them with new Tools and Skill Requirements is one way to improve their Craft and Efficiency.
So, I guess the way I see it, is that by getting tools like CE into an organisation will effectively improve the efficency of the IT Department
and in doing so make their contribution to the Organisation much more valuable.
It's just a matter of convincing the Customer that this is the case 😉
I am a supporter of the "sidecar" ABAP system concept. In fact I use it in several of my customers.
In most cases it started because the customer was on say 4.6C and wanted me to build ICF-based solutions such as BSP, SMTP gateways, etc.
But since then we have found that having an ABAP stack that we can push to as current a release as possible without having to consider the constraints the ERP system imposes has been very beneficial. It means I can drive innovation on this platform without having to impact the stable backend ERP system - somewhat a familiar theme these days.
I agree with what you said here:
>>> For me, the entire discussion is about whether or not it would make sense to try to squeeze all the new requirements we see in regards to UI technologies into/on-top of WDJ. <<<<br/>
Exactly. A paradigm shift is happening, if we want this or not. It's better that SAP invests, for the sake of keeping up to date with the latest UI technologies. But if this paradigm shift is real, what technologies should move into/on-top of WDJ should be the real subject of this dialogue.
I don't think assurances like "WDJ will not go away" and to prove it to say "we've added the following 3 features" will cut it. We need a real dialogue, discussing the very nature of that paradigm shift, and then exploring together what makes sense.
As I said many times as a disclaimer, I don't speak for the UI team. I'm at best an influencer and stakeholder, even though I believe I have good experience to be entitled to an opinion. What I will do from my side is to seriously explore HTML 5, and also better understand how today's Internet technologies are built. Facebook is using a PHP/Java combination, and there UI, also on mobile clients, is a major asset. We need to learn from the SAP community, the standards and open source community and also our industry peers.
Having worked with web based interfaces to SAP since early 1997 (I taught the first ITS training course in Walldorf in January of that year), and specialised in Web Dynpro Java since late 2002, I believe I am in a good position to offer my comments and observations.
As Michael also mentioned, neither of us are in a position of responsibility for product management or solution development, so the comments I offer here are simply those of a community member that has been deeply involved in SAP's use of the Web since, well... day 2 in my case (I wasn't quite there on day 1).
Firstly, I must say that although I objected to what I thought was a sensationalist or "tabloid style" headline, I thought Thorsten raised valid points that require answers (not funeral arrangements). Also, Thorsten, I would encourage you by pointing you to a quote from General Patton: "If everyone is thinking the same, then someone isn't thinking". 🙂
Secondly, I think Michael has written a well balanced reply that looks at the situation from a holistic perspective.
What I would like to add to the discussion is centred more around making sure that customer/partner expectation of WD Java capabilities is objective and reasonable.
Let me start from the beginning...
When WDJ was first developed, the original design concept was to produce a web development toolset that could create an abstract representation of your application's user interface, and then from that abstract description, generate coding in either ABAP or Java.
As SAP saw things at the time, the requirement here was, as much as possible, to reduce the disproportionately large number of hours developers had to spend developing frontend coding, when really the focus of their attention should be on the functionality of the business process.
The coding required to visualise the data used by the business process was viewed as "plumbing code" and was considered a distraction from the developer's primary focus. Consequently, the main drive of Web Dynpro was to create a development framework in which the visualisation of data was as close to automatic as possible.
As the development of this toolset began to take shape, it rapidly became clear that it would be much simpler to create two, language specific versions of the toolset, rather than a single, language neutral toolset.
This initial design and build took place back in 2002/2003.
There are two critical factors to add into the mix at this point:
1) At this point in time, the ABAP kernel could not yet accept direct HTTP connections. Therefore, an internal project was started which allowed an external program to open an HTTP connection and then exchange XML documents with the server. This project provided the technical foundation upon which the Internet Connectivity Framework was then built. This in turn provided the foundation for ABAP Business Server Pages.
2) Web Dynpro was developed just as a profound technological change was starting in the Web; one that fundamentally changed the way HTTP based clients interacted with web servers - namely asynchronous updates (I.E. AJAX). The problem here was that the existing AJAX technology (as it stood back then), was not sufficiently mature or capable to provide SAP with the required functionality. So the decision was taken not to use existing technology, but to create our own framework. Due to the fact that AJAX style technologies were rudimentary when WD was first designed, Web Dynpro headed down a design road that did not easily allow the future incorporation of asynchronous updates. In other words, the resulting framework was still rooted in the "synchronous update" school of thought.
Combine these two factors together and we end up with a toolset that provided SAP developers with the ability to rapidly create business applications that had a common look and feel.
The fundamental priority here was the rapid development of business applications and the visual appearance was considered to be something that should be standardised. This is because SAP needed to produce a common look and feel for all its business applications; therefore, it made sense to remove UI flexibility in order to achieve this goal.
With the benefit of hindsight, I believe the mistake we made here was to think that if we developed a toolset that met all our own internal development priorities, that that toolset would also therefore be useful/acceptable to our customers. The problem here is that (in my opinion), we did not fully appreciate the full range of customer requirements in the area of UI design - we were still completely focused on server-side, business processing.
Another consequence of the original design decisions is that we must life with is a user interface in which there is no possibility to create, or even extend, a UI element.
Is this a bad thing? Well the answer to that question depends entirely on your expectation of what WD Java should deliver.
In the 15 that I've worked at SAP, it is my observation that customer requirements for UI design fall someone along fairly smoothly varying spectrum.
On one side of the spectrum (let's arbitrarily call it the left hand side), there are the customers who are focused entirely on the business functionality and the ease with which the user can perform their business task. For these customers, the fact they cannot create their own UI elements or have total, pixel-perfect control over the screen layout, is of little or no consequence to them. Their focus is function over form.
No go to the right-hand end of this spectrum, and you have the companies where brand image is paramount. For instance, I went to one customer in London that was having problems with WD Java, and as I entered their offices, it became very clear that the marketing department ran the whole company - everything was in corporate colours; the walls, the carpet, the uniform worn by the staff on reception, even the office furniture toned in with the colour scheme.
For this customer, the function of the software was taken for granted, and they were now concerned at achieving the required form - to the point that they were more willing to spend a large amount of extra money simply to achieve the required corporate look and feel on their intranet, than to accept the fact that WD Java had limitations.
These examples define the opposite ends of a spectrum of requirements that, as far as I have observed, can be quantified on how a customer balances and prioritises form and function.
One of the key points here is expectation management.
If customers go into a web implementation with the tacit assumption that "all decent web development toolsets provide you with 100% flexibility in the UI", then Web Dynpro will be a big disappointment. But I would argue that this expectation is not entirely reasonable. Please don't confuse something that fails to meet your expectations with something that is bad - the two are not the same.
So in summary, I would urge people firstly to step back and look at the whole spectrum of UI requirements and then to say "Where do I fit in along this spectrum". To answer this question, consider how you balance and prioritise form and function.
Secondly, Web Dynpro Java is a useful and very powerful toolset for those customers that are less concerned about form than they are about function (In other words, customers over towards the left hand end of the form/function spectrum). For these customers, WD Java will help them develop robust business applications that do exactly what it says on the tin.
However, for those customers that assume Web Dynpro's functionality to be a given, and want a high degree of fine tuning, then I would suggest that perhaps WD Java is not the best toolset for you to use. In this situation, I would recommend that you seriously consider adding the REST enablement plug-in to your ABAP system and then use the web development toolset that you feel will give you the best results, with the lowest TCO.
I trust this explanation adds perspective to the whole question of "should I use WD Java?"
Hopefully this will make it into the featured blog list on sdn intro page.
I cannot add value to the discussion about UI-technology, but would like to move the focus to something more general and parallel: The "SAP way of Java Development".
There is a large sophisticated toolset that many customers are using and have invested in - among other things to develop WDJ:
* NetWeaver Development Infrastructure (NWDI) with e.g. the SAP proprietary version control system called DTR (very "mature"! 🙂 )
* SAP proprietary development process, e.g. no tagging in DTR, tracks=the SAP way of branching, CBS=automatic build without Continous Integration
* SAP proprietary component model (SCs, DCs) and dependency mananagement (Public Parts)
* SAP proprietary build process (velocity macros) independent of Eclipse build
As far I can read in old blogs, this toolset was invented around the time WDJ was born and my impression is it has reached "maturity" - freeze of features - some years ago.
As Michael Bechauf writes in the original blog:
> The second mistake was our insistence on
> purely model-driven programming models,
> where every developer knows that an isolated
> model-driven universe without a way
> to break out into the world of coding
> is futile.
This seems valid for the Java development toolset, too: It is a "universe" that is difficult (and not supported by SAP) to break out towards current Java best practices like CI, current version control systems like svn and (e)git, to sum up: it is very difficult to use this "universe" to run a standard agile Java development process.
This is even more interesting in combination with WDJ: There are few types of DCs that cannot be "normal" Eclipse projects, WDJ, VC and BPM are the most important of these (in NWDS 7.20). So if WDJ (and VC) should fade away one day, there is one reason less to use DCs instead of e.g. maven managed Eclipse projects, thus to leave the component model towards something common in the Java world.
On the other hand, SAP contributed (or still contributes?) to maven. And, while there is good support for NWDI in the forum, SAP does (did?) rarely or not use NWDI in their own Java development (e.g. Java NetWeaver).
What else does SAP do since last year concerning development infrastructure? One example:
"The Eclipse Git Team Provider (EGit) project was co-initiated by SAP to drive the evolution of a modern distributed version control system boosting development productivity with easier Eclipse integration and higher performance at reduced total cost of ownership."
Against the background of this, it would be helpful and maybe prevent wrong invest to know the strategy of the toolset for java development tools in SAP. What is SAP's recommendation for customers that are starting or just started with java development on SAP NetWeaver in 2010? What is the left and the right end of the spectrum to take Chris Wealey's words? Sure this topic is not as "hip" as WDJ compared to HTML5, but java developers are concerned today.
P.S. What do others do with mature UI technology? Oracle again for the n-th time extended normal support for their UI-technology "oracle forms" until 2017.
the comparison between NWDI and WDJ on the one side, and GIT/Maven/Hudson and HTML5 on the other is interesting because it shows one important principle: That eventually community-developed software becomes robust, and rather than putting a parallel SAP Java Universe next to community-developed code, it makes more sense for SAP to influence the community early, and integrate whenever robust results are available that meet SAP requirements.
However, in both areas (UI and version control) solutions were shipped by SAP at a time when no community-developed equivalent was even remotely in sight that met our requirements. Yet the speed with which the community has developed software has dramatically picked up. This obviously must have consequences for SAP design, and is exactly the paradigm shift that has happened in the last couple of years.
We can't completely eliviate the fact that parallel solutions are being developed in the community that are functionality at least similar. To ignore those, would mean for SAP to build a SAP Java Fortress, a SAP Java parallel universe, which is not what we want to do. Contribute early to community-driven projects, integrate the results into SAP solutions at the right time, and go with the flow is the right answer.
SAP will always provide support and feature enhancements for solutions it has shipped, but it also needs to provide solid advice regarding future roadmaps. Personally, I can't advice you whether an approach using NWDI or one using (e)git/svn makes most sense to your project. I'm not sure if there is a possible black-and-white answer. Have there been conversations about that on SDN ? I'm not sure.
unfortunately there is no noticeable conversation about NWDI vs. Java standard dev infrastructure on SDN. Seems this are "seperate camps". -
SAP was ahead of the times. But why is the SAP way of java so different and yielded to a "universe"? SAP's approach was in both cases very holisitic and far away from Java: NWDI is a "copy" of the ABAP way (who needs a transport-clone in the Java EE world?), WDJ is based on a high level language-neutral abstraction from Java programming.
The focus at these times was carrying experience from ABAP onto Java and be ABAP-compatible, trying to eliminate what SAP considered as downside from Java compared to ABAP, but not leveraging the strengths of Java like agility and community. This has changed completely inside SAP.
Enough about the past. If SAP asked me for my advice (what will never happen:-) ), my solid advice would be to put the same effort into OpenSource inhouse infrastructure for support and its marketing/selling. When SAP recommends to use OpenSource technique evaluated and contributed by SAP like they did e.g. for EclipseLink, I want to get an offer for support by them for production support.
I want to create OSS'es for OSS.
I can't find any Java here:
That said, Java is a great language, but there are many other useful ones, even though many still rely on the Java Virtual Machine as a runtime environment. If a truly ubiquitous JVM is available on all operating systems, that's good. The unified announcement of support of OpenJDK is certainly a step into the right direction. What's left is Apache's concern about the balance between Java compatibility and open source, which has been written about in the press. We agree, but thankfully, a lot of innovation related to enterprise Java is already happening in open source outside the JCP, and that is unrelated to the argument that Apache has with Oracle and the JCP. Their argument is around core Java, which for SAP is a mere runtime environment.
Blocking Java 7 at this point won't help anybody. For further details, see Mike Milinkovich's interesting post about the position of the Eclipse Foundation in that matter: http://dev.eclipse.org/blogs/mike/2010/10/13/java-7-vote/. We agree with him.
As you see, there are a lot of technicalities. I haven't posted any SAP specific comment, because I did not see any questions about it on SDN. If there are, I'm happy to write a blog about it. Suffice it to say that we believe we understand the situation well, and that for now the Apache/Oracle debate does not have a material impact on our Java strategy.
On the other hand, for applications like CRM ECommerce B2C, I believe it's totally necessary to use core J2EE/Struts/Servlet/JSP/MVC2 technology since aside from .net there's nothing better on the internet webshop technology. And this doesn't use WDJ but it's pure Java. So unless CRM ECommerce B2C or B2B comes up with WDJ version, I don't see why we have to invest in WDJ. It's just wrong architecture which is cumbersome, complicated and bloated.
Aside from Oracle's La**y going senile gobbling up every SW coming across horizon, this was foretold and predicted by many and maybe it was going away gift by one young exTopExecutive/ Architect of SAP; a goodbye kiss of Death?
I think there is a large misunderstanding in your mind about the need for JCo.
The runtime for WDJ apps is the NetWeaver Java AS, which by definition, is external to any ABAP runtime you might have.
Therefore, no matter what framework is used to build your Java apps (Struts, JSP, GWT, WDJ, whatever), if any of these application need data from an ABAP system, they will all need to make use of the RFC interface via the JCo library.
In other words, with respect to accessing data in an ABAP based system, WDJ is no more or less efficient than any other Java application.
Probably I may have confused the topic by including the CRM ECommerce App which is pure Java Apps which does use the JCO. In future, to make use of features of WDJ, if these apps would change to WDJ then I think it would be advisable for further investment. Then we need to consider if this is advisable as well since there's significant learning curve for any seasoned java developers on WDJ where your book may come in handy.
1 - If you are set anyway to develop applications that tightly integrate with the SAP core applications, use ABAP, take away the overhead of RFC/JCO, and go for WDA or BSP.
2 - If you have applications that have a looser coupling with the SAP core applications (I think that's why you use eCommerce apps as an example), then go for plain vanilla Java standards, and don't bother with WDJ and its added complexity.
I think that's a fair point, but at the same time, don't forget that there are customers that want to develop heavy forms-based applications in Java, with all the features involved like data validation, formatting etc. For that, I don't think there is a good technology out there that's based on Java standards. I'm not sure if there are commerical or non-commerical JSF or Ajax implementations who would have similar capabilities. Do you know?
If these forms-based applications would integrate with SAP, I think your point is that they should have used ABAP tools to begin with, but perhaps there are other considerations, like integration of SAP data with other data sources and processes outside of the SAP core for which the customer thought that Java would be a better solution, or simply readily available Java skills.
Be as it may, you can see from the passion around the "Kiss of Death" topic (still the top blog post for a few weeks in a row now), that there is a lot of passion for WDJ as well. So, there were good reasons why many customers started in Java. The issue is how to continue with WDJ. Yes, it's a mature technology which does what it does very well, but what's the path into the future that provides clear guidelines how WDJ will evolve, and incorporate emerging UI trends like HTML5. I think that's the answer that people are waiting for.
For a pure or strong java shops where primary developers are java based then the WDJ would make sense but for most of the SAP shops are ABAPer based. So it just make sense for ROI and cutting cost business model.
And we should all be concerned about that one c*azy guy in San Jose who owns the technology now. With all that $$$$, retirement to his own kingdom would be a suggested but who knows?