KnowledgeForward

I thought I’d write a few thoughts on a question a client just asked me. I’ll call it the “SharePoint and anything” question and it’s quite common. The company has standardized on some product(s) for collaboration, content management, and portal but now SharePoint is sprouting up all over the place and they want to know what to do. This issue has many dimensions and possible paths, so I’d recommend a client actually talk to me so we can work through it. But I’ll give the high level outline here.

The first question they tend to ask is “Do other companies have this issue?” Definitely! For lots of reasons, both good and bad, the majority of large organizations winds up with more than one system for doing collaboration, content management, and/or portal. I’ve talked to some that list several full portal products in use. There’s a difference between asking what other companies are doing and what best practice is though. Getting down to one platform may not be possible, but it’s a vector in most cases (there’s some complexity here that I won’t expound on right now).

Next, it’s important to determine if you are in an overlap scenario or a contextual integration scenario. Contextual integration just means you have two non-overlapping, complimentary technologies you want to use together like SharePoint and an ERP system. Great - that’s a whole discussion of it’s own that, you guessed it, I won’t expound on right now. But more often it is overlapping with other technology that does a good portion of what SharePoint does. That’s when I poke around and find out why it’s emerging. Because if SharePoint is growing up from the grass roots among other installed alternatives, it must be meeting some latent need that isn’t being met by your current collaboration, content management, or portal.

There are many different types of integration and sometimes organizations want several of these. The project owner has to determine which integration they will need to deal with.  Types of integration include:

• Programmatic/API level: Either custom coding or dedicated bridging applications like SAP’s Duet
• Database/Repository/Metadata level: Sharing or direct access of directories, documents in a document library, etc.
• Execution: Being able to port across platforms, like Mainsoft for Java EE, Portal Edition
• Web Services/SOA: Wrappering functionality in one portal for use in another
• Portlets/Web Parts: Java portlets that can surface SharePoint discussions, libraries, or lists. Or, vice versa, Web Parts that can surface content from other portal, collaboration, or content management products
• Single sign-on: Passing credentials from one system to another
• Unified search: Ensuring that a search done from SharePoint can pull up documents and discussions in another product, or vice-versa
• Screen scraping: Old-fashioned scraping of HTML from one site to display in another
• Linking: As simple as it can get - just helping users of one portal know when information is available in the other by providing a link (but not actually surfacing any content or helping with single sign-on)

Before getting too techie about it, I need to point out that there are technical and non-technical solutions to overlapping portal solutions. Governance and usage procedures are a critical part of the integration and sometimes the entire answer if there are technical constraints. Letting users know when they should upload a document to SharePoint versus their company intranet or their contract management system increases findability of key information.

This is a really quick summary. There are a lot more possible paths to this discussion, such as “systems integration” (connecting it to your infrastructure services, installing and customizing it, etc.), federation scenarios, vendor-specific information about the “anything” vendor and how easy they are to integrate with SharePoint, and more. But those will have to wait until another day.