Mission-critical AJAX builds ROI envy behind the firewall

Mission-critical AJAX builds ROI envy behind the firewall

Summary: I've been advising my clients for years on the operational and cost-containment virtues of Web services and SOA. But now I'll be adding the icing on the cake: slap AJAX front ends on those endeavors and do a lot better for less.

SHARE:
A couple of recent developments highlight the growing ROI power of AJAX, especially when applied to mission-critical applications behind the corporate firewall. While the high costs of IT operations continues to nag nearly all CIOS, the combination of AJAX-oriented GUIs and SOA-empowered middleware offers a new-found financial balm.

Indeed, the word compelling comes to mind when you factor the use of AJAX and latest Firefox browser as the client-tier tag-team that slashes total costs and vastly simplifies development for internal business application modernization and greenfield development. What additionally simplifies, and therefore further cuts total costs, is a coincidental embrace of SOA by corporate IT leaders. SOA on its own divorces the services and process development from the interface development -- sort of ready-made for AJAX-like UI deployment.

As Global 2000 enterprises, therefore, move to SOA, it makes sense for them to consider simultaneously moving to AJAX client interfaces. Or vice versa. The development-test-deploy cycle separation -- GUI on one hand and services orchestration on the other -- is clean. Developers on either side of the divide need not worry about client targets. Say adios to plug-ins, Active-X controls or Java applets. This is powerful. Separate teams can work the development of different tiers with operational integrity upon production. Build, buy or partner? Yes.

So when you consider the Web 2.0 development and deployment paradigm, don't limit it to the Web.  Make it include Intranet 2.0. Why? Public-facing Web applications are often used for e-commerce, which should be viewed as an additional income source, and therefore funded by IT budgeters as an investment. The impetus for adoption is based on functional improvement to customers and new revenue.

But internal IT applications are still often viewed as cost centers to budgeters seeking to hold the line or reduce total IT costs. It's harder to convince the bean-counters to invest in a cost center improvement. But AJAX on top of SOA could work magic to reduce the total costs of internal IT operations, with only modest investment and swift ROI. Those same investments, incidentally, can be used to then improve the revenue-generating e-commerce operations as well.

Bolstered by the move to SOA, an AJAX-oriented UI pilot project for internal use may be the prudent way to explore these development developments. As builders and architects gain confidence, more internal composite applications could then lead to expertise with the AJAX-SOA tag team, setting the stage for killer public-facing applications that improve functionality for the sellers and users -- while cutting total costs and improving the pay-off from rich e-commerce activities in the B2B extended enterprise future.

SOA and AJAX, like any IT change, require a compelling business case to garner managerial support and investment. I think we may now have a good case to make, especially when SOA and AJAX are used in tandem internally in a controlled environment.

So while the AJAX hype has been on public-facing Web applications that indeed significantly benefit from the technology, the application of AJAX to internal applications use, I believe, has greater near-term cost-benefit implications, and spurs long-term core competency payoffs. Show the CIO the money savings and make the paradigm shift happen as a functional and economic wedge against your competitors.

My conclusions on the economics of AJAX on SOA (AOS?) were supported after taking a briefing on the Feb. 13 release of TIBCO General Interface version 3.1 Professional Edition. The AJAX development framework and tooling, five years in the making and part of TIBCO's acquisition last year of General Interface, is free to developers for public applications and at a steep discount at $499 for 5 users for internal applications.

I was further moved in the direction of cost-benefit persuasion of AOS by the recent Oracle announcement that a new version of its Java application server and development tool are available with enhancements designed to ease back-end and AJAX development. Oracle Application Server 10g release 3, server software for running Java applications, is the foundation of the company's Fusion Middleware product line, which will eventually underpin Oracle's different packaged applications.

Using AOS could sure make life easier when managing Oracle's middleware and business applications. Perhaps SAP applications on the back end supporting AOS could also be used in composite arrangements alongside Oracle's? Sure.

I've been advising my clients for years on the operational and cost-containment virtues of Web services and SOA. But now I'll be adding the icing on the cake: slap AJAX front ends on those endeavors and do a lot better for less. Then go public (with the apps). The AJAX community sees the writing on the wall, and the race is on to deliver the de facto AJAX frameworks that will make the adoption of the AOS GUI further compelling on economic basis of cost, simplicity, and choice.

Topic: Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

3 comments
Log in or register to join the discussion
  • Nail and head

    This is a much better vector than just going down the new web development tool line. Relatively uncomplex systems, that have plenty of existing mission critical data just waiting to be leveraged? Well to see these things you just have to look at existing intranets. These are the best examples to talk about (in a corporate environment); these are the things that will make it worthwhile investing in better developer toolkits.

    Any talk along these lines will help people other than Google (*1) understand the potential that AJAX has - and clarify what it will not be doing.

    (*1) reference to ZDNet AJAX/Google blog http://blogs.zdnet.com/Burnette/index.php?p=9
    Fandorin
  • AJAX IS EVIL!!! ...Dont use it!

    The person who wrote this article doesnt seem to have enough direct web development experience to know value with these technologies in terms of development and usability.
    wildranger
  • AJAX IS EVIL!!! ...Dont use it!

    The person who wrote this article doesnt seem to have enough direct web development experience to know value with these technologies in terms of development and usability.

    Im a hard-core web developer and a .NET Software Engineer and I would NEVER RECOMMEND AJAX or its newest sibling ATLAS as a viable solution for anything on the web...or intranet for that matter. Its nothing but a JavaScripted, client-side complex mess, that allows fancy UI features so users can pretend they are in a desktop app, and make stateless database calls via the XMLHTTPResponse so users dont have to click a link or make a refresh. It adds NO VALUE whatsoever and is just a fancy buzzwords for client-side scripting which has always been problematic in the browser...intranet or not(http://www.stormdetector.com/essays/essay11.html)
    As much as 10% of users have Javascript turned off online (http://www.w3schools.com/browsers/browsers_stats.asp), meaning a large volume of people cant user AJAX system at all in websites and cannot use autoposteback in ASP.NET. Thats why Im adamant about JaavaSCript being a BAD technology....regardless of intanet values. Clicking links and posting back to the server is so fast and efficient using XHTML and caching technologie, if done correctly, you wont need most of what AJAX does. Interactive stuff can actually be done BETTER using Flash MX which has a faster, better, more robust XML feature. Its universally implemented across browsers and platforms as well, and less costly and complex to built than AJAX, despite the tools. What about security issues and the fact also that mobile agents among tons of other browsers DONT support AJAX? Now you have to design 2 web site portals to account for your userbase. Besides all this, Balthaser owns the patent to AJAX, so they claim, so you have to a address that issue if you are developing AJAX toolsets. Lots of problems and potential land mines with AJAX. Just remember, its nothing but a fancy XML object class thats installed when you install Internet Explorer on your computer, and a bunch of JavaScript and DOM calls in your browser. Its nothing new....

    If you want to write about real VALUE in intranets, online, and interfacing with Web Service architectures in terms of the browser and the web, check out XHTML and CSS and the new XHTML movement thats taking place in the web cuminty all over the world (away from old HTML which is what Microsoft's cryptic non-compliant browser, IE6, still uses). When you migrate away from AJAX and JavaScripted technologies and into cleaner more compliant XHTML markup that uses 60% less code, is more compliant with search engines, separates GUI and web design completely using linked CSS style sheets, and which is FREE of client-side code, you reach 99.9% or your userbase. Using Mozilla's family of browsers, you will be amazed at how fast and efficient sites designed around XHTML are (example: http://www.wired.com/). Talk about cost savings!!! Using XHTML, people with accessibility and disability issues can access your content, unike AJAX, your sites run lighting fast as they use half as much code (AJAX is ten times more code!), use XML/XSLT to drop in new data so content updates are intuitive and build around SOA webs ervices by default (AJAX must interface with your data store using an installed component that comes with your OS or browser and which MIGHT not be installed), and redesigns of graphics take a fraction of the time as all thats now in a handfull of CSS text files. Designer wanting to change the look of a website now just change text in a handful of style sheet files that affect thoudands of pages at once. Talk about cost savings!

    Why doesnt ZDNET ever talk about what really matters in the web development world...moving away from JavaScript and HTML and into this new XHTML/XSLT world thats coming? Check out http://www.w3c.org/ and http://www.alistapart.com/ to see where some of this is going.
    wildranger