Developing a website for 3 mln. users: SharePoint OR pure ASP.NET?

Question

We need to develop quite a powerful web application for an investment bank. The bank IT would like us to build it on top of the SharePoint platform

Answer 1

I'll not go into the merits of sharepoint, but suffice it to say that I have been developing in sharepoint since it was known as "digital dashboard" - it was just a javascript-encrusted today page for outlook. With respect to its .NET incarnations, it has taken me about 3 years to become what some might call "expert" on SharePoint 2007/MOSS.

First up, let me give you some warnings concerning the politics of these kind of jobs. As a contractor, ALL of my jobs over the last 6 years - covering shaerpoint 2003 and 2007 - WITHOUT fail, have been getting about me on site with a client who has demanded sharepoint, and a development shop with decent ASP.NET developers who have become hopelessly lost and more than likely have blown 95% of the budget on the last 5% of the project because they have embarked on writing custom extensions to the platform without fully understanding the product.

If clients, and the shops who service them, spent more time understand the product and studied it to see how they could change/streamline their business processes & requirements slightly to suit sharepoint instead of being rigid in their specs (that were ALWAYS written with next to zero real experience of the platform) and deciding to get custom development done, then more sharepoint projects would be delivered on time and on budget. Sadly, this is not the case.

So, number one: SharePoint 2007 is an excellent product, but please, for the love of jeebus, find yourselves some top gun sharepoint developers who really understands the product before you embark on this journey. If you don't, you will all go down in flames.

-Oisin

Answer 2

This is a matter of what kind of concerns you want to have in the application:

• Building it to look and function your way, go with sharepoint.
• Building it to have infrastructure for authentication, permissions, http/web security, scalability, backup, database maintenance PLUS getting it to look and function your way (but now way more under your control), go with a more pure .NET approach.

I would pick the one I am best at, as Kevin said above.

Edit
More about Kevins post: you can also have your application under sharepoint but with full access to the API, in my projects we do it as a normal ASP.NET application, with own masterpages and everything, but we still use the authentication, lists and doc libraries for uploads, roleassignments for permissions etc. Its a very viable hybrid.

Answer 3

Welcome to the dark land of politics.

It's worth making sure that your team properly evaluate and understand any compromises that SharePoint will have you make. Asking here is a good start. Things I'd look at include:

• What's the whole solution going to include? Often the administration of a site can involve as much or more development work as the front end. While the 3M+ user front end is the glamorous part it may not be the bulk of the work.

• Are there reference sites for 20K+ simultaneous user SharePoint sites? Honestly? What kind of hardware did that require? Is that available?

• Get a small group of experienced contractors in for a few weeks to properly estimate the work, both on ASP.NET MVC and SharePoint. Make sure they've worked on large sites. (There's plenty of contractors around at the moment!)

Also, anticipate failure. Have a fall-back option:

• If the MVC technologists win out, expect heat from senior management, and possibly even a skunk-works we'll-do-it-properly-anyway project that duplicates your efforts.

• If you do end up with SharePoint, listen very carefully to users throughout the development process and be prepared to create Web parts, MVC pages or whathaveyou to address problem points.

I've been in a similar situation where it turned out that there was heavy vendor influence at a very senior level. The senior team had bought into SharePoint and required it to be used for all internal systems; the OCTO (Office of the Chief Technologist) had mandated open-source technologies. It was fun to watch the fur fly in the middle.

(Our option in the end was to use a service-based architecture based on REST, which effectively booted the current version of SharePoint out of the system altogether.)

Answer 4

SharePoint is a lot of work and with that amount of users I personally (and being a SharePoint developer) wouldn't bother.

I would go down the ASP.MVC route in all honesty and not because it's new and the latest buzz technology. I would use it because it's hands down faster. This site for example is written in ASP.NET MVC and it handles all these requests per day on I think 3 servers. 2 front end and 1 database. Correct my if I'm wrong with that.

Answer 5

SharePoint development can be tedious but I'd hardly say the platform cannot be easily customized. I recently began developing with it full time and so far, I impressed at it's flexibility and suitability for my application but my needs are quite different from what you've described.

I understand 2007 is a vast improvement over 2003 so perhaps your information is only outdated. I hear 2010 is going to again be a significant improvement.

It's your job to deliver the functionality that the customer desires. If they desire a SharePoint solution, unless there's some particular reason why SharePoint really is a weaker model, that's what you should be able to deliver. In the event that SharePoint isn't a good fit, you need to be able to explain why to the bank's satisfaction. I'm not convinced "We don't know SharePoint" is an acceptable response in this situation: the bank's inclination should, at that point, be to find someone who knows both technologies well enough to deliver a product in SharePoint or better explain why SharePoint isn't actually what they want.

Answer 6

The problem with asking whether Sharepoint is easy to customize is that there's a wide range of levels of customization people are experienced with. And for some reason, most people also seem to think that whatever level they customized Sharepoint to is the extent to which anyone else would also try to customize Sharepoint.

It's hard to talk about degrees of customization in concrete terms. What is "customization" to me is wrangling with the core DAL, fighting with bugs in the CAML to SQL query optimizers, overriding the SPListItem hydration pipeline, etc. To others, "customization" might mean building some web part widgets and deploying them in a WSP. If you find that there is some impedance mismatch between your logical model and Sharepoint's working model, you will have a really hard time reconciling the two.