Rich Internet Applications and the software as a service model

Rich Internet Applications and the software as a service model

Summary: Software as a service is going to become a more viable business model in the years to come. Rich Internet Applications are going to play a very large part in that revolution by focusing on offline/online content as well as more customizable applications.

SHARE:
TOPICS: Apps
6

Yesterday my post about Microsoft and Google garnered a lot of responses. I've got to say, I'm looking forward to having a dialog with the readers here at ZDNet. It's a lot of fun to be in the middle of an active comment thread. Hopefully I can keep up and post responses. During part of that discussion, the issue of how software as a service can be a benefit for businesses came up. I realize that's the big question, so I won't attempt to tackle it head on (however my fellow ZDNet blogger, Phil Wainewright, does a great job), but rather talk about it in terms of Rich Internet Applications.

The holy grail of RIAs are those applications which can be deployed over the web but allow you to take both the application and the content with you. Being able to "synchronize" the application with the server which would download updated content and even perhaps updated versions of the application is the kind of feature that I think will bring RIAs to the masses. For businesses this creates a compelling distribution method. If you're building an RIA in house and you want to push out features, it's as easy as having your users sync with the server (which they would assumingly be doing anyway). On a grander scale they would do this on their PC as well as their devices, and they would have an exact copy of the application in both places, with the same data, available to them online or offline. It then really becomes the Universal Desktop and you can take the applications wherever you need to.

For a company like Microsoft, building, for instance, a rich internet version of Microsoft Office, would allow them to push out updates faster and perhaps even easily customize the product for higher end customers. While I don't necessarily like Microsoft's "lock-in" strategy, I understand both the business case and the development case. By trying to keep everything Microsoft-only, they can give developers a fairly consistent environment from which to create applications. In the software as a service model, a version of Office running on the web could, in theory, be expanded by a host of third party developers coding on WPF (although I realize MSFT hasn't been kind to the third party thus far).

For businesses, subscribing to Rich Internet Applications would not only empower the workers as mentioned above, but give them a flexibility when it comes to licensing as well as a more robust model for enhancement requests. The companies that succeed in software as a service, and more specifically, Rich Internet Applications, are going to be those that can quickly turn around feature requests for their best customers. That may be a difficult hurdle for Microsoft to overcome, but I think they have the right infrastructure in place. If they stumble however, there will be big companies like Google, or even Yahoo, there to fill the void and technologies like Adobe's Flash as alternative platforms. It's bound to be an exciting few years.

 

Topic: Apps

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

Talkback

6 comments
Log in or register to join the discussion
  • Rich Internet Application for offline?

    A rich client applciation for offline amkes no sense. What are you going to store the information in XML format? Unless you have a few hundred records - perforamnce will be terrible.

    A "Smart Client" application makes far more sense. It can connect to data over the internet but consume local resources such as SQL Express for offline data.

    We do that now in our interprise suite application. It blows the doors off applications like Netsuite and Salesforce.com since there is no HTML or JavaScript to load and data is cached locally.
    interprisesolutions
    • Not Hundreds of Records

      I don't think we're talking about hundreds of records here. You would sync what you need, take it with you, then sync the changes when you're back online. The goal isn't to port an entire database to RIAs, but rather to keep what's most important and allow the user to toggle that. It could be a movie, it could be a series of documents or it could be X number of records.

      It's all hypothetical, and your point about hundreds of records is a good one. Can you hash out how you see a typical workflow? Thanks for reading!
      ryanstewart
  • RIAs Have Great Potential

    There are a lot of scenarios that would benefit from moving from current day web applications, to RIAs. E.g. adding collaboration abilities to Office, wherein say a user receives an email or an alert, then clicks on a link in the email / alert which takes him to an Office collaboration program, where he can work on a document and communicate with others, would be very useful. The collaboration program which would be transparently supported by a server, could have voice, IM, and other communication features. Users could then have an interaction session in which some or all actions are made in layers (like in Photoshop), with the session actively replicated to all the participants? computers. Therefore if Bob wants to go over a spreadsheet with Karen, he could go to the collaboration program, send an alert to Karen from there, and she could enter into a session with Bob in the collaboration program. From there they could communicate via IM or voice, and take turns modifying or marking up the document. It would be great if the collaboration program could support Tablet PC (or ink) type mark ups.

    The above gives you an idea of some of the sophisticated things that could be done with RIAs which current day web / Internet apps simply cannot do. Other examples include say a mapping RIA that downloads to your device or PC, maps and data for the area in which you live, so that you can use the program to look up directions and navigate around, even when you are not connected to the Internet.
    P. Douglas
  • Syncro Nightmares

    It's all coming back to me now....client/server syncronization nightmares.

    RIAs takend offline face the same issues we did back then. What happens when an "offline" app no longer matches either the business rules or data layouts that exist in the "centralized" location? That would require different plugs in the central code to know how to deal with this.

    We had the same issues with client/server software. We had flags to indicate that something had changed, and hence had to download a new version to the client so that it matched. The same issues will occur here. Some of it could be taken care of by sophisticated code behind-the-scenes, but there will be times (as there were then) when a user has a whole bunch of changes done offline that they want to sync back to the central holder of the keys, but it can't because the data formats or business rules under which their data was created no longer match the rules of the game.

    I see offline RIA as a very small and limited use. But if you consider the possibility for ubiquitous, always-available-from-anywhere wireless connections to the Internet (via terrestrial repeaters, P2P type networks where someone else's computer is a node to your connection, etc.) then the idea of offline RIA is null and void.
    Paul C.
    • I Don't See A Problem

      [i]RIAs takend offline face the same issues we did back then. What happens when an "offline" app no longer matches either the business rules or data layouts that exist in the "centralized" location? That would require different plugs in the central code to know how to deal with this.

      We had the same issues with client/server software. We had flags to indicate that something had changed, and hence had to download a new version to the client so that it matched. The same issues will occur here. Some of it could be taken care of by sophisticated code behind-the-scenes, but there will be times (as there were then) when a user has a whole bunch of changes done offline that they want to sync back to the central holder of the keys, but it can't because the data formats or business rules under which their data was created no longer match the rules of the game.[/i]

      I really don't see a problem. 'Data formats' could be versioned, and the server software could properly convert old data on a PC or device to the system's current scheme (after it uploaded it), and then push down updates to the application, along with newly formatted data. Chances are within a company, a server won't have to deal with more than two versions of data formats at any one time - so the above scenario shouldn't become too complicated. If it so happens that an employee has not synched up his data in a while, then there is the option of someone grabbing his data, and doing a custom conversion on it, then giving him an updated version of the app, along with new data. (Or the system could be expanded to handle more than 2 versions of data formats.)

      The above situation does not seem too complicated to me. The only major issue I see is developing data conversion routines (queries, stored procedures, etc.) - which should not be too much trouble. When all is said and done, having RIAs and dealing with the above issue, benefits users a great deal more than them using thin client apps, because users gain tremendous flexibility, and the ability to use sophisticated software of a type that simply cannot be delivered by current day web / Internet applications.
      P. Douglas
  • RE: Rich Internet Applications and the software as a service model

    Top marks Ryan. In many ways you're describing what we call a canvas. That's why encanvas was created. To exploit XML and baked in applications so that normal people, not programmers or scripters can design their information apps to carry data along with their apps and then deploy them as temporary or permanent web, pc, or mobile composites. Data rules (decribing how your data manages itself) are also carried by the canvases. The only other thing we thought of was to remove the need for coding. Glad to see the world of composite applications is gradually moving away from scripters and moving towards information consumers,
    iantomlin@...