""What a seamless integration with SharePoint..."
"It's really, really fast (duh)..."
"See those Refiners on the left? That tells you who edited what file format and when -- coooolness."
These are some of the superlatives bestowed on FAST 2010 Server for SharePoint. Some of the praise is probably deserved. "View in Browser" is an instant lifesaver from needing to yank fat office artifacts through thin pipes. But some of the backslapping sounds hollow -- the same Microsoft ECM services binging from the same punch bowl for SharePoint. Down in the boiler room here's where I'm not feeling the love yet:
Unless you've been limping along with native SharePoint search, there are no out-of-the-box gratifications here
Any looming leaps forward require some heavy off-UI scripting
Testing those improvements requires a crawl cycle that defies the real-time response necessary to tweak a search platform effectively
Oh, and the users? They're too distracted to care that Refiners as time frames are really time stamps in server logs and that authors are administrators with network access
Here’s what I’m finding out through trial and mostly error while we conduct a bakeoff between FAST and Coveo, the incumbent vendor dating back to our SharePoint 2003 edition of KM at PRTM:
FAST doesn’t do multiple values -- more specifically multiple values can be indexed IF you don’t use them in facets (as Refiners). Sound familiar?
FAST doesn’t eliminate bogus system fields from the index like “Created By / Modified By.” Even if you uncheck the “include values” in the search index they keep right on coming.
The Fast Index is very powerful and undiscriminating. The good news is that the crawler never met a text-string it didn't find fascinating. The downside is that FAST dredges up old tires and the mosquitoes that inhabit them.
It makes no sense to hunt for the scant number of metadata fields in use versus all the column properties it surfaces – there are thousands. Key to containing the index is mapping important fields to a common value. Content architects seek this safe harbor between the comfort zone of known entities and a state of metadata impairment known as PEAD ("permanent enterprise attention deficit").
It's also not clear how to align MMS strategies with the tagging structure rendered by the index. The only constant here is miscellaneous. It's dubious even when we try to feed structured lists like accounting data. Like so many of the value adds in the FAST configuration toolbox, the "add companies" feature is useless in GUI mode. Outside of Powershell entities need to be added one at a time.
Can you imagine adoption of MMS one tag at a time? We'd have 43 variants on "managed" to mediate! Still, without any customization we're left underwhelmed with company name entities like "Mfg" and "KPI" -- leading indicators that humans were not involved in building the FAST extraction vocabulary.
Here's how not to get PEAD off:
Add a set of "Managed Properties” that captures the metadata properties worthy of structuring a search-driven architecture.
Instigate those values as Refiners.
Turn activity streams on ASAP to leverage People search -- an out-of-the-box experience worthy of the milestones that separate yesterday from tomorrow in a hurry
Are we happy yet? Once we hear back from our users we'll have a final verdict -- not just the latest version.#SharePoint #EnterpriseContentManagement #managedmetadataservices #Toolkit #FAST2010ServerforSharePoint #PeopleSearch #ScanningandCapture #SharePointSearch #activitystreams #userexperience #managedproperties #Coveo