What is Sharepoint development from a developers point of view?

Question

I hear a lot of talk about Sharepoint these days, but I'm having problems grasping exactly what it is through all the enterprise and marketing jargon. Trying it out hands-on seems too much of a hassle as well (several heavy software packages that you can't just download for free).

Could someone give a good developer-to-developer description of what Sharepoint is? I'd especially like to know what Sharepoint developers generally do.

Answer 1

== Edit 2017 ==

This is a fairly old post and SharePoint have changed a lot the past years. Most parts of the original post are still valid but some would only apply if you do on premise installations where the future of SharePoint seem to lean towards SharePoint Online. That being said, most functionality are still there with some improvements.

== Original post ==

SharePoint is a very complex CMS (Content Management System) with a lot of nice BSS (Business support system) features. There are so many advantages of it that it's hard to limit what to mention. However, some of the obvious stuff would be that you can mix so many "environments" at the same server, these environments are separated as sites.

What do I mean by environments?

Let's say you run a logistics company and are sick of having so many different systems just to keep your business up and running. Many of the systems also have different providers so the ecosystem around the company gets equally complex as well, here comes SharePoint to the rescue since it's a system that actually can host all required environments. In example.

• External web page, hosted either by SharePoint or by an integrated web page
• Order management
• Customer support and ticketing
• Item handling of freight
• Intranet sites with document management

Each and every of these environments can benefit from SharePoints built-in features like workflows and custom content types.

I'd say that the foremost reason to choose SharePoint would be it's versatility of storing different types of data. It's not a system to choose if you are planning one million transactions each second even if the performance can be greatly upgraded with several servers in a farm.

My point of view as a developer is that SharePoint is pretty much all about the lists, libraries and the metadata store since it's where most of the data is kept. This is something you need to learn and to understand how to structure your data and how you'll implement your information model.

The most common assignment in my world would be integration SharePoint with an external CMS, like EPIServer or Joomla, to set up an integration where the visitors shall be able to send messages from the web directly into SharePoint. These assignments then trails into creating a workflow what will happend with this message when it's received by the customer support / sales staff or whatever, all the way until the errand can be closed. When done with this I might build some graphs in a custom web part using mschart displaying some sales data or statistics of support errands. Currently im planing the data structure using SharePoint as a webshop. And there you go again, versatility!

There is also a very powerful API in SharePoint if you are into integrations. I am myself involved in the production of an ADO.NET Connector for SharePoint which turns SharePoint into a SQL server enabling developers to skip using CAML. And, there are plenty of other cool tools out there.

Let's not forget the second biggest advantage of using SharePoint. You can focus on forward development, the backend is already there.