Unlocking the Potential of RIA/SaaS -- Is There a Better Way?

Helixes, Spirals and Staircases



When thinking about how application platforms have evolved over the last 40 years, the image that comes to mind is that of a spiral staircase, or helix. While others may talk about circles or pendulums, with the principles of IT shifting back and forth, the reality is that technology capabilities and benefits increase at every successive turn. Remember those mainframes of the 1960s, operated with punched cards? Then the Microprocessor invention brought about the PC revolution - and created, essentially, a 'democratic' type of deployment, where distributed processing took over from centralized processing - providing new and scary amounts of computing power to every user desktop.

The advent of this desktop processing created a significant euphoria in the market as software suddenly became many times smarter. Even the simple spell-checker that we now take for granted would have once required many more times the computing capacity, and was limited to specialized "Text Processing" systems until the Desktop Client came along.

The development of Local Area Networks brought further power, functionality -- and growing complexity. As people began to realize that there was also a huge price to pay for maintaining the so-called 'Fat' Client, the euphoria began to wear off. A typical organization operating many desktops must outlay huge sums of money to install each machine and maintain it against bugs. High costs become a powerful incentive for people to look for a more efficient way.

Returning Full Circle

With the internet revolution we began to turn back to a more familiar path. Reaching out to the world with centralized portals means that the industry has now almost returned to the principle of the 'Dumb' Client -- where all major computation occurs at the Server -- and where the 'Thin' Client is named for the fact that it acts basically as a window. Having traveled full circle, today we are back at the same topology that we started with over 40 years ago, but this time the helix or spiral is at a much higher order of technological magnitude.

Rich Internet Applications (RIA) -- The Best of Both Worlds

We have not finished moving yet. While the cost of operation for the 'Thin' Client remains conveniently low, the reality is that it is limited in its operational scope, lacking the richness users have come to expect from 'Fat' Client applications.

These limitations are today leading the industry into a new mode of deployment -- RIAs and the advent of the 'Fit Client' -- that bring the best of both worlds together - the desktop richness of the 'Fat' Client with the low operating cost of the 'Thin' Client.

RIAs are fully interactive (desktop-style) business applications that are installed at a single location, the Server, and are accessible from any portal via the internet, the Client. They are able, depending on the platform, to take advantage of the local computing power of the Client hardware, yet manage all this without the complex installation and maintenance typical to the 'Fat' Client.

There are considerable advantages in moving to RIAs that include:

  • Access via mobile and remote devices, significantly increasing your market exposure;
  • Desktop-style 'drag and drop' functions that give a much improved user experience compared to Web browser applications;
  • Multi-tenant architecture that eliminates the need to maintain every new user, helping to lower the cost of ownership and operation;
  • Software-as-a-Service (SaaS) enablement in that applications are quickly and easily assimilated by customers of all shapes and sizes who will use your RIA;
  • Multi-tier architecture that lets businesses better secure the sensitive aspects of their application.

This is All Very Well, Butů

Consumers and businesses continue to use all modes of deployment that we have mentioned. This includes Mainframe/Terminals from the 1960s through Client/Server and the Web, and they will continue to operate a mix of application platforms for years to come.

Add to this the inherent trade-off between on-demand applications characterized by the SaaS phenomenon and the typical on-site applications that most organizations will continue to operate, and we begin to see the complexity that operating such a mix would involve. With such a heterogeneous application portfolio, businesses need to service different, though sometimes overlapping, constituencies that require varying skills and competencies to operate. This means money, lots of it. For example, a typical business may need to keep up legacy applications such as COBOL along with a host of in-house and possibly packaged applications because they contain critical features for so-called "power-users." Additionally, there may be the more modern Web applications that require Web developers.

How many of these organizations can really afford the multitude of diverse skills and manpower needed to assure the optimal operation of all their applications? What happens when an organization wants to stay ahead and introduce RIA, a highly complex form of application development in and of itself?

RIA Development Hurdles

RIAs represent the most challenging development process to date. Firstly, Client side development uses different technology than Server side development. For example, a particular language may be used for developing a RIA Client tier. This Client would then consume Server side services developed, for example, upon Java. In addition, there's an internet session to implement and manage, along with its specific technology and methodology. So, a typical development effort requires the acquisition and maintenance of a number of different teams to work on the different aspects of the application. As a result, the design, planning and management of the project become riskier, more complex and more expensive. As with any system, the more moving parts you have, the greater chance you have of experiencing a breakdown.

An added complication when dealing with a RIA Client is that you have to explicitly program responses into the application because the Client is now an independently functioning entity which must be managed on a per-field level. This is unlike the browser, where the Client page refresh occurs almost transparently.

Developing and deploying a RIA or SaaS solution requires businesses to first buy, and then integrate multiple platforms along with diverse Server and Client paradigms.

Is There a Better Way?

Is there a way of handling both the complexity of operating and maintaining a mix of application platforms within a single organization, and the sustained development effort that RIA development demands?

Today we are seeing the emergence of a new breed of application platforms. Dubbed SEAP, for SaaS-Enabled Application Platforms, these leverage metadata based application development and rules engines, augmented with process management capabilities. SEAPs provide much more intensive and extensive abstraction and significantly reduce the complexity of development and deployment over the entire application spectrum.

A few of these platforms can deliver RIA and SaaS. Some bundle the platform and a hosting service, providing an Application Platform as a Service (APaaS). It should be noted that for cloud infrastructure owners, who want to leverage their assets in a SaaS offering, a SEAP is a mandatory ingredient -- hence the importance of being able to obtain a SEAP as a stand-alone product. To understand what's in a SEAP, let's have a closer look at one of them. This particular platform can deliver RIA and SaaS through a unique unified development paradigm that incorporates all aspects of the development and deployment process. It can manage the setting and control of the Client side and Server side logic, the communication between the Client and the Server and the consumption and manipulation of back-end services - all from the same platform.

The Browser-free RIA approach can provide all the benefits of RIAs but, unlike the browser-based approach of Ajax-type solutions, it is not dependent on the browser and its various usability problems. Also, while client-side RIA platforms require separate Client and Server development and partitioning, this SEAP caters for both the Server and Client tiers, and handles all Client/Server partitioning automatically, thus greatly simplifying the development process and reducing costs.

You want a paradigm that can support the entire application delivery spectrum -- desktop, Client/Server, Web, RIA and SaaS -- with the same application trunk. This means that an organization running a typical OS/400 application can continue to deploy this application on old terminals -- but in addition it also becomes accessible to 'Fat' Clients, Web Clients, Rich Clients and Mobile Clients. This approach is a true reflection of corporate reality, extending even to bridge business requirements and platforms with the social nature of the Web.

So while software vendors now consider their next steps and how best to adapt to the new paradigms of the RIA and SaaS markets amid the fears of a shrinking global economy, a host of mega-vendors and start-ups are engaging in the emerging platform wars.

In such an environment, it would be wise to consider how best to cost-effectively manage the transition. For this reason, a proven SEAP platform featuring a single development paradigm should be vigorously considered by any business looking to cost-effectively develop RIA and SaaS based applications while allowing their users to continue to use and adapt their current application portfolio investments to the fullest.