Blogs

In an article for MarketsForGood.org earlier this year (Avoiding the Silo Gap), I wrote about the tendency organizations have to build out data silos around business units (sales, marketing, support, engineering) and, even within these business layers, around specific roles (project management, developers, HR). Rarely is it intentional -- our teams and people want to solve business problems, and so we add on tools and processes meant to solve short-term issues, all the while creating increasingly complex layers of data.

"Human nature is to solve the problems right in front of us. More difficult is to look at our problems more holistically — to step back and think about these issues long-term, and how else this data might be used. An operations team will look at solving their own needs, regardless of the potential benefits to their support or engineering teams. Likewise, support will develop solutions for support, and engineering for engineering. Architecting our systems holistically (and planning our businesses using systems-based thinking) can be difficult and time-consuming, but are necessary if we are to prepare ourselves for the unknowns. We are siloed in our thinking about business problems, not just the data."

With the rise of social collaboration solutions within the enterprise, the danger is that we are creating even more massively complex data structures without a clear understanding of the value of this data, how it is (or should be) connected to our business systems, relying instead on out-of-the-box search capabilities and the wisdom of our favorite OEMs to "get it right" on our behalf. It's the classic Big Data problem: we're not too concerned with the data we're not capturing or not utilizing because we don't yet understand its value.

One of the ways I illustrate this point in my day job as a SharePoint MVP is to share a couple simple pictures of the data structure of the native social features within SharePoint 2013, with a snapshot of the content databases that these features generate. My point is to show the volume and complexity of what is created around these standard features, but also how these content databases can be accessed by third-party solution providers and customers themselves, enabling us to build rich reporting and dashboard solutions.

Here's the rub: that same data is more limited (i.e. unavailable) through most software-as-a-service solutions, meaning that you have less ability to search, find, extend, or innovate on those social collaborations except in the manner that your favorite OEM determines on your behalf.

What's the answer? How do you provide feedback to your OEM when you don't fully understand what is being captured, what is accessible, and what capability is being taken away as your platform of choice becomes more packaged and componentized into its basic cloud services?

Simply put -- ask for everything. If my end users make a comment, like something, rate something, attach a file, compile a note, create a poll, initiate a discussion, share something, or any other social activity within my environment, I want to be able to track it, measure it, and make sure it is secure, compliant, and well-governed (all within the limitations of corporate and personal privacy, of course). Maybe the better approach is to ask your OEM "What social data is unavailable to me?" We need to demand access to our data. If we can retain access to and extend all of the various social activities in our system, we can avoid the dangers of creating yet another data silo.