Since I posted the last set of questions and answers emanating from the SharePoint webinar, I have had approximately 500 people everyday reading the blog. That last post posed several questions to you - the readers of the blog, asking you to share your opinions and experiences. To date I have had only three contributors.
Aw - come on you knowledge workers, enterprise 2.0 zealots, collaboration enthusiasts, ECMers, clearly you have something to say.
Make a comment. Share your experience and opinions.
I rolled up the questions here:
Is Nintex the only viable and practical workflow complement to SharePoint?
Are Interwoven, FatWire and SDL Tridion the only alternatives to Sharepoint in the WCM/DAM space?
Does anyone have a best practice or any type of experience in migrating content stored in other ECM systems into SharePoint?
Is Unity Studio a viable alternative to SharePoint for collaboration? What are the other options?
Does anyone have a best practice or any type of experience in migrating from Lotus Notes to SharePoint?
Of course add any other SharePoint opinion/experience you have.
This is it – the final post containing questions from the SharePoint webinar I presented on January 28, 2009. Previous questions and answers can be found in Parts 1, 2, 3, 4, and 5. As well, the recorded webinar, during which many questions were answered, can be downloaded.
The questions in this post are the most technical and product specific of all the questions asked during the webinar. I wish to state again, that my expertise and that of my company, Information Architected, is defining strategies, cost justifications and project plans for content, process, knowledge and innovation management. We focus on the intersection of ECM technologies and business management. Technology such as SharePoint are clearly within our sweet spot, and lately we have been involved with many strategies that involve SharePoint, but unlike consultants who specialize in integration services and solution deployment, Information Architected does not have intimate experience with the inner workings of SharePoint. I state this because, as stated, this post focuses on many highly technical and product specific issues. As a result, my answers are not as in-depth as those provided in earlier posts.
I have answered each question – but I am also asking questions in my answers. In the spirit of collaboration, those of you that can shed further light on these answers please do so in the form of a comment.
OK – with that said, here goes, the final 8 questions:
Q: Several other products are beginning to roll out SharePoint "connectors". I'm particularly curious about workflow - what is the adoption and satisfaction for those complementary pieces? - Any information about using Nintex workflow with SharePoint?
A: I am aware of one company that I have worked with (manufacturing vertical) that selected Nintex as their SharePoint-integrated workflow product. In their case the integration went very well, and user satisfaction is high.
Anyone else have experience with Nintex and Sharepoint willing to share your experience or opinion? How about other workflow products? Which work well or poorly with SharePoint? (Solution providers feel free to chime in, I ask only that you identify yourself as such.)
Q: In the WCM / DAM space, how does SharePoint fare against other products like Interwoven, FatWire, SDL Tridion etc.?
A: You may have noticed, Simon Cole of Autonomy commented on an earlier blog post on how the Autonomy product stacked up against SharePoint? He focused on the records capability of Autonomy/Meridio. Any other solution providers want to weigh in on this? Is the list of competition provided here (Interwoven, FatWire, SDL Tridion) all inclusive? What other products belong on this list? How would you rank them? Solution providers and users with experience comments all welcome, but please identify who you are.
Q: When migrating to SharePoint, What's the best way to deal with a large amount of legacy files stored on the FileServer? Can SharePoint be a replacement to File Servers?
A: First, the easy question – yes SharePoint can, and very often is a replacement to file servers. But what if you are migrating from a file server environment (or other approach to organizing online files), is there a best practice or toolset that simplifies the porting of the content into SharePoint?
I am aware of one company that needed to migrate gigabytes of content from Documentum to SharePoint. In this case, they wrote a macro that exported the content and all associated metatags and security schemes (this was the tricky part) from Documentum, to a file share area, and then imported into SharePoint. Other experiences or recommendations?
Q: We have a client that was sold SharePoint implementations - but don’t have the staff to operate it. There is a lot of discussion for our team to setup SharePoint Templates - What is the best course of action we would want to take before we even start to build templates?
A: I believe that you are on the right track. I have witnessed many organizations, especially those with a lean development staff, leverage templates to expedite the creation of tailored SharePoint sites. (Application templates are “out-of-the-box” SharePoint scenarios tailored to specific business processes or settings. They provide a starting point for “developers” looking to build SharePoint-based solutions.) Templates are among some of the more popular features of SharePoint. In fact, the most common complaint I hear about them is that there are not enough commercially available from Microsoft or 3rd parties (business opportunity?) On a non-technical note, start by determining which scenarios would be most leveraged within your organization. Do a needs assessment to determine the least common denominator of what is needed by those scenarios and then develop templates to fit those needs.
Are there technical best practices for template development? Anyone care to share their experiences and opinions?
Q: Have you seen any who have abandoned SharePoint that are adopting other collaborative tools, such as Unity Studio with which you can develop interlocking systems between different pieces?
A: I have not yet had the chance to speak with anyone who has abandoned SharePoint. (You may recall that 2% of the companies I surveyed indicated that they had deployed SharePoint in a production mode and then abandoned it.) While the survey uncovered that the primary motivation behind abandonment was security concerns, it did not shed light on what was done as an alternative.
As for Unity Studio – no specific knowledge on my part. (The only reference I could find to it using Google was an in-house “collaborative software environment for industrial automation and all disciplines needed to design a process or a plant", developed by Schneider Electric.
Are there any Unity Studio users out there that care to comment?
How about others who have decided to use a competitive product? What are the valid alternatives to SharePoint in your opinion?
Q: What do you recommend for SharePoint site collections in terms of flat and wide or a deep hierarchy design pros/con.
A: This answer is obviously a matter of opinion, in this case mine - flat and wide, based on taxonomy and portal usability tenets I believe in. But what do you say?
Q: Where do you see SharePoint consulting firms investing in their practice skill sets given the 'sophomore year' of SharePoint?
A: Hmm – anyone out these that would like to weigh in on this? As potential customers of such services, what talents and skills are most desirable in a SharePoint consultant/programmer?
Based on the survey, I would think that experience and methodology for integrating SharePoint with security and records control would be high on the list.
Q: We're looking to implement SharePoint at our location (3500 users) to replace Lotus Notes. I would like more information on what system requirements and staff needs to implement and maintain the system.
A: OK all you users and system integrators out there what do you say? What is the “right” staffing mix for a SharePoint deployment of 3500 Notes users. Anyone with specific experience migrating from Lotus Notes? Have any of you lived through a Notes to SharePoint migration? What were the lessons learned? What skills were most important?
And with that – THAT’S IT. The outstanding questions from the SharePoint webinar have all been answered. Ongoing dialogue and answers to the questions I posed in this post are certainly welcome however.
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.]
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?
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 - email@example.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 ...
You may listen to the recorded webinar, during which many other questions were answered.
This post has a theme to it - Records Management and SharePoint. Several questions were asked, all revolving around this issue. I have grouped them together, hoping that the juxtapositioning of questions and answers will render a result greater than a mere sum of the parts.
So here goes...
Q: What do you consider the difference between document management and records management?
A: Clearly this question is not a SharePoint specific issue, but a far more basic ECM question. I imagine it came up in the SharePoint webinar because, SharePoint received better grades for document management functionality than it did for records management. I can and do provide lengthy training and lectures on such subjects, but this is not the time or place, so let me be brief. Document management (DM) is basically the ability to provide library services on a file. It tracks revisions (edits) and maintains an audit trail of what was done by whom to the file. Additionally most DM systems also provide some approach to search and retrieval, and security. Records management (RM) is a far more formal and structured discipline, governed by a litany of standards and best practices. RM systems support the definition of a classification scheme for categorizing documents into “record types.” Additionally RM tools allow users to, or automate, the declaration of documents as records. Once declared, the records are secured, and maintained until their declared destruction or archival date is met, and then appropriate action is taken. RM systems can also play a critical role in e-discovery and compliance applications. Again, SharePoint gets “good” grades on document management, and “poor” grades on records management. (See earlier post for more detail.)
Q: Why do you think the survey respondents said that SharePoint is not used or only used somewhat in compliance and e-discovery applications?
A: I believe the answer to this question is implied in the response above. Put frankly, SharePoint does not provide adequate functionality to address records management and therefore is not heavily used in applications that require this functionality, such as compliance and e-discovery. Those who are using it “somewhat” are likely using the SharePoint environment as a platform for file sharing – only – and have augmented it with other integrated technologies and processes.
Q: Does a Records Management program assist in deploying SharePoint?
A: Clearly RM is an area of functionality that most users believe SharePoint does not provide well. So, in scenarios in which RM level control is desired or necessary, then yes, the integration of an RM system with SharePoint can be very beneficial, and render a less-risk SharePoint environment. On the other hand, no, this does not simplify deployment – but rather complicates it. Integration of additional functionality such as RM, was the number 2 greatest challenge sited by survey takers, second only to adequate personnel and toolsets to execute the integration.
Q: Does SharePoint increase the need for corporations to reignite their records management programs? What do we tell executives who think that SharePoint is the ultimate, simple solution to complete records management.
A: SharePoint provides facilitated sharing of files, not necessarily in a secure or controlled environment (read RM.) So yes, in my opinion, an organization should "reignite" its RM programs when deploying SharePoint, at least to ask IF the SharePoint collections warrant records-level ocntrol. If an executive is insisting that SharePoint should “simply be implemented to ultimately solve the records management issues of the organization", a little and simple education is necessary. This is a perception problem of what records management is. Have him/her describe what they mean by records management. If focus is on facilitated sharing – proceed. If focus is, on the other hand, on compliance, point them to these survey findings and beg that they learn from the experiences of those that went before him/her.
OK that's it for the RM questions. In my next post, I will revert back to a rich mixture of issues. BTW - we are getting close. Probably 1-2 more SharePoint Q&A posts, so stay tuned...
This is the third post in which I answer questions that were posed, but not answered during the webinar on SharePoint. (Part 1 and Part 2 also contain related questions and answers.) As always, but especially on this topic, given its relative immaturity, I encourage any of you that have similar or conflicting opinions, insights and experiences to comment.
You may still listen to the recorded webinar during which many other questions were answered and issues discussed.
So here goes -the next 10 questions and answers:
Q: Are BLOBs full-text searchable?
A: This question may have been asked generically, so let me start with a broad answer. In general, BLOBs or Binary Large Objects, can be full-text searched only with some search engines. My understanding is that BLOBs can be made full-text searchable with the SharePoint full-text search tool, but that this requires customization.
Q: How would you define "file sharing"? How is that the same or different from "file document storage"? Is one predominant application of SharePoint a file document storage system? (AND I am tacking on this separate question : How does SharePoint file sharing differ from a normal file system?)
A: Although some may argue that there are technical differences between file sharing and file document storage (comments welcome), based on the tone of the question, I am inclined to answer: file sharing and file document storage are basically the same functionality. File sharing is typically used to denote common access (sharing) of files over a network, usually following a peer-to-peer model. (This is the big difference between file sharing and a simple file system – the ability to share files without replication.) And, yes, based on the survey responses as well as my general, observations, the MOST predominate application of SharePoint is file sharing/ file document storage.
Q: Where is the best place on the Internet to get governance information about SharePoint deployment?
A: I do not know if it is ”the best” but the Microsoft SharePoint website has a sub-site focused on governance. Additionally Microsoft employee Michael Gannotti covers this topic in a recent blog post.
Q: Does the Oracle Integrated ECM product improve the records management functionality of SharePoint that was not positively viewed in the initial survey?
A: The Oracle ECM product, as is the case with many other ECM and RM products such as those from CA, Open Text, and IBM do provide records management functionality superior to that offered natively in SharePoint, and these product will integrate with SharePoint.
Q: How many of the surveyed organizations were using the RM portion of SharePoint?
A: The majority of users, 64%, were not using the records management functionality within SharePoint at all. 5% of the surveyed organizations were using the records management capability within SharePoint exclusively as their enterprise records system. Another 6% were using it to a significant degree. The remaining 25% said they used it "somewhat."
Q: Beyond employee facing portal, what's the next killer application for SharePoint?
A: Based on the survey data, there is no other clear front-runner for a SharePoint killer application, beyond employee facing portals. Although used in many applications, survey respondents predominately positioned SharePoint as a minor role within the business application. Findings such as this one led to the observations that SharePoint is very much positioned as a component to an overall ECM strategy (assuming of course you have a strategy - and issue I will address more directly in the next post - I promise.)
Q: Would you say that SharePoint is more for a medium to large environment rather than the small company?
A: No, one of the strengths of SharePoint is the (initially anyway) low barrier to implementation. While the collaboration and file sharing issues may scale very differently for a large company, many small companies can still benefit from such functionality.
Q: [NOTE: Several questions from multiple individuals have been grouped together here.]
Is Microsoft planning to fix security issues? Do you believe MOSS will bring any value to these findings with significant product improvements in the next 1-3 years or will it continue as is? We are in the process of migrating our SP 2003 sites to MOSS. I am finding the improvements in MOSS (over SP 2003) to be significant. Do you feel that Microsoft is attempting to fill some of the 'gaps' that were mentioned in the presentation?
A: I am not privy to any Microsoft internal strategy for future releases of SharePoint. But I am sure most who watch this space would agree that yes, Microsoft has definitely improved the efficiency and functionality of SharePoint over the last 2 years, and will continue to do so. SharePoint is a strategic and fundamental product for Microsoft and given the number of users already on board, it would be unlikely that Microsoft would abandon the product or put it in mothballs. Note that the FAST search tool that was acquired my Microsoft approximately a year ago, was recently integrated the SharePoint product set into (though not embedded yet). There are also a host of partners that are adding functionality to SharePoint.
Q: To what extent is SharePoint being offered as an on-demand solution vs., installation on the user's servers?
A: SharePoint is available as both licensed software and as an on demand or SaaS solution from both Microsoft and third parties. Among the organizations that took the survey, 30% were using SharePoint in a hosted solution capacity.
Q: Does SharePoint provide version control capability when documentation has been modified?
A: Yes. Among survey respondents, 20% did not use the document management (which would include version control) functionality provided in SharePoint, and 49% used it somewhat.
Q: Exactly how would a BPEL process interact with the SharePoint repository - is it an API, a SharePoint web part, etc.?
A: BPEL (Business Process Execution Language ) for Windows Workflow Foundation (WF) is an add-on for Windows Workflow Foundation in the .NET Framework 3.0. The download is aimed at software developers. (Also see Paul Andrew's blog, he is a Technical Product Manager on the Sharepoint team at Microsoft Corporation. )
OK - enough for now. More to come - so stay tuned...
This is my second post in which I answer questions that were posed but not answered during the webinar on SharePoint. (See earlier post for additional Q&A, and original post for details on the SharePoint study and the slides from the webinar ).
You may still listen to the recorded webinar during which many other questions were answered and issues discussed.
Q: Is SharePoint a hot short-term fad or will we it in prevalent presence 10-15 years from now?
A: I am reluctant to make predictions that go out 10 – 15 years. Far too much can occur to really have genuine insights regarding the fate of SharePoint over a decade+ from now. That said, however, I will say that I do not believe that SharePoint is a “fad”. Far too many organizations have invested time and money into it for it to simply go away like yesterday’s fashions. Moreover, Microsoft has much riding on this product/platform, and Microsoft is a force to be reckoned with. There is every indication that they will continue to support and enhance SharePoint. So while I am reluctant to speculate on what SharePoint will look like 15 years from now, I will state that I believe that it will continue to grow in scope and capability for the foreseeable future, and that it will continue to have a presence in most global organizations. We will see much market activity amongst ECM solution providers to complement SharePoint rather than compete head-to-head, and we will see Microsoft making improvements to SharePoint. What will it look like in 15 years – cannot say, but at the very minimum, remnants of SharePoint applications will remain 15 years from now.
Q: Is SharePoint like another Lotus Notes Virus?
A: OK, I am guessing that this was a bit tongue-in-cheek, but as they say, many a truw word [and question] are said in jest. So let me answer it. This question is perhaps related to the earlier ones regarding the competitive nature between Notes and MOSS. As I said in the last post, Notes users who have built complex and critical applications in Notes, do not yet appear to be actively migrating them to SharePoint with any degree of consistency and momentum. At the lower end of Notes applications, yes, SharePoint is a serious alternative that is replacing many Notes databases. If for no other reason, SharePoint is to be commended to applying pressure on IBM and its Notes product line. In both cases, however, the relative immaturity of the products, as full-fledged ECM solutions still warrants, for many organizations an investment in complementary products, and certainly much customization and integration work.
Q: What are the scalability issues in SharePoint and would you recommend SharePoint to be used as Document Management system, where collaboration is not primary requirement.
A: There are several scalability issues with SharePoint. Based on the responses to the survey, the greatest amongst these are performance issues when increasing quantity or size of the document repository, lack of support for complex document architectures, and the administration associated with larger installations. Based on feedback from users, I would not recommend using SharePoint as an ECM solution in cases in which internal collaboration is not a primary requirement. Again, internal collaboration and knowledge sharing were ranked as the primary strengths of SharePoint and the number one application amongst its users. To leverage SharePoint in a situation focused on other applications (for example, an external customer facing portal, complex internal records and content security management) would be a case of misapplying technology. These features are not SharePoint strengths (yet). Satisfaction ranks high amongst those using it for internal collaboration, and then satisfaction levels significantly drop (to say nothing of the need for customization and integration complexity.)
Q: What are the key functionality weaknesses that make SharePoint a weak solution for records management.
A: Two main issues. First, the records management functionality, known as the Records Center is a MOSS component and does not function in Windows SharePoint Services (WSS). Thus, right off the bat it requires further investment beyond SharePoint itself. Secondly, the Records Center is a platform, not a near-turnkey records application like that available from products such as CA, HP/Tower, Autonomy/Meridio, OpenText, IBM and EMC Documentum. Most records functionality has to be built using the toolset. There is no auto-declaration of records for example, nor rendition control or clawbacks. SharePoint provides only the most basic of records management features. Consider that MOSS Records Center is not DOD 5015 compliant out of the box, but requires a “resource kit” to make it compliant. If you attempt to download the resource kit from the Microsoft site you receive the following message:
“This additional download provides an easy way to learn about the pack while deciding if it is useful for an organization. It is not for production use. Please work with your account manager to engage a partner that has been trained on the DoD 5015.2 Resource Kit to support your DoD implementation.” – enough said.
Q: When or at which cross point is SharePoint expected to seriously compete with other ECM packages.
A: I would say that that time has already come. Granted, SharePoint still lacks all of the functionality that is bundled in the leading ECM suites, but consider that each of these products has a SharePoint integration story to tell. The point is that while SharePoint may not compete feature to feature, it does compete “enough” to be positioned as a viable component of an ECM strategy, as we have discussed, especially for collaborative internal knowledge sharing environments and portals. As Microsoft continues to enhance SharePoint, and there is every indication that they will, it will only become more competitive. Indeed, it is not outside the realm of possibility that Microsoft may acquire a “full-featured” content management system, and leap frog its competitors. Although they have not yet integrated it into SharePoint, recall that last year, Microsoft leapfrogged into enterprise search with the acquisition of FAST.
Q: Thoughts on limitations with SharePoint enterprise search and how FAST might come into play in the future?
A: I purposely listed this question to follow the one above, in which I used the FAST acquisition to show how Microsoft can leapfrog into targeted ECM markets through acquisition. Yes, the acquisition of FAST made Microsoft “a contender” in the enterprise search market, competing with products such as Endeca, Autonomy, Vivisimo and Google. To date, FAST functionality has not yet been tightly integrated into the SharePoint environment, but that is inevitable, and when that occurs, the features and functions of FAST will catapult SharePoint enterprise search functionality, positioning it amongst the leaders.
Q: Would you identify SharePoint as an Internal Social Network?
A: Yes. SharePoint does not provide all of the functionality that comprises social networking (e.g. social tagging and social network analysis), but it clearly has some of it. For example, SharePoint provides Wikis and Blogs, “My Sites”, and the ability to track and share declared groups of colleagues. You may recall from the webinar that most SharePoint functionality gets a “good” rating. That would pertain to this question as well. The Internal Social Networking capabilities are not leading edge, but for many teams – good enough.
Q: Are you seeing competition from open source solutions in same area?
A: Yes, and the most visible is Alfresco.
Q: How many respondents didn’t use SharePoint because they already have another solution in place?
A: I will answer this question in two ways. First, using the survey that was the focus of the webinar. You may recall, that amongst 592 responding organizations, 33% were NOT using SharePoint. Of those, only 5% indicated they were not using SharePoint because of a preference for another product. Not a conclusive answer. Because of the way the question and answer were worded, I cannot tell if the preferred product was already in house (the nature of your question), or if a new purchase was made in lieu of SharePoint. With that said, I will also share my observation based on working with many organizations over the last 2 years. In most cases where SharePoint is being used, other ECM products precede it. SharePoint is being embraced in many cases, not as a replacement, but an alternative. As SharePoint matures, this attitude or approach is beginning to change.
Q: With SharePoint are you restricting yourself to Microsoft platform?
A: Virtually every major vendor has a SharePoint integration story and strategy, so no, you are not restricting yourself strictly to a Microsoft-only platform. But, with that said, obviously, as an organization becomes more dependent upon SharePoint they are becoming more aligned with a Microsoft platform.
OK that's it for this post. You are probably tiring of reading, and I certainly am of typing. More to s=coem so stay tuned ...
Technorati Tags: alfresco, alfresco, CA, carl frappaolo, DOD5015, EMC Documentum, Endeca, endeca, enterprise search, google, HP, IBM, Meridio, microsoft, open source, OpentText, records management, sharepoint, takingaiim, Tower, vivisimo
On January 28, 2009, I was the featured speaker at the AIIM webinar entitled "SharePoint: Fact and Fiction. An overview of key findings and the slides I used during the webinar were presented in an earlier post, and commentary offered by attendees of the webinar were also posted earlier.
The focus of this posting (and more to follow), is on the questions that were asked during the webinar that went unanswered due to time. As previously stated, there were over 100 questions asked. I have removed those that were answered during the webinar and have in some cases merged similar and related questions together and eliminated redundant questions. In this post I address the first 11 questions, in no particular order. So here goes:
Q: Integrating SharePoint with ECM for archiving and/or other ECM capabilities... how many are doing this, why, what ECM capabilities are they using, and what are the technical, business, political issues that customers face in doing this?
A: WOW, this is a loaded question - perhaps a good place to start. The survey did not provide direct answers to each of these questions. Based on the survey responses, however, it is fair to say that the great majority are integrating SharePoint with other systems for complementary ECM functionality. This statement is based on the fact that aside from file sharing and portal platform, respondents indicated that other SharePoint-native ECM functionality is only somewhat used or not used at all (exact percentages will be available in the report.) Additionally, most respondents indicated that integration was a major hurdle to deployment which suggests that most SharePoint implementations involve integration - likely to some degree for complementary ECM functionality. Based on survey ranking of SharePoint functionality (level of quality) and anecdotal evidence from speaking with users, it is safe to think that archival and records management are primary examples of the type of functionality that is integrated into SharePoint, versus the native SharePoint functionality. As for the technical, business and political issues customers face in doing this. Clearly those will run the gambit. The survey did not address this matter, but in my working with various organizations I can tell you that there is no trend, other than typically one or more of these issues will be encountered. The technical issues are many - too many to get into here. Just recall that users pointed to integration and customization as the number one most underestimated cost and reason for project delays. In many cases it behooves an organization that wishes to augment or complement SharePoint to seek out products that can demonstrate preexisting integration. Business and political battles can be quasi-technical. I have witnessed more than one company in which business desires to go "outside" SharePoint face strong opposition form IT that has declared "SharePoint or nothing" as their strategy. There is also the possibility of having to defend why certain functions are even necessary. Oh yes, there was one other facet to this question: "Why do organizations undertake integrating ECM systems with SharePoint?". As you can imagine based on my commentary so far - not for the fun of it. Seriously - there are usually two reasons why. 1. because there is significant ECM legacy and there is therefore a desire to integrate it into the SharePoint emerging applications so as to avoid silos. and/or 2. While there is a desire/decision to go forward with SharePoint, certain business needs (e.g. records control) dictate that a higher level of functionality is required than that provided innately in SharePoint.
Q: How important is it to conduct an Information Architecture design phase of Sharepoint implementation for document management and how do you know if you got it right?
A: What I like about this question is that to a certain degree it highlights the level of naivite that exists regarding not only SharePoint but ECM in general. SharePoint is not a panacea. It does not provide any turnkey solutions that address all of your organizations ECM needs out of the box. So, in my opinion, it is very important to develop a strategy for its application, which should include the development of an enterprise Information Architecture. This is true of ANY ECM system. An Information Architecture should,as a best practice, be used as a foundation to any ECM system, especially one that is leveraged across multiple business applications, users and repositories. To this end SharePoint does not offer anything that any other ECM does not. The Information Architecture is required to ensure a centralized and rationalized approach to capturing, tagging and storing content to facilitate access and findability, and in the best case drive desired end results through the aces to content.
SharePoint does not circumvent that issue with one important exception. In some cases the introduction of an ECM system may be used as a way to help drive user interest and generate input into a strategic deployment. This is often the case with SharePoint because it is simple to deploy at a elementary level. (In fact the proliferation of un-managed siloed SharePoint environments is a common problem in some organizations.) in such cases it would not be critical to precede the release of these early ECM/SharePoint applications with an Information Architecture. It needs to be appreciated however, that when and if a decision is made to move forward in a more formalized and managed ECM capacity, that then the effort should be preceded by the development of an Information Architecture, for all the reasons cited above.
Q: Are you seeing a large amount of Notes to MOSS migrations?
A: There were actually a few questions that allude to Lotus Notes. One reason for this may be my mention of Notes twice in my presentation. The first was early on when I stated that I had not seen such market excitement and confusion since the advent of Lotus Notes. The second was when I made a comment similar to: "some of the confusion stems from the fact that like Notes, back in the early 90s, many today view SharePoint as a solution - when in reality it is a platform. What can you do in Notes - what can you do in SharePoint/ Given enough time, budget and gumption - just about anything." I reiterate this statement because it relates to my answer to this question. No, I have not seen much migration of Notes applications to SharePoint. I believe the main reason for this is because the Notes applications that continue to exist in most organizations today are not remnants of simple file sharing applications. They are more complex applications that have pushed the functionality of Notes using a fair degree of customization and integration to meet very specific business application needs. Therefore migration away from them takes some serious planning. They will not likely simply port over to SharePoint. Where I do see organizations migrating from Notes, these applications are typically being migrated to high-end ECM systems. In such cases, in evaluating SharePoint as a replacement many experience deja vu, i.e. a need to develop much functionality through extensive integration and customization, and as a result are reluctant to so so.
To a lesser degree, another reason Notes applications are not readily bieng migrated to SharePoint is that organizations that are still significantly using Notes are often IBM-centric shops, and therefore shy away form Microsoft-centric solutions.
Q: How were survey respondents using SharePoint? In intranet deployments? Other things?
A: This question is answered in detail in the report - so stay tuned. Suffice to say for now that, the great majority of respondents indicated they were predominately using SharePoint as an internal portal (i.e. corporate intranet), supporting file sharing and collaboration.
Q: Is there a reason why SharePoint is not used much for document management, BPM, Search and other Somewhat used and NOT used categories you have listed?
A: The answer to this question lies, I believe in the relatively low grades that SharePoint functionality got concerning this type of functionality. Aside from file sharing and internal portal development, most users of SharePoint functionality ranked the functionality performance between fair and good. In applications where such functionality is important, organizations apparently are choosing to use complementary sources.
Q: What is the difference between File Sharing and Collaboration?
A: Technically this question is not SharePoint specific - but will get answered anyway. File sharing is a subset or single approach to collaboration. File sharing is the ability to create a common library. Collaboration, by definition goes beyond that to include the ability to engage in dialogue/debate, co-author content in a dynamic manner, create a social network, broadcast/communicate in real time, perform social tagging, among others. While users point to file sharing as a strength of SharePoint, SharePoint does provide many of these other approaches to collaboration as well.
Q: Would you define knowledge management and collaboration, as it relates to a SharePoint application?
A: This question is similar to the one above - so is the answer. As file sharing is a subset of collaboration, collaboration is a subset of knowledge management. Knowledge management can have a technology component to it, but it is about much more than just technology. Technology supports and facilitates a knowledge management practice. (I'll keep this brief, as some know I can go on for pages on the tenets of knowledge management.) Suffice to say that SharePoint is not a knowledge management system, but its functionality can be used to frame and support such a ecosystem. File sharing, collaboration, wikis, blogs, social networking and process automation are all feature of SharePomt that could be used to specifically support a knowledge management practice.
Q: Our large Government Department is using SP for Web Publishing (Internet / Intranet sites) Do you have any info (statistics) on SharePoint for Web Publishing?
A: Among survey respondents: 10% indicated that SharePoint was exclusively used in their organization for web publishing, 10% used it significantly in this capacity, 34% use it somewhat, and 47% do not use it at all for web publishing. Among the 20% that use it in this capacity, 19% ranked the functionality as very good or better, 44% ranked it has fair-poor, with the remaining 38% ranking the web publishing capabilities as good.
Q: Regarding limited use of SharePoint for external sites, was the main reason license costs? Or was it lack of existing SharePoint Internet sites to use as a best practice model?
A: The main reason (53%) cited was security concerns.
Q: We have heard that Sharepoint does not scale effectively for large volumes of documents. Did this also come up in the study results?
A: Only 30% of those who responded to the survey reported having experience with scaling SharePoint. Of those, 23% reported success. The other 7% ran into problems that caused them to stop their scaling efforts. Among those that did encounter problems with scalability, the most-often cited causes were support for more complex content and greater volumes of content (59%), administration (59%) performance (47%) and supporting more complex applications (42%). (There is more detail on this in the report.
Q: Do you recommend using an archiving solution to archive SharePoint data?
A: If archival is an important area of functionality for your organization, and the content created and or managed in SharePoint should be subjected to archival, then yes, I woud recommend integrating an archival tool to augment SharePoint. Such functionality can be acquired in system that provide a wide array of functionality beyond archival (including products from Oracle, EMC, Autonomy, and Opentext), or systems targeted specifically at archival (including DocAve, CommVault and Syntergy).
Please note that the products cited here are not endorsed or even recommended. They were just the first that came to mind. Does anyone know of others - or want to share a positive or negative experience with such a product. All comments and additions are welcomed.)
OK - enough for this post. But stay tuned, there are many questions left that will be answered.
As a prelude to posting the unanswered questions from last weeks webinar on SharePoint, along with my responses, I want to share comments that were received. These are comments made by listeners to the webinar. I do not identify the comments' makers, but I ensure you that they were each made by end user organizations.
Although only 6 in number, they are rich in real world perspective.
I do not comment on them except parenthetically to clarify the context of the comment. You can pull from them what you want.
So with no further ado, and in no particular order:
"my current take on SharePoint: out-of-the-box, it's an enhanced network drive. To use it as a real intranet, you need $125K in professional services."
"Our organization is in the Somewhat Used area [referring to survey findings in which users were asked to rank the level of involvement with various Sharepoint functionality]. We have been using SPS 2003 and migrating to MOSS 2007, my largest issue is licensing cost. There is a big difference in standard vs enterprise for implementing the BPM, forms processing, records management and application development. "
"This [assuming this refers to the webinar and survey findings] is awesome. So good to know we are not alone in this pain. thank you"
"From a developer perspective, there are major hurdles to becoming effective - bad development environments, incomplete documentation, and a morphing architecture. No question, but giving some validation from the development prospective, which is driving the integration issues. Good work!
"Results [referring to the survey results] in general agreement with our experience. The learning curve for developers is VERY steep, however the benefits that can be derived (e.g. from BPM/WF) solutions is VERY high. We can now whip out workflows rather quickly, with huge benefits to the business. Bottom Line (in BPM/WF) - the value derived is well worth the cost/time of learning the toolset."
"A big problem we have with SharePoint (other than a proliferation of isolated departmental installations) is that links to documents in our large document library break if we re-organize parts of the logical tree structure of our library, since references are only available as path names. In previous work at other companies with Xerox DocuShare product, I could use DocuShare's permanent document IDs in our URL-based cross-document links and be free to reorganize our logical organization. [ This person went on to ask: ] Do you know of a solution to this problem with SharePoint? " [Does anyone?]
On September 26, 2008, Dan Keldsen and I hosted the webinar in which we reviewed the findings from our Market IQ report on BPM. (The report will be published in the first half of October, but you can reserve a copy now.)
In my last blog post, I reviewed and made available the slides we used in our presentation. As is customary, I will answer all of the questions posed that we did not have time to answer during the recorded webinar. (Please refer to the recorded webinar for the questions we did answer.)
Before I start, however, I would once again like to thank our underwriters: EMC2, IBM and Risetime. This is not an endorsement of their respective products. It is simply a sincere thank you as it is through the support of sponsors such as this that AIIM can provide its research at no cost to the general public. From the scores of BPM technology providers in the market, there were the ones that were generous enough to step up and support our cause to educate the market. So again, Thank You.
Now to the questions:
Q: Can you talk about software available to perform Process Analysis?
A: Business Process Analysis (BPA) tools specifically address the ability to model and analyze a process, separate and distinct from automating the process. This is a best practice pre-cursor to process automation. Ideally, these tools operate independent from process automation software, but provide an interface to such software, in order to eliminate the need of redefining the process to the automation tool. They range in functionality from simple drawing tools (e.g. Visio) to robust products that include features such as: automated process documentation; multiple GUIs to the model such as flow charts, UML diagrams and swim lanes; document management level control on the process models; process simulation and optimization testing; support for BPMN (Business Process Modeling Notation); support for BPEL (Business Process Execution Language). Providers of BPA functionality include (in no particular order) Oracle, IBM/FileNet, Savvion, EMC2, Ultimus, Mega, Metastorm, Casewise and Sybase.
Q: Can you clarify where the self assessment tool is and what it provides?
A: You can access the self assessment tool at: http://www.questionpro.com/akira/TakeSurvey?id=1035149
This tool, developed by AIIM Market Intelligence is a an easy to take, 14 question survey that provides an immediate assessment of your organization’s readiness and achievements in BPM, and how they compare to that of hundreds of other organizations.
Q: What do you tell an organization that thinks they are a Level 5 BPM organization, when they really are a Level 1 organization?
A: I do not know if I would tell them anything, but I would ask them a few questions. Initially I would ask them if they were familiar with the BPM Maturity Model. Then I would ask them to point to evidence that supports their opinion. If all else fails, I might provide them with case studies that illustrate a level 5 company, and ask them how they think they compare. Then I might ask them what it is they are smoking - JUST KIDDING.
Q: What is the ideal starting point departmentally for Business Process Management.
A: Well, as any consultant will tell you - "It depends." But seriously, it does. OK, maybe there is a good starting point - business process analysis. You should go through this exercise for each of the major (i.e. you need not do this for non-critical, straightforward, simple and working processes), processes in your organization. This should provide you with an objective assessment or insight into the potential ROI associated with each process, as well as the level of re-engineering that will be required (including change management). Weigh these observations along with any preferences the sponsor of teh initiative might have, and a best starting point should emerge.
With that I have answered all of the questions that were unanswered during the webinar.