Forget SaaS vs On-Prem, Here are 8 Application Styles to Consider

The EI discussion about Microsoft’s poor handling of Silverlight brought out the different viewpoints swinging. The “RIA was never a good idea” camp was in full force as was the “this confirms everything about HTML5” and the “Flash is on the same train as Silverlight” camps.

I don’t see these developments nor the evolution of Flash and its strategy as a confirmation that RIA is a bad idea at all, that Flash, at least is going away, or that HTML5 is the answer to all the world’s problems. Whether your RIA consists of Flash widgets embedded in HTML (my favorite RIA strategy for web apps) or AJAX HTML, RIA’s are essential for many kinds of app and HTML5 is years from being a first class choice for that work. There has been too much tendency to conflate every conceivable nuanced app type as one single web app that is best served by one single technology. That way lies crappy UX, high dev costs, and longer lead times to market.

There are new categories of application coming along all the time, and the vast majority haven’t really stopped to think about the evolution of application types and their ecosystems. Let’s forget the ongoing dogfight about Clouds, elasticity, SaaS, and Multitenant for a minute, and have a look at factoring software along some other dimensions.

I see 8 different application design centers, and you choice of which design center to use and which tools and platforms to go with it can matter quite a lot.

#1 Plain Old Desktop (POD) Apps

 

I always loved the term “POTS” = Plain Old Telephone Service, so I’ll borrow the idea for PODs, which are “plain old desktop” apps. This is still a huge business including MS Office and much of what Adobe sells by way of content creation tools. It’s also huge for complex games, though the platform is sufficiently separate we will want a separate category for console games which I won’t get into here.

Typical platforms include the desktop OS–Windows or Mac, and the traditional developer languages such as C# and Java. To deal with the pains of PODs, your app needs to be something that requires too much horsepower for the other architectures as well as a rich User Experience (UX).

#2 Server Software

A command line is a UX, and for some purposes, its even a good UX, so we will count this as an “app” category. It’s like the PODS except there are more languages and OS’s to consider. On the OS side we have Unix in commanding lead (in all of its many flavors) with Windows distantly to the rear. From the langauge side, the world has probably spent more time and effort building an explosion of different evolutionary language branches here than anywhere else. I can’t even begin to list them all, but suffice it to say that when in doubt, you could do a lot worse than to bet on it being a language for server side development. Certainly we can count on Java, C#, and Ruby on Rails as all being in this category.

Some languages are a little bit muddled as to whether they’re server or client languages. PHP is a little of both that mostly errs towards client in my book, but you wouldn’t think of it for server-less apps (if no client is a headless app, are those tail-less apps?). For this app category, we have no UX but a command line, so I’m not sure we’d pick PHP. Put it in the category of helping out Plain old web apps and RIA’s.

#3 Client Server

 

The Client Server model is tried and true and still a huge business, especially for business software. I don’t know how much genuinely new Client Server software is being built anymore. The Cloud and SaaS are a much better model for most applications. Think of Client Server as the somewhat unwieldy combination of a POD and Server Software. Most of what I’ve said for those other styles carries to this one when combined appropriately.

The combination of Desktop, Server, and Client Server are the oldest app styles that are still vigorous today. We’ll call mainframe software a flavor of Server or Client Server. All three are under siege or revolution. Desktop and Client Server are clearly under siege as various web technologies via to take their place. Server is under the dual revolutions of Cloud and Multitenant SaaS. There have been many minor infrastructure revolutions as well as the world transitions from SOAP to REST or decides POJOs (Plain Old Java Objects) make more sense than deep J2EE architectures (let alone CORBA style, Service Bus, and all the rest of that melee).

#4 Plain Old Web (POW) Apps

 

No fancy RIA tech, AJAX or otherwise. This is the modern equivalent of the half duplex 3270 green screen. But, it is lowest common denominator friendly. That means everyone can access it, but the experience may not be great. Save it for times when coverage is more important than satisfaction. Simple UI you just have to get through once in a blue moon is perfect.

The platforms? Who cares. POW apps should use such vanilla HTML they never notice. Tools and languages? Vanilla HTML and whatever your favorite dev tools are for that.

If we add POW apps to the other 3, you really do have the majority of revenue and installed base at present. What follows are newer models that are catching on to a greater or lesser degree. I should add that I see POW as stable and non-controversial, Server as growing but full of revolution, and the other two (Desktop and Client Server) as in decline to greater or lesser degrees.

#5 Rich Internet Apps

RIA’s are web apps that live in the browser but provide a nicer UX than a POW can offer. AJAX, Flash, or Silverlight have to be there for it to count. HTML5 supports this poorly at present, but everyone knows it wants to go here over time.

The “Rich” part of a RIA can boil down to lots of things, so let’s call some out so they don’t go unnoticed. Yes, we will started with Rich User Experience. But what does that mean?

Well, instead of posting a form, you have enough expressiveness that you can actually create new kinds of widgets and respond to user inputs with much more fluidity. We also have rich media, including sound and video to play with, as well as sophisticated ways of manipulating bitmaps to produce animations and art.

However, depending on the RIA platform, you may also experience other “riches.” Flash player delivers a very high performance virtual machine. It isn’t Java-class, but it is darned good. Recently, browser makers have decided performance matters for HTML as well, but it isn’t clear they’re keeping up with Flash. If your RIA has to do some kind of crunching, Flash may help it along. It isn’t just about the high performance VM, there is also the support for more elaborate data structures, which are also helpful where more horsepower is needed.

I have been fascinated by an idea I came up with called “Fat SaaS”.  We live in the multicore era where computers no longer get faster in raw terms, they just get more cores.  At the same time, it is very hard to write software that takes advantage of all those cores.  On the server side, the world has been evolving towards dealing with the issues need to scale large problems onto grids of commodity PC’s as a way to deal with the realities and economics of the multicore era.  On the client side, it seems that machines accrue more and more unused capacity without delivering good reasons for customers to upgrade as often as they used to.

Fat SaaS is an architecture that pushes as much down onto the client as possible and leaves the server farm largely for data storage.  In an extreme Fat SaaS case one could imagine that the clients become the business logic processing grid.  The goal is to tap into the computing resources that lie fallow there, and there are a lot of them.  Most organizations will have more client cores than server cores.

But we digress…

The last bit of “riches” I want to touch on is device independence.  We largely got there for server software, and write once run anywhere is a beautiful thing.  Other than Flash, we are nowhere in sight of it for the client.  This is a sad and embarrassing tale for our industry, and one that developers too often try to power their way through by just writing more code.  Browser incompatibilities are insidious.  As I write this article in WordPress, I’m trying to use their rich text editor.  It runs with varying degrees of success and a little differently on each browser.  Lately, it mostly fails on IE, meaning the UX has not been kept up to snuff.  If they would simply invoke Flash to do one single thing, manage the text editing, they could deliver an identical experience on every browser, not to mention many mobile devices too, though on Apple’s devices they would need an app to do that.

This browser dependence is absolutely the bane of HTML based RIA’s, and I can see no reason why the problems won’t continue with HTML5.  As vendors race to see who can deliver better HTML5 support sooner, keep eyes peeled for the incompatibilities to start.  If they do, that’s a sign that the HTML5 dream is not all its cracked up to be, even in the fullness of time.  It will take some new generation and a bunch of restarted browser implementations to get there.  Meanwhile, Flash will have gained another 5 to 10 years lease on life, despite detractors.

#6 Rich Internet Desktop Apps

RIDs!  A RID is a really cool thing.  It is the web era approach to building desktop apps–we build them with web technology.  Amazingly, nobody seems to have noticed that if you need to run disconnected, or if you want to build an app with web technology that does meaningful things on the desktop, Adobe is the last man standing.

Google killed Gears and Silverlight looks more and more deprecated by the day.  HTML5 is still struggling to get to the minimum RIA bar and will be for years.  What’s a poor RID developer to do, but focus on Flash?

RIDs are fascinating apps, and I would argue your nuts to build any new PODs or Client Server when this model would work. In the area of games, there are amazing developments in 3D coming for Flash Player that will also play to this architecture. Lastly, Ialready mentioned “Fat SaaS”, a model which is ideally suited to RIDs.  The RID just gives the Fat SaaS access to local disk and more of the machine’s facilities.  Fat SaaS work can go on whether the client is connected or not, and a connection can wait until the client needs to connect, which reduces the demand on the Cloud Server Farm still further.

#7 Mobile Apps

MAs are closely related to RID’s, and certainly much better known. The non-HTML RIA platforms are excellent for this purpose, and it is no accident MSFT sees this as Silverlight’s future.  HTML5 doesn’t do enough and it will be years before it does to have real apps stand alone with it. iPhone’s default toolset is basically foisting desktop technology on you to build these apps, and I’m skeptical this is as productive, but the stakes are high enough people deal with it.

#8 Mobile Internet Apps

MIAs:  when you want to live in a browser on a mobile device.  Plenty of data suggests that for apps that are not heavily used, users prefer to consume via browser.  This shouldn’t be controversial as it simply makes sense.  The browser makes it much easier to dip in and out of a lot of apps that you probably never use enough to learn really deeply.  MIAs are a different category than RIAs because like the RIA, there are considerations beyond one-size-fits-all HTML.  However, a MIA could be a RIA MIA (LOL) or a simple HTML MIA.  I won’t bother breaking those two out as new app types–we already have 8 and that’s enough.  The reality is the MIA is a placeholder reminder that you have to do something to make your app palatable on a mobile device lest you have a below par UX.

Conclusion

Have you thought about when to use each of these design centers, what the optimal tool sets are for each, and especially how to weave an all-platform strategy with as little work as possible?

Most haven’t.  I see low expertise in out in the world as much of this is new and very few organizations have so much breadth of experience.  Most of the time organizations start with one design center and move chaotically on to others as targets of opportunity present themselves.

We increasingly live in a world where being on one or a few platforms will not be good enough, and we won’t be able to build for all with organically grown “luck” strategies.  Maybe this is a good time to start thinking through these issues in a systematic way for your organization and its products?

Related Articles

Recursivity and RWWeb talking about Fat SaaS.