In essence, Farrell’s pushing the ideas behind the equivalent of Oracle Fusion Middleware for the rich client.
Enterprise Web 2.0 is more than a facelift of Ajax, said Farrell. His point is that, unlike consumer applications where you might casually mashup items that are only limited by the imagination, using the latest cool technologies, the enterprise by necessity is a more disciplined environment. You can’t just experiment with new tools if the result causes a breach in enterprise policies.
A good example is the well-known mashup of layering the locations and identifies of customers atop a Google Map. Exposed to members of your sales organization, that might be fine, but if somehow let loose on an external website, you could find your organization cited for HIPAA, Gramm-Leach-Blilely, or similar regulations designed to protect customer privacy.
While Farrell refers to the governance aspects, he places even more emphasis on technology churn. You can’t assume that this will be a disposable application, he said, noting that enterprise mashups should be insulated from changes or refreshes of underlying technologies.
For instance, Microsoft and Adobe have recently introduced their own families of rich web client frameworks. Their position is to come build your user interface on their technology, said Farrell. But our position is that the underlying technology will keep changing.
Besides churn in underlying frameworks is the proliferation of different APIs to back end systems, many of which may not be exposed in standard form as web services or portlets.
Oracle customers, if they have more than one of its products, could be good cases in point. While some may have a stable of recent Oracle JDeveloper apps, others may still be running their legacies based on Oracle Forms, Siebel’s C++ environment, PeopleSoft’s PeopleTools, or forms of C or RPG apps for J.D. Edwards.
For example, take a screen that manages an employee in PeopleSoft. To rewrite that in Ajax would take a huge amount of time.
Our View
Oracle’s own customer base could be poster children for exactly the framework approach proposed by Farrell. Thanks to Oracle’s shopping spree, it has quite a lot of diverse technology inside its tent, not to mention multiple generations of development languages that have come from Oracle’s own mother ship over the years.
And if you’re a veteran developer who spends most of your day with one of these legacy languages, probably the last thing you want to do is bone up on JavaScript. Of course Oracle is hardly unique in pushing tooling or frameworks that abstract Web 2.0 development from JavaScript. Ajax frameworks are continuing to proliferate in the marketplace, almost by the week.
So we can’t argue with the call for a framework that abstracts you from front end scripting languages or back end legacy or non-standard APIs.
But at the end of the day, the question of whether to use frameworks and which ones boils down to who is actually doing Web 2.0 development. If it’s your veteran ERP or CRM developers, then native frameworks are the obvious answer because you want something that literally speaks their language. But if it’s someone who’s the latter day equivalent of the casual programmer, then the choice is more likely to be whatever is the soup of the day.
Consequently, the argument over frameworks protecting you from churn in underlying technologies is valid only if your organization doesn’t swap out Ajax frameworks. If your Web 2.0 developers are not from the mother ship, or if IT is extremely decentralized in your organization, the question over framework swap will be hardly academic.
