Had an interesting phone interview the other day, and we got into the topic above, which I found interesting.
We both agreed that we were going to see far more social software in the enterprise in the coming years. The question was more about architecture -- would these software packages be purchased and deployed as free-standing entities, or would they be thought more in terms of a "layer" over something else already in the enterprise.
And, if you're aspiring to be a social media proficiency practitioner (as I am) -- or a vendor that's selling to people like me -- the answer might matter to you.
Enterprise Buying Patterns
If you listen to software vendors who are trying to sell in the enterprise, they'll usually make it sound like all sorts of large, important companies are buying their software.
However, if you dig down a bit, the truth is more usually that some group or another within that large organization made a purchasing decision. It wasn't what I'd call a corporate decision.
As an example, let's take SAP -- a large, enterprise ERP platform. No single group or department within a corporation will go out and deploy SAP -- it just doesn't make sense. 100% of their customers are probably "corporate decisions" rather than "group decisions" within a large company.
To take the opposite to an extreme, I happen to use SanDisk USB memory sticks. Does that mean that EMC Corporation - a Fortune 500 company!! -- uses SanDisk USB memory sticks? Technically yes, but I think you get my point.
Why does this matter for social software?
Because I think there's a big difference between some engineering group putting in a wiki for their team, and a large corporation making a strategic decision for all their employees. Trust me, the buying criteria will be very, very different.
If I'm selling to a small group, I'd want an offering that's focused on price, ease of installation, price, ease of management, price -- and maybe price.
If I'm selling to a large enterprise, though, the list is very different. If I'm a large enterprise, I've already made many, many investments in existing infrastructure software. I want my new social software to work with everything I have -- not as another free-standing entity, but as a "layer".
And I'll pay extra for that capability.
Layers Vs. Free Standing
All sorts of people toss around concepts like "works with" or "integrated" or "gateway" to describe how different software entities interact.
But if you're doing corporate social software, I think you're going to want to really drill into the details here.
Let's looks at a few examples ...
The Concept Of People
The company I work for already has several systems of record that define "people": name, location, phone number, etc. Do I want a separate domain in my social software that defines people differently?
Ideally, the concept of a "person" (as found in our PeopleSoft HR system) would be almost identical to the concept of "person" as found in my social software platform. Sure, there's stuff in the HR system that shouldn't be in the social software (!), as well as stuff in the social software that doesn't belong in the HR system.
But between the two, there are certain fields that are one and the same. I want to use my HR system as the "system of record" regarding people-related information, and not my social software.
Now, having my social software put a "social face" on that boring HR system we use -- that's OK.
I want my social software to create a "layer" over my existing concepts of people.
The Concept Of Calendar
At my company, we use Microsoft's Outlook religiously. We all schedule our time, our deadlines, our meetings, etc. across multiple time zones and multiple languages using Outlook. Because everyone uses it, we can synchronize time-based events without a phone call, email, etc.
Now, if my social software introduces a separate, distinct concept of "calendar", how useful is that? In the best case, it's just a useless piece of frippery. Worst case, some people start using it as their primary calendar, and then we lose the benefits of coordinating time-based events -- like conference calls.
I want my social software to create a "layer" over my existing concept of time -- a calendar. And, if my social software vendor offers a calendar, I'll probably have to disable its functionality.
BTW, if you can figure out a way to expose what I'm already using (e.g. Outlook) in a more friendly, social way -- I'm all for it.
The Concept Of Content
Here's my favorite -- I've written about this before.
At EMC, we've got a corporate "content backbone" -- Documentum. Now, lest you think that's unique simply because we happen to develop and sell Documentum, that's not quite true. A large number of organizations have content backbones. And, given our business model at EMC, if we weren't using Documentum, we'd be using something else.
The content backbone is more than just a repository -- it's an active, living entity that implements workflow, active information management, repurposing of content, and so on. It ain't just a honkin' document database.
Do I want my social software vendor to implement its own concept of content? Probably not.
I'd like my existing corporate content to be exposed (and modifiable) in the social software. Any content (or metadata) that I can pick up in the social environment I'd like to be able to manage with my content backbone.
If you dig into any modern content management system, you'll find a very fine-grained environment for controlling different aspects of a document -- far beyond what any social software vendor is prepared to implement.
I've got security and encryption features. All sorts of statistics that I can go look at. Integration with multiple web portals -- both internal and external. The list goes on and on and on.
I want my social software vendor to create a "layer" over my existing concept of content. I don't want to create a separate, distinct and isolated content domain -- one that's arguably much less functional than the one I've already got.
And, I Don't Want To Be In The Software Development Business
When I share these thoughts, someone inevitably says "well, you know, you can develop your own interfaces". Yes, that's true. Nothing here that time, money and a small team of developers can't fix.
But I don't want to be in the software development business. I don't have to do significant software development on my other enterprise platforms, why should social software be any different?
Does This Really Matter?
Look, if you're some small business, and you're looking at social software, the preceding discussion probably matters less to you. I mean, you probably haven't invested in some of those things -- and, if you have -- the chaos that would be created by separateness only occurs on a smaller scale, and you can probably live with it.
Or, if you're a "team leader" in a larger organization, and you're trying to get a nice environment for your team to collaborate around, you may look at the discussion above and say "it doesn't really matter to me", simply because you're focused on your needs, and not those of the broader organization.
And, if you're a social software vendor, and these are your target markets, you can safely ignore what I'm talking about.
What Large Corporations Are Really Interested In Social Software?
I've met several dozen now -- and they all seem to share similar attributes.
They're large, complex, global enterprises with a broad range of diverse offerings. They're essentially built on knowledge workers -- smart people who know how to do stuff. They've got a culture of innovation, of sharing, of leading.
And they've all got the itch to do something with social media proficiency like we're doing at EMC.
Every one of them that I've met has already invested heavily in things like centralized HR databases, shared calendars and email systems -- and enterprise content management systems.
I would argue -- very strongly -- that these large corporations will want social software that acts as a social layer over their existing capabilities, and doesn't feebly try to replace them. Extends what they already have, and brings more value to their existing investments.
A Maturing Industry?
Many of us as we grow up end up going through a phase where we rebel against the established order, and commit ourselves to righting the world's wrongs. And then we grow up a bit, and find that having a nice career, a spouse, a nice car, etc. really isn't such a horrible thing.
I'm guessing that the social software business might be going through the same phase to a certain extent. They're trying to change the order of things.
That's fine, but your single largest target market -- large corporations -- also wants to see things changed, but at the same time they have some logical, rational constraints about what kind of changes they can pursue, and which ones they can't.
I think the software vendors that end up winning in large corporations will be the ones that adopt a "layered" view of what they do over existing capabilities, and focus less on ignoring or replacing the investments that have already been made.
At least, I hope so.