Silverlight and Line of Business Applications

Url: https://www.livemeeting.com/cc/mseventsbmo/view…

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 (http://www.silverlight-tour.com), 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:

http://wildermuth.com/2008/06/25/Doesn_t_Anyone_Bookmark_Anymore.aspx