WSS/MOSS Development ... Where to draw the line?

Question

Our organization started on the SharePoint path about two years ago. Before that, we (the developers) wrote mostly asp.net front ends for SQL back ends. Now it seems like every time a new project comes up, we are asked to “make” it fit in SharePoint; and we have stuffed some things into SharePoint that probably should have been stand alone applications or web applications due to complexity and interactions with other technologies.

My question is: Where do you draw the line as to developing a project in SharePoint versus Web/Winform application, and how do you convince your manager(s) that SharePoint may not be the best solution for a particular project?

Answer 1

I sort of agree with you that this is sometimes a tough question. In general, though, I agree with the cliche that you just have to think about a sharepoint app a little differently. If your data can be considered as list-based, then SharePoint probably isn't a necessarily bad development framework. It may seem like more work on the surface, but IMO the challenges just move from one place to another. If you use things like custom field templates and web parts, you can relatively naturally handle all sorts of data. And you get the positive aspects of SharePoint for free (an already mature security framework, built-in searching, site and list templates/definitions, personalized page customizations, yada, yada).

I also I don't know what you mean by "complexity and interactions with other technologies" here, so it's hard to imagine what specific issues might be introduced when SharePoint is added to the mix.

If your dev team is relatively inexperienced with SharePoint and you care about quality and deadlines, I can definitely see your point. It's not an easy learning curve, but I think the SharePoint product is more naturally extensible than many people give it credit for.

Answer 2

One thing to consider when trying to 'integrate' a new app into the existing pool is whether there is any overlap in data (customers, inventory, etc) that would benefit from the merger.

There is also the benefit of being able to back up multiple applications and all of their respective data in one place.

Answer 3

There is, in some cases, a third option between a SharePoint application and an ASP.NET application. You can build custom site and application pages and deploy them to a SharePoint site. (The book Inside Windows SharePoint Services 3.0 gives a good overview of how to do this.) This will allow you to use ASP.Net and SQL Server within a SharePoint environment (which means you can also take advantage of things like SharePoint security). It's not as easy as developing a plain ASP.Net application, but it's a compromise.

Of course, this is sort of a technicality if they're wanting these new applications to be built on SharePoint technologies (lists, libraries, workflow, etc.), not just to be "inside" SharePoint.

Answer 4

Why are they asking for it all to go into SharePoint?

In my experience it is because the 'ole SharePoint intranet is being great as a portal to keep everything together and findable under the one information architecture.

Approach the issue from a uses perception of the application space in the organisation.

So long as the application looks and feels just like part of the intranet site and the user does not have to think about how to get to it (and how to get back out), you can pretty much take any architecture decisions necessary to get the best bang for the organisations buck when it comes to implementation and maintainence.

When we started thinking about the site less from SharePoint vs other stuff to the nice woolly concepts of Information Architecture, findability and usability, our decisions not to make it actually inside SharePoint, but still skin it like the Intranet became easier to sell.

Answer 5

One of the primary reasons why you might put an applicaiton in SP is when you want to take advantage of the building blocks SP gives you:

• Security (share security with the site)
• Data (store some or all of your data in lists)
• Provisioning (if you want you app on multiple sites)
• Some basic data UI e.g. Lists give you that and you dont need to build it.