loganpoelman.com

They think, "Ah, we make our stuff run in Sharepoint. Thats cool." Basically the "poke our web app thru an IFrame in SP and you're 'built on SP'" mindset. Problem is, thats not what their customers think when they say "Built on Sharepoint:."

SP is a bit like its own operating system (on top of another OS.) Its a framework and a toolset. Whats the difference? Your code calls a toolset. In a framework - IT CALLS YOU! 

A framework, like sharepoint (or LifeRay / WebSphere Portal / Plumtree / SAP Portal / ...), defines the behaviors/properties/features you need to implement. In exchange, it gives you a LOT in return. Think of it like taking all the common stuff you write in 5 applications, extract it into a single place (the portal) and you just write the stuff thats new/different. less work but that means less control for you.

Why should customers care? because they can buy stuff from other companies than you and it will integrate with your stuff with little or no effort. Also, the customer can create stuff in the portal, like workflow, and integrate it with your stuff with little effort.

Your dev team needs to use the facilities Sharepoint offers BEFORE they just go build their own. Sometime that means bending/warping things to follow the Sharepoint view of the world. But if you don't your stuff won't fit in nicely and "play well with others." 

So, if you are going to 'Sharepoint Enable', you need to "drink the koolaid," because its likely your customers already have (Microsoft markets these stuff heavily) or you risk looking like a Sharepoint Enabled Wannabe.