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. 

 

Lines 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.

 

Browser Issues

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.

 

Browser Issues

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 in 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.

 

The Not So Easy Choices

If your application doesn’t fit into any of the above scenarios, how do you (as an architect) recommend on model over the other?  Keeping in mind that applications are only as successful as their adoption, my philosophy is to lead with the smart client approach (WinForms or WPF) until I encounter a factor that rules it out.  The factors that must be investigated include deployment issues (verifying the correct .Net Framework is installed, initial application deployment, application updates), Security, and Data.

 

Deployment Issues

 

.Net Framework Install

Whereas the developer can assume the user will have at least one browser installed on their computer (maybe not the correct manufacturer or version, but that’s a topic for another article), this is not true for the .Net framework.  The correct framework is available through individual download, windows update, installed through ClickOnce, or via a bootstrapper in an MSI package for your application.  This typically is not a blocker.

 

Initial Installation

If your application is going to require any COM components (or anything that requires the registration), you are going down a perilous path that leads straight to DLL Hell.  If your application can NOT be developed entirely in managed code (along with any third part components such as reporting packages), then the application is not a candidate for smart client deployment.

If your application is completely managed code, the initial installation of the application can be accomplished through Click Once, MSI, or xcopy deployment through the company’s network via various network tools.  However, installation needs to be more than just getting the correct bits onto the users’ computers.  The application also has to be easy to launch (“Where’s that thing I click?”).  Both ClickOnce and MSI packages can add the launch icon to the correct locations (typically the Windows Desktop and the Start menu).

 

Application Updates

The initial installation is by far not the largest deployment hurdle.  It is managing the deployment of the application updates that proved to be the downfall of the Client Server applications.  This is where MSI loses.  However, as long as the application is still 100% managed code, ClickOnce and the various network utilities will handle this wonderfully.  There are instances where it makes sense to roll your own update mechanism, but the factors to consider go beyond the scope of this article. (that will be the topic for another article).

 

Security

When developing thin client applications, the security focus is on such things as SQL injections and other hacking techniques.  Physical security is not usually a concern, since the datacenters are typically well protected.

With smart clients, the application (and potentially a copy of the data) is installed on the desktop.  How do you store the connection string?  What about reverse engineering of the application?  What about any data stored on the computer?  Laptop thefts are more common, not for their hardware, but for the data and/or passwords they contain.  While this is not an article on security, and all such items need to go through you corporate security group, here are some commonly used techniques to handle these issue.  If your security personnel do not approve, or the security implications are deemed too much scope, than I would recommend developing a thin client.

 

Connection Strings

A common technique is to not store the connection string on the client computer.  The client will contact a web service that in turn returns the connection string to the client after some form of authentication.  The other (simpler, but arguably less secure) method is to encrypt the connection string in the application’s configuration file.  This then becomes an issue of key storage. 

 

Preventing Reverse Engineering

.Net code can be easily reverse engineered (just download Reflector and open up some of your assemblies).  The solution to this is a technique called obfuscation.  There are several commercial products that will handle this for you, but this adds an additional level to the deployment of updated assemblies.  If you have multiple assemblies in your application, they either need to be redeployed in their entirety, or you need to get a product that can handle differential obfuscation.

 

Data Security

If your application is occasionally connected, and you are storing data on the user’s computer, data security is a concern.  You have to be using a local data storage solution that supports encryption (such as most versions of SQL Server).  Storing sensitive data in raw XML is certainly not a viable solution, and will get you on the 6:00 news in a hurry!

 

Data

If the application will be storing data locally (such as an occasionally connected application), then there are several factors to contend with.  How do you merge the local data back into the main data store?  What concurrency model is to be used?  There are several products that will handle merge/replication; it’s a matter of picking the best one for your application (or at least one that your corporate policies will support and meets the requirements of your application).

A tougher question is how to handle concurrency issues.  Of course this isn’t a smart client vs. thin client problem; this is a problem with any application that has data and more than one user.  However, it is magnified when there is more than one data store as in the case of occasionally connected users.  For the purposes of this discussion, I will simply state make sure there is only one System of Record (i.e. avoid master-master replication schemes), and pick a tool that has merge replication built in.

 

Summary

So, where do we end up?  The one common thread running through all of these scenarios is (to borrow an oft-quoted term by a good friend of mine, Leon Gersing) “Critical Thought”. The deployment decision must be carefully examined to make sure that you business application is providing the best user experience possible while also covering all of the “ilities” necessary for long term success.

 

written by Phil Japikse

Phil has been working with .Net since the early days, and developing software for over 20 years. Phil is currently developing smart client applications with Windows Presentation Foundation for the long term care industry, and just completed architecting a set of Commerce Server 2007/BizTalk solutions for a Fortune 50 company along with teaching them implement Scrum/Agile practices. A Principal Consultant with Pinnacle Solutions Group, Inc. (a Senior level firm specializing in Custom Software, BI, and eCommerce solutions located in Cincinnati, OH), Phil is an avid .Net Application Architect, Developer, and Speaker.  Phil currently holds certifications as an MCSD, MCSD.Net, MCDBA, Scrum Master.  Phil also serves as a Firefighter/Paramedic for the local fire department.