Blogs

Information Today's KMWorld held its first ever SharePoint Symposium this past week in Washington DC. A personal highlight was when one of the presenters summoned the cognitive glue that drew an affirming nod in the gallery and binds many KM managers to our critical and often measurement-defying profession: "We are natural organizers from infancy." The speaker then implored us architects, taxonomists, ECM managers, and freaks of metadata to "[G]o outside our industry and look for patterns." Hallejujah. Pass the attribute hierarchies!

One of the gifts of being observational (KM practitioners are by nature outside players) is that we not only spot patterns but can see where the pattern-matching abilities of the insiders tend to sputter out, e.g. their sense-making dries up with their revenues. Nowhere is this impairment more possible than with the legion of third-party tools that sell SharePoint security, audit, and optimization functions to IT administrators. In the hard climb to deployment, this is what Shawn Shell calls those three missing top steps on the top floor of our long, huffy haul up a flight of SharePoint stairs.

Case-in-point: when I got back to the office my team and I did a pre Proof-of-Concept demo call with two leading SharePoint 2010 migration tools. The takeaway? The sales guys weren't over-promising. The sales engineers weren't talking over our questions. Given the fact we spent no time on compliance and security we had the balance of an hour call for unscripted scenarios that focused on supporting users -- instead of the help desk.

The SharePoint migration hype cycle can seem like a cable news channel unto itself. That’s because third party providers smell an opportunity to offer an integrated set of platform tools for administering SharePoint farms. They tout the higher level view they afford system administers to view and act on Microsoft’s chronic inability to aggregate the usage, replication, storage, and governance associated with its enterprise-level products: Who will approve this? Who will create that? Who gets to publish and what version can be assigned to so forth?

It was plain to my team that third parties were speaking to aspiration (let's migrate!) more than reality (here's how you configure and deploy). That's understandable. Getting in sync with the enormity of the API is hard enough. Weaving that into a unified UI with plausible dummy data, referencable contacts, and delivering WOW factor outcomes for your users? Ahem ... SharePoint 2013 anyone?

There’s no end to the over-engineering in the endless loop of limbo numbers on the dance cards of Microsoft partners and tool vendors. Some see this as deliberate, others as a nuisance. Either way, a Microsoft-pure approach to native SharePoint is an invitation to weed-whacking, not summit-scaling by any stretch. For that there’s an entire gift shop of gold certified vendors who write code designed to backfill SharePoint’s inability to present or instigate an enterprise level view of your Content Database.

Ironically, it wasn't the migration story that wowed us but the more stable and established content management tools that provide a rich inroad into the user experience that are lost in the log files of our current MOSS deployment. Our thinking? If we could do our splits and merges of our content databases and content types in one encironment then we could prepare the new 2010 architecture with our content and configuration settings in tow. That means using a database detach method for moving day and then rebuilding it as a test environment in the new home. In effect we would bypass the need for dedicated migration tools which are still being tested themselves.

That said, I don't want to oversell this competing vision of your next deployment plan. I'm no farm admin or application programmer just as surely no advocate for the cowboy approach of "big bang" content migrations. Any glimpse into your ECM’s content distribution patterns requires third party site administration tools that can double as quality checkpoints for testing your file preparedness for migration. That’s just the kind of small stuff that can snowball into a massive headache as your rollout grinds to a halt.

The important thing for us ECM managers and KM grunts to keep in mind is that we see the patterns that speak to our users. The fact that the tools guys don't know how to price these capabilities (or even know their value) is no less reason to leverage content management functions as enterprise reporting tools. That more than any purchase or service is the key to a successful 201o deployment. Maybe then the work we do will become slightly easier to measure?

We can always hope.