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?
Probably not.
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.
But the "non-social" enterprise software vendors also have to play ball and use open standards to integrate. When both sides agree to use LDAP, being a people overlay is easier. If every document has a canonical unique URL, then integration, at least at the widget level, becomes easier. If both sides both produce and accept RSS, well, you get the picture. Social (web 2.0) software likes lightweight integration. Otherwise we're back to EAI and middleware work again.
Posted by: John Troyer | May 13, 2008 at 05:53 PM
Overall the interview was fantastic; I learned many skills and facts that I need for the future.
Posted by: Target market | May 13, 2008 at 11:51 PM
Agreed!
Posted by: Chuck Hollis | May 14, 2008 at 07:31 AM
A bit more on John's comment.
After thinking about it more, I guess what I'm saying is I don't want a push-pull replication model, for example, social software sucks the content of an LDAP database into its own world, and then tries to push any modifications back to LDAP.
Yuck.
Better that social software has no construct of LDAP contents other than what it can access in near-real-time (caching is OK).
I think there's a difference.
Posted by: Chuck Hollis | May 14, 2008 at 05:50 PM
Chuck,
Great post. I agree with the social layer concept. In your opinion, will the companies that you describe within your post work with SaaS to provide this social layer or will everything need to be behind the firewall?
Posted by: Mike Walsh | May 16, 2008 at 05:43 AM
I think that's an orthogonal discussion.
SaaS has to do with how the value is delivered: as a product, or as a service.
From a pure technical perspective, there's no reason why the different components couldn't be traditional, SaaS or some mixture.
But that creates complexity. Some (smaller) companies will inevitably drift towards SaaS for their core applications -- we can already see that happening today. And, of course, they'll want a social layer to go with that.
Other (larger) companies won't be using SaaS for core things like HR, LDAP, etc. so the opposite will be true.
Posted by: Chuck Hollis | May 16, 2008 at 02:01 PM
Ideally - this should be a layer, but it can be freestanding as well. Minimally you can just have ldap integration for membership. The reason I say it can be freestanding depends on what the business context is and your understanding of the problem you are trying to solve. "connecting people" is a very broad theme. What specific problem are you solving and for whom? Have you adequately defined and analyzed that problem? After reading this entire blog, I'm not 100% convinced. It seems like you've been on this journey of discovery here and it's interesting -- but I'm wondering if you should be diving deep into the world of the sales force to truly understand some of the pain and problems they might face. For example, where do the social problems actually lie in sales, can you do some social network analysis to determine where knowledge lies, who are the goto resources, how sales communicates today and with whom? etc...
Having been someone "in the field" working with customers and also having been a goto resource for knowledge -- the biggest problem is product knowledge (what it can/can't do and what the expected behavior should be programmatically). Most of that knowledge is in a developers head or exists in a front line support person who deals with problems everyday. Other issues include finding the right resource who can help a client during a pilot or troubleshoot a production problem. Or it's in product management who can help with features and product direction. Ideally you need access to product management, engineering, support, etc... And you need it accessible remotely.
Doing the right analysis might actually reveal that 20% of people in the entire company might actually have all the knowledge and implementing a community might not do too much if they are not contributing -- or if a few of those key resources decide to leave the company.
I'd step back and rethink your ROI and relook at "how are we working and communicating and socializing today?" and map that out. Then say "how should it work ideally given the current tools out there"? How does Jive truly address those problems? That is approach is what Facebook does so well (at least in my opinion) -- they say "how do I socialize with my friends in real life today" and how does that translate to the online world and how does it fit my lifestyle?
Posted by: Rich | May 18, 2008 at 09:09 AM
Best of luck on the brand-new consulting gig, Rich.
Posted by: Chuck Hollis | May 18, 2008 at 09:50 PM
Nice Trend... Very informative and so resourceful.
Posted by: social software blog | May 19, 2008 at 03:51 AM
Social software is going to be increased dramatically in 2009 - but you WILL NEED Experience - don't expect to come in an dominate a market, it just doesn't happen like thiat.
Posted by: HR Software | February 09, 2009 at 10:23 AM