Are you considering SharePoint for your enterprise? For what purpose? And what's your definition of enterprise anyway?
This month CMSWire is taking an in depth look at where SharePoint alignswell in the enterprise, from an enterprise information managementperspective. I have been working with SharePoint 2007 pretty solidly forthe last 3 years (and the previous versions before that) and I havebuilt solutions that used pure out of the box SharePoint, solutions thatincluded custom development, and solutions that included integration ofthird party software in order to meet the requirements.
This situation describes what you may call the major advantage (blessing) or disadvantage (curse) of SharePoint depending on your viewpoint, your bank balance and your available pool of .Net expertise!
I have not built any solutions on SharePoint 2010 yet, but I have evaluated deeply, and indeed am currently doing so again, both from an internal social media perspective and an intranet portal perspective. SharePoint 2010 has many improvements over MOSS 2007, but in the end I believe that is just detail. The overall picture remains the same, there are considerable benefits and dis-benefits to large enterprise deployments of SharePoint.
What Size is Your Enterprise?
The first question is, what is your definition of an enterprise deployment? My last employer had a series of global intranet portals based on MOSS2007 served from data centres in North America, Europe and Asia for upward of 55 000 employees (not all concurrent users, obviously!). With customized applications the application of Microsoft's service pack 2 caused horrendous performance problems that took months to diagnose and fix.
However if you were in a single data centre, with a minimal WAN (with good bandwidth) and say 10,000 users (i.e. my employer before the last one) the performance issue might not have been quite so debilitating. Although you can break any underlying platform with customizations, this is in some respects due to the arcane architecture of SharePoint -- how many "12 Hive" experts do you have in your development group?
This in turn might be viewed in the context of the breadth of functionality baked into this single platform --- how many other products do you know that attempt to tick so many potential requirements boxes!
Returning to the subject of defining the enterprise -- if you have 8 departmental level implementations of SharePoint, 5 for collaboration, 1 for BI dashboards, 1 intranet portal and 1 for Records Management, and at some point or another at least one of them touches all points of your business, then does this qualify as an "enterprise wide" deployment? While I would say it does not, you might say it does...
What is Your Enterprise Use Case ?
Of course another double edged SharePoint sword I alluded to above is the question of what exactly do you want to use SharePoint to do? In SharePoint 2010 we have the six main capability areas as depicted in the diagram below:
- Sites -- The web publishing functionality enhanced for improved personalized experiences across intranet, extranet and internet sites.
- Communities -- The collaborative element of SharePoint, think ‘team sites’ in the MOSS 2007 vernacular, plus new features, many of which encompass elements of the SLATES model.
- Content -- The home of the enhanced Content Management features, including Records Management and some limited Digital Asset Management (audio, video and graphics files).
- Search -- One element of increased findability via SharePoint is the improvements to search. People search facilities have seen some considerable enhancements in SP2010.
- Insights -- Collaborative Business Intelligence including features such as Excel Services, Performance Point Services and Business Connectivity Services.
- Composites -- SharePoint's features for building ‘composite applications’ (aka “mashups”) this includes Visio Services, Access Services and SharePoint Designer.
Your enterprise deployment scenario may include only a single capability area, for example from the Content area you may be intending to deploy SharePoint as your enterprise wide Document Management solution. Or you may be looking at multiple capability areas, or even all of them.
If you are looking at multiple capability areas you need strong governance arrangements as well as the technical resources, as you will need to take an holistic approach and follow a "think global, implement local" type of approach, with a truly strategic approach to planning at one end of the spectrum, and small iterative pilot projects at the other.
For example, in my experience as a consultant it is rare that there is either a single business owner, or a single technology executive that owns the SharePoint "platform" -- instead you're likely to have one team responding to a business sponsor who wants business intelligence dashboards, and another responding to the requirement to integrate My Sites and social features into the intranet. These different sets of requirements might be competing for the same internal (or external) resources.
So on this front my advice would be this, as your use cases for SharePoint become broader and more diverse, worry more about your governance than the purely technical aspects.
I should also provide a few lines on that particular issue that often seems to surface with SharePoint. Someone bought it to fulfill some particular requirements, and now it is seen as the answer to everything; is this line familiar "the answer is SharePoint, now what is your question?" It's a great idea to leverage your existing technology to ensure a better return on investment, but it's never a good idea to ignore the business requirements and force a square peg into a round whole.
What is Your Enterprise Procurement or Development Model?
Yet another disputed potential advantage or disadvantage of SharePoint as a .NET platform is the "ecosystem". For every potential hole in the out of the box product, there is a Microsoft partner ready to sell you a solution. As described by J.B. Holston, NewsGator's President and CEO in my article on NewsGator integration with SharePoint 2010, Microsoft's long development cycles for the broad underlying platform ensure that their more agile partners can fill multiple niches much more quickly and nimbly. So for you this means a choice has to be made:
- Use SharePoint purely "as it comes" out of the box
- Use SharePoint as a development platform and build customizations / custom apps
- Extend SharePoint with third party applications
Which route you will take will depend on many variables: do you have a tendency to do things in house or to out source? Do you have internal .NET expertise or partnerships which can provide it? Do you like to build or buy? Do you have policies on customization versus configuration, etc. Experience suggests if you use SharePoint as a development platform and build customizations then your total cost of ownership is going to increase.
So if we return to the question "Where does SharePoint align well in the enterprise?" that answer can only ever be that wooliest of consultants responses : "it depends" !
The key point is to treat SharePoint like any other potential solution or product, ensure you know exactly what you want to do (clear and well defined requirements) and ensure you understand what approach you want to take (build or configure) and focus on the full range of costs, and the overall total cost of ownership. When you do that you will be able to decide whether SharePoint can meet your requirements and its potential fit in your enterprise information management environment.