SharePoint Governance Is Data Governance

From Platform to Principles

Each platform and vertical industry “hires its own.” SAP teams want SAP people. Healthcare teams want healthcare experts. Salesforce teams look for SalesForce developers. Banks look for financial services people. It’s the way of the workplace.

SharePoint is no exception. Being a “SharePoint person” conveys membership in a deep-dive community of technical expertise that speaks its own language, from farms and site collections to Designer workflows and PowerShell scripts.

Being a “data governance person” is new. The discipline hasn’t been around very long, and most “data governance experts” emerged from whatever platform needed governing at the time. And the older a SharePoint deployment is, the more likely its “SharePoint governance” is to be focused on document and content management, for the simple reason that SharePoint began its life in the digital workplace as a web-based file share, and in many cases it continues to be one.

SharePoint isn’t a platform where most people expect to find a data governance expert. And yet SharePoint governance is a great exemplar of data governance, for three reasons:

1. Microsoft and the SharePoint community have done a great job communicating the importance of governance, so that when you go to a SharePoint Saturday or a SharePoint conference, it is an in-joke that “you can’t talk about SharePoint without mentioning governance.” Can’t beat the awareness there.
2. Governing SharePoint gives hands-on experience in every aspect of data governance, from the obvious to the not-so-obvious, as we’ll see below.
3. Effective data governance demands collaboration—not the technology, but the practice of negotiating and communicating among stakeholders that becomes second nature to every SharePoint governance lead. “Repeat after me. You have to Share. That’s the Point.”

The DAMA Dictionary of Data Management defines Data Governance as “The exercise of authority, control and shared decision making (planning, monitoring and enforcement) over the management of data assets.”  DAMA has identified 10 major functions of Data Management in the DAMA-DMBOK (Data Management Body of Knowledge).

So, how is SharePoint governance really data governance? What functional principles can we see in the platform? Let’s walk it through.

The Obvious

The most obvious data governance for SharePoint is the farm administration involved with Database Operations Management. Most data governance teams would recognize the infrastructure governance tasks involved in content database deployment, database backup and restore, database-attach upgrade, and disaster recovery. Ensuring that these operations function smoothly is essential to data governance. A truly great operations team is self-governing in this regard, whether it’s the offshore admins working 24/7 shifts or the busier-than-a-one-armed-paperhanger “SharePoint dude” (or dudette) who’s running three Central Admin farms with one hand and migrating entire site collections with the other.

Think SharePoint, and you think of Document and Content Management. Managing document libraries and web pages is the most basic form of data governance, so much so that many data governance plans explicitly focus on “structured data” and exclude unstructured content. Which is a shame, because more and more data is becoming more and more unstructured, both in documents as data models and as snapshot report extracts for ad hoc analysis. For some data governance stewards, the mere mention of such practices evokes a reflexive response. “Well, that’s not governance.” Somehow, data management in documents, or even managing documents as data, has become the antithesis of governance. (It might be useful to ask, “why not?”)

User access and permissions is another obvious area for SharePoint in Data Security Management. Here again, many data governance plans define collaboration and knowledge sharing sites as open areas for information management, and may either govern by exclusion (financial records may not be posted to intranet portals) or by location (all financial records will be stored in SAP). SharePoint’s flexibility and granularity of permissions can tilt data security management quite far toward the front office, and well beyond the comfort zones of enterprise CISOs. Effective SharePoint governance requires (and supports) strong enterprise controls on information and data security, and these can be implemented with the same level of attention and investment one would expect of any enterprise platform.

In SharePoint, Data Development is an organic process that touches content development, content organization with folder structures and metadata tags, coauthoring and versioning, data collection and analysis, review and approval, publishing, and iteration. Often, the concept of data development arises only when a team is preparing to share their work with others and begins to focus on presentation and communication. Data development in SharePoint is paradoxically obvious (it’s everywhere, adding content and data is what people do with the platform) and not-so-obvious, as it’s not nearly as structured as data developers on other platforms may expect.

The Not-So-Obvious

Data governance teams familiar with ERDs and data dictionaries might not as readily recognize site collection and site structures as Data Architecture Management. However, SharePoint has a clearly defined and well-structured hierarchy of data structures, so much so that they can be easily taught to business users. Defining some basic mappings of data structures to business domain objects can be a pattern map for a business-driven logical architecture: one site collection per department, one site per project, one library per fiscal quarter, &c. SharePoint architects have to be good data architects, working with levels of structural granularity from the content database to the list field and everything in between.

Those in the know about SharePoint will associate Metadata Management with the Managed Metadata Service, as well they should. Governing a MMS term store with multiple business taxonomy owners and both enterprise and site-level term sets is an exercise in cat-herding that will have most data governance teams reaching for their data dictionaries. But the real taxonomists will dive deep into the business ontology of business-created Site Columns and List Columns. These Choice, Lookup, Person, Date, and Calculated fields are where business users can (and do) extend data models on the fly. Set some alerts on the most active sites, then watch and learn where your business is evolving, and where your governance teams can do some outreach on the fly too.

A simple change of column type (say, from text to date) or a Required field can restore Data Quality Management as quickly as it gets diluted by the fluidity of SharePoint data modeling. The adaptability of lists is one of the easiest ways to teach DQM to a business team, since they can tune their data quality requirements easily through the UI as site administrators. There may be no easier way to engage business users with their own data quality than to convert an unstructured Excel document to a SharePoint list with a source and target set of columns (text fields for the source and appropriate datatypes for the target), and invite the document owners (aka data stewards) to complete the mappings hands-on. You’ll have them clamoring for strongly typed data before they know what it is.

Column type changes can also be used to drive in-flight maturity and adoption of Reference and Master Data Management. Replacing a choice column in a list with a Managed Metadata column from the Enterprise Term Store is a simple way to communicate master data to business users without documentation or training. A content type from the Enterprise Content Type Hub can carry multiple columns of reference data directly into the UX layer, often making the adoption and master data change entirely transparent to business users.

Most people would reject the concept of a typical SharePoint farm as a repository for Data Warehousing and Business Intelligence Management. And yet, for many business users, their SharePoint site is their “document warehouse” and a searchable knowledgebase for the intelligence they need to do business. As data governance emerges from back-office ERP and CRM systems into the unstructured world of the front office “digital workplace,” SharePoint and Office 365 might start to look a lot more like the BI/DW of the future, especially if data integration and web parts can make it the UX to the Data Lakes of the Cloud.

Collaboration and Data Governance

“Many people are completely on-board with Data Governance – up to the point of working collaboratively across business units, where only roadblocks are envisioned.  Data Governance is definitely disruptive but in a positive way (if approached properly).  It does entail change – including organizational change (e.g., Data Governance Council, Data Stewardship Coordinating Committee, etc.).  We’re not talking about a guerrilla approach to Data Governance where some visionary, but under-authorized data architect tries to effect change using influencing skills!” (http://blogs.perficient.com/healthcare/blog/2012/06/12/data-governance-vs-data-management/

Funnily enough, that guerrilla approach is exactly where SharePoint governance shines, and where the next generation of data governance stewards must learn to shine too. Because Big Data has escaped the twin fortresses of ERP and CRM, and it’s headed to the cloud as fast as mobile developers can get it into their apps and business users can upload it to their OneDrives so they can play with it in Tableau or Spotfire. And the fastest way that data moves today is, more often than not, as a document in a SharePoint site, far beyond the reach of any enterprise data steward.

A “No, no, don’t touch” approach to enterprise data governance will starve a data warehouse as quickly as it bloats the SharePoint farm with Excel extracts. Business users trust data that they own, manage, and control, so that learning to share becomes the foundation of data governance.

Data governance needs to do more than say No. It needs to find acceptable ways to say Yes to the speed of business.

Data governance demands collaboration. And the SharePoint community has learned a critical lesson for driving collaborative change across business units: WIFM. What’s In It For Me? Only enlightened self-interest will prevail, and it will do so when (and only when) stakeholders engage each other directly for mutual gain. WIFM is a much more powerful driver of organizational change than any council or committee. Insofar as a Data Governance Council or Stewardship Committee can foster that sense of shared stewardship by discovering and communicating WIFM to its membership, that will be the measure of its success.

We need to Share. That’s the Point. It’s just good data governance.

SharePoint Saturday Durham: Driving SharePoint Adoption Through Migration and Governance

I had a great time in North Carolina presenting at SharePoint Saturday Durham. Check out my presentation on SlideShare:

Lessons Learned From Seven Years in Content Management

I’m about to embark on my third internal content management system (CMS) since 2001. Content management has come a long way since then, when our VP of Engineering hired a consultant to deploy the free SharePoint Team Services 1.0 as part of Windows XP, and hoped the group would use it. Within a month, the single document library looked like the front hall table where an entire dormitory had dumped their mail. That’s how I became a SharePoint admin. Four years later, a systems integrator recruited me for my SharePoint experience as a full-time Process Manager for a large state project administered entirely (that was the goal) through SharePoint–again, free and out of the box. This time round, my current company will be using an open-source alternative, Confluence, and I’ll be one of several Subject Matter Experts (SMEs) on the deployment team.

Most deployments start with a tool, and the technical questions about what the tool does and how to make it do what you need it to do. As SharePoint has emerged as a tool worthy of an acronym (MOSS, which is nicer to say than WSS), discussions seem to center on how to deploy, customize, enhance, extend, add-on, and otherwise engineer SharePoint as a software solution.

My own lessons learned focus less on these techie questions, which are satisfying because they have clean answers (even if they’re not the answers you want). Our deployments were never intended to be customized, and the desired investment was zero money and near-zero IT time. Even when a third-party solution would have solved a business problem, as the BA admin I had no access to the SharePoint server itself, which was administered by our IT group in each case. When you’re working with an “out-of-the-box” solution, you don’t get to think out of the box. I got quite good at devising creative solutions “inside the box” that leveraged SharePoint to satisfy exceptionally demanding business users without touching the server or writing a single line of code. That, as they say, is another story.

The most important lesson I learned, and that I teach, is that building a library involves more than shelves and bookbinders. You need authors, readers, and–promises of search engines and collaboration systems to the contrary–you DO still need librarians. The part I play with would-be CMS engineers is to repeat, early and often: “Computers do not create content. People create content. Producers used to be called writers. Consumers used to be called readers. Librarians help writers and readers find each other.” And, when faced with the intense and well-meaning frustration of a content producer at needing to get the words right: “Yes. If we all lived in your head, we’d be better off. But other people need to understand it too.”

So, in recalling seven years on the front lines, here are some lessons learned. Each has a story behind it, and some vivid and/or bitter experience: but writing for the web needs to be concise and crisp. So, here you go.

About Users

• Content Management Systems (CMS) and Knowledge Management (KM) are projects undertaken only when it hurts. The people it hurts the most are not necessarily the ones who will get the most use out of a well-designed CMS.
• Do not forget to communicate to the end users of the CMS what problems the new system is designed to solve. If you are really proactive, you will ask them what problems they would like it to solve. These will be different than the pain points identified by those who started the project in the first place.
• No one likes to make someone else’s job easier at the expense of more work on their part.
• Don’t bother fixing what isn’t broken. If your users are sharing content in a way that works for them, leverage and improve on that before telling them why they could be doing better.
• Managers may want users to collaborate far more than users want to collaborate, or vice versa. These expectations are implicit requirements in a CMS, and may surface only when rollout does not meet expectations.
• Collaboration and content ownership are both important, not the same, and can be, but are not necessarily, in conflict.
• Content producers have obligations as content owners that may create limits and disincentives to true “collaboration.”
• Producers do not like to share content that “isn’t finished.” The CMS needs to provide tools that the producer will accept as alternatives to keeping drafts and notes on their personal hard drive.
• Content producers are The Few power users and vocal stakeholders, while content consumers are The Many who often do not even consider themselves stakeholders.
• The Few will insist on creating the CMS to serve their needs, which are usually far more complex and can be confusing to consumers.
• Turning consumers into producers creates a higher signal-to-noise ratio that often backfires and creates resistance to the CMS.
• “Collaboration” can and will expose differences of opinion, factual inconsistencies, power struggles, and unmade decisions. Consumers do not want to know all this. They want authoritative information–even when they disagree with it and then want to “collaborate” to change it.
• Managers and team leads are generally more interested in sending than receiving.
• The same person will behave differently as a consumer than as a producer.
• Producers want consumers to pull, while consumers want producers to push.
• Lots of producers will create overlapping, inconsistent, outdated content that needs a SME/KM to ratify. This person was once known as a writer.
• Consumers want to know what The Answer is, Now. They don’t want to do research and analysis, they’d rather ask a person (their de facto KM).
• As long as it’s faster to ask a person, consumers won’t go to the CMS. Producers must leverage the CMS to provide answers.
• Most content producers actively enjoy the sense of urgency and importance that comes from answering questions and knowing the answers. Promoting self-service knowledge transfer takes away that sense of personal fulfilment and is a disincentive for producers, even when they are overwhelmed with questions and acting as a bandwidth bottleneck.
• As long as it’s faster and more accurate to send an email or an IM than to do a search, users will ask questions before searching for answers.
• Especially in software environments, many users have much stronger facility with spoken than with written English. This makes tacit verbal knowledge transfer (asking questions face to face) more attractive than explicit formal knowledge transfer (go look it up).
• CMS is best for asynchronous communication and will never replace synchronous communication. Users will always need face-to-face, phone, email, and IM.
• Users in search of answers often do not know how to frame the question. They may not know how to recognize the answer when they find it, especially if it’s not the answer they are expecting.
• Users like to browse. Users like to search. Some users are Browsers or Searchers by nature, but eventually all users will want and need both. Don’t make them choose by designing your CMS to prefer one or the other. If you have a dedicated Browser or Searcher dominating your requirements team (especially if that person is a senior manager or tech lead), try to enlist users of different approaches and experience levels to balance the team.
• Once you have invested all that time in producing written content, be gentle but firm with consumers who are overwhelmed at “I have to read all this?!” Be even firmer with producers who don’t want to keep it up to date “because no one wants to read all this.” They will usually short-circuit the CMS to share more current knowledge one-on-one. This will make your CMS fall even further into disrepair. Librarians must encourage, cajole, demonstrate, help, and insist that writers write, and that readers read.

About the KM Role

• No one will call you a knowledge manager. You won’t know you are one. How do you tell? Here’s a useful metric: you are answering questions more often than you ask them.
• It’s a personal discipline to go to the CMS instead of answering from your own knowledge. Shooting from the hip reinforces tacit knowledge transfer and guarantees distrust in the CMS.
• If your own knowledge is out of date and you discover this through a question, UPDATE THE CMS AT ONCE so the explicit knowledge is accurate.
• Think of the CMS as your reuse repository for answering questions.
• Seize the teachable moment. When someone comes to you with a question, show them how you find the answer in the CMS. Next time, walk them back to their cube and talk them through the search themselves. Invest your time in teaching your users to fish. Of course they would rather you serve them fresh fish and chips to order. This will not scale. (Pun intended.)
• Keep track of all the questions you get asked in a given time period and how you answered them. This will make the ROI of KM very visible to your manager.
• Find ways to add and update content daily, in small doses. Building a KM system is something that will always fall into the “when we get to it” category. It’s your job to get to it, since you’re the one who needs it the most.
• Integrate email into your CMS!!!! If you can’t pull AND push content via email, your system is doomed.
• Users can and will insist on personal and customized, just-what-I-need-to-know content. Explaining that you cannot send each and every QA person a daily list of only the bugs they need to review is often fruitless and may result in your manager ordering you to do just that and work extra hours to do it. Invest your extra hours in building an automated system to do it for you.
• Give your CMS a face. Be the Knowledge Manager and the Go-To Person. Then, and only then, send them links to answers as your first line of defense.
• Remember that asking good questions is a learned skill. If it’s easy for you, it’s probably transparent and you wonder why others can’t just go find the answer themselves. Notice what questions your users are NOT asking before they come to you.
• Elicit expectations actively and up front. Pay careful attention to what The Few stakeholders expect, especially what they expect you to know without telling you. These are the most difficult expectations to manage, and you may have limited choice in mitigating risk.
• You will never stamp out the process of emailing attachments, but you can damp it down by sending links instead.
• If you are serious about cutting down on attachments, enlist your IT department to place a limit on mailbox size. This will make your users scream bloody murder. Let IT be the bad cop so that you can be the good cop by promoting links as an alternative.
• Be polite but firm with people who email you documents to post for them on the CMS. You may have to provide that service, especially for your manager. If this practice is choking your inbox, reexamine your navigation structure and ask why it’s hard for your users.
• Do not expect your users to memorize your directory structure. If they ever do, they will not let you change it. Be gentle with people who post things in “the wrong place.” Make sure your CMS can handle the manual routine filing that you will need to do behind the scenes.