Rapid Business Development: Lightswitch vs. Dynamics CRM vs. SharePoint 2010 vs. ASP.NET MVC 3

Published on 03 May 2011 • Estimated reading time: 11 minutes

In this post I am going to look at comparing four technologies that can be used to build business applications easily. This post was inspired by how similar a number of products have become over the last few years—and more importantly, how the new kid on the block Visual Studio LightSwitch, which is a specialized rapid business tool development platform built on top of Visual Studio, is going to affect this ecosystem. It is important to also remember that this is being written in the LightSwitch Beta 2 timeframe, so some details may change by launch.

LightSwitch feels very similar to me to another product I have worked with in the past: Dynamics CRM, which is a Customer Relationship Management tool from Microsoft. CRM does very well in the xRM (x = extensible) scenario, where I think it will come up against LightSwitch a lot. I haven’t had an opportunity to use the latest CRM release yet, so I have had to rely on the help of experts to fill in my gaps!

SharePoint 2010 is another product I have worked with and, of course, can be used for building business applications quickly because it is the “operating system of the enterprise” and has good features for these types of applications.

Finally, while watching Scott Hanselman do the ASP.NET MVC 3 demo in the MIX 11 Keynote, I was struck by how that is very close to a rapid business-user development tool with all the new scaffolding features. ASP.NET MVC is a real outsider in this group because it is first a development toolset for web development and, maybe, a rapid tool second—where the rest are rapid development platforms or tools first.

I think the differences between these four are very interesting, and while each has its strong and weak points, this should definitely not be looked at as a “pick one only” post. There are many scenarios where you want to combine them for even better experiences.

I have broken down the issues into twenty-one(!) aspects (key points we can compare them against each other), which are grouped into six scenarios to make it easier to digest. Each scenario starts with a list of the aspects and a brief description, followed by a comparison table of those aspects.

Starting

• Ready to go out of the box: Once installed, can it do anything? Seems silly, but quick turnaround at the start—even if actual development is longer—is important, as it helps with prototyping, shows some rapid development, and hints at how hard it is to learn (for me at least, if it does something, I find I can experiment and learn quickly). It is important to note that we are not looking at making it align with your company needs here; we just want it to do something. Eating CPU cycles and RAM is not something we want either.
• Northwind Style Sample development costs: This aspect looks further than the above and examines how much more it would take to get it tailored for a company, like the fictional Northwind, to have a xRM-type system, as it can be done across all four. Fewer $ signs mean less time and/or resources for the functionality.

Finishing

• Cost for on-premise deployments: This looks at the money cost for licensing to get the solution up and running on-premise (i.e., in your company). Licensing is, of course, flexible, and this will vary based on who you are—so this is not indicative for all. It does not include such things as server hardware or common costs, for example, operating system licensing.
• Deployment Complexity: Getting a solution up and running shouldn’t be difficult for an organization, and a lot of time can be lost (and costs incurred) changing, upgrading, and troubleshooting systems that do not want to be deployed.
• Deployment Documentation: When it happens that you need to deploy, having a wealth of documentation (be that videos, best-practice guides, troubleshooting material) is vital and plays a large part in getting a solution up that works every time.

User Experience

• Front End Technology: A good-looking, feature-rich UI can seriously ease adoption, and what we are looking at here is the richness level of the technology used for the out-of-the-box front-end user interface.
• How good the standard UI looks: Completely subjective, and really this is based on what I think looks best.
• Flexibility of out-of-the-box front end: Here we are concerned about how easy it is to adjust and tweak the out-of-the-box front end.
• Themability: Corporate branding is massive business, and making sure the application out of the box looks like it is part of your business is important. It is important to note that both CRM and SharePoint can have custom front ends built, which enable this scenario—but that requires extra development. We are focusing on the out-of-the-box options here and assuming you have the theme built already.

Extensibility

• API for integration: In the short term, having an API means it is easy to get data into your new solution; in the medium term, it means more ways to sync data and mash up your systems; and in the long term, it gives you a way to get your data out. It is vital to have an API.
• Marketplace: Apple kicked the idea of having an App Store into reality for many of us, and now having a marketplace to get extensions, customizations, or themes is an important aspect. I am ignoring public sites like CodePlex and focusing only on official marketplaces. Galleries are just marketplaces with no vetting, meaning they are bigger but the quality bar is not guaranteed.
• Additional Authentication Options: Only your employees or customers (which may be everyone if you are lucky enough) should access your solutions. What do we get out of the box to limit access to the system? All four systems support Windows and forms-based authentication, so I am only listing other options available.
• Permission Structure (Authorization): Being able to control what parts of a solution you can access once you have logged in is also vital, and having a lot of flexibility in this space is important, as very seldom will one structure work for everyone.

Information Worker Features

• Offline support: Being able to work when you are not in the office is a vital need for many people. So how do these platforms enable that scenario? In theory, it is always possible to build this, so we are just looking at the out-of-the-box offering.
• Easily import data: How do we get information into the solution besides the API? Does the product make this easy with out-of-the-box tooling?
• Printing: Despite the promise of a paperless office, it still is not the case, and being able to print is important—even if it is just to XPS or PDF for invoicing.
• Office Integration: Integration into Microsoft Office products (Word, Excel, Outlook, PowerPoint, Access, Publisher, InfoPath, and OneNote) means that your IWs will be able to work in the tools they are comfortable with, easing adoption and productivity.

Other

• Databases Supported: Where the data can come from for your application is a critical piece of the puzzle because it means the difference between building ETL solutions to handle moving it around if the source is supported or having it just work.
• Minimum Skills for Tailoring: Tailoring refers to customization of a system without needing a programming language. At some point, you will need a developer, but how far away that is, and what can be done by an analyst or superuser early on, is important from a time-to-solution and cost perspective. Lower is better here.
• Can run in the cloud?: If you are not thinking about how you can leverage the cloud, you are not thinking. Making sure the solutions can cater for the cloud is an important consideration. All four solutions can run in the cloud, but how they run is also important.
• ALM Experience: How does this tool work with a full ALM experience? Can I unit test it easily? Will it go into source control easily, and what happens when multiple developers are updating the same files? How about build server and development tool integration? All important questions in understanding the complete picture of what these tools cost or what you sacrifice with some of them.
• Requires Silverlight: Despite decent market penetration and ease of deployment in corporate scenarios, the requirement for Silverlight can be a deterrent to businesses, especially those where the CEO uses an iPad2 😜. This is not answered in the table, as only LightSwitch requires Silverlight. CRM has no dependencies, SharePoint has a fallback mode, and if you used Silverlight with MVC, it would be possible to have a fallback mode—provided you developed it.
• Data performance: This is not in the table, as it only applies to LightSwitch. For CRM, MVC, and SharePoint, I assume your frontend (web) is always close enough to the database (e.g., the same LAN), but in LightSwitch, you can really separate them. Here, it is important to note that LightSwitch is not great with data performance between backend and frontend—it sends massive amounts of data around. In my view, it really does not feel optimized for WAN scenarios.

Special Thanks

A post this in-depth could not have been done without input from my “brain trust,” and I thank each one of you for your help:

• Bruce Nicholson
• Michael O’Donovan
• Adam Cogan
• Zlatan Dzinic
• George Doubinski (he has an awesome site—just go admire the work he put into it)