New studies highlight the potential downsides of SharePoint
I try to keep track of articles about SharePoint that come from outside the SharePoint Bloggers “Echo Chamber”. I think it’s important to understand what the wider IT audience is thinking and hearing about SharePoint. For those who don’t know her, Mary-Jo Foley is a long time Microsoft watcher and pundit, and has a broad readership among the more senior IT ranks. Unfortunately this article doesn’t really go into enough detail to get a good understanding of the criticism and concerns that are being raised, and I don’t have the $900.00 USD spare to purchase the reports. However, that doesn’t mean I wouldn’t be very interested in reading them, and I’m sure that they will be read by key decision makers at customers zevenseas is working with right now.
I actually welcome this sort of report, as I think the “gold rush” to SharePoint we are seeing right now is resulting in the nail and hammer situation. “When all you have is a hammer, then everything looks like a nail”. SharePoint is certainly not the first product to be seen as the solution to every possible business problem. Lotus Notes, which was an incredible platform for its day, almost self-destructed under this weight. People were constantly trying to make it do “relational stuff”, and even its custodian, IBM, attempted to turn it into an email server (I suspect that may be a controversial statement). Building a great SharePoint solution requires that we, as consultants, know much more than just what the product can do.
Recently, during our first meeting, a customer asked me a question that went something like this: “What makes the zevenseas approach to building SharePoint solutions different?”. My answer came down to a single word. Pragmatism.
While we have great enthusiasm for SharePoint, and we only create SharePoint solutions, it doesn’t mean we feel every business problem can be solved with a healthy sprinkling of SharePoint teamsites. Actually, I would much rather recommend a customer use the specific technology, designed from the ground up to meet their need, than to attempt to coerce SharePoint in to doing something it doesn’t really want to. SharePoint is our technology, and fortunately it is very good at many of the things businesses need, but all business problems should be looked at pragmatically and in the absence of any preconceived solutions or “technical religion”.
The next key application of pragmatism comes when reviewing requirements, and perhaps it is here that it’s most important. Business problems are rarely simple, in fact even the simplest are actually quite complex. And complicating things further is the tendency for them trend toward greater complexity in proportion to the amount of time you spend talking about them as a group. I think you can see where I’m going here. SharePoint is a great platform because it lets you do things quickly, and easily, and often simply by tuning out of box functionality. We are big believers in rapidly prototyping solutions via weekly iterations and getting feedback via actual usage of the system. There really is nothing like actually watching people use your solution, and there are no end of surprises, its a great way to prioritise functionality and understand where your focus should be.
Finally, pragmatism plays a role in the overall design of your solution and it works in partnership with a deeper understanding of the bigger picture. A SharePoint consultant needs to understand exactly why the customer has invested in SharePoint. They must understand the overall landscape in which their projects fits, asking themselves what broader business objectives are being met by the implementation of this collaboration platform. While this is likely a post all on its own, the customers I work with have implemented SharePoint because:
- It’s a very rich platform on which they can build rapid business solutions
- One they can consolidate existing business solutions onto to, thereby reducing the number of platforms they have to support.
It huge out of box feature-set means they can minimise customisation, the ongoing maintenance of which is where the big costs really start creeping in. So, as a consultant, you have two jobs. The first is to make sure you build solutions that work with SharePoint, leveraging every bit of out of box functionality you can, and avoiding wheel reinvention wherever possible. The second is to help those who define the requirements understand just how best to map them to the platform. It means not just taking a requirement on face value and mindlessly building it out, but deciding if small compromises can be made which result in bigger long term cost savings.
What I’m really saying is that SharePoint projects require SharePoint consultants. It’s a discipline all on its own, you wouldn’t get a ASP.NET developer to build you a WinForms application. Just as SharePoint is not simply another Object Model for an ASP.NET developer to pick up. It requires a completely different mind-set, one focused on augmenting, pragmatically, rather than building.
So, in summary, that’s what is different about zevenseas, we’re very pragmatic.