To SharePoint Or Not (as a foundation for application development)(vs ASP.NET)

Question

I have a POV that you should only use SharePoint for application development under these conditions.

1) The application uses documents and these documents need some sort of functionality that SharePoint does extremely well (searching/indexing, sync with Outlook, etc...) If all you want is a document bucket and a list then ASP.NET or ASP.NET MVC.

2) The application must use workflows or custom workflows. No workflow then again I would look towards ASP.NET or ASP.NET MVC.

3) The company must be willing to dedicate at least 1 full-time developer to SharePoint. Not 1/2 or a 1/3 of a developer. You need commitment and focus to do SharePoint development correctly. You must drink the Kool-Aid. If you are not willing to specialize in SharePoint, but only willing to dabble, the resulting solutions are terrible (IMHO). Even better if you can dedicate two developers or a team (think supportability / maintenance / expertise / specialization).

So what do you think?

note: I think all Microsoft shops should be using the out-of-the-box features of SharePoint if their company has chosen to pair that with Exchange as part of their collaboration architecture. I'm not anti-SharePoint.

UPDATE
After sitting in a SP workshop I have learned that SharePoint Workflow is only applicable on a per SharePoint List item basis. Therefore, if your workflow doesn't use SharePoint List items, then you should probably look at .NET Workflow foundation or something custom. Consider this a replacement to my #2 item.

Answer 1

I would agree. Sharepoint currently (moss 2007/wss 3.0) makes custom dev a very painful and slow process. The only point I would disagree with is the workflow portion. In my opinion the workflow in SharePoint is nearly unusable, and should be avoided. If you are going to do workflows, go for k2:blackpearl or MassTransit for the open source free option.

Answer 2

Let's say you have a data warehouse that collects data from many points in the company. Hopefully you have a few dimensions that have business folks designated as "dimension owners." These are the people that have a stake in the organization of data in the dimension. They are responsible for keeping things like hierarchies and lists up-to-date but these collections aren't populated with operations data that come from transactional systems, they're business terms and groups and descriptions that the business speaks. This is their natural business language. East Sales Team, Small Business, High Risk, Print-Ad Promotion 25, etc. The point is your data warehouse is built from 99% operations/transactional stuff but it's the business arrangements that makes it all sensible for your users and you need a place to capture it.

You certainly can make a web app. You can use an Excel file. Whatever. But you can also use a SharePoint list. Where SharePoint is attractive for this is when the environment already exists (and thus SUPPORTED), when your requirements aren't extensive, i.e., referential integrity not required, you don't have the resources to create a new web app, the business users are already familiar and comfortable with SharePoint, you need it yesterday, etc.

So I'm not talking here about writing code and compiling libraries to be installed on SharePoint. I'm just trying to present a reasonable "right time and place" for it to be used.

BTW - Here's a very handy how-to on pushing and pulling data between SharePoint lists and SSIS.

Answer 3

SharePoint should be used as a foundation for business user collaboration (that being storing, finding and editing each other documents). Using SharePoint merely for application developement hurts and requires point 3 made in the question.

For application developement, I prefer to use SharePoint as a web portal that points users to the application or hosts it's web interface (via user controls, webparts and the like)(oh wait, I all ready said SharePoint was a web portal).