I have been spending some time on the idea of using SharePoint as an application hosting platform, as opposed to using regular ASP.NET applications. Some solutions are a great fit for this, others are not. My main goal is to describe some pros and cons, in order to help make the decision between the two frameworks. Please note that, although I have invested some time on looking into this, this is not an official Microsoft position on the matter, just my personal view.
There are many things that SharePoint provides beyond what you regularly get from an ASP.NET environment (which is already fairly rich). Here's a list:
1. Authorization and Authentication
Before you start developing your application, you usually have to figure out a way to manage user access to your app. In general, you need a way to allow specific users and groups into your app. Many times, software developers need to build the ability to add users and add permissions to those users. I've seen people spend quite a lot of time on those.
If you decide to base your application on SharePoint, you basically get the entire infrastructure to define roles for your application (a set of permissions) and also to add users to the application under a specific role. This is fairly straightforward both from the user perspective and from system administrator perspective. In the end, it's a consistent experience across all applications and you don't have to code anything to make it happen. It's also important to notice that you can use different types of authentication (including Active Directory and LDAP, provided out-of-the-box) or even change the type of authentication, while your application will work just the same. SharePoint 2007 also hides items and actions a user has no permissions for (this is known as "security-trimming"). Because there are defined in the infrastructure, it's simpler to future-proof your app as new technologies become commonplace, like Federation.
2. Storage and Data Definition
When you develop your application, there's usually a database (or a few) that goes along with it. In the early stages of your application lifecycle you will define what data you need to store and that will end up in a set of tables somewhere. Your data architecture team will define what the data should be and your database team will eventually define the tables, columns and views you will eventually implement. In the end, your ASP.NET application will be tied to a database server somewhere by something called a connection string.
If you're using SharePoint, you get a place to store your data. No direct SQL Server access. No connections strings specific to your application. Instead of tables, you get SharePoint lists and libraries. You can create custom lists with custom columns that look a lot like the tables. You can also have links between lists like using lookup fields, which are very similar to a foreign key in a database table. When you deploy your application and create a new instance of it, the data elements are there.
3. User Interface, Menus and Navigation
Another item that architects can spend a lot of time on is UI. There's no standard for how a web application should look like and the way to layout menus, toolbars and icons. The whole Web 2.0 thing and AJAX did not make it any easier. If you're developing an ASP.NET application from scratch, expect to spend some time defining how your application should look like. Then expect to have that change (sometimes dramatically) over the life of the app. Master pages in ASP.NET 2.0 are supposed to help with that. It won't help your team agree on a specific UI, though.
If you go the SharePoint way, you do get a good set of out-of-the-box UI framework. In fact, if you want something simple, you can just use the out-of-the-box templates and build from there. You get quick launch menus (usually on the left), top bar navigation, search toolbar (usually on the top right), application settings (usually a drop-down menu also at the top right), etc. This is fully customizable and you can choose to disable or enable any of those elements. SharePoint 2007 takes full advantage of master pages and re-branding a site is fairly straightforward. You can also create a set of pages in SharePoint that work as a front-end to your application, hosting web parts. A common scenario is having different pages based on your specific role on the application, with links to these from the quick launch menu.
4. Usage Reporting and Auditing
Another thing that is commonly required in this day and age is the ability to track application usage. This can go from simple usage reporting to full blown auditing down to the record level. With all the regulatory requirements these days, you might just be force to do this. If you want to build auditing in your ASP.NET application, you will need to write the code to track the events, the UI to configure what gets tracked and also the reporting on the results.
In a SharePoint, there is built-in functionality for both Usage Reporting (overview on how many users hit your app, what areas are most used) and Auditing (who deleted a specific item and when, list of all users that acessed a specific item, etc). You also get all the tools to enable and disable these at the application or list level, which can save a lot of work...
5. Basic Data Entry
In any ASP.NET application, there will be the need to enter data. Some of it is the somewhat mundane data entry into forms, data validation, etc. It is fairly simple to create an ASP.NET page, drop a few controls there and let users add/update/delete records into a table. Again, this is a low-value activity that you can delegate to a junior developer or outsource. You can also leverage from of the datagrid components that will provide a good set of abilities without much work.
If you define your data as a SharePoint custom list, data entry is a given. Just click on the "New" button on the list to get a form to add data, according to your column definition, complete with data validation, drop downs, checkboxes, etc. To take it a step forward, you can use InfoPath and Forms Server to create more sophisticated forms, all rendered via a browser interface. Another way to "enter" data is to mail-enable a list and allow data to flow in via e-mail in some scenarios. You can also upload documents, complete with check in, check out and versioning. Pretty hard to code and manage those in a regular ASP.NET app...
6. Views and Reports
An important part of your application is the ability to provide reports. You can write those in ASP.NET. It shouldn't be too hard to craft a SQL SELECT statement to get the data you need and then render it using HTML tags or a nice ASP.NET control like the datagrid. You can also use SQL Server Reporting server for more flexible and user-customizable reports.
SharePoint apps will get an out-of-the-box ability to create "views". There are basically reports on a list created in SharePoint. You select the columns, the sort order, filter records on a specific criteria, group by specific fields, aggregate totals and averages, etc. This is something that does not require any development, but just interacting with the built-in UI (assuming you have permissions). You can have many views on a list, including datagrid-style view with editing capabilities. You can also have a mobile view, which facilitates browsing from the the more limited browser in a smartphone or PDA. SharePoint can also leverage SQL Server Reporting Server.
It is fairly common to require user notifications from your application. A common scenario would include the need to send an e-mail to a group when a new item is created or when an item is changed. If you can send mail from you app, that's not so hard. There's also a common requirement to provide RSS feeds, which are not hard to code. You will like need to spend some effort on how to configure those, if decide to allow user configuration on who gets the alerts or what fields are included in the RSS feed (instead of hard-coding those).
SharePoint does include a feature to attach alerts to lists and you can also provide RSS feeds from any list. So you won't need to spend any time write coding to send e-mails or provide RSS content. More important, SharePoint provides the ability to manage those alerts and RSS feeds. You can set up alerts for you or anyone else in your team and they will get notified you create alerts on their behalf. You also have an out-of-the-box capability to customize the fields in your RSS feeds for a specific list.
8. Office Client Integration
Another common ask in web applications is the ability to interact with the Office clients. For instance, you might want to somehow integrate with Outlook or you might require the ability to upload something from Word. These are usually hard to code, since it turns your application into a distributed one, with issues around synchronization and all. If your application needs to upload files, you might end buying a control to provide that in a user-friendly way.
That's an area where SharePoint shines. For any list, in addition to RSS support (which integrates nice with Outlook 2007), you have the ability to download data into Excel and Access. You also have the ability to connect lists with Outlook, which you can take offline, update and then sync back with the SharePoint list when you're connected again. Included is the ability to save files to SharePoint libraries directly from the Office clients like Word, complete with required columns being enforced. All of those are built in and could be leveraged as part of your application.
9. Deployment and Scalability
ASP.NET applications are deployed to IIS. You can package them and deploy to any web server in your environment. However, you still need to be careful managing thins like the application pool you'll use, the URL associated with it, the connection string to your database (which can be external to your app, in the web.config file), security, how your load balance your application, etc
In SharePoint, your application gets deployed in a site collection in SharePoint web application in a farm. It ends up being again deployed to IIS, but it comes with pre-configured details around application pool, URL, storage, security, host headers, etc... You package those "solutions", including metadata in XML (column definitions, list definitions, workflow definitions, etc), code (web parts, custom workflow activities, etc.) and actual content (list data, HTML pages, documents, etc). Those can be two types of packages: a template (saved from a prototype, using an option in site settings) or a solution (new in 2007, created using Visual Studio). After you packaged your SharePoint applications, you can deploy them once and have them available to the entire farm. The trick is to leverage the built-in ability to deploy solutions to the configuration database to have them deployed to each web front end server via timer jobs (this includes copying files to the server, registering assemblies, etc). Again, you're leveraging the infrastructure, so your SharePoint apps will share that infrastructure. You also have full support for having multiple instances of your application (multiple site collections using the same template or site definition) running side-by-side on the same server (this is referred to as multi-tenancy).
Last, but not least, you need backups. You ned to backup your data, of course, but you also need to make sure all your configuration information is properly saved. If you store everything in SQL Server, you might be able to get away with saying "backup your database and you'll be fine", but you might need some additional work if you customize your web.config or you store some information on your web server. Ideally, your application would need to provide a UI to allow an admin to manage backups.
SharePoint, especially in 2007, has a great backup and disaster recovery story. First of all, absolutely all SharePoint data is hosted in SQL Server. Not only the content, but all the configuration as well. If you add another web server, for instance, and attach it to the existing configuration database and enable it as web server, you will get a fully functional web server, with all the IIS application pools and web configuration done automatically. You have the capability to backup the entire set from SQL or you can do backup at the site collection level as well. There is a web UI to manage backups.
SharePoint can help you with many of the architectural details around data, user interface, security and management. Those would otherwise take some time to tackle if you opt for a plain ASP.NET application. In fact, many solutions could be developed in SharePoint without actually writing much code (or any code at all). As architects and developers become familiar with what SharePoint has to offer on top of ASP.NET, they might shorten their application lifecyle and standardize many aspects of their infrastructure, ultimately reducing complexity and cost in creating, deploying and managing applications.