All,
At my current company, we are looking to replace all ASP.NET Applications and OLTP databases with Sharepoint 2007. Our applications and databases deal with 10,000+ rows, and we have 5,000 + clients actively using the system. Our Implementation of sharepoint would replace all n-tier applications.
Does anyone have an experience in implementing this? My current viewpoint is that Sharepoint is not built for or adequate enough to handle this type of application. Can it really replace application with hundreds of pages, and hundreds of tables? Support Data warehousing operations? Support high performance OLTP operations? Provide a robust development environment?
Any and all input is greatly appreciated. Thanks S.O. Community.
SharePoint can absolutely handle this this level of data and users. But I'd have serious concerns though about whether the people in the organization can adequately manage, develop, and use such an implementation. There are hundreds of wrong ways to do things in SharePoint, and very few "right" ways.
At the level of usage you're talking about, you're going to have to do some serious customization and development. You'll have to be careful that people don't get fooled into thinking it will work for them out-of-the-box.
SharePoint is a platform, like any other, it has strengths and weaknesses and can be made, through various levels of effort, to do anything you really want to with it.
Can SharePoint handle the load you ask about? Without a doubt. Can it support your data back end? Sure, either via the "SharePointy" mechanisms of the BDC/BCS, or though your own custom code.
The better question is what is to be gained from essentially re-developing all of your applications on a new platform, if anything?
Don't be swayed jump on the SharePoint ship because Microsoft is selling it as the new shiny. A thorough knowledge of ASP.Net is required for development in SharePoint, but having that alone doesn't allow for a rapid start-up in development.
https://stackoverflow.com/questions/256407/what-are-your-biggest-complaints-about-sharepoint
How good/bad is sharepoint programming?
Basically not a good idea to shift to sharepoint. Difficult to use. Steep learning curve. You would probably need sharepoint consultants.
update: Developing a website for 3 mln. users: SharePoint OR pure ASP.NET?
Sharepoint CMS vs UmbracoCMS
might be more relevant to you.
Also you may want to look at Running away from SharePoint (just kidding)
Thanks all for your answers!
After reading all of the feed back, it seems to fall in line with my research. Having said, here is what I gather from your responses:
SharePoint out of the box is a CMS.
SharePoint Lists do not replace relational tables.
Extending SharePoint to fill other uses is limited to custom development within the SharePoint framework.
From my research:
- Utilizing a relational database in a SharePoint application is done through custom code. Adhereing to point 3 above.
- Developing and building applications in SharePoint, with features that fall outside of the CMS domain , nullifies many sharePoint features and requires heavy custom development.
Again, thank you all for your feed back, this ihas invaluble to my research.
Here's some info on Sharepoint capacity planning: http://www.microsoft.com/resources/documentation/wss/2/all/adminguide/en-us/stsb07.mspx?mfr=true
It suggests that more than 2000 items per list would not work.
For posterity , and anyone else who stumbles here.
Further points:
- Most Developers do not have enough SharePoint Development Knowledge to properly implement a solution with SharePoint.
- ASP.NET Knowledge is required to develop SharePoint applications.
- SharePoint Maintains a step learning curve.
Are we saying that developing on a platform built on top of ASP.NET is harder to learn then ASP.NET it self?
Ouch man, I don't know if you want to head down this path; SharePoint has a pretty notorious learning curve, isn't something easy to bend and flex too much.
Related
I'm currently looking at developing an application, and have a choice between doing a standard ASP.NET web application or integrating it into SharePoint. Our client would like it to be SharePoint if possible, as they are under pressure to put all new development into it, but standard ASP.NET is still an option.
It is an application to manage and view data in a database with about 10 tables, including an approval workflow when certain new items are added. Referential integrity of the data is important.
I have experience of developing ASP.NET applications, but very little with SharePoint. Does anyone have any criteria they would apply to deciding between the two?
So far I am thinking along the lines of:
Referential integrity of the data is important and SP doesn't seem to handle this very well without writing lots of custom code
SharePoint doesn't seem very scaleable with the suggested limit of 2000 items in a list
The application has an approval workflow, which does seem to be something SP does well
On the wholem, it seems like we would end up writing lots of custom code and not really using any of the out of the box SP features. So my thinking is why not just write a standard ASP.NET application.
Are there any other key things we should consider?
By now, you may have already found this link: http://blogs.msdn.com/sanjaynarang/archive/2009/06/19/should-i-build-my-application-in-sharepoint-vs-asp-net.aspx. If not, it's a decent starting place with some good questions to ask.
What follows is my take as a long-time .NET developer (for as long as the platform has been around) and a SharePoint architect (since 2003). That's basically my way of saying that I've been on both sides of the fence.
In my opinion, SharePoint is a platform, not a product. As ASP.NET provides valuable web-based services to the core .NET framework, SharePoint supplies additional services and capabilities on top of ASP.NET. The platform removes the need for writing common code pieces that are a part of so many ASP.NET apps: security code, user profile management, personalization, UI/UX baseline, etc. When you get into the plumbing, you get even more: rich caching support that requires minimal configuration, customization modularity via Features, and more.
Should every application be built in SharePoint? I'd never push for that. With my current client, we use a mix of SharePoint-based and custom ASP.NET applications. Whether an application gets built in SharePoint vs. written from the ground-up in ASP.NET is a function of what we're doing. We conduct the same sort of exercise you are. If SharePoint's features and functionality can be brought to bear to reduce development time, it goes in SharePoint. If the need is too specific or we feel we'd be working around SharePoint, we go the custom app route.
You have some very specific concerns for your application, so let me take a crack at them with the little I understand about your requirements:
REFERENTIAL INTEGRITY: based on what you're saying, it sounds like your data model is pretty specific. Building your information architecture to natively leverage site columns, content types, and lists probably doesn't make sense. That doesn't throw SharePoint out, though. There's absolutely no reason why you couldn't build the data model you want (presumably in SQL Server) and then consume it with components that reside in SharePoint. If you're using MOSS, some of the BDC WebParts might work for you straightaway. If not, you'd still be writing controls and/or pages to work with the data, correct? There's nothing wrong with using SharePoint as your presentation layer for access to SQL directly or (in a more scalable, n-tier fashion) go against business services somewhere else.
2000 ITEM LIMIT: this is a common concern and one that is misunderstood. There is no 2000 list item limit; the actual measurement is 2000 items per view (and that's with out of the box views, by the way) or "container" (such as a folder). You can store many more times that (millions, if you like) in a list if you partition with folders, build your own view to page, etc. Again, given your data structure and the likely need you have to dodge SharePoint's lists, this wouldn't be an issue if you simply consumed data from SQL Server.
WORKFLOW: SharePoint is nice as a workflow host, and the OOTB workflows are handy. I'm assuming you're looking at MOSS (versus straight WSS), but just in case: the approval workflow comes with MOSS. If you're constrained to WSS, you only have one workflow available to you: the three-state workflow.
At the end of the day, SharePoint is .NET and built on top of ASP.NET. Much of the code you'd have to write in a SharePoint app you'd need to write in a custom .NET anyway. I'd look at things from the perspective of understanding whether the experience and features SharePoint affords you (as a developer) can help speed your development cycle and/or improve the user experience (something we, as developers, sometimes forget).
David in Dakota does have an excellent point, though, in that the dev experience for SharePoint is different from straight ASP.NET. The need (or rather, best practice) to deploy via Features, understand specific SharePoint concerns (e.g., lifetime and disposal of SharePoint objects), etc., mean that there will be ramp-up time if you do build in SharePoint. There are quite a few good resources out there (including folks here on StackOverflow) that can help, but you'll need to factor some learning into the equation of whether or not SharePoint makes sense.
One more parting thought: Microsoft is slowly shifting many of its own products and platforms to leverage SharePoint as their UI/UX layer, and the trend is picking up some steam. PerformancePoint, Project Server, Team Foundation Server, and Commerce Server all use SharePoint as their presentation tier. The trend will probably continue, though I don't know how far. If you use any of these products (or their on your technology roadmap), a SharePoint investment now might pay off later.
Despite all of my writing about and advocating for SharePoint, I don't think it's the right tool in every scenario. I still build WinForms apps, smart clients, command line apps, and more quite a bit. It just comes down to weighing "what I get" for "what I spend" (in both time and money).
I hope this helps!
Your evaluation is quite accurate. (It would help to have more detail about every feature your application needs but that's not really practical for this medium.)
The problems you mention have been largely solved but you would need to understand and implement the solutions. For example, there is a CodePlex project that can assist with referential integrity and there are recommendations on how to manage the number of items in a list. But using SharePoint is never going to give you the freedom of writing an ASP.NET application from scratch.
Another thing to consider is how you and/or the client expect the application will evolve in the future. If it will need more collaboration-style features or features such as version history on list items and integration with the Office client then SharePoint may be the better option.
You should also think about the complexity of deploying and updating your application on SharePoint.
At our company we are currenty trying to define the basic things our software architects have to know about SharePoint for them to architect and/or lead a SharePoint implementation project. Many architects in our company have a .NET developer background and know a lot about .NET development and the various framework components and tooling. However, they currently lack SharePoint knowledge. In fact they don't even want to know the nitty gritty details. They want to know just enough about it to make the right architectural decisions and apply proven patterns. If more specific knowledge is required they'll ask a SharePoint expert.
So What would is the basic set of SharePoint knowledge / skills that an architect would need to have?
Skills such as list, documents, workflow, permissions... are a bit too basic and are requirement for a SharePoint DEVELOPER.
I'd argue that perhaps site (and site structure) is an area that would fall under the architect's plate.
There are more areas that a SharePoint architect can help with:
Capacity planning - running multiple servers in a farm. Scalability and other magic words.
Knowing the capabilities and business scenarios of using SharePoint - this is a very common one.
The manager asks: what can SharePoint do for me?
The developer asks: well, what do you want it to do.
The manager then asks: well, I don't know what it can do for me so how do I know what do I want it to do?
Closely related to SharePoint capabilities are the various licensing costs related to each component.
As well as familiarity with development and customization costs. Take the same project time that would have taken in ASP.NET, then multiply it by a large coefficient, and then add an additional constant.
And closely related to what-can-it-do, and how-much-does-it-cost, is the all important question of Return-Of-Investment. All hail supreme ROI!
SharePoint deployment can be a massive issue and a lot of pain.
SharePoint upgrade from v2 (MOSS 2003) to v3 (MOSS 2007). We should be seeing a new version of SharePoint in 2010(?). Well soon after the next version of Office goes out the door. So past upgrade experiences may be useful.
Knowledge of 3rd party webparts. I believe a SharePoint architect should be able to give you at least 5 webparts that they've tried from CodePlex and tell you what they think about them. These are free and easy to grab and play at your own leisure.
Some knowledge of commercial webparts. Because they are still cheaper than writing your own.
Have at least 5 SharePoint blogs that they follow religiously (know the community). If not having their own SharePoint blog (give back to the community).
If they are on StackOverflow they must try to answer SharePoint questions (such as this one).
Attend local SharePoint usergroups. I think communities are a huge deal. Especially what you'd learn from talking with people directly and learning what they are doing with their SharePoint installation. You may just surprise yourself.
Experiences with SharePoint Integration - this comes in two equally important flavours - both from SharePoint accessing existing systems (business catalogs, webparts, etc), as well as other systems accessing SharePoint content via webservice or API.
In addition, SharePoint works with (or works well) with Office, OCS, reporting services, performance point, project server.
SharePoint hosting arrangements - Microsoft SharePoint online services can be a popular and cheaper option to start using SharePoint. It can be hosted inhouse, or with a 3rd party company. Knowing the options is always useful.
Must have read SharePoint code using reflector (and preferably still having hair).
I think it takes at least a couple of years to be a SharePoint architect (your mileage may differ). Your .NET architects need to want-to-be a SharePoint architect, otherwise I agree with other's summaries before me - find someone who already is a SharePoint architect.
An architect should have quite a good understanding of our a product works, from a functional and technical viewpoint.
So in my opinion, an architect should:
Have been involved in at least 2 Sharepoint deployments, from design to roll-out.
Have knowledge of our the major sharepoint components can be used using the API.
i.e. Sites, Lists, Documents & Workflow components.
As none of your architects have this knowledge, I would pair them with a Sharepoint expert in an existing Sharepoint project, so they get the knowledge they need.
Ideally SharePoint Architect Skills fall into the below mentioned categories
Infrastructure Level/Operational
Capacity Planning
Physical Architecture (Farm Setup, Network, OS, Licensing)
Application level (Functional and Non-Functional)\
Requirement and Feasibility Analysis (Custom Vs OOTB Development/Implementation)
Techno-functional Mapping of requirements
Information Architecture
Logical Architecture
Conceptual Architecture
Detailed Design
Database design (not in terms of traditional Database design), this is with respect to Number of content Databases for Site collections/web apps.
Deployment
Best way to go for deployment, first time and incremental
Some other activities that an architect will collaboratively work is the Project Manager in Planning, Estimation, Execution/Implementation, Risk Management (assessment, mitigation).
Apart from his daily tasks of working with technical teams, testers, User Interface professionals, Vendors, Clients (Business and IT teams).
Interacting with Enterprise Architect groups if any.
In my not so humble opinion I think the entire "Sharepoint Architect"/"Expert" thing is over-played.
Sharepoint is a tool to centralize an organizations digital resources for centralized collaboration or working together in a centralized way.
The best explanation of What Microsoft Sharepoint is and does
from the WROX book "Beginning Sharepoint 2010 - Building Business Solutions"
"Because computers play such an integral part in any business, not surprisingly, more and more
of the information that is created, consumed, and shared in an organization is digital. The more
business that you conduct and the more successful your business becomes, the more information you
have to manage. Usually, you have some form of document for just about every process and transaction
that plays out during the day-to-day operations of your company. From proposals to legal
documents, from sales receipts to human resources policies, the amount of information required for
a company to function is staggering.
To manage your information overload, SharePoint offers tools with which you can build business
applications to better store, share, and manage digital information. With it, you can create lists,
libraries, and websites for your various company teams to help run your business processes more
efficiently. By locating your organization’s important business data in a single location, it becomes
much easier and intuitive for users to find the right information when they need it rather than
searching through disparate locations such as email, computer hard drives, or file shares.
WHAT IS SHAREPOINT 2010?
SharePoint 2010 is an extensible and scalable web-based platform consisting of tools and technologies
that support the collaboration and sharing of information within teams, throughout the enterprise and
on the web. The total package is a platform on which you can build business applications to help you
better store, share, and manage digital information within your organization. Because you can build
with or without code, the package empowers the average business user to create, deploy, and manage
team websites, without depending on skilled resources, such as systems administrators or developers.
Using lists, libraries, and web parts, you can transform team websites into business applications built specifically around making your organization’s business processes more efficient."
Creating a schema for an organizations Sharepoint deployment is not rocket science. 1. Determine the structure of the organization 2. Determine what Sharepoint can do as far as centralizing the organizations digital resources. 3. Create a Sharepoint construction plan. 4. Build it, test it, refine it. 5. Maintain it, test it, refine it, add onto it. There! Not so tough.
Sharepoint can be a nasty beast to work with if you don't know the ins and outs of it (they should be experts with it to architect it). At a minimum, they should know how lists, sites, and permissions work. Ideally they should also know how all the web parts fit together on pages and how they are supposed to interact. Really if the architects don't want to learn about sharepoint, they are going to create a .net web application and force it to run on sharepoint. It won't really follow the paradigm of how a sharepoint app is supposed to work.
I would look at a company called Mind Sharp for guidence as to what they should learn.
My advice is look for a doer that doesn't just reads PowerPoint to much in the Sharepoint world is just based on what other people have said.
We have been having issues with crawling 500000 items in a Sharepoint farm and everyone gives another story how to get better speed... Normally people refer to not more than 2000 items in a folder, but that does not change the crawl speed....
So a good architecture is someone who is able to do POC proof of concepts himself of his design and not just refers to some vague stories.....
I have seen to many Sharepoint Architects that hasn't had experience from real life....
Our company has an ASP.NET application for customer information database. The application started small but has grown without proper design. Now a new version of the app should be developed, which basically would mean designing and implementing it from scratch. The company is interested in making use of Microsoft Sharepoint Services in future and it has been suggested to pilot it with this customer database application.
So my questions is:
Is database driven application something WSS is good for? Mostly the app would perform CRUD-operations on the database and also create reports.
I agree with Greg in that I wouldn't necessarily recommend putting your data in SharePoint lists (this is what Greg may be assuming). But my short answer would be "maybe".
Here's the long answer...
SharePoint runs on ASP.NET so it should accommodate your needs. You would likely be writing ASP.NET web pages that live within SharePoint that access your database or writing web parts that live within SharePoint that access your database.
You could consider the BDC for reading/retrieving data, but that requires MOSS Enterprise and won't provide the CUD part of CRUD. Other tools like CorasWorks DIT may help, but I suspect that custom web parts or pages are the way to go for you.
There are plenty of benefits you can get from SharePoint such as authorization and maybe things like integration of your data with SharePoint list data, provisioning, search, etc. It really depends on the nature of your application as to whether SharePoint will provide much of a benefit.
Short answer: No.
Long answer:
Is there any collaboration? Supporting documentation for the data? Workflow? If no, then there really isn't any reason to host it through SharePoint - you won't be gaining much.
Additionally, keep in mind that the SharePoint lists may look like tables, but they aren't - there is no relational aspects of the lists - no joining, no cascading updates/deletes, etc. This may be a problem if data reporting is a big part of your app.
You can store the data externally and have it appear as read-only lists in SharePoint, but you're still jumping through a lot of hoops if you're not using any of the other SharePoint features.
Kirk beat me to punch and said it better than I would have anyway :)
Another thing to consider is the possiblity of workflows in your process. For example, if you need to start a process when a new contact is added (a follow-up call, etc.), then SharePoint provides a great deal or benefit.
Perhaps a hybrid solution would be appropriate. A custom app for your CRUD and SharePoint integration for the pieces that make sense and provide value.
Building in SP for the sake of using SP probably isn't a good idea.
We have an ASP.NET application that runs in MOSS 2007. While we barely use any of SharePoint's features, we do get the advantage of SharePoint's security model, navigation webparts (we use CorasWorks), integrated Reporting Services, and workflows. In the very least, SharePoint features are there for us to use someday.
All of our application data is in its own SQL Server database. We don't store anything in the SharePoint content database.
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?
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.
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.
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.
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.
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.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Have any of you ever tried to run from sharepoint? I've worked with sharepoint enough to know that it is not something that interests me. My interests are more along the lines of APIs / backend / distributed development. Have any of you found ways, as consultants, to move away from sharepoint and keep learning other things of interest? I'm currently in a position where sharepoint is in huge demand and I can't quite find a way to simply step aside from it. any suggestions ?
If I infer correctly that you work for a consulting firm then find out what other kinds of things your firm works on. Learn those technologies better that the people who currently work on them for your firm, involve yourself in those projects, even if just in a hallway conversation manner, and come up with better (faster, cheaper) solutions for the problems your firm is solving.
Your options are really seem to be 3-fold
convince your boss your talents
would be better used elsewhere
convince your co-workers they want
you on those other teams
convince your company's clients that
they want you, specifically.
Learn Java, or Ruby.
The Microsoft sales model of "attach" whereby they sell a solution comprised of multiple technologies and then sell the next solution on the basis of "well you have already invested in SharePoint so you already have the skills in place and the infrastructure for this new bit of technology we have" is here to stay... it's very successful.
SharePoint is cloud computing for business who have MS shops... you avoid it by not doing C#. If you're doing C# then given enough time, your apps will need to run in the corporate cloud and you should be looking after your career by embracing it.
Just my 2p. Sorry if it's not quite the answer you wanted.
I know exactly what you mean. I think you don't mind the idea behind a product like SharePoint, but really hate the way its been implemented and how problematic it is. I know its a nightmare to work with.
As a C# developer, I cringe when I hear the SharePoint word, SharePoint is Lord Voldemort. But unfortunately it comes with the job of being a senior C# / Microsoft developer.
I say unfortunately because its likely if you're working in a corporate structure sooner or later you will end up having SharePoint in your solution. Not because its good, but because as others have said - MS use SharePoint as a Trojan horse to get and keep business.
There might be some hope with the new version of SharePoint coming out (2010). Maybe this will finally include a better programming / implementation model.
Otherwise either work for smaller companies (usually less pay, but not always), or try to play down your skills as a MOSS developer if possible. Never actively market them unless your salary depends on it. Remove the skill from your skill matrix, and turn down jobs that completely focus on MOSS. Some MOSS integration here and there you can live with. An entire solution focused on MOSS will drive you insane.
If all else fails, learn other non Microsoft languages, and within a year or 2, SharePoint will be but a faded memory.
I know lots of developers who are thinking about quitting IT because of SharePoint. I would say don't let it be the end of your career.
And finally bitch and moan, and inform managers on a weekly / daily basis, as to why you are battling in SharePoint. Let them know, and constantly remind them how bad a technology it is.
When life deals you lemons. Make Lemonade.
Seriously, if you are seeing SharePoint in such high demand, maybe working with the beast is the best idea. SharePoint is really just middle-ware. SharePoint can simply be a distribution point for your solutions (i.e., a user interface such as a web application can be hosted on SharePoint through a Web Content part). If you look at it, SharePoint may even prove useful as a document respository or small scale data store, in the form of lists.
Maybe you should turn down SharePoint contracts and accept contracts that interest you.
Depending on the market you are in you can simply tell your boss at the consulting company you work for that your not interested in doing Sharepoint projects anymore and that you'll be forced to look elsewhere if they continue putting you on Sharepoint projects. That would work around West Michigan where the developer demand is high and the supply is sub-par.
I'm, on the other hand, just starting to use SharePoint to enreach my currently boring C#-only projects. I'm starting to use it as a front-end to the distributed and complicated systems: simple configuration and customization, reporting, management, system control - looks like all this is available in this package it it's easy to make is usable by non-techies and by beginners.
I personally don't want to work with SharePoint anymore. I've worked on developing a solution for it and even went full charge with a web integration of it. I hated it.
First you have to master the awful programming model then handle all the deployments and it's not even the beginning. If you are developing a product for SharePoint, you have to debug the software itself which is a feat on it's own.
My solution to this is to be very upfront about it. I don't mind doing knowledge transfer and helping out people but I don't want to be developing/deploying SharePoint applications.
My boss get it, my friends get it.
Our latest joke come from someone who said a few months ago that it was "easy and fast to deploy application with SharePoint". The joke? "Did he just put easy/fast in the same sentence as SharePoint?"
So unless you salary would be lower because of it... downplay your skills on it and be upfront to your boss. :)
Have you ever looked at Alfresco (http://alfresco.com)?
It serves many of the same purposes as SharePoint, but does it from an Open Source J2EE application. It will leverage your existing collaboration / content management experience and expose you to a whole bunch of open source technologies.
Full disclosure: I work for Alfresco.
I've already given this suggestion to another guy...Running from SharePoint won't be difficult because technologies are similar to each other according to their structure. SharePoint is not the worst technology to be used, although it is limited in some way... Fortunately, software sphere is too wide to be afraid of not finding anything you can be interested in.