Share-Biblio-Point
I think it helps to start-off with a basic frame to understand the design of SharePoint. Think of SharePoint like a virtual library, where librarians decide what you get to search, read, checkout, and use.
SharePoint, at its heart, is a list-oriented database. Like books in a card catalog, SharePoint compartmentalizes functions and data in “lists.” The document library is a list, the picture library is list, the discussion board is a list, etc. The data hosted in each of these functions is then placed into this list superstructure; like books on a shelf. Each of those lists can then have features like access controls, audience customization, data visibility controls, and data feeds imposed over top of the hosting environment.
Screenshot of a typical SharePoint site
For SharePoint, files and documents are king. Any collaborative effort and knowledge creation occurs within the documents and presentations themselves. Some consultants parse this as the difference between document management and records management. This perspective illustrates that we are really talking about file-oriented objects and work products which revolve around the quality of the content resident in the file.
Using Its Powers for Good
SharePoint is well-suited for a few defined business processes. It is ideal for hosting Microsoft Office documents (doc, ppt, xls, etc. – don’t forget to add the “x” at the end of your files if you have Office ‘07). SharePoint tightly integrates with these file extensions and enables features like sequential edits, workflows, and refined document management (check-in/out function). These features make a traditional shared drive model look outmoded.
The platform also integrates with other Microsoft tools like Windows (Instant) Messenger and can supply presence awareness for those who are also logged-on to the network.
Simple web design and customization makes even the most junior SharePoint developer look like a wizard. For those who invest a fair amount of time to understand how the webpart system works, you can quickly deploy a blog, discussion board, or a survey. Your boss and coworkers will start referring to you as “Gandalf” when you can establish a team site within 15 minutes as opposed to 15 weeks.
Then There’s that Evil Thing . . .
An often overlooked issue with SharePoint is the hidden cost of an implementation. That hidden cost manifests itself in many ways. Let’s talk about the Microsoft marketing strategy . . .
Investing Small, Losing Big
If an organization/company purchases enterprise licenses for Microsoft Office, they will throw in the SharePoint software in for “free.” Along with that they may offer some light consulting services to assist with the implementation. As a CIO, you’re thinking, “Free collaboration software? Score! Maybe this will shut those ‘web-savvy’ customers up.” Unfortunately, by the time you complete the implementation and training, you learn too late that the platform doesn’t bend as easily as you may think. Some of the functions that you may want to suit your business needs will likely require the purchase of additional web parts. Its at this point where the Internet becomes your enemy. The number of vendors offering enhancements to SharePoint seems never ending. Users will come pounding on the CIO’s door to make SharePoint do things that it was never intended to do. If you do choose to install some of these apps, you have new licensing and upkeep costs for a wide variety of vendors.
Content Management and Critical Mass
Most collaborative environments thrive on the achievement of critical mass. In SharePoint, the opposite is true. The platform performs best when the collaborative ethos is well established, tight, and contained to a group of about 10 – 30. Why is that? The search features of SharePoint are not as robust as you may think. As evidenced by the rise of third party vendors around search, SharePoint’s search and discovery capabilities are seriously lacking. Files, upon which the environment is predicated, are not easily found. So the more people you have contributing content to the environment, the more difficult it is to find said content.
Making It Too Easy
While one of the greatest strengths of the environment is its ability to quickly deploy web parts to users, it is also its greatest hindrance. With just some light self-driven training, a user who is granted “Design” or “Owner” privileges can deploy any capability they desire. This is often a path to disaster because said “owners” deploy everything out-of-the-box regardless of the business need. This blog said it best:
First let me say that I think SharePoint is a fantastic idea . . . Have you ever heard the “KISS” theory? Keep it simple stupid. Well unfortunately nobody on the Microsoft SharePoint Portal Server team seems to have heard about it. First off, let me say that SharePoint Portal Server is an awesome tool, in theory! However, it seems to have been designed by people that thought they were rocket scientists, and expected some massive adoption . . . Another basic rule in Microsoft has again royally broken, is the “Less is more” rule. Especially when you are dealing with non power users.
The end result is that users who you would like to attract to your site are immediately confused by all the functionality and walk away. It’s always easier to default to your existing business processes than try something new.
One of the things that is rather elegant about a WordPress or MediaWiki installation is that it requires users and developers to think about why and how each environment functions. That thought process surfaces important discussions between developers and users about the business rules that govern the placement, disposition, and processing of data.
It’s Still About Collaboration
Above all else, in my humble opinion (and other’s), SharePoint is not a collaborative environment. The value and Achilles’ heel of the platform is its security model. It is far too easy to restrict data from the prying eyes of others. If you are operating in an organization where data sharing (let alone collaboration) is not the norm, SharePoint does not improve this condition. If there is one thing I have learned in collaboration consulting, if you offer the average user two options of restricting or sharing their information, they will choose the most restrictive option.
The document-centric/list orientation of the environment also makes it difficult to process, analyze, or manipulate data. This document-centered view of information grounds an organization in a print and publication model that is quickly becoming irrelevant.
In summary, SharePoint installations result is pouring digital concrete down organizational silos. I understand Ian Morrish’s perspective that SharePoint does not create silos because there are ways to add authenticated users. With the greatest respect to Ian’s work, this is precisely the problem. Security, once again, is the determining factor for the sharing of information in SharePoint. As long as the information management model prefers access controls, then your chances for bumping into unknown sources of data and knowledge are greatly reduced. This is a highly important feature of truly collaborative environments.
RE: Security
Brian, I agree, SharePoint is one of my favorite picking points as well. I know of a couple organizations that have no less than 20 different SharePoint instances across their organization. Much of this is because they have trouble securing the data and instead of building in the right security hooks they just build a new server and independently manage the users.
One of the solutions we’ve built assumes that the documents should inherently be open and searchable. However, which documents are being access and the usage patterns of the users are monitored. This way the information is open, but the outliers who are doing things they should not are quickly identified.
It’s the best of both worlds, broken down silos while still maintaining the security and accountability that the customers demand. What impressed me was that it was written in such a way that it could do the analysis across all of the internal SharePoint instances and wasn’t tied to one instance at a time.
It would be a happy day if everyone moved over to more open tools. We’re getting there but I have a feeling we’ll be dealing with the SharePoint problems for many more years.
Brian – I find this to be a very thoughtful article. I read through it twice and still want to do so again just to make sure I have caught all the strands of thought which you have woven together. I take the invocation of my name seriously!
My initial reactions are:
1) The Share-Biblio-Portal characterization and discussion is dead-on, and could/should be reprinted in Microsoft’s own initial customer documentation (you probably hate hearing me say that). But what you initially capture as its essence is also turned against it, as a supposed limiting feature – for a world that has not yet come to be, the world of holistically dynamic data, self-organizing without any “document” constraints. I have had sympathies with that vision for a long time, but also recognize the reality of existing business practices which can be evolved but not broken. Think about the life-span of a system in an enterprise deployment: it could survive for the next, what, 4 to 5 years? Is it likely that “the spreadseet” or “the report” (or even god help us “the slide-based presentation”) will be dead and gone from information-workers’ practices in that time horizon? I doubt it. Google doubts it -hence their focus on Google Docs. And given the folks I know on the business (analytic) side of IC houses, say, it would be more helpful to them to assist in their evolutionary processes than to break asunder what they have. So I believe the Biblio label is apt anda good thing, and liable to be with us for a little while longer.
2) On the search question, I agree – and so does Microsoft corporately, as evidenced by the decision to do two things in 2006-2007: first, dramatically improving the OS DesktopSearch in Vista (sucked balls in XP, but in Vista kicks ass), and second purchasing FAST to provide a truly enterprise-class search capability that could ride over SharePoint and reach across both documents and other streaming (“non-document”) data stores. Acquiring FAST at a cost of billions was an acknowledgment that you’re right, it sucked to have to go straigtaway to some third party to get good search after deploying SharePoint. (Side note: in 2002, 2003 I used to talk with Leon Bloom of the old IMO about getting better search engines for Intelink, and we agreed Google would help… but by 2004, 2005 when I was at DIA Google was demonstrating their lack of interest in enterprise “non-document” search beyond their Appliance – so guess ho wetalked to: FAST! Unfortunately we could not get around that pesky foreign-ownership issue at the time, so you never saw an ICES or ICDL FAST search engine…)
3) Your main point, the source of “evil,” is the one I will really quibble with – because it confuses me. Unless I’m mistaken, you are complaining that SharePoint offers too much platform functionality and developmental openness, so much so that even end-users wind up being able to innovate and add capabilities to their own liking. Call me crazy, but that’s a strength – even if it requires that IT staffs learn to adopt a very Zen attitude, that change is okay and adds stability to the environment. Stability comes from the shared platform, not from cookie-cutter “apps” and pages. I think the first commenter got that right. It really doesn’t wind up being “cement” poured down stovepipes, but a realization that given the atomization of modern business units, they can be unique and yet be sharing at the same time.
Anyway, those are my 2am immediate reactions on a very thoughtful – and thought-provoking – post. Thanks for the time and analysis you put into it, and I owe you one.
I couldn’t quite put my finger on what is wrong with the developmental flexibility until recently. I saw a SharePoint installation that deployed *everything*. I mean *everything*. It was immediately apparent to me that very little thought was committed to why those features and functions are there. Then the program manager was confused about why no one used their uber-cool multi-functional site. I think Miguel (http://www.realsoftwaredevelopment.com/author/miguelcarrasco/) hit the nail on the head. It’s too complicated and tries to pack everything into one environment. Keep-It-Simple-Silly. People gravitate to platforms where the purpose is direct and the services it holds perform well. SharePoint tries to do a lot well and can’t because its too much. So that flexibility that would seem valuable is actually a hindrance. It’s like car with multiple steering wheels and stick-shifts. You can use any of them, but it just serves to confuse the driver.
This is a separate point from the pouring digital concrete issue. No one pays for the extra functionality from 3rd party vendors. So as Matt points out, you can make SharePoint do your bidding with a significant investment in customization and/or third party apps. Programatically speaking, installing SharePoint means you have just signed up to a customer obligation without knowing the out-year costs to make it fit the business model. Some of the blogs (this one in particular: http://pro-thoughts.blogspot.com/2008/01/why-i-hate-ms-sharepoint.html) better articulate why SharePoint becomes quicksand.
“Damn you, Swiss Army Knife, for your profusion of blades and utility! How am I ever supposed to find th – oh, there’s the corkscrew. Cool.”
In the example you cite, (a) sounds trivial to “fix” and (b) who’s really to blame for over-exposing features to end-users in an organization’s deployment? I don’t use footnotes in Word on any regular basis, but there the command sits, up on the ribbon – so what? “Curse you, Ribbon!”
@lewis:
Try cutting your hair with the scissors of a swiss army knife. Clean and prep a fish with the knife (dare you to try!) or open 10 bottles of wine without breaking that teenie-little corkscrew.
Heck, carry it around for a week in your pocket without losing the little plastic tooth-pick. Go ahead, then get back to me about how good the “swiss army knife strategy” is.
To be clear, I’ve got absolute nothing against the Swiss-army-knife brand of products. They have their purpose, but it is NOT to replace a toolbox full of real tools. (note: enterprises deserve real tools)
Every technology has an implementation cost; if it looks “free” that just means the cost is hidden (not necessarily intentionally hidden, but hidden none the less).
Decision makers focused only on checklists need to stop looking for quick fixes and “freebies” and start paying attention to the implementation details. Once they’re doing that, they’ll see for themselves what’s “good” and what’s “bad”.
My pre-requisites for a collaboration tool:
-> open source, with contributors from various companies around the globe.
-> battle-tested – there’s no need for adopters to be guinea-pigs.
-> should be possible for a do-it-yourself type to learn and use for free.
-> the developers must “eat their own dogfood” – use the tool for their own collaboration.
-> should be able to run equally well on MS and Linux platforms
Thanks, Brian (and Lewis) for a fun read.
Regards,
-Paul Reiber, Reiber Labs
This post was Tweeted by @jfranks03
Your example is perfect: A Swiss Army knife has utility, but it does not do a single thing well. It does lots of things with limited utility.
[...] The Promise and Pitfalls of SharePoint « The Green Dotted Line (tags: sharepoint) [...]
Interesting post!
Re: Less is more
That is definitely a key issue not only with MOSS but any collaboration technology. It is not without coincidence that simple collaboration tools such as twitter experience a huge adoption while basically providing just one feature.
While twitter’s merits are debatable, its model of simplicity can definitely serve as an example of a user-oriented design paradigm.
The above should be reduced to dollars and sense. In their spare time, one technologist can administer a Wiki (e.g. MediaWiki or TWiki) for 1000+ users. Because of this simplicity, adopters can get 1000-fold ROI. Due to complexity and update frequency, s SharePoint administrator has a full time job keeping up with 25 users. The ROI could well be negative! Now add in in the cost for user and admin. learning curves. If one’s goal is building a big, expensive IT department, then SharePoint is nearly ideal.
These numbers are from real, painful, experience detailed at the listed URL.
I fully agree with most all of Brian’s comments, but would like to offer some additional thoughts.
I believe Brian sees the fact that Sharepoint users can create whatever group memberships they feel is necessary for security as one of most the significant issues impeding enterprise collaboration. Though this is certainly an important consideration, I’m not sure I see this Sharepoint feature as the core challenge to organizations who have chosen to deploy wiki software.
TWiki also supports the ability to restrict access to content as needed. The flexibility to control access to information at some level is required within all enterprise organizations. Many of our customers insist on LDAP or AD integration in their deployments. What we observe in these cases, is that although the IT departments are proficient in managing user access to systems and sometimes even managing group membership at the department level, they can’t begin to manage ‘knowledge groups” at all. They are simply too dynamic. So that control has to come from somewhere outside of IT. In TWiki’s case, TWiki access controls can overlay LDAP, and also restrict read-write access to information w/o LDAP.
A much bigger collaboration issue confronting many organizations today is related not so much to the question of: ‘Does one tool make it too easy to lock down information?’,but more of: ‘How best to address the informational bias of many individuals and over arching corporate culture that keeps companies from realizing the true potential of a knowledge sharing organization?”. Many organizations we’ve seen have created greater barriers to collaboration because historically no one wiki was a good fit for all user types and the decision to buy or download free open source was typically made too low in the organization. Many of these departmental wiki silos have been created simply because early wikis didn’t have the nice WYSIWYG editors they do today and required the use a of a markup language that was different depending upon the wiki selected. Today there are converters that can be used to consolidate these silos. Relative the the cultural issues doing the consolidation work is a straight forward technical matter.
The fact that Lewis Shepherd, the Chief Technology Officer of Microsoft’s Institute for Advanced Technology in Governments took the time to comment on Brian’s points is noteworthy. That MSFT had to spend a $1.2B to acquire FAST’s search technology indicates how critical search is to delivering efficient enterprise collaboration solutions.
The latest version of Certified TWiki includes the Plucene search engine to quickly within Office based attachments. Because it’s indexed search, its very, very fast. It was natural to include Plucene in Certified TWiki because its open source. (THANK YOU! to the Plucene open source development team).
One observation we have of organizations with a deep understanding of wiki based collaboration and its impact on organizational knowledge, is that the amount of content residing in MS Office documents decreases dramatically- by more than 70%… So then the question really is; If Sharepoint’s main value is searching and storing office based information in a way that’s somewhat better than placing documents in NT file system and finding them with desktop search, how valuable is it when most content is created directly within the Wiki?
Some organizations in the midst of making the transition to true wiki based collaboration models have deployed interesting hybrids; They use Sharepoint, for the filestore but prefer TWiki for the wiki/web 2.0 collaboration engine front end. And in at least one case, because they had already deployed the Google search appliance within the enterprise, chose to integrate their existing search engine appliance with TWiki as the Mashup point.
David Pointzer Sr. Process Engineering Manager, R&D of Mars Inc. states it well. (They also have Sharepoint) “It is my experience that a true competitive advantage comes from not just getting the wiki tool that everyone can get and use. No advantage there, just keeping up. An advantage can be built by taking a look at how these tools can be customized and supercharged to facilitate your particular ways of working, culture, business, etc. This is where the TWiki solution is strongest.”
If you want to discover how many wikis silos you have within your organization, consider giving our WikiCrawler a spin. You might find the results surprising.
Cheers,
Will
All trademarks and copyrights contained in this Blog post are owned by their respective trademark and copyright holders.
http://twiki.net/blog_2009-05-08.html
I have been developing for SharePoint for quite some time , and Have been using it since Early 2000 during eval.
I understand your frustration , regarding the contradiction between the promised and delivered (Sales and Marketing Departments tend to do that).
One point I would like to share with you , SharePoint is not a full product it is a very sophisticated collaboration framework , that requires customization in almost 90% of the time.
Early and long design and analysis phase is required to make any SharePoint a success. Like any other framework .
If you you have any similar products or frameworks you can compare with SharePoint I am interested to know about (please include the cost as well , and in case of open source please include annual support for commercial and government contracts )
I totally agree that the licensing model for SharePoint(MOSS) for Internet applications is very expensive , and many companies don’t want that type of commitment.
Again , if you want to realy think about design and implement of a sharepoint Solution , think of Objects and Ontology. that will give you a better understanding .
Thanks for Sharing the Point
Where TWiki is positioned above against ‘commercial’ Sharepoint, this is not describing reality well. Both TWiki and Sharepoint are commercially driven products, both companies live from selling support contracts.
Sharepoint has an expensive licensing model, and TWiki is no longer free software, since TWiki,Inc. has pushed out virtually all developers from the TWiki Open Source community.
If you are looking for a powerful enterprise wiki that is driven by a large community of developers and consultants, I invite you to http://foswiki.org, where TWiki-now-Foswiki development continues.