views:

345

answers:

4

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.

+5  A: 

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.

chris.w.mclean
Let me clarify. I didn't say SP workflow was great. I just meant that if your app doesn't have workflow why not use ASP.NET? By the way what happened to Mass Transit. Is the project still very active? +1 on the slow and painful.
MJLefevre
Yes, MassTransit is still active. One of the lead devs on that Chris Patterson is here in Tulsa and the company he works for uses in in their internal production systems, so even if it hasn't hit v1.0 I think it's pretty stable...
chris.w.mclean
Now hopefully MSFT will fix a lot of the dev pain points in 2010. I have a small amount of hope that doing custom dev in 2010 will be a much better value proposition.
chris.w.mclean
+3  A: 

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.

esabine
I can see where you are coming from. But in 4 weeks you can get pretty close to duplicating the basic List functionality in SharePoint. And then you have TOTAL control over the app. You don't have to work through an abstraction that you have no control over. I hope MS does something to make getting data out of a SP List easier. If this is a core part of Microsoft's strategy getting data out should be as easy as ODBC. +1 Good arguemnt and link
MJLefevre
Provided you use a custom tool like MetaMan, using SP as a data surfacer for your enterprise data is much faster then coding your own. But you do lose a lot of control in the SP model.
chris.w.mclean
Lose a lot of control and $ using the BDC. Maybe if the BDC was free or standard part of SP it would be more convincing. On a tangent, it doesn't make sense charging for Excel Services (they're not very good). I really do like the way SharePoint search works over BDC data. +1 to Microsoft on that.
MJLefevre
+1  A: 

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).

Nat
I guess that means we sort of agree. I do like the idea of using it out-of-the-box, but for custom development you really need an expert and a strategy.
MJLefevre
+1 on the host point. Personally, I'm a big fan of the "iframe model" of SharePoint development.
MJLefevre
A: 

Even without documents, you can still use Sharepoint as a platform for a portal with custom webparts (maybe some of them are based on site document libraries). It is a good portal platform and my companies research portal is sharepoint based, and it works pretty well. The good thing is that with these webparts based sharepoint portal, you can still take care of permissioning issues, and presentation customiztion issues (drag the webpart to a particular zone etc, which users do a lot, btw) relatively easily. Also, WSRP type webparts work pretty well with Sharepoint.

And you are right, only if you have good Sharepoint devs, then it does make things easy for you and is a decent platform, docs or no docs.

desigeek