I'll start out by saying I've not yet used a Content Server 10-based application or even logged onto a demo server and so much of this is just speculation based upon information I learned during TechConnect (a good pretty well executed virtual conference). There may well be some things I'm not aware of that could materially change my point of view, both positively and negatively, but I'll try to stay on safe ground.

There are a number of cool new features on CS10 and it seems possible that some long-standing capacity and performance issues have finally been addressed but some of the work is a wee-bit funny considering the stated direction of ECMSuite.

Facets & Columns

For those people who like to "navigate" their content by browsing through folders and other hierarchies using their web browser, as opposed to using search, facets and columns are likely to be of great benefit. Facets look like a great way to segment or filter local content based upon the metadata in the content. This is a real boon for those organizations that use custom metadata to classify and/or categorize their data AND use a web browser as their primary access to that content. They are extensible and yet relatively simple to configure; a good addition to the Content Server.

If I understood things correctly, columns within a folder are now objects within Content Server and there can now be any number of columns using any available metadata within the system. For instance, if you had a category called "Colour" that was (say) a Boolean expression describing whether a particular image was in colour or black-and-white, it could be used as a column in a folder and the user could then sort on that column (as they do with other columns). The columns can provide "linked" data and for some particular content will undoubtedly be very well suited to this (a quick click finds all the black-and-white images sorted).

The biggest drawback is, I think, that neither are available outside of the web browser-based interface to folders and the Enterprise Workspace. Neither are currently exposed to other interfaces which in and of itself isn't surprising for new functionality but given previous statements regarding the direction of Content Server as a back-end application to SharePoint or to Blackberry / iPad I find it a little surprising that none of these applications have access to either facets or columns and no commitment to do so either.

RAMP

For a change, the majority of the changes to Content Server have not been cool new functionality, rather I'd suggest they are finally taking a bite at long-standing RAMP (Reliability, Availability, Maintainability, Performance) issues.

Booleans

CS10 has finally chosen to look upon Booleans as true Booleans -- taking either a TRUE or FALSE value and properly recognizing that there are many ways to say "TRUE", like "1" or "true" or even "yes", similarly there are just as many ways of saying FALSE...this is only something that a long-term user will appreciate because everybody else would expect that it worked this way (what else does "Boolean" mean?) ... still, definitely an improvement and goog to see.

Dynamic Threads

Mostly because Open Text pretty much ignored the plight of the large Content Server site administrator, particularly at install time, there has always been a desire for a single CS process to handle a large number of threads; setting up and maintaining multiple CS instances to meet a demand requires significant manual effort and once deployed appears to some to use too many resources. To fully utilize server resources (in particular CPU) requires multiple CS9x instances (often 2, 3 or more per CPU core), so-called vertical scaling, in fact most servers will run out of RAM long before they run out of CPU. CS10 promises to change that, allowing for as many as 32 threads according to various Open Text personnel at TechConnect.

I've already written about how Open Text has missed the mark on the Dynamic standpoint (the number of threads can dynamically grow but never shrink) but if a single CS server can in fact handle 30 threads as effectively and efficiently as 5 6-threaded CS9.7.1 servers can then this is definitely an improvement for very large scale deployments.

As good an improvement as this is, I think caution is prudent here as well; a lot of what makes CS so good at scaling up is that each "front end server" is independent of the others and vertical scaling means that each CS process is limited by the Operating System as to how much CPU resource it can use. Because all CS processes are non-privileged, they equally share server resources, if you have 4 processes all competing then each will get 25% of the available resources. Thus, though one thread can sometimes negatively affect other threads within the same CS process, it wouldn't affect the other processes whether they are vertically or horizontally provided. This natural redundancy and resilience has now been removed, one bad thread can (potentially) affect 30 others. Such interference has historically been rare and I've no reason to believe it will increase in frequency with CS10, but the impact on a running system will be much greater when it does happen.

Also, twice I heard Open Text personnel suggest that the new higher thread count was due to using a 64-bit Operating System ... I am having difficulty with this logic, I can't see why a larger address space would in and of itself allow for more threads (or to put it another way, why a 32-bit environment would stop more threads from effectively working). I surmise that this is either inaccurate (that there are other changes allowing for the improvement) or there is some future threshold / plateau wating to be found and there may well be thread scheduling problems yet ... something to watch out for, this needs field testing for sure.

Finally, though the details are very light, it appears that some of the previous per thread caching has been changed to shared caches ... caching is hard and so while this sounds good from a RAM footprint standpoint, I think customers need to look out for caching related performance and perhaps even data-integrity issues as well, particularly in these early days. It is a good direction with good intentions but it will ultimately depend on how well it is implemented.

Search

Another evolution of the already very good Open Text search engine, "the one [search engine] to rule them all and in the end bind them". Again some long-standing issues are being addressed:

• This one finally is based on and using a 64-bit JVM for all platforms. This is potentially a huge benefit to large-scale customers as it should allow much larger search/index partition sizes which should cut back on the required administration time, however as of TechConnect Open Text has explicitly not updated their partition RAM recommendations (suggesting 1GB max) as they have not yet performed sufficient testing to provide better guidance. 
  • I have to say I found this disappointing, I hope these updated recommendations come soon and I also hope that they support much larger partition sizes, the 1GB limit really sucks. Management of large search / index engines within Content Server is a very complex task, these recommendations cannot come soon enough.
• While the details weren't disclosed, the memory fragmentation issue seen in search / index partitions that were/are causing frequent problems (including service outages) for some customers has apparently been addressed AND the memory accounting is also more accurate
  • This should mean that search partitions which currently shouldn't exceed 80% full or else risk a service outage (because that 80% wasn't accurate) can now push closer to 90% full. This will also tend to help the large customers with resource allocation and should also lead to a more robust service
• New indexing options allow for some content to essentially be excluded from using index resources (like keywords and summaries) further reducing the required resources. I think this could well account for a significant reduction in resources for some.
• Automated index verification with apparently some working resource governors should allow for an ongoing verification of the index partition. This is long overdue but welcome just the same.
  
  • It's not yet clear to me everything that this verification process covers but it seems to happen relatively quickly such that most customers will, I think, be able to effectively utilize this service during "off hours" ... very large customers with 100s of millions of records may still find it too burdensome to use and may have to still just "trust" that all things are well with the index.

Two Search Related Recommendations

1. Though not required, a re-index / re-extraction is a good idea. A number of the above advances will only come into play after re-extraction, however I'll repeat that search is backward compatible so you don't have to re-index, but the benefits of doing so seem worthy of the extra effort.
2. The new search engine will be provided to existing CS 9.7.1 customers, given that the engine apparently fixes the fragmentation issue (or at least provides more accurate information), it is a worthy upgrade that should be transparent.

GUIDs are now in use!

I didn't dig really deep into this but I did hear the Customer Support folk at TechConnect claim that GUIDs, or Globally Unique Identifiers, are now in use for CS objects. Assuming this is accurate then it should have two positive effects for Content Server:

1. The 2 billion object restriction per CS instance should disappear --- whether that has already occurred or not I couldn't say but a GUID has a much larger address space and should effectively remove any restrictions (I didn't hear them say that however so I suspect that is not yet true for some technical reason, it will take quite an engineering effort to replace CS object IDs with GUIDs but at least it is now started ... this is either good news or GREAT news)
   
2. A global deployment no longer should have to play silly-bugger with the object IDs used in order to share content between various instances ... the GUIDs should allow for clear, unambiguous ownership of an object regardless of where it was created or where it currently resides. I suspect it will take most of 2011 to figure out how to take advantage of these, but I see this as a necessary step in the right direction.

There is No Compelling Reason to Upgrade -- In fact, I'd advise against it for most

Anybody who knows my work knows that I wouldn't upgrade to CS10. Though there is very little additional functionality, there are some apparently significant architectural changes to the core engine. These changes were significant enough to warrant the major version update (this is not a marketing upgrade but a real technical one) and will undoubtedly need some tweaking over the short term. As a deployment expert, I am always very cautious of a "dot zero" release, a wise administrator of an existing implementation will wait for an as yet unannounced Service Pack 1 release before a production-level upgrade ... it will come and it will fix bugs that are not currently known to exist. BUT that shouldn't stop the testing from starting, a SP1 release will not change the basic steps involved in the upgrade process.

The upgrade process itself is quite convoluted, complicated, and exacting ... much of the reason for this is because of the switch to exclusively a 64-bit OS with no current 64-bit Windows version available for CS9.7.1 and an exclusively UTF-8 database that can only be "upgraded" from US-ASCII as a 9.7.1 server.  The only supported upgrade option is "parallel", which is a good method but will definitely take more time than an "in-place" upgrade. This may not improve (we'll just have to wait and see) but I predict a lot of customers are not going to be happy with this approach. For large deployments this could mean a very large and significant extra cost or (more likely) extended downtime during the upgrade as servers are changed from 32-bit to 62-bit environments, databases are upgraded and configured.

Actually, while I have some sympathy for Open Text on this matter, the current "only supported method" for upgrading is really a significant burden that I predict will not sit well with many customers. While such an upgrade does offer a good time to look at a server refresh, requiring it as is effectively the case for many existing customers will only see the upgrade delayed until such a time that the upgrade is warranted throughout each customers' IT department. This is a loss of architectural flexibility, in my opinion, and I suspect it will keep many customers from upgrading in as timely a manner as OT would like.

New Deployments Should be CS10

While I'm sure there are many CS-based applications and modules not yet ready for CS10, I would certainly deploy this for any new application I could. I think that the likelihood of being affected by 'dot zero' problems is relatively small for new sites and the benefits of CS10 are worthy of taking advantage of. Undoubtedly there will be problems but those problems will likely be smaller than the upgrade effort will be.

Also as a new CS10 customer I would predict you will receive better than average customer support (and OT already has good customer support) as everybody at OT will be highly motivated to make this a good release. That isn't new behaviour, it is the way Open Text has always been and I'm sure it hasn't changed.

CONCLUSION

Again, I've not tried Content Server 10 but this does seem like the best new version of Livelink / Content Server since version 9.5; after too many years, Open Text has finally taken on some of the long-standing RAMP issues. Time will tell whether they have solved them or not but my hats off to them for finally at least trying. CS10 is definitely an evolution of Livelink, there are no revolutionary ideas as far as I can see, but I prefer the evolutionary approach and I applaud Open Text on this release.

I remain somewhat confused as to the direction Open Text is taking regarding Content Server, they seem to be suggesting it is both staying and leaving, but I think this is just Open Text still trying to be all things to all people. This product remains a viable contender in the ECM space and I fully expect that there will be a Content Server 11, 12 and beyond ... Livelink has life in it yet.