.NET Musings

This is part one of a two part post discussing the architectural implication of Smart Client vs Thin Client deployment models. Both of these posts will appear together as a single article on the web site NPlus1.org, a site dedicated to the architectural community.

The Problem Space

At the end of the day, the goal for any line of business application is to make life better for the users. That, of course, is the users’ perspective. There are other considerations that must be taken into account, and those are the “ilities” - Maintainability, Supportability, Scalability, etc. These (quite often) are in direct contrast to the wishes of the users. How do we bridge what the users are asking for versus what IT is willing to develop AND support? As an architect, one of our jobs is to find that common ground.

A stroll down memory lane…

When I started writing program code, it was on a mainframe. The code ran in a central location, and was accessed by terminals. This was a developer’s dream. One central location for all code made deployment a breeze. Of course, the users (at the time) didn’t know any better, and accepted the status quo.

When the personal computer became prevalent in the workplace, we started programming Client Server applications. The desktop wasn’t much at the time, but it was a vast improvement over the terminal applications the users were used to. With advances in desktop technology, applications became more complex, more critical for the business, and life was looking great...at least for the user.

We entered into the era of development known as “DLL Hell”. IT personnel (desktop support, infrastructure, and developers included) were pulling their hair out due to the massive support efforts necessary to keep the desktop applications running. Every desktop had to be touched whenever there was an update, installing a new version of a third party add-in usually broke other applications running on the desktop, and the list went on and on.

The Rise of the Internet…

When the internet started to be utilized for line of business applications, it was like a dream come true for IT. We could manage applications from one location, deployments were a breeze, DLL Hell was but a memory, and life was good…for IT. With the limits of the browser, we essentially returned the users back to the days of the mainframe. The pendulum had swung completely back in IT’s favor, and browser based applications (usually referred to as Thin Client Applications) were being used everywhere from internal applications to e-Commerce.

.Net and SQL Server Bring Options…

The most significant change to impact the prevalence of browser based development was the release of .Net. With the new registry-less runtime model, desktop applications could be “xcopy” deployed. SQL Server Compact supplies built in synchronization capabilities, allowing for “occasionally” connected clients. These and more have opened up smart client application development without many of the nightmarish problems of the past.

What about Rich Internet Applications?

Browser-based applications have gotten increasingly more sophisticated since the early days of strict document publishing with raw HTML. Adobe’s Flash introduced higher end graphics capabilities, animation, and other rich multimedia functionality to web sites. Ajax gave developers the capability to do partial and asynchronous page loads, improving performance by only re-rendering parts of web pages and reducing the “flash” of the browser. Microsoft entered the RIA market with Silverlight as a direct competitor to Adobe bringing “Flash” type multimedia to the .Net developer.

All of these (and other technologies) brought the browser closer to their desktop siblings (also known as Smart Client Applications). The rise of Rich Internet Applications (RIAs) has brought us into a world where the deployment model becomes an architectural decision in many (but not all) cases.

Different Browsers, Different Rendering Interpretations

Even with the new functionality available, it’s not all peaches and cream. The internet version of DLL Hell is browser compatibility. The Internet standards are more often than not treated as “recommendations” by the browser manufacturers. Not only do the different brands render pages differently, the versions within the brands are often quite different in their display.

The rendering differences bring a sub-decision into the fold, and that is what browsers and version to support, or attempt to support all browsers (at least at some level). Either way, the applications must be “functional” in all of the mainstream browsers.

The Easy Choices…

There are several factors that must go into choosing between thin and smart client architectures. Sometimes, there isn’t much of a choice, and one model is clearly better than the other. (Keep in mind we’re discussing Line of Business Applications, not games or utilities.)

When the Web is Clearly the Best Answer

There are still straight forward cases where the best answer for deployment is thin client. The rendering differences still require quite some thought as to which browsers (and versions) to support, and I will point out for each of these categories my opinion on the matter.

Line of Business Scenarios

Corporate Intranets

As the name implies, these almost always call for a web based solution. The goal of an Intranet is to facilitate communication among the employees and between the employee and the company.

This is the only item in this list where standardizing on a single browser can be acceptable. I still believe that the applications in this space need to be functional in all of the mainstream browsers, but it is well within a company’s rights to tell its employees to use Browser X Version Y when accessing the intranet. They might not like it, but they are a semi-captive audience. And the cost savings of standardization might be well worth the potential irritation to some of the employees.

E-Commerce Applications

For e-Commerce, the standard is (and will be for quite some time) to deploy as a thin-client. Could you (as a user) imagine having to download an application before you could check the price at your favorite e-tailer? If you are targeting the public, web is the only answer.

These sites are all about making money over the internet. This is certainly the strongest case for supporting all browsers and versions (back to a reasonable level). This will probably entail separate style sheets for each browser, plus a lot of hackery to get the rendering where the business wants it in all supported browsers. But, it is about making money, so the extra work will probably translate into extra sales.

At the time of this writing, an e-Commerce application that I am working
on is supporting: Internet Explorer 6+ (yes, there is still a significant amount of traffic using IE6), Firefox 2+, Safari (Mac AND Windows) 2+

Marketing/Brochureware

A company’s presence on the web is now the equivalent of the signage over the door. Often, a person’s first impression of a company is their web presence. In this age of global economies, even mail order customers will often research a company on the internet before placing an order.

Browser Issues

These sites are significantly simpler (from a programmer’s perspective), and much more involved from a graphic designer’s point of view. These also need to render in all browsers to be effective, but this is a much less daunting task than e-Commerce applications.

One way “publishing” applications

I have three children. They are all very active. Sometimes it is overwhelming to keep up with everything, between sports, school, and other activities. However, thankfully, almost all of the organizations have a calendar on the web. Some are secured, some aren’t. This could probably be included under the Marketing category (I don’t since it is more targeted), but again, the web is the clear choice.

Browser Issues

These applications are typically community oriented, sometimes for non-profit organizations, and usually developed by volunteers. Some leeway is usually afforded to browser compatibility. Again, I believe they need to be functional across the majors at the least.

Target Hardware Issues

Lack of Hardware control

Even if you have complete control of the target audience (i.e. your sales force), if your company does not control the computers that the application will be accessed from, thin client makes much more sense. If your employees don’t have corporate laptops, and plan on working outside of the office, having to install/deploy your application on the family computer is not going to be a successful deployment model.

Disparate Operating Systems

If the target audience is running different operating systems, the common denominator is quite often the browser. In these cases, thin client is probably the only answer.

When Smart Client is Clearly the Best Answer

As a user of applications, I would say that ANY application that is not in the list above should be smart client. As an architect, I have to temper my actions with wisdom, and take ALL factors into account. That being said, there is really only one clear cut model that clearly needs to be smart client (from an IT point of view):

Occasionally Connected Clients

If your users will not always be attached to the internet, deploying a web based application obviously won’t work. Consider Microsoft Outlook. Probably the best known occasionally connected application in the world, and definitely a smart client. You can read, create, and delete email when offline. You can even “send” – items are queued until next connection.

If you are developing an application for the occasionally connected user (such as sales force automation), and you plan on giving your users portables to take out in the field, smart client is absolutely the best choice.

This concludes part one of this post. Part Two will go into the scenarios where there needs to much more thought involved, as they are not clear cut situations.

Happy Coding!