Using Sharepoint as a development tool?

Question

We have been using .NET for business applications (high availability, many concurrent users) and some people here are suggesting most of these applications could be developed with Sharepoint 2010.

The main reason why they want to push Sharepoint into that area (We already use sharepoint but for sharing and managing content - where it works well) is that they think the TCO would be lower than .NET's.

I am not convinced (although I admit Sharepoint is a great and valuable tool) that sharepoint is good for developing business applications (like a product inventory app, for instance) and I think .NET is much more suitable for that.

It´s also important those applications be part of the whole SOA architecture (which is used here) and also that they support Single Sign On.

What do you guys think? Is sharepoint also a greater tool (at least cheaper - TCO) than .NET for creating business applications?

As sharepoint developers are more expensive than .NET's (regarding worked hours) isn't it strange people say it's cheaper to develop new application with Sharepoint (through .NET!!) than developing it with just plain .NET?

When one should choose one over the other for that scenario?

Cheers

Regards

Answer 1

SharePoint is a platform that provides business services. Some applications will integrate well with the platform, some won't.

Here are some of the questions you should be asking yourself:

• Can we incorporate SharePoint OOB functionality to reduce over all development time?
• Are SharePoint lists and libraries a suitable data store for this application?
• Can we use SharePoint security groups to secure this application?
• Do we have people with SharePoint development experience to build this application?

So, I guess the answer is: it depends.

Answer 2

I think the main driver is that a lot of core things that would take custom development can easily be created out of the box with SharePoint. In theory, you should have less development cycles since the only place you have to "develop" is the custom extras that you may (or may not) need. You also have the added benefit of your LOB tools being directly linked with the collaboration and social aspects of SharePoint (search, user profiles, mysites, BDC, etc). Obviously there's a potential shift in your strategy; if you have 50 dedicated .NET developers today, do you really need them all now? You might need half of them now, but find a new need for a group of SharePoint configuration people that really understand how to build good LOB systems on top of SharePoint. Typically, developers want to develop and often overlook the out of the box capability. If the go-to phrase is "we can write code to do that", they probably don't understand as much about the platform as they should (generally speaking).

When I think back to the way my previous employer used to work (a company in the DoD space that did LOTS of custom .NET), 80-90% of the stuff we were paying people to develop from scratch in .NET was basically out of the box capability of SharePoint, and we had constant issues of single sign on not working correctly, content not being searchable, content ending up in multiple places at once, and disparate systems that weren't able to talk together. While some of those issues were issues of the processes in place (and obviously not .NET itself), if those tools had been built on SharePoint, a lot of our problems would have been solved right out of the gate, leaving those precious development hours to be put to better use fixing issues, making tools better, and solving business problems.

SharePoint still has the stigma in a lot of organizations that it's a file system or a content management system, but at the end of the day it's truly a platform. It scales (if your infrastructure is built and maintained well), it's robust, and it's heavily customizable. I'm a little biased, but the vast majority of LOB systems I've seen could be built on SharePoint (most of them easier and faster than their custom .NET equivelants).

Answer 3

SharePoint is great for serving as a framework for the presentation of applications. It gives you a lot of great things such as security, navigation, document/content management and search. When I see companies leverage as an aggregator and a means to surface applications, or present data from those applications I see a lot of success. Where I see it fail time and time again is when people decide that they want to use the SharePoint like they would a relational database. They tend to put together a prototype quickly, but they bit brick wall when it comes to things like upgrades, maintenance, reporting etc. All the sudden all this data is in there and its way harder to get to than say a SQL server DB.

I tend to offer this guidance to clients:

-Loosely couple solutions to SharePoint

-Build the real LOB system as a service based application backed with a real relational database.

-Build reusable components which can be configured to allow [power] users to assemble functionality and views into the application. e.g. link records from the LOB to documents etc or web parts containing functionality / data to the LOB system.

Answer 4

Just to add my $0.02, I think it's worth noting that the two are far from mutually exclusive.

SharePoint is a platform built on .NET. If it doesn't meet your requirements out of the box you can develop custom .NET code or interface with your existing systems using BCS.

It's also likely that you can replace some of your more straightforward applications with OOB SharePoint capabilities such as lists and workflows - hopefully this will lead to reduced maintenance costs as you are using native features.