No, this is not the pitch for a knife set or some kind of mandoline/chopper hybrid.  This post will delve into StoragePoint’s ability to be more than just a SharePoint BLOB storage solution.  Hopefully it will provoke some thought about what’s possible with this powerful solution.

Co-existence with other CM/DM platforms

I generally abhor the idea of co-existence strategies as it relates to SharePoint and “legacy” CM/DM platforms because:

1. They give Microsoft and partners an excuse to go for the easy win instead of the knockout punch.  I’ve seen Msft AE’s rollover too many times in the face of competing with one of these so-called “partners”…it’s painful and frustrating.
2. More times than not they are a desperate attempt by “legacy” vendors to stave off the wholesale commoditization of CM/DM that SharePoint represents…to the point where their technology becomes cost prohibitive or even worse old and irrelevant.
3. And up to this point the “legacy” vendor has controlled the messaging around co-existence.  BTW, the constant reference to these platforms and vendors as “legacy” is a not so subtle shout-out to how god awful old some of this stuff is.

All that being said, there are many legitimate reasons for co-existence.  They range from simple economics (…we just invested millions in this and we can’t just scrap it) to risk tolerance (…we have so much content in so many places that we can’t just flip a switch and put it all in SharePoint).  With legitimate reasons in mind I offer up StoragePoint as a solution.  It can easily be used to externalize content to “legacy” CM/DM platforms as well as provide a means to slowly migrate from said platforms over time.  To prove this out I prototyped a StoragePoint adapter for FileNet Image Services 4.0, packaged it up as a solution, and deployed it to SharePoint.

Once installed and activated I created a StoragePoint storage profile using the new adapter and supplying a connection string pointing to a library and document class on an old FileNet image I dusted off…seriously the drive this thing was on looks like it came from a recently dug up time capsule.

With a profile in place I went to the Invoices document library on my Finance site to upload a document and provide some metadata.

Behind the scenes StoragePoint pushed the BLOB along with promote-able metadata to FileNet Image Services via the adapter.  You see from the StoragePoint Details panel that the document was in fact externalized.  The number noted in for the Folder property is actually the Document Id returned from FileNet…take note.

We can also view the document within SharePoint using any standard viewer…I’m using KnowledgeLake’s in this example.  Remember, when I clicked on the link in SharePoint to view the document it went out thru StoragePoint, thru our adapter, and pulled the bits back from FileNet.

I then flip over to my FileNet image, load up IDM Find (Panagon Desktop search tool…sporty ain’t it?), and search for the document by Invoice Number.  Note that the ID of the document returned (100039) matches the Document Id from the Details panel above.

Opening the properties window for the document shows all the metadata from SharePoint was promoted to FileNet.

 And last but not least you can open the document from within FileNet.

So with nothing more than some trivial adapter code (I worked on FileNet systems for 10+ years, so it’s all relative) we have a bonified co-existence strategy.  I can view the documents and metadata on both systems…and we’ll discuss find-ability below.  You can obviously apply the same approach to Documentum, OpenText, Stellent, or anything else out there.

And because we’re effectively managing the content in SharePoint we can also control its retention/destruction from within a MOSS Record Center…can I get a “Federated Records Management”?

Federated Search

Now that I’ve created a relationship between a list item in SharePoint and content sitting in another repository I can use SharePoint’s search capability, whether that’s the current OOB flavor or FAST to enable federated search across an organization’s StoragePoint-enabled content repositories.  Existing content in these other repositories would be accommodated by simply synthesizing placeholders in SharePoint…we’ve done this before…it’s easy.

And no this isn’t some fantasy or drug-induced hallucination.  It works…be happy to show ‘ya sometime if you’re not buying it.

And you will obviously also be able to search for the content within the other repository…as shown above with IDM Find.

Migration Platform/Framework

This is my favorite part…unplugging those out-dated, bloated, and expensive CM/DM platforms.  Without writing any additional code I could simply run a Recall job which would pull all the content back into a SharePoint content database.  Once there I can turn that other system off…trust me, it will feel good.  From there I could change the Storage Profile to put it on my SAN or NAS and run the Externalize job.  Ideally we’d develop some kind of Migration job that would be a hybrid of the Recall and Externalize jobs already in StoragePoint, without the BLOB write to the database and read back out…don’t need to incur that overhead. 

Are you feeling it?