Technology Stability in a World of Constant Change

[Former Member]

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.