Interesting things about ECM

2010/02/04

Q&A discussion around SharePoint and Oracle UCM posted to the Nexus 2009 Group.

Filed under: Oracle UCM, Sharepoint — Tags: , , — Anthony Fast @ 10:15 pm

Source: http://www.sharepointgovernance.org/peers/PublishedPeerDocuments/SharePoint%20versus%20Oracle%20UCM%20LInkedIN%20Discussion%20Thread.docx

LinkedIN question dated May 12, 2009:

I would like your feedback ‘technically’ speaking on this question…

Should we migrate all Oracle UCM content to Microsoft SharePoint and why?

Email responses May 12 – July 14th, 2009:

Response

I think we should migration all UCM content to SharePoint.

From an end-user’s perspective:

1) Searching for content in UCM is painful. The indexing process is slow, and the search results are terrible.

2) The UI in UCM is dated, not very modular, configurable or extensible.

3) It is harder to expose content in UCM to other consumers.

From a Developers perspective:

1) SharePoint is built on top of Microsoft .NET.

2) SharePoint is integrated Microsoft Visual Studio, one of the best development tool in the industry.

3) Extensions on SharePoint can be written in any .NET languages.

4) SharePoint uses modern technologies/tools.

5) It is much easier to write and debug code in SharePoint.

That said, the learning curve is definitely much steeper in SharePoint since you would have to know the entire web related technologies including Windows Server, IIS, MS SQL, and .NET.

Response

I would suggest moving non-web content to SharePoint but only if we can use with the KnowledgeLake Imaging Server. The maturity of web content management features in UCM beat SharePoint. Having said that there are a host of reasons why SharePoint should be considered for library content services.

This would get all technical and non-technical staff more familiar with SharePoint.

We have already found benefits of locating multi-user spreadsheet access in SharePoint. We inevitably will find other organizations that may want help to migrate UCM to SharePoint. This would be good experience for our technical staff.

I still have difficulty locating information in UCM; however w/o KnowledgeLake search we would be in the same boat with SharePoint. Overall I find the SharePoint GUI to be far more intuitive and we would likely get better user adoption.

Response

SharePoint seems to be a good choice for document collaboration.

However, to answer the question in a larger context of where SharePoint might “fit” in our business and what our peers, customers and competitors are articulating in the marketplace is also a good question.

SharePoint shouldn’t be seen as a replacement for Oracle (or IBM, EMC). So far, here are the following reasons:

1.) Records management – although there is some records management capability in SharePoint, the feature set it a bit “underwhelming”.

2.) Workflow – Oracle has a superior workflow capability.

3.) Storage – there is no native support (in SharePoint) for comprehensive storage technologies (like WORM) or any other “write once read many” technologies. (and the marketplace seems a little wary about Microsoft controlling all aspects of their document lifecycle).

These three things basically relegate SharePoint to the “tip of the spear” as far as document management, business process and storage is concerned. Anyof these could change rapidly in the future, but it seems there is more integration development between SharePoint and Exchange and MS Office Suite than for an expanded feature set along these lines. If this is true, it will push SharePoint even closer to the document origination function, and away from a document storage function (ie… greater than 5 year retention and storage).

I think I finally understand that this is what people mean by collaboration.

It seems that asking a company to standardize on any one document management system is like expecting them to buy just one type of file cabinet, and then storing all documents in one single place. For large fortune 1000 companies this isn’t reality. For small companies, this may be just fine…SharePoint may be all they need (so I don’t see much of a future for products like DocuShare)

Maybe we should see the product suite as a document technology “stack” that begins with document origination in SharePoint and ends with Oracle.

Response

For many of our purposes, the shortcoming(s) of our existing UCM system focus on unsatisfactory search results. I assume this could be resolved if we were to rely on UCM for dynamic (changeable) content (and we should do this if we retain UCM). However, from a strictly content management standpoint, I see no dramatic difference between UCM and SharePoint’s potential using the current versions (MOSS 2007 & UCM 7.5.2) of both products. Anytime we rely only on text string queries, we are going to frequently get more in the result set than what is desired.

If we use SharePoint, we need to be able to use metadata in our queries and I understand that the current SharePoint is inadequate unless fortified by something like the KnowledgeLake enhancement for query.

As important as content management is our need to have effective collaborative tools which are substantial even though incomplete in SharePoint (these can be augmented by products such as Oracle Autovue, WebEx, etc.). The development staff seems to prefer the SharePoint characteristics.

It is highly probable that long term product growth and enhancement will be more active in the SharePoint product line vs. Oracle UCM. Likely both products will advance in capabilities over time, but SharePoint seems to have the momentum. In addition, add on enhancement product selection looks to provide a wealth of focused vertical market solutions in the SharePoint environment. SharePoint looks to be more pervasive in the marketplace than Oracle UCM.

If we have the resources to do so, I suggest that our long term internal requirements and our product marketing/sales objectives would likely be more thoroughly served by a migration of the information in UCM to a well governed SharePoint system.

Response

We use SharePoint & UCM in IT help desk support for many of the reasons listed we have gravitated to SharePoint for our KB, Support Portal and Content Repository. Because it is very easy to post information in SharePoint our usefulness of UCM has been declining rapidly. I have not seen or researched 10gR3 UCM and it may be worth looking at before we pull the plug on UCM. As one of the others said the searching for records in UCM is very difficult but SharePoint brings you back a lot of information you don’t want or need.

Technically they do a lot of the same functions but I think that our teams and departments needs more collaboration based application software for staff working remotely more than we they need Information Lifecycle Management. I would like to see an examination of how we currently access content and what types of information we commonly use. This would help us to decide if we migrate to SharePoint or upgrade/repair UCM and/or use a product like the ILINX connector to SharePoint for a combination of the two.

Response

There are couple interesting links regarding the two:

http://www.cmswire.com/cms/enterprise-cms/does-oracle-ucm-standup-to-sharepoint-002989.php

This is the somewhat Oracle-centric article referenced in the above:

http://www.oracle.com/products/middleware/content-management/docs/gilbane-workplace.pdf

I personally would bet on SharePoint simply because I prefer, and am more experienced in c# and .net versus java, and also find Microsoft’s interfaces much cleaner and intuitive.

Response

I felt the following was an informative article on this subject (link to actual document follows at bottom)

Does Oracle UCM Standup to SharePoint?
By Barb Mosher | Aug 8. 2008

Gilbane recently produced a research paper entitled: Information Workplace Platforms: Oracle vs SharePoint which has some interesting findings on which of these two ECM platforms is the best choice for an organizations information lifecycle.

The report findings are based on research on a number of companies who reviewed both platforms for their Information Management needs and what their final decisions turned out to be.

The report, authored by Tony White, Lead Analyst, Web Content Management at the Gilbane Group isn’t a long read, but takes us into the world of information workplace platforms and the pain points they address.

Defining Information Workplaces

This paper is more about educating us on what Information Workplace Platforms are and why they are needed then about the actual technical solution that Oracle or SharePoint plays. Which is a little disappointing because the title would lead one to expect something totally different.

As for a definition then, the paper defines an Information Workplace Platform to include: federated search, portal, content management, records management, document management, rights management, retention management, imaging, Web 2.0, e-discovery, and workflow.

Choosing Between Oracle UCM and SharePoint The research covers three specific customer examples where both Oracle and SharePoint were considered as Information Workplace Solutions. In most cases, Oracle was selected as the solution of choice. Of course, that solution didn’t just include Oracle UCM — it also included the Oracle Fusion Middleware of which UCM is only a part. Does that make it a fair comparison to SharePoint? Not sure.

One point that was discussed was the lack of SharePoint federated search. This is something that has since been resolved with SharePoint. Microsoft also received their U.S. Department of Defense 5015.2 Certification in May of last year, so the report is a little out of date in some respects.

CMSWire asked Tony Byrne of CMS Watch what his take was on Oracle UCM vs SharePoint. “The contrast between the two is a bit more nuanced than departmental vs. enterprise and collaboration vs. ILM. Generally speaking, yes, SharePoint is better suited to the former and Oracle the latter, but the story gets murkier when you dig into the details of each product.”

And it’s the details that we lack in this report.

Alan Pelze-Sharpe of CMS Watch agrees saying, “the thing is to see UCM as part of the Fusion platform, in that context it is a true ECM linking into BPM and a whole array of web services (identity management etc) and importantly supports ILM thoroughly.”

If that is the case, then should we not also include BizTalk Server — Microsoft’s middleware solution — and other MS solutions in the context of a decision on which platform is the better choice.

Aside from that, Microsoft has acknowledged it needs to do some work with SharePoint and associated solutions to provide true ILM.

Final Thoughts

The report concludes with Gilbane’s own views on which platform is the better solution and it’s obvious they are very pro Oracle — both UCM and Fusion Middleware combined. They do acknowledge that both solutions have their strengths and weaknesses and that they have based their conclusions on the platforms value for ILM.

That being said, SharePoint should not be considered only a “point-solution” for collaboration and basic team workspaces based on this research alone. In the right context it can be the right solution for the right organization. It’s all in the requirements and a full review of the platform’s capabilities — maybe even — shock — piloting or prototyping.

THE ABOVE MENTIONED DOCUMENT CAN BE FOUND AT:

http://www.oracle.com/products/middleware/content-management/docs/gilbane-workplace.pdf

Response

Right now we are using UCM for two purposes, to store some of our active content and host our public facing websites.

I don’t have extensive experience with MOSS Content Management, but what I have seen is that it is in practice not much different from UCM. Technically I don’t see any glaring problems other than getting over the MOSS learning curve. Both technologies have the problem of needing a well defined metadata model to support searching of our content. The one UCM feature we might miss is the conversion of documents from Word, Excel, PowerPoint, etc to PDF.

I have never seen MOSS do web content management, but I have read that the feature exists. We need to do more research into this feature to make sure it meets our requirements.

As a developer I would much rather develop in MOSS. If we are going to be doing more MOSS products and projects in the future, and then migrating our own systems to MOSS would provide us with much needed experience.

Response

It would depend on what our future considerations are for the use of the products.

If the intent is clearly just to be used for collaboration purposes then I think SharePoint is the better product. Why?

I have recently been using SharePoint for multi-user spreadsheet access and used it more extensively on a recent project because that is where they stored all the project information that we needed to access. I find the user interface in SharePoint to be much easier to use and more pleasurable to use. UCM is clunky and outdated. In SharePoint, searching for documents is easier, although the volume of documents was low in both my use cases. In UCM I can search using more of a “google” search for known items that exist in the system and still not get a hit back when I search for it. I have to sometimes use just capital letters, lower case for others, or combinations of both for others to get hits back. So, on paper it is supposed to have better search capabilities but they really stink. I find that I either get nothing back or too much back with UCM when I search.

If our plans are to grow the system and get into more sophisticated workflows, records management, etc. then we should either stay and “suffer” along with UCM (and its clunky UI) or look at using SharePoint with an ILINX connector that could promote the content from SharePoint into IPM, UCM or other document management systems for archiving, BPM/workflow, records management, etc. Use the power of the document management system we have to provide the true ECM capabilities but utilize the easier to use interface of the SharePoint product.

I don’t believe that Microsoft will ever get the product to be an enterprise level product. They have gotten it out there but I don’t think it will evolve into a true ECM product. It will remain a good department level collaboration tool but not go much beyond that. They seem to be able to get products out in high volume to the lower and mid level clients but never seem to really break into the larger higher end customers like an Oracle does. They have tried to do this in the database space and the ERP space but never seem to be able to overcome the hurdles to really get the largest of the customers. Except for those who hate Oracle!

In the case of the project I referenced earlier. Now that the project is over they should be moving the important project documentation to an archive. The project team has been disbanded but the information needs to be stored for long term and then records and retention managed yet easily retrievable. They need a document management system for that. Not SharePoint.

Response

There are many valid points that are raised in these responses. I think one important consideration for this dialogue is ‘context’. The individuals responding to this query all have unique perspectives that are largely shaped on their functional role in the company and their direct experience with clients. At times, we tend to look at things only through our own perspective and not in the broader context. Industry trends and technological limitations can’t be ignored, but again, let’s consider context.

First, regarding the challenges that we face surrounding searching in UCM. We have to consider that the original metadata model that was developed for our Content Server was developed as a prototype when the platform was relatively new. It was then put into production and remained there. The metadata architecture model for Content Server is fundamentally different than the IPM platform which is where our core competency and extensive experience base was rooted. At this point in time, we have a much more mature understanding of the differences in those metadata models, why they matter and how that would play into a design and implementation. It is likely that if we were implementing that whole solution today, the metadata model might look very different, which in turn could significantly impact the quality of the user experience. Secondly, some of the metadata (e.g. author) was complicated because of the content review process that was put in place. If we tried to search for content based on who we naturally thought the author would be (i.e. a Program Manager for project management, etc…), we couldn’t necessarily do that because someone else (admin staff) ultimately would up being the ‘author of record’ because they approved and did the final checkin. Again, all of these things impact the ability to search, and the end users are unaware of the details, only that they are having a hard time finding their content. The question this poses is this; “Is that a function of the system, or a metadata model and review process that could have been refined to make for more effective search capability?”

Second, the ways that we use Content Server (and all of its associated modules) is extremely limited. We’re only using basic document storage and WCM functionality for our websites. There are myriad components used by other customers (i.e. Collaboration Management, Digital Asset Management, Records Management, customized applications) that significantly enhance the value of the platform to any given organization relative to their needs. We’re only going just below the surface. When you combine the ability to customize the interface, leverage the content repository, and include additional database support, and creative design, some very valuable and meaningful applications can be produced that add significant value to a business. The training application that we developed for medical sector client in 2007 is a perfect example of that.

Third, from a WCM perspective, as mentioned above, there is no contest that Content Server is still more mature than SharePoint.

Fourth, all of the comments above about the flexibility and ease of development (for skilled developers) in the SharePoint environment is true.

In Summary, SharePoint will likely go the way that Windows did back in the late 80’s and early 90’s. It won’t be able to be ignored forever. When Windows first came out, it was going head to head with IBM’s OS/2 operating system, a clearly technically superior product. Through some very brilliant marketing strategies, the Windows OS started showing up on the “new computers” (IBM clones). People started using the clones because of the lower cost and Windows came with it. Subsequently, applications started being developed for it, and over time, it became a defacto standard. Over the years, it matured and eventually became a stable, meaningful and valuable player in the market place and technical space. That was then, this is now and Microsoft is now the largest software company in the world with vast resources for development. SharePoint is not going away. It will grow, mature and a large application base will be developed for it. We have embraced it, learned it, and are developing in the environment to push the envelope for it the same way we do for other platforms to fully realize the possibilities. That being said, it should be considered in the broader context of content management, all content management. It is a tool that is part of a larger tool bag. Our model and methodology has always been to use the ‘best of breed’ for any given situation or solution. I don’t think this discussion is any different. We should leverage the right tools for the right job(s). We’re starting to do that as our knowledge and skills with SharePoint evolve, I think we just need to be thoughtful when approaching decisions to eliminate entire platforms and ensure that the decisions we are making are informed decisions and that we are considering things in the broader context.

Disclaimer

The information contained in this document does not necessarily reflect the opinions of the company. Individual names have been removed. The intent is to share the thought process that may be going on in many organizations that are grappling with the same decision being discussed in this document.

Advertisements

2009/10/22

Google Search Volume index for Oracle UCM and Microsoft Sharepoint

Filed under: Oracle UCM, Sharepoint — Tags: , — Anthony Fast @ 10:21 pm

Regions: ALL

Period: Last 12 months

oracle ucm
1.00
microsoft sharepoint
22.4

Microsoft SharePoint Integration for GroupWise Unveiled at GWAVACon Las Vegas
The Open Press (press release) – Jan 14 2009
SharePoint Solutions Creates Software to Integrate Microsoft SharePoint With salesforce.com
PR Newswire (press release) – May 27 2009
Extend the Power of Microsoft SharePoint with New Edition of Quest Web Parts for SharePoint
Trading Markets (press release) – Jun 23 2009
Metalogix Software Showcases Microsoft SharePoint and Microsoft Exchange Migration and Archiving Products at Microsoft WPC09
Trading Markets (press release) – Jul 13 2009
OfficeRecovery.com Data Recovery Software Contributes to Microsoft Sharepoint…
Legal Tech Base (press release) – Sep 10 2009
Concept Searching Announces conceptClassifier for SharePoint for Microsoft SharePoint Server 2010
PRLog.Org (press release) – Oct 19 2009
Regions
1. India
2. Australia
3. Netherlands
4. United Kingdom
5. Spain
6. Canada
7. United States
8. Japan
9. Brazil
10. France
Cities
1. Bangalore, India
2. Chennai, India
3. Mumbai, India
4. Delhi, India
5. Sydney, Australia
6. London, United Kingdom
7. Toronto, Canada
8. Madrid, Spain
Languages
1. English
2. Dutch
3. Japanese
4. Spanish
5. Portuguese
6. French
7. German
8. Chinese

Source: http://www.google.com/trends?q=oracle+ucm,+microsoft+sharepoint&ctab=0&geo=all&date=ytd&sort=0

2009/10/14

ECM, CMS and WCM Job Market in Bay Area California USA

Filed under: Alfresco, Oracle UCM, Sharepoint, WCM — Tags: , , , , — Anthony Fast @ 8:44 pm

Source: http://simplyecm.com/2009/06/06/ecm-cms-and-wcm-job-market-in-bay-area-california-usa/

job_market_ecm_cms_wcm_dm
There are couple of my friends getting laid off from their company, who are working in the Enterprise Content Management, Content Management System and Web Content Management market in Bay Area, CA and in India. Is the job market not good? Is there any implementation going on in companies for ECM? Atleast for WCM and document management and/or collaboration implementation projects are going on in various companies.

I went ahead and did some research on this. I chose three Job search engines – juju.com, simplyhired.com and indeed.com. I chose an area – Santa Clara, CA 95050 and searched jobs for every ECM technology product for 100 miles around.

Technologies I chose were Alfresco, Sharepoint, Documentum, Oracle Stellent and IBM FileNet. The jobs could varu from implementation consultant, developer, project management, business analyst etc., You know what? The interesting find is – There are n number of Sharepoint implementations going on. Sharepoint is very very popular. Documentum is next, but not that high compared to Sharepoint. All others are just hanging in there.

Market is definitely bad and that kind of says – the situation of Job Market for ECM, CMS and WCM related work/projects. By the way – if you are an ECM company and if you want to definitely get job – learn Microsoft SHAREPOINT for now. You will definitely get job in this market too!!

2009/10/13

SharePoint Content Structure – Let a thousand content types bloom?

Filed under: Scalability, Sharepoint, WCM — Tags: — Anthony Fast @ 4:19 pm

Source: http://www.earley.com/blog/sharepoint-content-structure-let-thousand-content-types-bloom

“How many content types should you have?”

This is the question that came up in a conference call last week on SharePoint architecture. This organization had implemented their corporate portal on SharePoint 2007 and was interested in going forward with more portal sites but had some concerns about the approach to information architecture they had undertaken.

I answered what I would answer no matter what technology it was – “Only as many as you really need to implement the appropriate level of metadata, workflow and templates.” Which is of course vague, as most good consultant-ese is. So I followed up with the notion that when we work on web content management implementations, we typically end up with 10-15 content types for a site of medium complexity. We always try to keep the structure simple and number of content types few for many good reasons, ranging from ease of content structure management to content publisher user experience.

The folks on the phone were quiet for a minute… You see, the previous consultant they had worked with had a bit of a different (read opposite) approach. The philosophy they described was that SharePoint content types should be created to the maximum degree of granularity (e.g. one content type per library) so as to reduce the need for content publishers to select a content type and tag metadata values. For example, if you had a site for human resources forms, you would have one library and content type for medical forms, one library and content type for dental forms, etc. Each content type would be extremely specific and require little tagging. “If you need 30,000 content types, then so be it” is the idea. (insert eye twitch.)

The intent behind this – to reduce uncertainty and effort for content publishers – is noble and good, but the overly-granular content types seems to be in the realm of sledgehammer to kill a fly. To help explain why, I thought I’d enlist the help of a couple of friends and colleagues.

First, I emailed content management guru Bob Boiko, author of the Content Management Bible, to see if he agreed. His response?

“How many content types is the right number? The fewest possible to squeeze the most value out of the info you possess. If it were my system, I would create a generic type and put all the info that I could not find a business justification for into that bucket. It’s not worth naming if you can’t say clearly why you are managing it. Then I would start with the info we have decided is most valuable and put real energy into naming the type and fleshing out the metadata behind it. Then on to the next most valuable and so on till I ran out of resources. In that way, the effort of typing is spent on the stuff that is most likely to repay the effort.

Amen to that! But I also wanted to get a tool-specific view from my colleague and SharePoint expert friend Shawn Shell. So I skyped him…

ImageSo, what do you think?

Image Well, having a content type for every document library is certainly an interesting approach, though I think your SharePoint administrators, as well as your users, will go quite mad.

ImageSo, I think the argument is that having this many content types is supposed to make it easier on the users by presetting all choices and removing the potential for error. If you never have to choose a content type because each library has a very specific default that matches the content you are creating, then there’s no confusion, the idea seems to be… From a general content management perspective, this is flawed. But what about from a SharePoint-specific standpoint?

ImageI can understand why this might make sense on the surface.  Unfortunately, I think you end up exchanging one kind of confusion for another.  Further, there’s a huge maintenance implication as well. For example, if you have a content type for each library, you are, for all practical purposes requiring the user to decide where to physically store a document.  This physical storage then implies your classification — regardless of whether a default content type is applied.

ImageSo, you’re basically recreating all the ills of a fileshare folder structure!

ImageIn essence yes. To make matters worse, more complex SharePoint environments will necessarily include multiple applications and multiple site collections. Because content types are site collection bound, administrators will have lots more administration to create, maintain and ensure consistency across the applications and site collection. This would normally be true, but when you have such an overload of content types and libraries, the complexities of management are compounded.

ImageSo, if you have 50 content types, and you need to use them in 2 or 3 site collections, you’d have to create 150 content types. Good argument to keep your use of content types judicious. Is there a hard limit to the number of content types one can manage in a site collection?

ImageThe answer is “sort of.”  There’s no specific hard limit to the number of content types in a site collection, but there are some general “soft limits” in the product around numbers of objects (generally 2000). This particular limit is an interface limit where users will see slower performance if you’re trying to display more than 2000 items.  The condition won’t typically manifest itself for normal users, but it will for administration. The other real limit is the content type schema can’t exceed 2 Gb.  While this seems like a pretty high limit, if you have a content type for each library, loads of libraries in a site collection and robust content types, there’s certainly a chance to hit this limit.

ImageWhat about search? I assume that a plethora of content types would have adverse effects on search.

ImageIt absolutely does.  Like everything we’ve discussed here, the impact is primarily two fold: 1) administration and 2) user experience. Content types, as well as columns, can be used as facets for search.  If you have an overwhelming number of facets in results, the value facets bring is reduced.  Plus, as I mentioned before, having large numbers of content types could also produce performance problems when trying to enumerate all of the type included in the search result.

From an administrative standpoint, we’re back to managing all of these content types across site collections, ensuring that the columns in those content types are mapped to managed columns (a requirement for surfacing the metadata in search results) and, if you have multiple Shared Services providers, that this work is done across all SSPs.

ImageI expect there will also be a usability issue for those trying to create content outside of the SharePoint interface. Wouldn’t users have to choose from the plethora of content types if they started in Word for?

ImageThis is another excellent point.  Often, when discussing solutions within SharePoint, we think only of the web interface. When developing any solution, however, you need to keep both the Office and Windows Explorer interface in mind as well. Interestingly, using multiple document libraries, with a content type for each library, makes a little more sense from the end users perspective, since it’s similar to physical file shares and folders.
However, the same challenges that many organizations are facing related to management of file shares can manifest themselves when using the multiple library and matching content type approach as well — putting these organizations back in the same unmanageable place they started.

ImageGreat, thanks Shawn for your insights! I’ll be sure to spread the word to avoid a content type pandemic.

So there you have it folks. Less is more. Standardize, simplify and don’t let your content types multiply needlessly. Your content contributors and SharePoint administrators will thank you.

2009/10/07

Comparing Alfresco and SharePoint 2007

Filed under: Alfresco, General, Sharepoint — Tags: , , — Anthony Fast @ 7:48 pm
Category Alfresco SharePoint 2007
Cost Estimate $15000.00 $40000.00
Available Languages
Learning Curve
License GNU General Public License (GPL) Commercial / One-time Cost
One-Click Updates
Standards Compliance Level
Site Setup Wizard Limited No
Total views 32 11
CONTENT MANAGEMENT
Archives
Content Categorization Yes
Content Construction Kit
Content Staging and Merging Yes Yes
Content Tagging Yes
Content Templates Yes Yes
Custom Content Types
Import-Export Yes
Printer, Email and PDF Versions
Revisions and History Yes
Scheduling Yes Yes
Subscriptions No Yes
Tag Cloud Yes
Voting and Rating Limited
CORE APPLICATIONS
Advertising Management No Yes
Affiliate Tracking No Yes (Add-on)
Calendar Yes Yes
Chat No Yes
Commenting System
Contact Form No Yes
Contacts Management No Yes (Add-on)
Events Management No Yes
FAQ Management Yes Yes (Add-on)
File Repository and Distribution Yes Yes
Forms and Surveys No Yes
Full-Text Document Search
Graphs and Charts No Yes
Guestbook No Yes
Helpdesk / Ticketing System No Yes
HTTP Proxy No Yes
Internal Search Engine Yes Yes
Lightbox (or variants)
Link Management Yes Yes
Live Chat
Media Gallery Yes Yes
Newsletter Management No Yes
Polls No Yes
Sitemap Limited Yes
Streaming Audio Management
Streaming Video Management
Tests, Quizzes and Raffles No Yes
XML Sitemap for Search Engines
FLEXIBILITY
Interface Localization (l10n) Yes Yes
Internationalization (i18n) Yes Yes
Language Negotiation
Multi-Site from 1 Codebase Yes Yes
Multi-Site from 1 Database
Multiple Domains Management Yes
Right to Left Language Support
INTEROPERABILITY
CGI Mode Support No No
Content Syndication (RSS) Yes Yes
Database Query Editor
Database-to-Web External Databases
FTP Support Yes Yes
iCal No No
Section 508
Text Browser Support
UTF-8 Support Yes Yes
W3C XHTML Compliant Yes Yes
WAI Compliant Yes Yes
Web Services API Yes Yes
WebDAV Support Yes Yes
LAYOUTS, DESIGN AND TEMPLATEES
Content Type Theming
Drag and Drop Layouts
Granular CSS Classes
Scheduled Theming
Style Wizard No Yes
Sub Theming
Template Language Yes Yes
Theming / Skinning Yes Yes
URL Path Theming
Web-based Template Management Yes Yes

MOBILLE INTERNET
Device Capabilities Caching
Device Capabilities Detection
Device Groups
Site Wizard for Mobile Site
SMS Support
Templates per Device Group
Unique Mobile Content
PAGE EDITING
Clipboard Yes Yes
Copy / Paste from Office Yes
Email Content to Site Yes Yes
External Editor Limited
Image Auto Thumbnails Yes
Image Editing Limited (Add-on)
Image Resizing Yes Yes (Paid)
Macro Language Yes Yes
Server Page Language Yes Yes
Spelling Checker Yes (Add-on) Yes
Trash Bin Yes Yes
Undo History Yes Yes
WYSIWYG Editor Yes Yes

PERFORMANCE
Advanced Caching Yes Yes
Automatic Meta Tags Yes
Bandwidth Optimization Limited Yes
Database Optimization No Yes
Database Query Caching
Database Replication Yes Yes
Friendly URLs Yes Yes
Load Balancing Yes Yes
Minify Javascipt
Search Engine Optimization Yes Yes
Static Content Export Yes No
SECURITY
Audit Trail Yes Yes
Captcha Anti-Spam No No
Content Approval Yes Yes
Database Backup/Restore Yes
Email Verification No Yes (Add-on)
Error Reporting Yes Yes
Kerberos Authentication Yes Yes
LDAP Authentication Yes Yes
Login History Yes Yes
NIS Authentication No Yes
NTLM Authentication Yes Yes
Password Encryption
Pluggable Authentication Yes Yes
Sandbox Yes Yes
Scheduled Backups
Session Management Limited Yes
SMB Authentication Yes Yes
SSL Support Yes Yes
Versioning Yes Yes
SITE ADMINISTRATION
Administration Dashboard Yes Yes
Drag and Drop Interface Limited Yes
File and Document Manager Yes Yes
Google Analytics
Inline Content Administration No Yes
Internal Search for Admin
Link Checker Limited
Mass Upload Yes Yes
Media Library Yes Yes
Metadata Yes Yes
Offline Maintenance Page
Online Administration Yes Yes
Personal Dashboard
Site Navigation Management Yes
Statistics No Yes
Translation Strings Management Yes Yes
Workflow Engine Yes Yes
Zip Archive Support Yes Yes
SUPPORT
Certification Programme Yes Yes
Code Skeletons Yes Yes
Commercial Manuals Yes Yes
Commercial Support Yes Yes
Community Forums Yes Yes
Developer Community Yes Yes
Issue Tracking Yes
Mailing Lists No Yes
Online Help Yes Yes
Support Network Subscription
Trainings and Seminars Yes Yes
User Conferences Yes
USERS
Avatars
Buddy List
Memberlist
Memberlist Search
OpenID Login Support Limited
Paid Content Subscriptions No
Private Messaging System No
Public User Page
Registration Form Yes
Registration Form Custom Fields Limited
User Access Control Yes Yes
User Contributions Limited Yes
User Groups Yes Yes
User Points / Karma Rating
User Preferences
User Profile Custom Fields
User Profiles Yes Yes
User Signatures
Who’s Online List

Source: http://www.cmsmatch.com

2009/10/06

SharePoint Scaling Limits

Filed under: General, Performance, Scalability, Sharepoint — Tags: , — Anthony Fast @ 6:14 am

Source: http://old.markharrison.co.uk/blog/2004/09/sharepoint-scaling-limits.htm

I frequently get asked for SharePoint scaling limits so I though I would blog an entry I can refer people to.

First an extract from the Capacity Planning section of the Windows SharePoint Services Administration guide which answers general WSS limits questions:

None of these are hard limits enforced by the system. They are guidelines for designing a server that has good overall performance.

  • Site collections (Database scope) 50,000 … Total throughput degrades as the number of site collections increases.
  • Web sites (Web site scope) 2,000 … The interface for enumerating subsites of a given Web site does not perform well much
    beyond 2,000 subsites.
  • Web sites (Site collection) 250,000 – You can create a very large total number of Web sites by nesting the subsites. For example, 100
    sites each with 1000 subsites is 100,100 Web sites.
  • Documents (Folder scope) 2,000 … The interfaces for enumerating documents in a folder do not perform well beyond a thousand entries.
  • Documents (Library scope) 2 million … You can create very large document libraries by nesting folders.
  • Security principals (Web site scope) 2,000 … The size of the access control list is limited to a few thousand security principals, in other words users and groups in the Web site.
  • Users ( Web site scope) 2 million … You can add millions of people to your Web site by using Microsoft Windows security groups to manage security instead of using individual users.
  • Items (List scope) 2,000 … The interface for enumerating list items does not perform well beyond a few thousand items.
  • Web Parts (Page scope) 100 … Pages with more than 100 Web Parts are slow to render.
  • Web Part personalization (Page scope) 10,000 … Pages with more than a few thousand user personalizations are slow to render.
  • Lists (Web site scope) 2,000 … The interface for enumerating lists and libraries in a Web site does not perform well beyond a few thousand entries.
  • Document size (File scope) 50 MB … The file save performance degrades as the file size grows. The default maximum is 50 MB. This maximum is enforced by the system, but you can change it to any value up to 2 GB (2047 MB) if you have applied Windows SharePoint Services Service Pack 1.

For SharePoint Portal Server, here’s an extract from the Capacity Planning whitepaper:

It is important to understand the ramifications of the different features and functions of the SharePoint Portal Server solutions to size the system so that the performance of the system is good.

The following table lists some of the SharePoint Portal Server objects and describes their recommended use. “Typical” indicates comfortable and well tested; “maximum” indicates that the system can support that number, but not without some performance ramifications or
special configurations.

An asterisk (*) indicates a hard limit; no asterisk indicates a tested or supported limit.

  • Portal sites (full) – typically 2 … maximum 15 *
  • Portal sites (child) – typically 10 … maximum 100 *
  • Areas – typically 1,000 … maximum 10,000
  • Best Bets – typically 1,000 … maximum 25,000
  • Area depth – typically 5 … maximum 20 *
  • User profiles – typically 50,000 … maximum 1,000,000
  • Audiences – typically 500 … maximum 10,000
  • Audience memberships – typically 500,000 … maximum 5,000,000
  • SSO credentials – typically 100,00 … maximum 100,000
  • Search indexes – typically 3 … maximum 32
  • Content sources -typically 25 … maximum 250
  • Search scopes – typically 25 … maximum 250 *
  • Indexed documents per content index – typically 100,000 … maximum 5,000,000
  • Indexed documents – typically 2,500,000 … maximum 20,000,000
  • Thesaurus entries – typically 1,000 … maximum 10,000
  • Alerts – typically 50,000 … maximum 1,000,000
  • Team sites – typically 10,000 … maximum 250,000
  • Personal sites – typically 10,000 … maximum 250,000
  • Create a free website or blog at WordPress.com.