The Two Sides of SharePoint's Integration Story


After four years of evaluating Sharepoint, Peter Campbell, the Director of IT at Earthjustice, decided to pass on the Microsoft portal/content management/team colloboration software. He recently explained his decision on Idealware, a tech Web site for non-profits.


Campbell gives a list of reasons why SharePoint scares him, but what really grabbed my attention is that he sees SharePoint as a choice between integration capabilities and fostering integrated, colloborative work.


There are a lot of things about SharePoint designed to simplify integration. Campbell notes that SharePoint would simplify his life because it integrates with Microsoft Exchange, Office and Window Directory (of course) and because it also includes hooks to a range of databases. That said, Campbell's quick to warn that the integration can quickly get tricky if you're dealing with legacy systems (and who isn't?) or advanced programming.


So, I guess I see it as a bit ironic that he's rejecting SharePoint because he-and others-say it creates a jungle of document silos. For this and other reasons, Campbell believes SharePoint will make the organization less integrated in terms of how the members work and share information:


"If my goal is to promote collaboration and integrated work in my organization, using technology that transcends and discourages silos, I'm much better off with apps like Drupal, KnowledgeTree, Plone, or Salesforce, all of which do big pieces of what Sharepoint does, but require supplemental applications to match Sharepoint's smorgasbord of functionality, but are much less complicated and expensive to deploy."


But Eugene Rosenfeld, the CTO of Black Blade Associates, begs to differ. Rosenfeld is a Microsoft Office SharePoint Server Most Valuable Professional (aka, MOSS MVP), so obviously he has a vested interest in defending SharePoint. And, in a post published Monday, he does so politely and reasonably.


For instance, he notes that while it's true SharePoint integration becomes more complex with legacy systems, the same is true with all technologies.


Of particular interest to those of you concerned with integration will be Rosenfeld's rebuttal of this conclusion by Campbell:


"I can't help but contrast this with the far more manageable and affordable alternatives, even if those alternatives aren't the kitchen sink that Sharepoint is. Going with a non-Microsoft portal, I might lose all of that out of the box integration with my MS network, but I would jettison the complexity, demanding resources, and potential for confusion and site sprawl."


Rosenfeld says he began his career doing enterprise application integration, and he counters it's easy to overlook the costs and time application integration can add:


"I can tell you from experience that getting multiple applications to talk to one another in a way that is meaningful to your end users is always much more expensive than procuring one, integrated application. You're generally looking at a 3X cost increase for the labor costs to do the integration. Also, don't forget to budget extra time on top of deploying the systems to do the integration work."


Taken together, the two posts are an educational point and counterpoint on SharePoint and its integration story. You'll also find both pieces link to additional useful discussions on SharePoint.


As an aside, I should mention there is one issue Rosenfeld didn't address and perhaps he should have: Campbell's complaint that SharePoint "... integration is based on SOAP, not the far less complicated REST standard...."


I feel obligated to point out there may be good reasons for this. Some say SOAP is more useful if you're concerned about security, encryption and reliability-all appealing attributes for business users. On the other hand, there are those who say this is a lot of bull - REST can do that too. Both sides, however, acknowledge there are times when you might choose SOAP over REST, or vice versa. And that's as far down the SOAP versus REST road as I'm going today.