Craig Cmehil, Ethan Jewett and I had an interesting conversation (over Twitter, natch) earlier today about demand for New Web tools like Twitter, social networking, social bookmarking inside the firewall.
Twitter’s 140 character limitation sometimes leads to convolution, but I think the core question was how do you approach internal demand for these tools? From the outset, AppsLab has been evangelizing participation as the path to understanding. The big problem is how to get people to participate. I’ve observed four types of people thus far:
- This is old news dude. I already use Facebook to stay in touch, and I tweet from my iPod Touch while I’m on wi-fi at the airport. I have a cron job to tweet that I’m sleeping when I’m sleeping.
- This is really great stuff. I participate as you suggest and join Facebook and build a network.
- This seems useful, but I’m too busy to try these consumer sites. Bring value to me and my daily work, and I will participate.
- No response. This person is either way too busy to participate or thinks I’m a complete tool.
The majority lies in the third group, the hidden demand. So, we used the Field of Dreams theory to tap this demand with Connect, i.e. “if you build it, they will come”. And they did, and after a while, you can’t delineate between the first three groups because many of them participate in both internal and external networks, which is great.
But then you start to get feature requests, and this is where our conversation started. Initially, it was about the merits an internal version of Twitter, like a white-label version or a clone inside the firewall. More broadly, the question is which is most successful inside an enterprise:
- Using the external version, i.e. congregate on Twitter or Facebook. Why reinvent the wheel?
- Deploying a clone for each web app, either Open Source (e.g. Pligg) or homegrown (e.g. IdeaFactory). This provides intranet security baked into roughly equivalent functionality.
- Deploying a platform clone and using it to add functionality, e.g. Connect. This allows you to expose a single network to other web apps.
Each method has its advantages. Broadly, we advocated the above methods like so: Ethan 1, Craig 2, me 3. That’s not to say we disapprove of the other methods, it’s just an observation of how it seemed to me. Let’s look at each in a little more detail.
Using the external version
I don’t know what Ethan does, but I think Craig and I do similar things, i.e. internally evangelize new web. If I didn’t do that, I’d probably follow this path too. Why would I use an enterprisey version of the consumer original that works for me? I’d collaborate with others who work with me and push others internally to do the same, following the “don’t do anything stupid” rule.
I definitely see Ethan’s point here. Use what works for you on the down low and hope it doesn’t get blocked by IT/IS. He suggests using external widgets internally, which seems risky when you consider the security implications and the potential limitations of the APIs, e.g. we can’t use embedded Google Maps in Connect due to the terms of use.
Deploying a clone internally
If you’re doing something inside the firewall, you get the old argument about portals vs. sites. It’s funny because I don’t really care for portals on the Interwebs, but inside the firewall, I like a portal better. This is due to speed of information retrieval. I know my way around Interwebs better than the Intrawebs.
So, I’m less likely to use ad hoc internal tools. Craig mentioned he was working on an intranet clone of Twitter, but he bemoaned the duplication issue. The only compelling reason to duplicate a perfectly good external tool like Twitter is so you can protect proprietary information. Because of this, some cloned tools are wildly successful, e.g. wikis, others could be if they’re used a lot, e.g. Pligg, bookmarking, others, not so much. I’d throw Twitter in the last bin.
Deploying a platform internally
If you look at what tools succeed when deployed individually, you’ll see why a portal or platform approach is what we chose. If the intranet is littered with wikis , news aggregators and blogs, bringing them all together is ideal, especially if you can add value to build a large user community. Consolidation of tools and information is the primary value add inside the firewall, plus the baked in security.
We couldn’t bring them all together, but Connect builds the network. We’re slowly adding features to the network, like bookmarking and tagging, another example of a feature that I think will be more successful as a network add-on than as a standalone feature.
I guess my point is that new web tools require a network to get the full benefit, so why rebuild the network every time? I like the other approaches, but they don’t include the network right away.
Of course, one problem is overloading the platform with apps, which circles back to the origin of the conversation, i.e. a Twitter clone. Personally, I don’t think the people that ask for a chat widget would use it enough to justify the investment. Ditto for a Twitter clone built in to Connect, but that’s why we have voting on ideas.
Anyway, this is the type of discussion we plan to have at The Working Group, what works, what doesn’t and why. Once again, the group isn’t an Oracle thing, it’s meant for practitioners.
I like the conversation effect of Twitter. I doubt Craig, Ethan and I could ever have had this exchange in any other forum. Obviously, 140 characters isn’t always enough to make yourself clear, so if I’ve misrepresented Craig and/or Ethan, let me know in comments.
Sound off about your opinions in comments. What works for you and why?
Even though not Twitter like, Oracle Collaboration Suite (OCS), which is an enterprise level product, already has forums and chat capabilities, and much more.
http://www.oracle.com/technology/products/cs/index.html
Where do you think OCS is relative to enterprise 2.0?
Even though not Twitter like, Oracle Collaboration Suite (OCS), which is an enterprise level product, already has forums and chat capabilities, and much more.
http://www.oracle.com/technology/products/cs/index.html
Where do you think OCS is relative to enterprise 2.0?
I heart OCS. We use it internally for corporate email, chat, files, etc. I can’t change it to do social networking or bookmarking though. I don’t have that type of pull.
I haven’t spoken to their product team about Enterprise 2.0 recently. And if it I knew, I couldn’t tell you 🙂
Nice try though. If you want to sit with someone on the product team, let me know.
I heart OCS. We use it internally for corporate email, chat, files, etc. I can’t change it to do social networking or bookmarking though. I don’t have that type of pull.
I haven’t spoken to their product team about Enterprise 2.0 recently. And if it I knew, I couldn’t tell you 🙂
Nice try though. If you want to sit with someone on the product team, let me know.
Search for “This person is either way too busy to participate or thinks I’m a complete tool.”
“complete tool” is intentional ? Please clarify..
Search for “This person is either way too busy to participate or thinks I’m a complete tool.”
“complete tool” is intentional ? Please clarify..
Kishore: Sorry, “tool” is an English colloquialism for a useless person or someone for whom you have no use. Kinda opposite of its dictionary meaning, but what do I know?
Kishore: Sorry, “tool” is an English colloquialism for a useless person or someone for whom you have no use. Kinda opposite of its dictionary meaning, but what do I know?
Great write-up. I’m a tad late to the party here, but I figure better late than never.
My impression of the reason we have different approaches is that we’re trying to implement in an environment that may make untenable demands on the software deployed within it. Interoperability and openness often clash with security concerns and politics.
Describing my (currently) favored approach of using external tools in conjunction with open internal tools as ‘on the down low’ is correct in a sense: I think developing prototypes outside of the institutional framework around the development process can be a powerful approach to introducing internal tools and (most importantly) triggering conversations.
This doesn’t mean that the development and the tools are secret and unsupported. In fact, the goal of conversation requires that the existence of tools be shared and that we be willing to discuss the tools.
Example: External widgets on internal wikis raise information security issues around cross-site-scripting. Discussion: How do we balance increased (I assume) productivity from these widgets against the security tradeoff? Is it or is it not worthwhile to redevelop the widget in-house in order to change the security exposure under discussion?
These are complex discussions around subjects that most people (myself included) don’t fully understand. There are issues around whether we are correctly portraying the the tradeoffs of information security and how we measure the return on investment of knowledge management and communication tools.
I think it helps a lot to have examples that we can use as discussion points and I certainly like being able to use my tools of choice, but the real goal is to accelerate the discussions and create solutions (both technical and political) that I hope will end up unifying the three approaches.
Great write-up. I’m a tad late to the party here, but I figure better late than never.
My impression of the reason we have different approaches is that we’re trying to implement in an environment that may make untenable demands on the software deployed within it. Interoperability and openness often clash with security concerns and politics.
Describing my (currently) favored approach of using external tools in conjunction with open internal tools as ‘on the down low’ is correct in a sense: I think developing prototypes outside of the institutional framework around the development process can be a powerful approach to introducing internal tools and (most importantly) triggering conversations.
This doesn’t mean that the development and the tools are secret and unsupported. In fact, the goal of conversation requires that the existence of tools be shared and that we be willing to discuss the tools.
Example: External widgets on internal wikis raise information security issues around cross-site-scripting. Discussion: How do we balance increased (I assume) productivity from these widgets against the security tradeoff? Is it or is it not worthwhile to redevelop the widget in-house in order to change the security exposure under discussion?
These are complex discussions around subjects that most people (myself included) don’t fully understand. There are issues around whether we are correctly portraying the the tradeoffs of information security and how we measure the return on investment of knowledge management and communication tools.
I think it helps a lot to have examples that we can use as discussion points and I certainly like being able to use my tools of choice, but the real goal is to accelerate the discussions and create solutions (both technical and political) that I hope will end up unifying the three approaches.
@Ethan: Thanks for adding to the discussion. The takeaway for me is that different approaches fit different situations. Craig makes a point on his blog about throwing up something internally and using it within the firewall, but as I mentioned in his comments, that approach assumes you have the hardware in place, which often isn’t the case budgets being as tight as they are.
Our discussion really got me thinking empirically about how to approach the Enterprise 2.0 demand internally, which in and of itself is a positive. Anyone approaching an E 2.0 problem needs to understand the broad options and moving parts before continuing down any of the paths.
Anyway, all good stuff.
@Ethan: Thanks for adding to the discussion. The takeaway for me is that different approaches fit different situations. Craig makes a point on his blog about throwing up something internally and using it within the firewall, but as I mentioned in his comments, that approach assumes you have the hardware in place, which often isn’t the case budgets being as tight as they are.
Our discussion really got me thinking empirically about how to approach the Enterprise 2.0 demand internally, which in and of itself is a positive. Anyone approaching an E 2.0 problem needs to understand the broad options and moving parts before continuing down any of the paths.
Anyway, all good stuff.