This is the fifth post in which I provide answers to questions that were posed, but not answered during the webinar I conducted on SharePoint. (See Parts 1, 2, 3, and 4 for additional questions and answers. You may also listen to the recorded webinar, during which many other questions were addressed as well.)
This post is comprised of questions that center around the concept of SharePoint as a component to an integrated solution, including co-existence with other ECM products, issues of integration and how best to position SharePoint.
So without further ado...
Q: Can you please give me a ballpark idea of what a SharePoint developer costs per year?
A: During the introduction of the webinar, and my initial blog post on the subject, I mentioned that one trend that led me to the conclusion that SharePoint is building in market momentum is the daily listing of job openings I receive through my ECM job market agents, for SharePoint developers. The market survey also found that lack of SharePoint experience and expertise was the number 1 greatest challenge to deployment (and partner expertise #5). As a result of such trends, those with SharePoint experience and skills are in demand and command fairly high salaries. I estimate that an average cost is between $60 – 125k year, based on company, location, experience and industry. (In Boston, where I am located about $90k)
Q: Is it true that all documents must be stored into a database?
A: Yes, in order for the documents to be managed within SharePoint they must be stored in the content databases.
Q: How is SharePoint a component for the ECM solution?
A: In a word through integration. But it is likely that the issuer of this question had something slightly more strategic in mind. Several times during the webinar I mentioned that the survey data indicated that SharePoint is predominately used as a component to an overall ECM strategy, not as the entire ECM system. This observation was based on the various data points that showed SharePoint being used in many departments across the enterprise, but in few instances as a standard or heavy usage within any business application. When asked what business applications SharePoint was used in, a few received a "not at all" ranking, and many received a "somewhat", only. This infers that other tools or components are being used by these organizations to achieve their ECM solution for that business application. Also – when SharePoint functionality was ranked by our survey respondents, you may recall, that file sharing and collaboration were used heavily, but many others were ranked as having minimal use. Thus in order to integrate the SharePoint component into a full ECM strategy (with search, records, web content etc.) it would have to be part of a component, not the whole system. So back to the original and terse answer – integration. And yes there is quite a healthy business growing around this at the moment.
Q: Do you have any knowledge or experience with SharePoint in a university setting? Would you recommend its use in that environment?
A: I have no direct knowledge of SharePoint being used in a university or college setting. Are any of you out there using SharePoint in an academic environment?
That said, there is no reason why SharePoint would not function as well in a university setting, as in any other settings. (I have personal first hand knowledge of SharePoint in health care, financial services, professional services, insurance, manufacturing and government.) The point to remember is that the same SharePoint strengths and weaknesses encountered in these other verticals will be the same of academia. (See the market report for detail.)
Q: What type of bushiness application is the best fit for employing SharePoint?
A: According to the market report, SharePoint is most often used for internally facing collaborative portals and knowledge collaboration applications. As mentioned in earlier posts, and elaborated on in the market report, filing sharing and collaboration were the most highly ranked (by far) SharePoint functions. SharePoint can be used as a component of other business applications, but as my experience and the survey indicate, this happens through considerable integration with other tools, platforms and applications. Therein lies the reason for the survey finding that SharePoint implementations are most often complicated by integration issues.
Q: For those organizations that relayed customization as an issue, please elaborate...was cost of customization the issue? Was the customization exercise more difficult than expected? Please elaborate.
A: I will elaborate to the degree I can. The survey did not delve too deeply into this specific issue, but did shed some light. Half of the survey respondents indicated that the deployment of custom SharePoint solutions required more effort than expected. The biggest obstacles cited were (lack of) developers and toolsets, and integration with existing applications. So yes, customization is apparently a major issue, specifically with regards to integration, as opposed to customizing the SharePoint interface itself.
Q: Is it fair to say that SharePoint is being used mostly as a portal application?
A: Based on the survey data, yes, the number one application was internal or employee-facing portals.
Q: Are there OBVIOUS [all caps provided by submitter of the question] differences between mid sized and large companies in terms of usage and/or satisfaction?
A: Interestingly enough – NO. I did run several slices through the data, and found that size organization had little to no influence on overall levels of satisfaction, functionality usage or applications that SharePoint is applied to.
Q: My personal experience is that SharePoint may not be as prevalent in Europe and other parts of the word. I'm curious if this is true or just my limited exposure to the market.
A: OK all you European ECMers out there – what do you say? I can only comment based on what I have heard from colleagues in Europe, that the SharePoint fervor is much like that in the US. Anyone agree – disagree?
Q: Microsoft with the new version of SQL 8 told us that now SharePoint can be used to manage XML files natively and apply a record management to those collection. What do you think about that? We still believe more in a solution like Marklogic, Soft AG Tamino or Ixiasoft TextML to do that type of job. What do you think about our opinion?
A: MicroSoft makes many claims regarding SharePoint, and all are technically true. Does it provide records management – yes, but as the survey revealed most SharePoint users do not utilize the records management functionality. Why – well among those that do use it, it gets poor-fair grades. So while I have no doubt that SharePoint can version control and records control an XML file, I seriously doubt it does so with the same degree of functionality and control that XML specialized tools, such as those you listed in your question, provide. If your strategy includes specific and dedicated use of XML files, I would recommend, at least for now, managing those files in an XML-oriented tool. So – I agree with your opinion. -Great minds think alike ;).
Q: [Note: Two user questions are presented here, as they both focus on a similar issue and can be addressed in a single answer.]
- Hi How do you see SharePoint interfacing with a specialized ECM product such as Livelink from Open Text. Can they co-exist? Thanks
- My organization uses FileNet as its main document repository. We have plans to move toward SharePoint as our document management solution. Even so, FileNet will be around for years to come. Can SharePoint be used to manage content across multiple repositories?
A: The short answer to this question is a resounding YES. Literally every ECM solution provider has a SharePoint integration story to tell. Open Text has been the most vocal and direct about this, but if you look at the marketing collateral of the ECM vendors (including but not limited to Open Text, IBM/FileNet, EMC Document, Oracle/Stellent, Spring CM, ClearView, and even open source ECM provider, Alfresco) you will find a SharePoint integration story. Of course, in this context, it is important to reiterate out a survey finding – integration is a major challenge to SharePoint solution development. Not only is there the labor and time involved, but first and foremost you need to have a strategy – and no “solution provider” can provide you with that. As business users and developers of content, as records managers and compliance officers, as information architects, you need to determine the appropriate approach to integration. Is SharePoint a single point of access front-end, or one repository on the backend, accessed by another ECM/portal solution. Does (some) content get developed in SharePoint and then managed by another ECM at some point in its lifecycle? Does search provide the bridge between the systems. The possibilities are almost limitless. Each should be evaluated from a cost benefit/risk perspective.
And that leads me to the next set of questions.
Q: [Note: Several related questions are presented here, and addressed with a single response. ]
How do you get started with a SharePoint implementation?
What happens to organizations over a couple of years that implement SharePoint without a strategy or a governance model?
- If we are planning on deploying all facets of SharePoint in the next year, what are the largest pitfalls we should try to avoid?
- Do you think that some of the expertise lacking in organizations is that organizations are underestimating the need for expertise in ECM/EDRM etc and that part of the problem is fundamental ECM design
- Was any information gleaned as to the governance and taxonomy development PRIOR to deployment - or have most not bothered?
- Do you think based on the low price point of SP there is an expectation of not properly investing in proper front end consulting?
- Are you seeing today that companies are not setting a IT governance before rolling out SP? How do you avoid recreating a file server file management strategy in SharePoint?
A: Perhaps my response is a bit prejudiced by the fact that I have spent the better part of 20+ years building ECM strategies for organizations, and proselytizing on the importance of strategy and information architecture. So, how do you get started with a SharePoint implementation? Do a needs assessment and develop a strategy. Position SharePoint within the strategy, understanding its role and value proposition. Integrate it into the same information architecture and governance model that you have for all of your business content.
That said – I am a practical realist and so I will add that it is sometimes advisable to simply just get started – i.e. SharePoint is simple enough to support the creation of a handful of collaborative sites, as a learning experience. Let your community explore the merits and drawbacks of SharePoint. BUT – do so with eyes wide open – and be at the ready with a strategy. In other words, there is no harm in facilitating exploration as long as it is monitored responsibly, with an intention to migrate “successes’ into an ECM strategy and corporate governance, and constructively delete and learn from “failures.
Avoid the pitfall of believing that SharePoint is easy. Yes, I know I just stated that it is easy to get started, but realize that is all you are doing. As the survey respondents indicated the biggest challenge to scaling is developer talent and integration issues. Also, as the survey respondents indicated, be aware of the fact that in many cases specific SharePoint functionality (e.g. records management and security) may not meet your organization’s needs. So be prepared to augment SharePoint with complementary tools and technologies. Do not “settle” for SharePoint functionality, unless it is “good enough” for the demands (lack thereof) of your organization. (Sounds like a strategy right?) If an organization allows SharePoint to organically grow without any governance or management over a period of 1 or more years, they will likely end up with at best - a host of individuals sites that meet the needs of individual communities, but that represent a risk because there is no way to manage or appreciate what is contained in the sites. (These organizations have not learned from the e-mail and Notes compliance problems of the past). They also will likely end up with silo solutions, severely limiting the value of the content repositories.
Unfortunately adequate planning and strategizing often does not precede an ECM implementation, and the chances of that occurring only increase with a tool such as SharePoint which can appear to be “so simple” initially. I have said it before, using e-mail is very simple as well, and that is what has gotten many organizations into a sticky and often expensive situation. Ease of content creation and sharing leads to lack of control, lack of governance and no establishment best practices. This situation is potentially viable for unsuspecting SharePoint users. But not only is this a matter of risk and best practices, it can also lead to under utilizing SharePoint. The last questions was a good one – how do you avoid simply creating file share? Answer: – plan and strategize.
Whew - that was a loaded set of questions that led to a lebgthy answer. BTW - the observatiosn and opinions asserted in teh last response are being echoed in teh interviews I am conductiong with SharePoint users. Some interesting case studies are emerging - and are forthcoming.
On that note - if any of you out there feel you have an interesting SharePoint experience to tell (positive OR negative) - I would like to hear it and share it with our community. Contact me though this blog - or e-mail directly - cf@informationarchitected.com
With that I conclude this post with some good news - I am almost done addressing these webinar questions. The next post, which will focus on some hard hitting technical and competitive issues, will be a bit different - so stay tuned ...
