Mark Schneider's SharePoint Taxonomy and Governance Blog

If a Cat Has Kittens in an Oven, Does it Make the Kittens Biscuits?

Folk-saying often have a lot of wisdom for those of us driving the adoption of new technologies.  One of my favorite is "If a cat has kittens in an oven, it doesn't make them biscuts."  The kittens are obviously still kittens no matter where they were born. 

Similarly, if you take someone with 10 to 20 years of experience writing COBOL programs and send them to Java training, they will come back and write COBOL programs in Java.  More to the point with SharePoint, if you build a SharePoint environment and treat it like a network store, then it will become a network store.

Change your thinking, change your business approach, and then you will be successful with a tool like SharePoint.

 

 ©Copyright Mark Ragar Schneider, 2009 All Rights Reserved

A Simple, Hands-On Taxonomy Example You Can Try at Home...

Business travel can be frustrating.  I've had a number of situations where my workshop engagement or training engagement takes me to a city with more than one major airport.  The problem is that the person entering the engagement into my calendar was not aware of this, and so I would sometimes fly into the wrong airport.  This is usually a minor inconvenience, but can be a major hassle and embarrassment if it inconveniences my customer, so I decided to solve the problem using SharePoint 2007.  I pulled together a text list of major airports and their three-letter codes.  I then put this into a list, and used the list as a look up in my travel calendar in SharePoint.  I also sourced other items from pre-populated lists.  This makes it easier to enter the data, less likely to overlook something if it is required by SharePoint, and far less likely to have multiple variants on an airport identification.

This is about the simplest example of a useful taxonomy I can think of for you to play with in SharePoint.  You can purchase extensive lists of pre-populated and interrelated lists like this for use in SharePoint.  These lists can do everything from speed up the entry of medical codes to help your end users navigate complex standards and industry codes.  The key thing to remember is that these can be deployed more or less everywhere so that they are available to folders and lists no matter where they are found.  The inheritance, webpart and content type capabilities within SharePoint make it possible to "teach" all of SharePoint to provide structured taxonomy data to all end users everywhere.

The POLICY taxonomy that I cover in my workshop helps you to establish standard policies and profiles to govern information that has been classified according to one of these NOUN taxonomies.

So...

Good News / Bad News

Good News:  Corporate America seems to finally be getting comfortable with email management

Bad News:  Email is pretty much obsolete as a collaboration tool, and with the upswing in instant messaging and cell-based text messaging, it is kind of obsolete in general.

 

 ©Copyright Mark Ragar Schneider, 2009 All Rights Reserved

More Evidence That the World is Shifting -- Cell Phone Use

Did you know that, according to a study by Nielsen the average teenager sends and receives 1,742 text messages a month (combined)?  Similar studies also reinforce the idea that cell phones are primarily used for text messaging and not for telephone calls.  Again, the average teenager sends/receives 1,742 text messages a month!

In the minds of most teenagers, email and voicemail are hopelessly obsolete.  So be watching for unified technologies that can take voicemails, emails, text messages and similar genres of electronic communication and convert them to a common data stream.  Text messages, instant messages, emails and voicemails will all have to be tracked, managed, archived, searched and lifecycled just like any other permanent record.

 

 ©Copyright Mark Ragar Schneider, 2009 All Rights Reserved

More Project Wisdom from Madagascar 2

You really need to see this movie.  Here is a quote (more or less) that sums up the whole science and psychology behind project initiation in most organizations and corporations...

King Julian:  "Quickly, let's get moving before we all come to our senses!"

King Julian also nicely sums up architecture and design reviews.  After trying to solve the water crisis brought on by Nana the insane grandmother and her roving band of New York tourists, (you had to be there) by sacrificing a lovelorn giraff into a local volcano, King Julian laments his overall failure by saying "the science seemed so solid."  How many of us techies can't relate to that one?

 

 ©Copyright Mark Ragar Schneider, 2009 All Rights Reserved

Yes, I'm Actually Going to Show You How to Implement Taxonomies

This blog has been up and running since July of 2008, and during that time I've worked to raise awareness of the taxonomy issue.  Although I still intend to discuss some of the concepts and theories behind the use and usefullness of taxonomies, it is time to move the blog in a new direction.  So, I'm still going to tell the odd joke and write the odd anecdote, but the focus of the blog is now going to turn toward practical implementation.

I'm going to begin exploring practical taxonomy application.  My efforts will include, but not be limited to:

1. Evaluating taxonomy tools provided by various vendors in the world right now.  What do these tools actually do?  Are they useful?  What is the scope of their taxonomy service and application?
2. Evaluating vendors of "canned" taxonomy lists and files.
3. Providing insight into the benchmarks and standards that guide taxonomy providers.
4. Listing potenitial taxonomy consulting and contracting firms (in case you need to hire a small army of librarians to come in and help you develop a unique taxonomy)
5. Discussion of methods for integrating taxonomy management into your governance planning.
6. Tips on building taxonomy and governance management into your project planning processes.
7. Project initiation methods for taxonomy-dependent projects.

I've also received a great deal of encouragement lately to write and publish a simple and straightforward cookbook for planning, building and implementing taxonomy-related technologies and projects.  In other words, a book with sample taxonomies for different types of organizations, organizational change methods, project management methods, sample governance plans and strategies and so on.

I will do the book by hook or by crook.  Please note that the taxonomy and governance planning I'm talking about is frankly not the same governance and taxonomy planning everyone else is talking about.  Historically governance planning in IT has meant configuration information, deployment, recovery, lifecycle planning and a host of other topics knit together into a coherent plan.  The governance planning I'm talking about has more to do with organizational and business strategy.  I pose the question, "if you really could bake your business policies and strategies into the DNA of every single superfolder (library) in your computing environment, what would you want those policies and strategies (behaviors) to look like?"

In other words, how do you turn SharePoint from a pseudo 'network drive' into an efficient strategic resource for your corporation?  This is the question my blog seeks to solve.

 

 ©Copyright Mark Ragar Schneider, 2009 All Rights Reserved

Why are Taxonomies Such a Big Deal Right Now?

As I've shown in my blog, the concept of taxonomies is not new.  Biology classifies life forms into a taxonomy, libraries organize books by taxonomy, addresses are taxonomies, as are diagnostic criteria.  So why is it suddenly such a big deal, especially in the SharePoint space?

If you've been reading my blog for a while, you know that I consider SharePoint to be an architectural layer and not an application.  It is a virtual program environment that is replacing Windows over the long-term.  When things can be organized according to physical location, then their location becomes the organizing principle for their use, naming conventions and structure.  When we take away physical constraints then we have to create logical organizing principles to keep our various designs and solutions integrated.  In the computer world the people who work with logical organizing principles are called "Architects."  It is their job to make sure all the stuff in the computing environment integrates and works in concert.

Well, one of the major things SharePoint brings us is a virtual "super folder" rather than the old non-virtualized dumb folders we have come to know and love.  The older folders were physically defined and organized, but the new folders are logical--they are not tied to physical structures, locations or organizing principles.  So the logical organizing principles we use to manage them fall along taxonomy lines.  Logical folders relate to each other through relationships, inheritance and logical connections.

To make a long story short, SharePoint bakes things like the ability to work with taxonomies into the "DNA" of every single folder in the environment.  So, if you deploy a taxonomy database of every mailing address in North America into SharePoint, then (and here is the amazing part) every single super folder (i.e. Library) knows the mailing address taxonomy.  the same is true for other taxonomies as well.  Medical terminology and diagnostic criteria can conceivably be deployed so they are inherited throughout the environment as well.

The tricky bit comes in making use of inheritance and taxonomy structures to deploy business policies that govern how different kinds of information 'behaves.'  That is where the "Verb Taxonomy" otherwise known as the "Policy Taxonomy" comes into play.  You also want to have the various SharePoint Sites, Lists and Folders inherit security information, approvals, audiences, workflows and the like through the same mechanism.

The combination of inherited taxonomies of nouns and verbs is very powerful when guiding your employees and customers during their use of SharePoint.  It isn't necessary to lock SharePoint down, SharePoint can provide strategic guidance while the knowledge worker is free to operate with tactical freedom.  This is because the nouns and verbs can be deployed to become part of the "DNA" of all the relevant SharePoint Sites, Libraries and Lists.

 

 ©Copyright Mark Ragar Schneider, 2009 All Rights Reserved

The Definition of Bad Weather...

When I was speaking in San Diego, the conference director at the Hilton Torrey Pines expressed concern that they were about to have bad weather.  Just to make sure we are all on the same page, I thought I would help establish some benchmarks for the phrase "bad weather."  Since this conversation occurred in February and I'm from Minnesota, I usually judge bad weather by a single question.

Bad weather qualifying question:  "If I were to go outside in shorts and sit on the ground, would I be dead in 30 minutes?"

• Northern Minnesota in February - Yes, you would be dead.

• Florida during a hurricane - Yes, you would be dead.

• Texas during a big tornado - Yes, you would be dead.

• An ocean island during a tsunami - Yes, you would be dead.

• San Diego when the temperature plummets to 57 degrees Fahrenheit - No, you would not be dead.

• San Diego when there are a couple of clouds in an otherwise pristine sky - No, you would not be dead.

So, I'm sorry... the phrase "Bad weather" can't be used in conjunction with the phrase "San Diego."  Granted they have fires, but that is not technically a weather phenomena.

 

 ©Copyright Mark Ragar Schneider, 2009 All Rights Reserved

So, On a Very Practical Level, What is a Taxonomy?

A taxonomy is a way of classifying things or concepts by similarities in structure, use, concepts, relationships or intent.  It is a very broad concept that has a lot of uses, and the breadth of this concept is where most of your confusion comes from.  It is a little bit like asking "what is a dozen?"  The definition of a dozen is pretty straightforward, but if you go to a candy store and tell the clerk "I'll take a dozen," the clerk is likely to ask "a dozen what?"

So, if someone says they don't believe in the usefulness of taxonomies it is a little like saying they don't believe in the usefulness of a dozen.  Taxonomies are a part of life whether we recognize them or not.  The human mind organizes things into manageable sets and then works with the relationships between the things in the set. 

So all well and good, but what kind of taxonomies are we talking about?  Physical mailing addresses are a great example of a common taxonomy.  In the US we take it for granted that each place is mapped to a single address.  On the other hand there are a great many ways to write those various addresses.  is it "1st Ave N" or "1st Avenue N" or "First Ave North?"  Companies that work a lot with mailing addresses can go out and purchase a set of files with all the mailing addresses for North America entered into a huge list.  Then, rather than type in the address the user can pick a street, house number, state, zip and so on.  Most GPS systems work with prepopulated address taxonomies like this because it takes fewer system resources to spell it all out than it does to write code that can interpret imprecise addresses.

If you use a tool like mapquest the computer interprets your feeble and fuzzy human attempt to type in an address (at least mine are feeble and fuzzy, I don't know about yours) and then it comes back with a list of addresses you may have actually been attempting to enter.  This is a process where Mapquest runs a fuzzy search against an established list of addresses.

Strictly speaking the list of addresses is not really the taxonomy as such.  the taxonomy is the set of definitions, rules and principles that make addresses meaningful.  The list of addresses is a set of standard terms that follow the taxonomy and can be used to generate standard information in compliance with the taxonomy.

Telephone numbers used to form something of a taxonomy.  Area codes told you the large geographic area where the phone resided.  The prefix provided greater resolution for the location of the phone, and so on.  Now that the phone system is based on digital switching technologies, and you have the right to retain your phone number, and long distance calling is often bundled at a set fee, your telephone number is just a number.  It really has no embedded information, logic or relationship represented within it. 

In the United States the Social Security Number is intentionally devoid of embedded information.  one way to approach it would have been to have the various numbers mean something about the individual.  That was considered an invasion of privacy, and also a great big hassle to administrate, so the Social Security Number is intentionally devoid of encoded information.  Two of my sons happen to have sequential SSNs but that is mere coincidence.  Sequential numbers are not an indicator of relationship; we just happened to apply for their numbers at the same time and on a slow day.

So, should you invest in an address file that will deploy into SharePoint and make it so all your knowledge workers use exactly the same address?  Yes!  I can't think of a reason why this is a bad idea.  It actually makes it faster for people to enter information, and it can make it harder to fudge metadata (which is where that information will wind up).  So, when we talk about noun taxonomies we are talking about this kind of list.  If your business leads you to interact with the medical profession, it is a great idea to buy a taxonomy of medical terms and install it in SharePoint.  This means that you can use those terms, insurance codes, diagnostic criteria and so on throughout your entire organization with every site and library.  This is a good thing.

It is even better to cap this off by structuring your content types, site collections, and templates so that the right prepopulated noun taxonomies come along with it.  The focus of my workshop is to initiate your SharePoint project with taxonomies and governance scoped into the project, and to establish the rules that will govern that information.

So, in a tool like SharePoint, it is possible to make it so that confidential financial information can only be communicated to certain locations, roles, systems, etc. without executive approval.  The "Verb Taxonomy" that I'm pushing is a taxonomy (structured set of policies organized by relationships and principles) of policies that can use the noun taxonomies as input and automatically provide workflows and approvals.  It is important to provide a taxonomy of business policies that can be used to influence and govern the use of information across the enterprise.  This goes for SharePoint and any other tool in your organization.

The noun taxonomy can be used to classifly a document as being a "financial" document.  Once it is classified, how do you want it to behave?  What are the rules for working with that document?  What is an appropriate audience.  You don't want to leave these decisions to each individual's interpretation, but you also don't want to rigidly lock the system down in order to control the use of the document.  So, we are looking for a relatively simple way to establish policies governing the use of different classes of information, and to have those policies logically "follow" the document wherever it goes.  SharePoint provides is with a powerful and simple method of inheritance, and if we inherit based on content types then those inherited workflows, policies, templates and approvals will logically follow the document.

So, you need both a noun taxonomy and a verb taxonomy.

A great place to shop for prepopulated taxonomy lists is www.taxonomywarehouse.com.

 

 ©Copyright Mark Ragar Schneider, 2009 All Rights Reserved

Comments on a Comment I Received...

One of my regular readers wrote to me last night and expressed frustration.  He is concerned that the concept of taxonomies is vital to the health of a SharePoint deployment, but that no one seems to understand or care.  He also expressed concern that my approach to taxonomies isn't going to work.  This particularly caught my eye because I don't really have my own approach to taxonomy use.  I have my own approach to stakeholder management, and my own approach to incorporating taxonomy management into project planning and IT governance. My goal is to take away the blank stares before the project starts.  If you think it is tough having a successful IT project, try it when your stakeholders don't at all understand one of the most important success factors.  So, I am working to educate folks on the nature, use, importance and interaction of taxonomies in tools like SharePoint.  We establish the framework and then I recommend that they pursue taxonomy specialists in helping them design and populate their environment. 

It is also true that the unbridled use of taxonomy structures will kill the agility and tactical freedom that SharePoint offers the knowledge worker.  So, how do you provide strategic structure while safeguarding tactical freedom?  You need a taxonomy of policies to structure things like approvals and workflows while allowing agility within a limited scope. 

I deleted the posting because he fudged all the metadata that one enters in order to comment on a blog.  I don't do anonymous, and if someone really understands and believes in metadata then they would not be likely to fudge it when making a comment about it.  However, I think his comments are valid and so I will address them here.

1. I agree that taxonomies are vital, but I also believe that they can be over done.  To what do you apply a taxonomy?  To what do you avoid using a taxonomy?  You need a foundation of policies to serve as a tool for managing and understanding your taxonomies.  That is what I'm trying to drive home.  I really don't have a taxonomy approach, so I'm not sure what there is to disagree with at this point.  My message is -- keep your taxonomies simple and control them with a taxonomy of policies (verbs).
2. That I don't have my own competing approach to taxonomies is evidenced by the fact that I am currently reviewing taxonomy tools and packaged taxonomies.  Why?  I want to put together a list of recommended taxonomy suppliers.  So I am trying to help people approach taxonomy standards in a straightforward way.  I intend to provide a list of nuts-n-bolts providers who can help you with everything from taxonomy development and validation to software tools.
3. In his message he comments that no one in his organization understands taxonomies.  When he mentions them he gets the proverbial blank stare.  This is the biggest thing I'm trying to fix.  This blog is dedicated to getting the message across.  My workshop is all about getting people to understand the role of taxonomies, putting together a plan and executing it.
4. My role is, in essence, project initiation (see some of my project posts).  The key thing is that the project charter has to include both a governance and taxonomy plan so that the project can succeed.
5. Taxonomies are Not Necessary for Finding Things!  They are Necessary for Automatically Governing Things.  Companies like Google advocate getting rid of taxonomies as a whole.  Their appliances can do a decent job finding information without an explicit taxonomy.  They use, I believe, Markov Chains in order to do so (one of the topics of my blog posts is a non-technical discussion of a problem I'm trying to solve using Markov chains).  Other companies are developing fuzzy-set searching and other tools to eliminate the need for taxonomies.  So why do I think taxonomies are vital?  Because finding information is one thing, knowing what to do with it is another.  In a corporate context, when someone searches for a document, do you want them to find it?  Should it be security trimmed?  What is its life cycle?  The system must address the issues of use, protection, lifecycle, audiencing and voice using policies.  Where do these policies come from?  A standard "noun" taxonomy can't possibly tell the system what rules to apply to the use of the document.  A search appliance without an explicit taxonomy also can't govern the documents.  How does one create meaningful policies to execute governance decisions, and then systematically apply those policies?  That is the question this blog seeks to answer.  The 'verb taxonomy' that I'm advocating is a structured method to cross reference and apply governance polices to elements within SharePoint.  How are the policies invoked?  By categorizing the items through a standard noun taxonomy.

So, I'm addressing his email in my postings because I think he brings up some valid points.  Ironically however, I think we are in "violent agreement."  The biggest problem that my workshop addresses is the "violent agreement" that arises from miscommunication (due to not having the same terminology and concept formation) between stakeholders.  At the end of the workshop, not only have we written a project charter but we have also established a common framework of concepts for governance, policies, other noun taxonomies, and so on.

So I heartily respect "Nathan's" comments, but I really think he misses the point.  He actually highlights the need for consensus before starting an implementation project!

The major stumbling block in taxonomy use is that taxonomies become enormously bureaucratic if they are not bounded by policies.  This is the issue I'm dealing with in this blog.  Taxonomies are actually pretty simple critters.  Remember that the hardware and software isn't what will kill your project, it is the peopleware that will drive you to defeat.

Explicit taxonomies are not necessary for finding things.  They are, however, necessary for governing things.  This is the point of my blog.

So, good comment but I suspect you may have misunderstood what it is I'm trying to accomplish.

 

 ©Copyright Mark Ragar Schneider, 2009 All Rights Reserved