Silverlight and Line of Business Applications

  • Jun 26, 2008 at 3:01 AM
  • Shawn Wildermuth


Silverlight Logo

In case you didn't catch it, I participated in a webcast called geekSpeak.  This webcast was hosted by Glen Gordon and Chad Brooks. The topic today was "Silverlight and Line of Business Applications". While geekSpeak's usually focus on hands-on examples of creating code, we took a different tact today and discussed the larger topic of where Silverlight fits in the development ecosystem (at least Microsoft's ecosystem).

For my money, the real benefit in Silverlight is for applications that cross the firewall. This means Line of Business applicaitons are really for B2B and B2C solutions. Unfortunately, what I hear from the community is that people see Silverlight as a solution for porting their desktop and traditional 3-tier applications to the web. Is this a good idea? I don't think so. The problem is that desktop development usually involves business objects that tend to have a direct connection to the database. Moving these sorts of applicaitons to the web means that you need to create an extra layer of communications and serialization. There is a cost both in development and performance for these extra layers.

It comes down to a key question...why are you moving to a web model for your application? If you want to expand the reach of your application to more users and clients (outside your organization), Silverlight is still a great story.  Unfortunately many organizations see web applications as a deployment solution. No install, no framework, etc.  While clearly this isn't true for Silverlight per se, its also a bad reason to go to a web application. Technlogies like Click-Once and XBAP are a great solution for a better deployment story than traditional desktop applications.

Since I brought up XBAP, let's plug it a bit. I notice that even amongst WPF guys, XBAP is a lost story. If you're not familiar with it, essentially its an in-the-browser WPF applicaitons that is deployed via manifest files (e.g. like ClickOnce). This means you can have the richness of UI, the better data binding story and interactivity that WPF/XAML affords you without having to deal with the limitations of Silverlight. I suggest that many organizations that want to use Silverlight for internal applications (inside the firewall) should be doing XBAP instead.

So what about ASP.NET/AJAX? The big story here is that HTML-based interfaces still have the longest reach of all the Internet enabled applications. HTML just works on many more platforms and browsers than Silverlight or Flash. Before you commit to moving away from HTML-based UI's, spend some time with your server logs.  Understand who is really using your existing application before you leave anyone in the dust. A better strategy is often to include fall-back functionality. For example, in my Silverlight Tour website (, I decided that developers may have Silverlight installed so I wanted to give them a better experience by showing an interactive map of tour stops. But their bosses and accounting departments were unlikely to have it installed. In that case I made a design decision to never prompt to install Silverlight, but instead if it wasn't installed to show a simple table of the classes instead of the Silverlight app. This is a great solution to moving forward without leaving old users in the dust.

Why is Silverlight not a good solution inside the firewall? The two issues are infrastructure and security. In order to build solid line-of-business solutions with Silverlight, you need to have a way to communicate data with the server. Building this infrastructure can be labor intensive, but more importantly adds complexity. More moving parts == more than can go wrong. Security is the second issue. Silverlight (for good reason) is pretty locked down. This means you will need to often learn to work in tighter confines (limited access to storage, no access to file system, registry, ports). If your application is meant to work in trusted scenarios (e.g. Integrated Windows Authentication), the limitations of the high-security environment will be a real limiter.

So what does this all mean? I still think Silverlight is still the solution when you need to *extend* the HTML model in the browser. Line of Business applications across the firewall still need to be web driven in my opinion, but enhancing that story with Silverlight for soutions like data visualization, user interactivity or media is a great solution. While I think that creating whole-browser solutions make sense for some applications, it doesn't for many many more. My fear is that we will move from monolithic desktop apps to monolithic Silverlight apps.  The web is still a disconnected model and deciding on building a single huge Silverlight app (instead of page-based functionality) just doesn't make much sense. If you are planning on building one of these monstrocities, please also read my recent blog about linkability in Silverlight:




Jonathan Thursday, June 26, 2008

What is your opinion of frameworks like VisualWebGUI by Gizmox? It provides a way of building a single UI and rendering it in html, silverlight and wpf coming soon. Are there any other alternatives to this product?


Sebastian Thursday, June 26, 2008

What about one of the main things of silverlight? cross-browser, cross-platform?? You dont have that with XBAP, also if your application needs to change the content very often you get extra overhead if you do it server side with, even if you use ajax, so silverlight is a geat solution for scenarios that has to do extensive client side work and needs to support many platforms and browsers.


Shawn Wildermuth Thursday, June 26, 2008


Clearly XBAP isn't a solution for multiple platofrms, but in my experience many of the XBAP is a solution for many enterprises that want to do Silverlight inside the firewall where they have control over the OS/Browser.


Terry Thursday, June 26, 2008

I think SilverLight will definitely eat Asp.Net's lunch in the near future. I used to build web sites requiring Flash and Acrobat plug-in. I not only stated it clearly on the login page that users should install those plug-ins but also offered friendly installation URLs. Just a few clicks, they'd be ready, and I will do the same once SilverLight becomes GOLD.


J. Ambrose Little Friday, June 27, 2008

As of today, I still (after all these years) would say the pre-eminent deciding factor between WPF (or WinForms, or even XBAP) and Silverlight (or ASP.NET/other Web technologies) is reach.

If you know *for sure* that everyone that needs to use your app is going to run PC w/ the target .NET framework or is willing to use VMWare Fusion or Bootcamp, then you can save yourself a lot of headache by going with WPF (or sticking with WinForms, if that's what you have).

That said, I would caution against pigeonholing Silverlight into just a "Web technology" for (most of) the masses. It definitely should be considered for LOB, and as it matures, this will only become truer. As its facilities mature, there will be fewer and fewer reasons not to just default to Silverlight (for the greater reach) and upgrade to WPF if your application needs require it.

With this in mind, I'd say it is worth considering Silverlight for LOB even now for new development, but I'd probably hold off on porting any major WinForms LOB apps today. In that case, maybe just start with portions that are either the most painful for users or that you need to gain greater reach with.


Vimal Upadhyay Tuesday, September 15, 2009

Good write up, but still i think focused on more technical side could be usefull.


Kajal Kr. Das Saturday, January 9, 2010

Dear Shawn,

Need your valuable suggestions on the following scenario:

We are supporting an LOB WinForm application for one of prominent consumer product companies. The application is based on .Net 1.1 framework and has its own complex framework, which sits on top of .Net framework. The application is deployed in both back office desktops and field force laptops. In laptops, the application always works in disconnected mode. At the end of day, the laptops are synchronized with backoffice (this process, over time, is taking longer and longer time, thereby creating bottlenecks). Field force also has handheld devices, which are also synchronized once a day.

Of late, both the client and us, are thinking about upgrading the technology in order to cater to the following:
a) Deployment issues (deploying the application in so many laptops and desktops, after every 2-3 months, is really a pain).
b) Licensing cost of softwares, which are required to be present in all the machines.
c) Voluminous processes like Laptop synchronization, interfacing with SAP are slowly becoming bottlenecks.
d) The look & feel and usability features are becoming obsolete.
e) The UI layer being very thick, performance in some parts of the application, is becoming another area of concern.

Presently, we are thinking about renovating the application with a new framework based on Silverlight + WCF + SQL Server 2008.

Please let me know your opinion.

Best Regards


Shawn Wildermuth Sunday, January 10, 2010


Unfortunately you're asking for a pretty deep opinion that I would be afraid of directing you the wrong way. I'd suggest you find someone who can come in and asset the situation and make an informed opinion. It too easy for me to make assumptions about your project, your team and your situation in this forum.

Leave a Comment