On a swing through Oregon in March, Joel Oleson and I presented to the Portland SharePoint User’s Group on topics surrounding social computing, metadata and taxonomy within SharePoint, and someone asked a great question: why can’t you just purchase a pre-defined taxonomy?

One of the most important aspects of a successful SharePoint deployment is a well-defined taxonomy and metadata library. Taking the time to define your metadata and content types, build out your taxonomy, and set in place a governance model will ensure that your users will be able to find their content (granted they are assigning the metadata!). But defining, building, and governing your system takes a lot of effort – both at startup and as an ongoing activity. So why can’t someone just purchase a canned taxonomy and vast lists of keywords from a consultant to jumpstart their work?

While I’m sure there are consultants who offer this kind of service, providing guidance and expertise on process and best practices, is that really the right thing to do? (I’m not knocking these consultants by any means, just talking about what is right for your business) They cannot offer more than generic taxonomies based on broad industry knowledge, or around competitive product and service verticals. How useful is this information, really? How much time will you spend trying to match this generic taxonomy to the nuances of your business, instead of outlining your own business taxonomy and expanding on what is unique about you?

I go through these questions as part of my presentation on the topic at user groups and SharePoint Saturdays (most recently at #SPSDC). The hard work must be done by those who know your business – you and your team. Of course, there will be plenty of consultants who will be happy to charge you to embed themselves, offering to learn everything about your business and then build out your system. You might get to deployment more quickly this way if you don’t already have the SharePoint expertise within your organization. But what happens when the consultant leaves post-deployment? Where is the expertise to maintain and update what was built to keep your system relevant?

I came across a great quote in the Harvard Business Review by Dan Ariely in ‘Why Businesses Don’t Experiment’ (April 2010, Page 34):

“Companies (and people) are notoriously bad at making trade-offs. There’s the false sense of security that heeding experts provides. When we pay consultants, we get an answer from them and not a list of experiments to conduct. We tend to value answers over questions because answers allow us to take action, while questions mean that we need to keep thinking.”

The net-net: you need to do the hard work of planning out your taxonomy. Get help, sure, but don’t think you can hand it off to someone else. But if you do decide to farm it out, ping me and I’ll send you my consulting rates

Guest Author: Christian Buckley
http://buckleyplanet.net

Christian is a senior product manager at echoTechnology, where he responsible for content, strategy, and evangelism. Prior to echo, Christian was part of the Microsoft Managed Services (MMS) SharePoint team, now known as BPOS-D (Business Productivity Online Services-Dedicated). He has also led product and deployment teams in the creation of product lifecycle management and supply chain-integration solutions for some of the world’s largest manufacturing and telecom companies, and co-authored 3 books on software configuration management and defect tracking. You can find him at http://buckleyplanet.net or on Twitter at @buckleyplanet

One of the most common questions surrounding metadata and taxonomy management is ‘How do you begin?’ As with most user-driven technologies, SharePoint is often “unleashed” without proper planning or governance structures, and most administrators find themselves needing to retroactively apply standards across their environment. Companies tend to hoard information and may find themselves overwhelmed by the disorganization – and how to even begin the process to get things under control.

Without proper management, search becomes ineffective, content become silos hidden behind team sites (or even within team sites), and user satisfaction plummets.

Unfortunately, there is no “easy” button to fix this problem – and its not a problem unique to SharePoint. Even the most proactive organizations struggle from time to time with managing their system governance. If you’re reading this, you more than likely are looking for help in strengthening this aspect of your current SharePoint system, or are planning for a future deployment. In either case, there are some things you can implement to jumpstart your efforts as you look to put in place a more formal governance model:

1. Create an internal SharePoint user group
   Even if your plan is to release a tightly-controlled portal with strict guidelines around content types, workflow, and usage, you still need to involve the users and get their perspective. The power of SharePoint is its ability to inspire collaboration, even within a meticulously choreographed user experience. You need to tap into the community as a way to refine your model, adapt your systems to the ebb and flow of the business, and, quite simply, to learn from your users.  I’d suggest creating both a task force with accountability for compiling and approving your taxonomy and the governance model itself, and then to send an open-invite to all employees to participate in a broader user group. As part of your process, have the task force present their results to the user group before finalizing their plans. By allowing users to participate in and define the process, the users will have a vested interest in the success of the system.
2. Clearly define roles and responsibilities
   Governance Task Force chair and members. Farm Administrators. Site Administrators. Project Owners. Approvers. Reviewers. Identifying core permissions and groups within SharePoint is one aspect, but modeling your governance model on your internal project methodology makes sense. If you don’t have a defined methodology, once again – keep it simple. Err on the side of ad hoc flexibility over rigid structure, as it is easier to add structure as needed than to remove it. At Microsoft, I was a fan of the OARP model: Owner, Approver, Reviewer, Participant. It was simple and clear (when it was used). At the very least, you should understand and assign similar roles within your organization so that it is evident where accountability resides.
3. Outline your taxonomy, communicate it, and iterate
   Once again, this is the most difficult aspect of governance for most organizations: putting pen to paper and outlining your taxonomy. Funny thing is, many companies already have their high-level taxonomy outlined – on their websites. Product lines, business units, and site maps. It’s a good place to start. Sit down with your governance task force with a fixed amount of time (an hour) and create a high-level draft. Then publish the draft out to the end-user community for feedback. The point here is to create something, get feedback, and iterate. Follow this process several times, keeping the time short so that you have minimal impact on day-to-day business. By taking it in small steps, it also allows you to step back and reflect after each iteration. You’ll be amazed at quickly things will then come together – and, with everyone participating, your taxonomy will more closely reflect the way your users work, and the way your business is actually run. But remember: this is just a start. Your governance task force should perform a regular review (monthly/quarterly) of your taxonomy and metadata, sharing proposed changes with the community and incorporating feedback. In SharePoint 2010, this means regularly reviewing the enterprise Term Stores, the various Managed Terms and Managed Keywords, and promoting keywords as needed, ensuring that your model stays relevant.  

Clearly, there is a lot of work to do within these steps as well as outside, but by taking action now, you will be well-positioned for success – with both the data required to put your SharePoint taxonomy in place, and with the necessary team (and cultural) support to successfully implement your governance model.

My advice: keep it simple, let your processes grow and develop organically, and keep your users – and especially your internal SharePoint community – in the loop on what you’re thinking and doing. These things will go a long way in ensuring your SharePoint deployment is successful (i.e. people are using it!)

Guest Author: Christian Buckley
http://buckleyplanet.net

Christian is a senior product manager at echoTechnology, where he responsible for content, strategy, and evangelism. Prior to echo, Christian was part of the Microsoft Managed Services (MMS) SharePoint team, now known as BPOS-D (Business Productivity Online Services-Dedicated). He has also led product and deployment teams in the creation of product lifecycle management and supply chain-integration solutions for some of the world’s largest manufacturing and telecom companies, and co-authored 3 books on software configuration management and defect tracking. You can find him at http://buckleyplanet.net or on Twitter at @buckleyplanet

Guest Author: Christian Buckley
http://buckleyplanet.net

The concept of blogging is not as new as you may think – only the technology is young. Well, younger than the average teenager, at least. Blogging came into the mainstream conscience by the late 1990’s, but had its beginnings in the early days of the world wide web, back when the internet was the private network of a privileged few.

For a full history of blogging with important names and dates, you can always read up on Wikipedia. My focus here is more on the business applicability of blogs, and their history inside of SharePoint.

Importance of Blogs on Social Communications

Access to information is critical to success in this day and age. Blogs have helped to democratize information, allowing each of us to share our expertise and opinions, and allowing us to tap into the the long tail of information (A couple must-reads are Chris Anderson’s Long Tail – with a link to his original article, and Malcolm Gladwell’s Outliers)

What makes an expert an expert, anyway? While the value of formal research remains at a premium, the opinion of so-called experts has become a commodity. (Why am I, with my MBA and 20 years of industry experience less of an expert than a 20-something research analyst at Forrester?) In a world of 24 hour news cycles, our thirst for more information – specifically, information that meets our social, political, and theological perspectives – has grown astronomically. And with this thirst, blogging has exploded.

The root cause of this explosion is not just about the improvements to the underlying technology – although technology has certainly increased the rate of change – but about cultural changes. The social informatics of the way that we work have been dramatically altered over the last 20 years, and the blogging platform has played a major role in that change.

The Customer Relationship and 2010

Blogs enable dialog between content owner and constituency, quickly and inexpensively, turning one-to-one communication into many-to-many communication, which over time can drive down support costs, reduce product requirements cycles, and improve the overall customer relationship.

From a business perspective, this tight connection with customers allows for constant reflection on what works / what doesn’t. It forces companies to be more vigilant about their brand, allowing them to react quickly to customer complaints or queries. From a capitalist perspective, this also drives healthy competition and innovation, as companies have a direct view into a competitor’s dirty laundry and the known gaps within a product or platform.

Within SharePoint, there was a similar – if not slow – progression in blogging technology. In WSS 2.0 and SPS 2001, the paradigm of blogging had not yet shifted, and site owners who wanted blog-like functionality (it had not yet entered the average user’s lexicon, even if the fundamentals of blogging were in place) were limited to using content web parts and announcements to achieve their desired result of user/site owner content. Much like the static website, they could alter their portal, but this was once again a one-way, broadcast model of communication.

In SharePoint 2007, Microsoft added some basic blogging capability, but the technology fell far short of the innovation happening within commercial offerings, such as Blogger, Wordpress, and Typepad (my platform of choice). Todd Klindt wrote a couple great posts on the shortcomings of SharePoint’s out-of-the-box blogging template back in 2007, found here and here (although he did recognize that with some customization, you can get 2007 just about where you want it).

With the 2010 release, SharePoint has finally caught up with the mainstream, and may even surprise you with some of their great new templates and innovations. Of course, aside from the feature-by-feature comparisons, the true value of blogging within SharePoint is the seamless integration across the entire platform.

After selecting the blog template (which now shares the template browsing capability of the MS Office-based products), you can simply name your new site and destination URL, click Create, and your new blog is live.

Your blog is accessible through your My Site, and your entries show up on your activity feed. With SharePoint 2010, Microsoft has simplified blog management, giving administrators the ability to quickly and easily add, modify, and remove posts, comments, links, photos, and change the look and feel of their blog. Readers have the ability to comment, flag as a favorite (I Like It), and to tag and add notes, all of which appear in the user’s My Site activity stream for others to discover.

Next in this series: SharePoint Wikis

Guest Author: Christian Buckley
http://buckleyplanet.net

Christian is a senior product manager at echoTechnology, where he responsible for content, strategy, and evangelism. Prior to echo, Christian worked with Joel at Microsoft in BPOS-D (Business Productivity Online Services-Dedicated). He also led product management and deployment teams in the creation of product lifecycle management and supply chain-integration solutions for some of the world’s largest manufacturing and telecommunications companies, and co-authored 3 books on software configuration management and defect tracking. You can find him at http://buckleyplanet.net or on Twitter at @buckleyplanet

Guest Authors: Christian Buckley and Joel Oleson

Back in October at the SharePoint Conference in Las Vegas, the two of us had a conversation about what it means for a product or technology to be a “disruptor” and whether SharePoint (and SharePoint 2010, specifically) fit the criteria. According to the universal source of knowledge and wisdom, Wikipedia, a disruptive technology describes an innovation that “improves a product or service in ways that the market does not expect, typically by being lower priced or designed for a different set of consumers.” Does SharePoint meet that bar?

After posting short articles on both of our blogs, spurring discussions online and offline through Facebook and Twitter, feedback seemed to land fairly evenly across both sides of the argument.

Historically Speaking

The enterprise collaboration platform, as we were reminded by SB Chatterjee via a Facebook conversation, can be traced back through products such as ERoom, Groove, and Lotus Notes, and even further back to knowledge management and project and portfolio management solutions which sought to connect teams and content and workflow. Some of the earliest evolutions happened within the hi-tech and manufacturing space with product lifecycle management (PLM) solutions that connected product management teams and their hardware counterparts through very expensive value-added networks (VANs) using cryptic messaging protocols – all in an effort to tie the manufacturing process to a “single version of the truth” around the Bill of Materials (BOM). These solutions were expensive, highly proprietary, and inflexible.

Then came the wave of web-based solutions. Looking back at the development of portals and knowledge management hubs and the evolution into what we now refer to as Enterprise Content Management (ECM), what is clear is that the ECM battle lines were being drawn into the early part of the decade with various factions of portal solutions, collaboration solutions, and ad hoc team and group solutions.  Then SharePoint entered the stage and asked “Why can’t we do all of these things, but do them cheaper and more efficiently?” SharePoint was really the first mainstream attempt to bring together collaboration, portals, document management, enterprise search, records management, and business intelligence into a single platform – and do it at a price point that not only the Fortune 500 could afford.

While the early versions of SharePoint were far from beating the competition in feature-by-feature comparisons, what it did right was to envision where businesses were really spending their money, and recognize that all of those “expert” solutions were also far from perfect.  They saw that the chain had many strong segments, but the links between many of them were weak. Instead of targeting one of Gartner’s Magic Quadrants, Microsoft decided which ones it would allow partners to stretch it to, and began developing a platform. (Essentially, we’ve seen with each version that sharepoint slowly captures the enterprise backend, acronym after acronym:  “SharePoint 2010 is Poised for Broader Enterprise Adoption” by Gartner – October 19, 2010)

While many of the SharePoint core innards can be traced back to FrontPage Server Extensions (_vit_bin), Site Server (audiences), SQL (SQL Dashboards) and MSSearch (now using FAST), the platform was born in 2001 and has become the fastest revenue generating product in MS history. It has accomplished much in its short ~10 year history, to be sure. With the release of MOSS 2007, a common criticism was that SharePoint was late to the enterprise 2.0 game, but in actuality, Microsoft was very much in the game, developing or adopting the components that would become the SharePoint powerhouse.

The Chicken or the Egg

If we’re looking at things objectively, the SharePoint feature set largely mirrors capabilities offered elsewhere in the market, either piecemeal through consumer-based products or services, or through competitive solutions. For example, knowledge management and product lifecycle management platforms have been around for more than 20 years, there are dozens of blogging and wiki platforms, discussion forums have been around since the BBS days, and even the ability to show online presence has been around in portals and through IM platforms for a good part of the past 15 years. But Microsoft has made improvements to many of these features, bringing them together within a single platform. But does that make SharePoint a disruptor?

While SharePoint is not the first to provide most of what it does, arguably, it does many things better – if not through the individual features, then through its unified platform that made tools previously accessible (for the most part) only to the technical crowd and put them in the hands of the average business user. That’s a fairly compelling argument in favor of SharePoint being a disruptor.

There are a number of exiting advances in SharePoint 2010. For example, the Managed Metadata Service, giving administrators and users the ability to better control metadata and keywords, is a big step forward for the platform. Sandbox Solutions allow you to test out customizations and integrations within a controlled space before unleashing on your entire system. Better integration of the offline Groove story in what is now known as SharePoint Workspace. However, do these features meet the criteria of a disruptor if SharePoint provides a solution for a problem they created through their own design and architecture (an argument that you can make for all three of these)?

But does incremental equal disruption?

SharePoint defined enterprise profiles and personal spaces. From Jeff Teper’s History post on SharePoint “The team proposed we give every user their own personalized site and is still very proud they shipped it in 2003 before there was a MySpace or Facebook.”  SPS 2003 My sites shipping in mid 2003 actually preceded even early myspace.com in Aug 2003.  While myspace has been receding as of late, they did much to help define why we need a personal profile and what it means to create a persona, and, more to the point, why it’s important to be connected.  In the corporate space, it isn’t so much about individual creativity as it is about building the right networks. My Sites are quickly becoming the personal hub for the enterprise, and adoption is sure to grow as the core of the social revolution in SharePoint 2010.  Going back further, the site server profiles and audiences which carried over to SPS 2001 even gave us a glimpse of what would come.

The first enterprise shipping wiki solution was Sharepoint.  Sure. We had Wikipedia and various open source solutions out there, but when you start talking about enterprise muscle, SharePoint was the first to provide any real scale.  How many people know that the Wiki inventor actually worked at Microsoft?  From December 2003 until October 2005, Ward Cunningham (wiki inventor) worked for Microsoft Corporation in the "patterns & practices" group.  Essentially, wikis and blogs were both included in SharePoint 2007, which shipped in November 2006.  If you were to look at the dates on the specs, you’d likely find that this functionality was actually spec’d out in 2004. Using blogs and wikis in the enterprise was not on the minds of many people at that time. Understanding this, it’s much easier to see how Microsoft was able to bring these ad hoc tools into a platform add some serious value, especially when you realize that these components have been in the foundation since the inception of SharePoint, in many cases beating competitors to market.

Making a Case for SharePoint as a Disruptor

SharePoint wasn’t the first in each category it has entered. But the most persuasive argument in favor of SharePoint being a disruptor, in our opinion, is as a comprehensive platform – and all that that enables.

As the platform matures, it increasingly provides tools and features for IT Pros to shape and control deployments. But are these game changers, or simply incremental improvements to meet the changing needs of its user based? Must disruptors drive the market, or can they follow and improve on what the category leaders create?

Within SharePoint 2010, there are a number of strengths which may prove to be disruptors in the marketplace:

1. Business Intelligence. BI is a space that SharePoint has been maneuvering inside and around for the past couple years, working with SQL to bring to fruit true Business Intelligence for the Masses.  The business connectivity in Sharepoint 2010 pointing to SQL, Oracle or essentially any ADO.NET data source or web services integration is huge.  Not only full CRUD, but also offline and rich integration with Office 2010.  Pushing SharePoint Performance Point into SharePoint Server, the rapid rise of Excel Services, and the apparent goal of every finance and cottage IT team in every company running SharePoint to build out real-time dashboard, scorecard, and reporting solutions is a clear indication that SharePoint is lowering the barriers for companies large and small to invest time and money in BI. No longer are these solutions viewed as separate deployments, but integrated into the same platforms as your team sites and My Sites. Going forward, companies will increasingly flip the switch and give more and more access to these powerful solutions that provide rich views of information.
2. Composites. Composite apps are where the rubber meets the road. They give teams the ability to bring together various functions and quickly prototype, build, and release business-critical solutions.  For example, pull together a management solution using Digital Asset Management with enterprise metadata, ratings, built in search, and social tagging.  Or use the streaming video right out of SharePoint with SilverLight web parts to create a YouTube for the enterprise.  While there may seem to be some level of catch up with things like tagging and document ID for records, the activity feeds and social application space in SharePoint 2010 have real potential.  For composites, the only requirement is imagination.
3. Development Platform. With 2010, SharePoint is making huge leaps and bounds into the realm of the developer. Having said that, the majority of .NET developers has yet to embrace SharePoint as the de facto standard for deploying applications in the enterprise.  Is it possible for SharePoint to become the standard?  Definitely.  SharePoint has become key infrastructure in the enterprise.  It may just take a bit more time for IT to realize SharePoint as the application platform, moving from the stigma of a file sharing solution stigma to the platform of choice for developers of business applications.  With the built in features around workflow, security, policies, document sets, scalable lists, and true high-availability support, SharePoint has the opportunity to shake up the datacenter. It is moving from a two-web front-end environment used for simple out of the box collaboration solution to something of a substantial hosting platform for applications, portals, ECM, Search, social, and on and on.  The wave has not crested yet!

So is SharePoint a disruptor? Reviewing any single component as a standalone solution – probably not. But SharePoint as an enterprise platform has become the dominant player, whether in the portal, collaboration, or social media segments. SharePoint is a game-changer, a power-house, and an industry-leader, for sure. In that respect, it’s clearly a disruptor.

What do you think?

Guest Author: Christian Buckley
http://buckleyplanet.net

Christian is a senior product manager at echoTechnology, where he responsible for content, strategy, and evangelism. Prior to echo, Christian worked with Joel at Microsoft in BPOS-D (Business Productivity Online Services-Dedicated). He also led product management and deployment teams in the creation of product lifecycle management and supply chain-integration solutions for some of the world’s largest manufacturing and telecommunications companies, and co-authored 3 books on software configuration management and defect tracking. You can find him at http://buckleyplanet.net or on Twitter at @buckleyplanet

Guest Author: Joel Oleson
http://www.sharepointjoel.com

Joel is Sr. Product Architect and SharePoint Evangelist at Quest Software where he is responsible for product strategy across the SharePoint business unit. As an internationally recognized technology expert in SharePoint, Social Computing, and Internet Technologies, Joel’s writings and extensive public speaking experience across six continents leverage his expertise helping customers and partners. Engagements frequently include keynotes and featured speaker requests at major industry events.

Prior to Quest, Joel worked at Microsoft for seven years, including architect of the first global deployment in Microsoft IT and the launch of SharePoint 2007 in the SharePoint Product team. Please visit Joel’s well-read blog, http://www.sharepointjoel.com or on Twitter at @joeloleson