I am working in a company with huge DotNet team. We currently have MOSS 2007 license which I assume is a costly one and just one administrator working/maintaining all Sharepoint stuff.
I felt that Sharepoint is not being utilized to its potential. Being interested in Sharepoint Development for past 1 year (I am a .NET Developer with 6 years of exp) I offered my help to our Director, his first question was
"Why do I need a Sharepoint Developer?"
Now I need help in selling a "Sharepoint Developer" to my director.
I would be glad to provide any more information you need about the company or current utilization.
EDIT: Just want to elaborate more on my company's scenario. We have sharepoint being used mostly for Internal use like Raising Service Tickets, Maintaining Networking Stuff ( Servers, Sites, clients details), Document Sharing with Clients.
If you want the official “value proposition” of SharePoint, it goes something like this; the product already has a lot of common application behaviours built into it (doc management, access control, search, etc) therefore it streamlines development by being able to build directly on top of these features rather than building them from scratch. It’s a .NET based environment so your current developers can leverage existing skills.
However, it’s not all that simple. There’s a very solid learning curve, you need to develop directly on a Windows Server and the lifecycle and deployment of apps if very different to ASP.NET. Have a read of What are your biggest complaints about Sharepoint? and also The hidden costs of building on enterprise software platforms.
Ask him how much time your team spends coding/planning/worrying with:
Authentication
Security
Document Management
Versioning / Change History
Records Management (on a very light sense)
Backup / Restore support
Load balance
Multi domain support
Separated Content Databases
Content Collaboration and user-created structures
Theme support
Syndication
Outlook integration
??
And how much time you ACTUALLY worry/code/plan implementing your BUSINESS RULES
SharePoint is far from perfect, but in a .NET world it is a hell of a good start to get things done without reinventing the wheel.
Why do you think you need a sharepoint developer? What can more/better sharepoint development offer from a business perspective? Does it do thinks either faster, cheaper or better than you currently do them? You need to be able to verbalize this for management to buy-in.
Does the existing administrator have a technical background? Perhaps as a developer? If not, then yes, there is value in having a "Sharepoint Developer" handy as soon as you want to do anything even remotely outside the box in SharePoint.
Want to extend the functionality of your lists/libraries? You'll need to know how to create a CustomAction in .NET, or know how to combine JavaScript/JQuery with ASP.NET webservices to do so.
Want to create some custom rollups for reporting? Do you folks track tasks/project information in SharePoint? You'll need to understand ASP.NET server control fundamentals, and possibly XSL so that you can whip something together using SharePoint designer.
Maybe you want to standardize your content (calendars, tasks, etc.) through custom content types. You'll need a development background to understand how to provision this using SharePoint's solution/feature mechanisms.
Or perhaps your director would be interested in reporting? If you pick up a third-party reporting tool such as Dundas Charts, good luck making anything remotely complex without having a development background.
These are just some things off the top of my head..
Point out the business benefits that your company would IMMEDIATELY derive by doing / going Sharepoint. In your spare time at the office, create a proof of concept perhaps that you could parody with your director in able to get his/her nod.
As someone who once was a sharepoint developer, it is hard to add value to that product. It will mostly be cosmetic changes or something you find to be really cool, but at the end of the day SP already provides the functionality. Also if you do something amazing with it M$ will eat your lunch.
I worked on MS CMS (which preceded MOSS) and the people who stuck with MOSS are earning good money - but proving business benefits to the skeptical is very difficult.
To sell yourself to your director you need to demonstrate that MOSS will either save the company money or help generate extra cash. From your brief company description I would reckon that cost focus is the way forward.
So ask your boss what are the three biggest cost savings that your company wants to make in the next year (there is always a focus) and (if you think it is worth asking) the three areas where the company is looking to expand.
Then go away and work out how MOSS (or any enterprise level CMS for that matter) can support and possibly improve the chance of meeting these objectives. If you can do that and present the director with some focused, manageable projects then you may be on the way.
Related
I've started to wondering whether ASP.NET Webforms/MVC even have a place in the web developers toolbox anymore... It seems that CMS systems like Umbraco have replaced the web developers job. Yes I know that those CMS systems are built with ASP.NET Webforms/MVC - however is there even any reason for learning those things if all you gonna do is to use a CMS system anyway? - Also I cant find any situation where a CMS system can be replaced by your own web application.
My question is therefore: Is there any reason for learning Webforms/MVC when using a CMS?
EDIT:
My question might be more like: When should I use a CMS, and when should I go and build my own web app?
The problem with CMS solutions, and I mean all CMS solutions (not just Umbraco, or other .NET solutions, but in any language) is that you will always pay a price for using them. You may gain more from the time-savings afforded by using the CMS, but there are trade-offs to consider:
You will sacrifice a great deal of flexibility
You could pay a significant performance penalty. Many CMSs load a large amount of modules and code to service every request, and much of this is not relevant to a particular page function. (though some CMSs are more monstrously heavy than others!)
The future of your project is tied to yet another vendor, and their own choices
Very often, you rule out the possibility of using other databases that might have better fit your customer's needs (Umbraco doesn't support PostgreSQL, Kentico only supports SQL Server)
Once you start using a CMS you will be tied into satisfying the architectural decisions and API of the CMS framework, and you could eventually be backed into a corner.
This can be particularly problematic if your 'site' is more of a web application than a pure content delivery site. In such cases it can make more sense to choose to build using the full flexibility of the web application framework, rather than risk getting backed into an architectural corner.
On the other hand, if you are building a web site that has potentially hundreds of pages, with a lot of user-contributed content and is much less of a web application, then often a CMS is the way to go, and makes a lot of sense. But remember, you now have two frameworks and two APIs to learn and manage (your platform's framework and the CMS framework).
Writing a CMS is like invading Afghanistan.
Everybody gets a turn but nobody wins.
I don't think that Stack Overflow could have been built with a CMS. Does that answer your question? =)
Update
To answer your updated question.
If you want a regular corporation web containing news, articles, forum etc: Go ahead and use a CMS.
If you need to build a more custom web site like stackoverflow, a web interface for a system or anything like that: Built it using MVC etc.
I personally use a CMS for our corparate website and a MVC framework to build user and administration interfaces for our products.
Not every problem needs a CMS. In the same way not every problem needs a bespoke MVC/webforms website. It depends on what your requirements are. You pick the technology to solve the problem.
Build vs buy is the hardest decision to make. As a developer build always looks best. You can do better than that pile of carp they want to buy. Nevermind that you're reinventing the wheel, axel, cart, etc. To users/management buy always looks best. They don't have to think to hard about what they want and can have it now, not 3 months later after you write it. They forget it'll cost the same again to customise & make it impossible to upgrade.
I'll stop ranting now.
Umbraco is a pretty bare minimum CMS. To customize it (e.g. Version 7+) you'll need to know Heavy MVC, JSON, XML, Sql, etc.
In fact a Site built on Umbraco 7+ is entirely based on MVC views you set yourself and assign to SurfaceControllers (which are MVC controllers) and all you are really getting is the ability for users to edit things about your pages and have Umbraco manage it for you in a DB.
In short you still need experienced web developers to build a site on Umbraco, they just save a lot of time by not having to build the entire backend from scratch.
You use Umbraco to organize Document Types that define what Templates (MVC Views) are used for rendering different types of documetns (e.g. Web Pages) and then you built the template from the ground up with 100% control over the HTML, Css, and Javascript that get's output.
Imo Umbraco is more of a Framework like Django than a complete CMS.
Sure you can build a site in Umbraco and not customize anything, but it would be a pretty cheesey site.
The whole point to Umbraco is to give skilled .Net Developers a good platform for building a site on top of it, but they still have to build it.
Now sharepoint would be more of a complete CMS out of the box that you can do a lot with, but let's see a few problems with SharePoint...
Resource Heavy, eats 50+ Gig's to install
Eats 16 GB of ram just to boot it up (Sharepoint 2013)
Requires Sql Server 2008 R2 or equivalent (enterprise license, $$ chaching)
Requires Windows Server ($$chaching)
It's a monster basically, if all you need is a user editable blod platform... man what a waste of money. Foundation is free, but doesn't include things like the Blog Site Template, so you buy a server enterprise license ($$ big cachinge, 40,000$+ in some scenarios...)
Agreed. A CMS like Umbraco provides a (very) good out-of-the-box solution for the most basic applications. Any sort of specialized purpose is going to require additional programming knowledge. Anymore, though, and your major, if not primary need is going to be a good understanding of the business need. I think we're getting away from building the Legos themselves and on to building the neat toys with the Legos. Cheers!
A CMS (or similar application framework) will provide you with a lot of functionality out of the box, and many of them also have a good library of plug-ins. But you'll still need to write WebForms/MVC code if you want to add any custom features.
Hi I met an investor who wants a new product to sells to other companies. We agreed to make it SaaS, but we're arguing over three options:
SaaS product using pure ASP.NET
Saas product using huge SharePoint server
A couple of SharePoint add-ons (web parts)
I can't disclose the product but its is about collaboration and involves many interaction between users. That is the reason why we have SharePoint as an option also because a user might optionally create web pages (single home page) many many times.
Some users don't want SaaS. So, there is possibility of hosting the product locally (to protect their 'sensitive' data).
So my question is: which one would you choose from programming point of view?
(Note:I asked this question in onstartup site, and i was advised to ask here for the technical aspect)
It's hard to give a conclusive answer without knowing more details of the project. However, my general advice is to consider SharePoint only if you plan to use its built-in features and don't need to add a lot of custom ones.
Moreover, I recommend you read these questions:
ASP.NET vs SharePoint - which one is better for web developers?
How good/bad is sharepoint programming?
https://stackoverflow.com/questions/256407/what-are-your-biggest-complaints-about-sharepoint
How is SharePoint perceived in your company?
based on tiny info of project , i would Harmonize with marek , as it deals with Collaboration
share point would be the best choice.
There are two things called "Sharepoint". There's Sharepoint Services, and Microsoft Office Sharepoint Server (MOSS). Sharepoint Services provides a lower level framework that you can build other applications upon rather nicely, and doesn't require any additional licensing. However, MOSS requires very expensive licensing, and will only make sense to build upon if your customers already have MOSS. You don't want to force them to purchase MOSS and implement it just to use your product. MOSS is built on WSS (Windows Sharepoint Services).
If you're selling it as SaaS, then that means you will need to buy those licenses, which will be very expensive.
If what you need to do is "Sharepoint with some additional stuff", then maybe sharepoint makes sense. If not, then go with a ground up approach.
SharePoint can be the main solution for enterprise, if users really need RIA and heavy customization, SilverLight would be one of your solution.
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, but we would prefer to do pure ASP.NET programming.
The web-app should have the following characteristics.
1) It will be a site for bank's clients that will allow them to view their stock portfolios, get miscellaneous reports with graphs and charts, etc.
2) The web-app will also allow clients to send orders to the bank to buy stocks and perform other financial operations.
3) The number of users will be approximately 3 000 000 (total) and 20 000 at any one time.
We have never made any SharePoint programming, but as far as I know, SharePoint is primarily designed to create intranet sites for colleagues to communicate with each other and work more efficiently, to maintain a document library, etc.
However, the bank IT told us that SharePoint has in fact lots of other features that will help us make the project more efficiently - for example, it seems that SharePoint has some built-in scalability and high availability technologies.
I heard saying that SharePoint development is very tedious, that the platform cannot be very easily customized, etc.
The question is: is it better to create our web-app on pure ASP.NET and deal with scalability and other issues ourselves, or base it on SharePoint - taking into account that the web-app we need to create is non-standard and complex?
Thank you,
Mikhail.
UPDATE
In the answers, someone suggested using ASP.NET MVC. My another question is: should we use "classic" ASP.NET or ASP.NET MVC for such project (if we leave out the SharePoint option)?
Do you need document management? Do you need version management? Do you need to create "sites"? Do you need audience filtering? Do you need ECM (fancy word for CMS), Do you need collaboration stuff on your site? If your answer is no then SharePoint is not for you.
You said "We have never made any SharePoint programming" and for that reason alone I think you should not use SharePoint. You also say that your app is going to be "non-standard" and complex, another reason not to use SharePoint.
Sounds like you know ASP.NET so I would advice to stick with ASP.NET or ASP.NET MVC.
Hope this helps
The answer is simple, you should go with what you know. If you prefer to do it in ASP.NET then, that is what you should go with. Trying to learn a new technology on that size of a project will almost certainty cause you severe problems when trying to develop it. Can sharepoint scale to that number of users, probably, but you don't know how to make it do that. That is the real key.
They are correct SharePoint does have a lot of functionality out of the box, but that doesn't mean that it will make you more efficient, because you don't know all of the APIs etc. to access.
Actually, if you want to know the way to cheat. If they force you into using it, you can run ASP.NET applications under SharePoint (well kind of). You can tell SharePoint to essentially ignore a path in the site and use regular ASP.NET as a web application just like any other site does. Really, this isn't using SharePoint, but it can get you out of a bind, in the "Needs to use SharePoint to make them happy scenario".
Mayo suggested contacting MS. I have a feeling they already have a relationship with the bank and have provided some insight about the project. I would contact: http://www.mindsharp.com/ and see if they can help you out. They are a training company, but I bet that the owners would be willing to help consult, and I haven't found anyone with more knowledge on SharePoint than Todd Bleeker.
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
What a load of CRAP that sharepoint isn't cut out for what the op wants to use it for. Especially the "Do not get yourself wrapped up in SharePoint" comment from ChaosPandion. Maybe he thought it to difficult and gave up...
Sure SharePoint development takes some getting used to, but it is able to what is wanted by the op most definately. SharePoint is built using ASP.NET so anything you do in ASP.NET can be used / ported to SharePoint. It is not a standalone product, but a DEVELOPMENT PLATFORM. It will scale to serve that many users, using multiple WFE's (Web Front Ends) and a SQL Cluster as backend.
The question here is: is sharepoint the most suited platform for building this site? Then I would have to answer, probably not, seeing as the wanted functionality is almost all custom development. If you plan on doing web content management as well, then yes, SharePoint is definately worth looking into. Also, SharePoint takes away all (or at least most :-D) authorisation and authentication wories. It is Department of Defense certified. And if the offered out of the box security is not enough, just write an authentication provider (seeing as SharePoint uses ASP.NET's provider model).
To answer your questions:
The bank IT told us that SharePoint has in fact lots of other features that will help us make the project more efficiently - for example, it seems that SharePoint has some built-in scalability and high availability technologies.
SharePoint is farm based, to which you can add machines, having each machine perform a different task, which means either app server, index server, WFE, document conversion services., WFE's can be behind a load balancer to distribute requests. Also I want to mention the web content management again.
I heard saying that SharePoint development is very tedious, that the platform cannot be very easily customized, etc.
Like I said, SharePoint is based on ASP.NET, so it is as much customizable as ASP.NET is. You could even create an ASP.NET web site, put all UI in Controls and then use those is SharePoint, maybe even have the controls use it's own database. As for it being tedious, not really. It's just DIFFERENT and deployment / testing is not like normal deployment / testing. SharePoint uses so called solution files (.wsp files), to package up functionality and deploy it to the server. This IMHO makes it possible to deploy functionality in a very modular way. Furthermore, there are loads of cool open source projects out there that make sharepoint development much easier and also provide cool extensions to "pimp" your site and make it more fun and easy to use for end-users.
Nuff said....
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.
UPDATE: After looking at this more I would add that I do not believe that SharePoint is for you. As I mention below SharePoint is for collaboration. If the users that come to the site require an isolated experience then SharePoint is more overhead than you need.
SharePoint is built on top of ASP.NET so you have everything that you want to do with ASP.NET in addition to what SharePoint provides. Anyone who says that it is difficult is trying to make it that way. You can deploy stand alone custom pages with 100% of your own code and it will run under sharepoint, or you can create new application pages that also contain any code you want to write, or you can simply add your own webparts that can be added to any page you choose with 100% of your own code.
Here is just one example.
Creating an Application Page in Windows SharePoint Services 3.0
What SharePoint offers on top of that is a whole different paradigm on collaboration tools. If you wish to leverage it (if not the cost on return is somewhat limited) you can build amazingly complex and integrated solutions that is build around the aggregation of data from across an enterprise.
That being said, do not go into it lightly. If deployed wrong or with a half understanding of where SharePoint excels and where it does not will result in a diaster. Unless you have the time to understand the core concepts of SharePoint I would warn against it but your client is right. If you do build it in SharePoint you get a great deal more flexibility. One right off the bat is the ability to mix authentication modes. I designed a solution that mixed custom forms authentication with an LDAP backend with Windows Authentication. Anyone could visit the same pages but your authenticated account could come from two different locations.
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.
You said,
I heard saying that SharePoint
development is very tedious, that the
platform cannot be very easily
customized, etc.
You have been misinformed about SharePoint. All SharePoint pages are ASP.NET pages. You can customize any of them, either directly, or by using Microsoft Office SharePoint Designer, which is free.
Get started at http://msdn.microsoft.com/en-us/sharepoint/default.aspx.
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.
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.
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.)
I would build this on SharePoint. It is quite suitable for big sites and many sites have already been built on it: topsharepoint.com
SharePoint (like all complex applications) does require sufficient knowledge that you do not seem to have at the moment which is a big risk in my mind. Don't listen to the nay-sayers though.. lack of knowledge is a common problem for devs dealing with SharePoint but it doesn't mean you can't make it do whatever you want.
Regardless, what other options do you have? I think the days of building completely custom CMS's have passed just as building completely custom Intranets are not cost effective anymore. There are many competitors to what they want to do with SharePoint (Umbraco, Sitecore, Sitefinity, etc) and most of them seem better than 100% custom.
So the answer might be neither ASP.NET or Sharepoint..
I was involved in a SharePoint(WSS) project that was very data centric. The project consisted of more than 500 lists that has very complex relations between them. The client also asked for more than 350 Reports. Don't tell me why did you use SharePoint from the beginning. It was a managerial decision and we already delivered the project after 14 months of pain (this is 6 months overdue to the deadline)
When we first started the project, we didn't know anything about SharePoint development (believe it or not). The management said that they will take the risk. They were very convinced that SharePoint is the optimal solution for anything!!!(well, that proved wrong at the end of the project).
Anyway, we were learning SharePoint while we were developing. Our development were mainly based on SharePoint designer to customize all the AllItems/NewForm/EditForm/DispForm for every list to provide the needed logic/validation that the client asked for (Using JavaScript). We also implemented around 15 Custom Fields (e.g. master-details fields). We also made an event receiver to handle all the adding/updating/deleting... events for all the lists in the site. Plus around 40 ASP.Net user controls.
The main problems that faced us (we worked-around it but sadly in an inefficient way)
1- The Client asked for a search web part in each AllItems.aspx. The search web part should have multiple keys for the client to search with. We did that using Form Web parts using SPD no problem. But the real problem was how to search for a related field that was not in the current list. (So, in such cases we had to save these fields values in our list to be able to search for (crap, I know!!)). You might ask, why didn't you implement ASP.Net user controls for such task? Well, that would require us to forsake the default AllItems web part, and were already customized hundereds of AllItems.aspx pages with alot of customization that would take us a lot of time to reimplement them from the beginnging. Also, even if we used user controls, CAML is very inefficient in retrieving data from multiple related lists!
2- I think you can guess this one, if we've already faced a big time doing search web parts, how on earth will be able to do the 350 reports!!:D But we figured out a work-around (as usual :S) we made an Access DB file with links to all the 500 sharePoint lists, then we implemented a user control that has a report viewer control. This user controls takes an ordinary T-SQL Query to query on the Access DB, the Access DB retrieves the data from the SharePoint DB and pass it back to the user control which views the DataSet on the report viewer.
There are other administration related problems, but I would like to focus on the development here.
So, after I showed you the picture (sorry for the long post). What do you think was the best SharePoint development technique that we should have taken in such a data centric Project, if any?
I heard that some companies doesn't use lists at all in such projects, and builds there own SQL database tables instead of the SharePoint Database. But I can't keep my self from wondering, If I'm making my own DB, and hence implementing my CRUD web parts from scratch (We will also lose the security module benefits provided by SP Lists), what would be the benefits of SharePoint?
Once again I apologize for the long post.
I think you found out exactly what I did. Sharepoint just isn't good at handling large enterprise type applications. We ended up creating a custom database to house our data. We used Webparts for the user interface, but otherwise, the entire application was independent of Sharepoint.
In my opinion, Microsoft is overselling Sharepoint. It's actually good at team collaboration sites and simple Excel services applications, but anything beyond that it just isn't capable of handling.
I have to disagree with both Geoff and Abu in regards to SharePoint being a bad choice for large enterprise applications.
As you state yourself Abu your team were learning on the job as you had no SharePoint development experience, the issues you faced was more a Management error that a platform problem, management should have brought in SharePoint contractors to work alongside your team to help build what sounds to be a fairly complex system.
As a developer who has worked with SharePoint for a number of years many of the projects I have worked on some that I myself would not have believed suitable for SharePoint with in my first few years of developing on this platform, however now with more experience I know how to leverage the power of the platform far better and I realise the advantages gained using SharePoint for projects of that nature. That said I have a number of issues with parts of the platform but this is no different to any other platform I have worked on including parts of the ASP.Net platform.
If I was asked to develop a solution using a bespoke Java based system (or perhaps the new MVC platform) I am sure I would experience many problems similar to what you experienced where I simply don’t know what the right approach would be. That would not in any way be an issue with the platform but more with my inexperience.
I am sorry to hear that both of you experienced pains working within the bounds of the SharePoint platform that was forced on you by your management. Though I am disappointed that you are so fast to point the blame away from yourselves and your management.
Was SharePoint the best platform for your projects I can’t say, but that doesn’t make it a bad platform for enterprise applications.
I disagree with Geoff that SharePoint is no good for large enterprise type apps. You have to remember from the start that SharePoint is a development PLATFORM. This means it gives tyou a lot of functionality out of the box, but is extremely customisable.
Being a platform does not mean every bit of customisation needs to be done based on SharePoint lists. Seeing as it is built on ASP.NET you can do anything in SharePoint you could do in ASP.NET as well.
I have built a great deal of ASP.NET apps that were hosted in SharePoint, letting SharePoint do the authentication etc.
I have to say though, determining where SharePoint should stop being your base and you should switch to regular ASP.NET is sometimes hard..
If you are looking for a data-centric solution in SharePoint, the best solution is to use the Business Data Catalog (BDC). This keeps your rich data relationships and all of the SQL (or other DBMS) goodness you want where it should be - in a repository designed to be optimal at storing data.
For an overview of what the BDC functionality can do, see this post on the SharePoint Team Blog. For much more details, read the series on SharePoint Magazine. Note that these features requires an Enterprise license of SharePoint 2007.
I am in process of evaluating MOSS (SharePoint) and traditional ASP.NET for my client's site. The site will be available to client's partners over the internet. I'm interested in differences between these two approaches from following perspectives:
Development perspective. How does development differs? What are pros and cons of both approaches?
Performance perspective. Which platform shall deliver better performance?
By now, we know that not much features of MOSS can be used out-of-the-box, and the features will be added using web parts.
The big difference that you need to be aware of is the licencing. To use MOSS over the internet will require an Internet licence. The actual cost depends on what deal you have with MS, but it is a significant cost.
We have found that it is more costly to develop for Sharepoint than ASP.net pages. Especially due to requirements for the development environment and deployment problems.
From a performance perspective it depends on how you program it. With ASP.net you have more control and therefore, should be able to get better performance.
Do not use MOSS unless you are leveraging the functionality that MOSS provides.
SharePoint out of the box has a lot of great features you will not be able to duplicate as easily. For instance the Office integration. With SharePoint your client can share documents ( word, excel, etc ) and have them kept under revision control.
You can easily setup individual portals for their clients where they can have discussions, share documents, communicate, etc.
SharePoint is also a content management system. Your client can add/edit/remove content as they wish. With MOSS they get the benefit of publishing workflows as well as being able to roll back their changes/deletes. The publishing workflows could spawn an approval process for the changes. Built in
SharePoint's workflow support is a one of the top benefits. You can create them with SharePoint Designer. SharePoint Designer is free from MS. InfoPath forms + workflows provides some obscene opportunities you will not develop as easily on your own.
SharePoint Designer provides an avenue to develop more advanced solutions than the web interface as well as site branding ( look & feel ).
Best thing is, if you create 1 solution, you can bundle it and deploy it. For instance if you setup 1 client portal, you can bundle it and "copy" it to new client portals.
MOSS is a set of additional functionality that you pay for. It can be expensive. You have to leverage the cost of licensing against the cost for you to duplicate what is already available.
Depending on what your client wants you might not even need Visual Studio. A lot of the work can be done by building solutions with whats already there, which is a lot.
Frankly, I don't understand why people compare SharePoint and ASP.NET as if they were competing products. If you need majority of the features of SharePoint (collaboration, workflow, communities, office integration, document management etc), then it may be worth your while to use SharePoint rather than re-inventing everything.
But if you are developing a classic web application, why bring MOSS into the picture? Unless your clients already have MOSS in place and would rather use it to host their apps. And if your clients are really gung ho about SharePoint, you might want to remind them that SharePoint licensing is very expensive while ASP.NET is free!
Part of the curse and blessing of SharePoint is it's ability to be infinitely customized. Most of the features of SharePoint can either be used as-is, customized with SharePoint Designer or replaced entirely by writing your own C# code. This is a blessing because it means SharePoint is infinitely customizable. It's a curse because customizing it can be a royal pain.
That last comment "Do not use MOSS unless you are leveraging the functionality that MOSS provides" by Shiraz Bhaiji hits it on the money.
And I'll even expand on that. Do not use MOSS unless someone in your organization is going to force everyone in the organization to use the MOSS. Because if people aren't forced to learn how to use it and change their ways, you're wasting time and money by migrating to it. Most places I've seen, people continue to use their file shares, and email (Exchange) to share and collaborate with. They never end up using their Sharepoint. I don't know how common that is, however, if you suspect that'll be the case with your organization you should give this aspect more concern.
One of the biggest parts and focuses of MOSS and WSS is "Collaboration" and ECM (Enterprise Content Management). If your clients/partners can utilize these features sharepoint would be a success.
In addition, since MOSS is part of the office 2007 system, it is fully integrated with all office programs and using Exel Services and Infopath Form Services, your users would be able to enjoy web-based Excel and forms without having to install them.
I would also strongly discourage using MOSS if you have to do any sort of customization. If it does what you need out of the box, then great, but otherwise you'll quickly burn time and resources trying to dance around it.
I can't tell from your question whether or not you're aware that SharePoint is built on ASP.NET and Windows Workflow Foundation.
The big difference in my mind is that the Development model for SharePoint assumes that you are developing against a server. This is not as big a deal as it used to be, since it's practical for each developer to run Windows Server 2008 in a private VM. Still, there's no "Visual Studio Web Development Server" when SharePoint is involved.
See Sharepoint tools support in Visual Studio from Somasegar's Weblog, especially the many comments (72 at last count).
Performance wise, it's a tricky one to answer, as it's very depending upon how your custom solution is developed, what hardware platform you're planning on deploying the solution to, etc. I think most people would agree that, in general, MOSS will be slower than an ASP.NET application written in house, primarily because it's unlikely to be as complex and expansive as MOSS.
That said, it's very easy to deploy MOSS across a network load balanced farm (obviously increasing the licensing costs significantly), and share the load that way, thus getting a pretty significant performance boost over a more traditional ASP.NET app deployed to a standalone server.
As others have said re: development, it's incredibly dependant on what you're actually wanting out of the end solution. As Dr said, it would be a major development effort to reimplement some of the core MOSS features, such as it's Office integration, it's document management, version control and fine grain permissions.
If you feel that you're going to have customise a large chunk of MOSS, then the development effort can be quite involved, especially if you don't have anyone in house familiar with the process. It's a big product, and finding your way around it's innards and API is no small task when first starting out.
I should mention that we've had a lot of clients who have gone into MOSS evaluations thinking that there will be a significant amount of work customising, etc, but not realising that actually, 90% of what they want to achieve can be so with minimum development efforts, it's usually more a lack of understand of all the options available to them within MOSS.
I have written a blog entry which compares the traditional ASP.net and the SharePoint apps. You can see that here:
http://manish-sharepoint.blogspot.com/2008/05/comparing-sharepoint-server-with-aspnet.html
HTH