Of Parallel Projects and Compound Wikis

I promised you I'd share all the major twists and turns of our journey here, and we're coming through an interesting interaction between other projects, specific requirements, and corporate interplay.

Setting up the story will take a while, but the outcome is good (I think), and I'm guessing that this sort of issue will frequently pop up in larger enterprises that are considering social media platforms.

The Context

My team is running the EMC ONE platform -- a default, behind-the-firewall SM platform designed to get people comfortable with the whole idea.

Yes, we're going to see some business value from the interactions behind the firewall (much seen already, more coming), but the real goal is to have people who can participate in SM communities outside the firewall.

As a result, we picked a platform and a path that suited our needs.  And, broadly speaking, no regrets.

But we knew we couldn't serve everyone's needs, but we'd try.

The Parallel Project

Early in our project, we started talking to someone in our services group who had a very different need.  They needed to collaborate around large, multi-part documents: technical documentation, process documentation, etc.

The wiki model in Clearspace (and most other tools) is pretty basic -- it's basically a flat document.  When we first looked at the package, it looked fine to us.

What this team needed was the ability to collaborate around a structured document: multiple chapters. 

This chapter goes to this team, that section goes to that team -- yet still retain a "single document" view with things like table of contents, revision history, etc.

We really couldn't help them at the time, so they went off and started looking at things.  They were able to come up with a prototype based on XWiki (an open source-ish tool) and, well, what they came up with looks pretty cool.

It's More Than Just This Project

As I looked at what they had done, it immediately struck me -- we're going to need this in LOTS of places across EMC, and not just within the group that had developed it.

A lot of what EMC produces and uses are large, structured documents.  Today, a small team produces them, and publishes them in one place or another.

No one can comment.  No one can improve.  No one can update.  Frequently, they're never really updated after they go up on some web site.

If we had the ability to take a significant portion of these long, important pieces and open them up for continual improvement, well, I'd offer that'd be a pretty important social media capability for the company.

And, sorry to say, I missed this biggie when we were first looking at requirements for our social media platform.

Now We're In A Tough Spot ...

First, I can't ignore the functionality.  It's big, we're going to need it, and that's that.

But, if this XWiki thing profilerates, we'll have (at least)TWO unintegrated platforms to do social media collaboration behind the firewall.  Two user and authentication domains.  Two search domains.  Two user experiences for people to understand.  Not to mention the costs associated with maintaining and enhancing something custom, rather than commercial.

And, of course, roughly twice the infrastructure costs.

The options don't look very appealing at this juncture.

It'd be wonderful for the Jive folks to offer this functionality (or at least a piece of it) sooner than later.  They'd get a win by getting more revenue licenses from EMC (at least several thousand), and wouldn't have to worry about competition, at least, at this account.

I think they might realize that it's not just EMC that will need this.  I'm now of the opinion that -- if a vendor is going to serve corporate collaboration needs -- Jive will to have to offer something like this, sooner than later.

A few folks from Jive were out here meeting with us this week, and we got to see parts of their roadmap.  Nothing like this in their plans right now.  And getting a vendor of any size to pivot on a dime is not fun for either customer or vendor.

Another option is to write our own code.  We have many software developers here at EMC (remember, we develop all sorts of IT products), and we also have the option of contracting this to a third party.

But, honestly speaking, I don't want to be in the code-writing business.  Especially for a major piece of core functionality like this one.  And, I'm worried, unless it's deeply and architecturally integrated with the existing Clearspace constructs, we'll have an ugly, custom wart on the side of what is overall a slick, integrated and intuitive environment.  Not to mention, expensive and difficult to maintain.

Or, we can scrap our overall approach, and start over again with another package that supports a more advanced model of wiki collaboration.  Of course, starting over is not fun, but it's not too late to figure out if we started down the wrong path.  I wouldn't even consider that for a small piece of functionality, but the more I think about this, the bigger it's getting in my mind.

I'm hoping (praying, actually) the Jive people can come back with a reasonable proposal to address this sort of requirement in a reasonable timeframe.

Otherwise, we're gonna have a mess on our hands.

The Politics

No recounting of this tale would be complete without a brief mention of the corporate dynamics that went on around this issue.  Let's just say it wasn't all sunshine and roses.

The group that developed the prototype was very passionate about what they were doing.  They couldn't see why they wouldn't be allowed to proliferate this everywhere.

Their heart was in the right place, but there were a few externalities.  They had no real handle on the true costs: infrastructure, labor (of different skills), etc.  Also, I felt that they had severely undersestimated the effort associated with getting people to actually use the tool -- something that we're struggling with each and every day.

But, more strategically, this team didn't feel that it was their issue that they'd be creating problems elsewhere in the company if they profilerated an entirely different tool.  From their perspective, they had a problem to solve, and this was it.  Everyone else can go solve their own problem.

After a short meeting, our governance group agreed that the pilot should be able to proceed, but -- at the same time -- me and my team had to get busy on figuring out how to get this functionality into the current platform, if possible.

I know it's going to take this project team a good deal of time to get up and running and get people to use their platform productively.  I hope we can come up with a good solution before they get done with their pilot.

Comments

[Ludovic Dubost]

Hi,

I'm Ludovic, founder and CEO of XWiki. I'm very proud that you see the value of the XWiki Platform which allows to do the type of things that you have been doing (you might want to look at Curriki http://www.curriki.org which is built on top of XWiki and provides editing and managing or compound XWiki documents).

Now there is one sentence I would like to react on:

"Not to mention the costs associated with maintaining and enhancing something custom, rather than commercial."

XWiki is supported by a company (24 employees) and is able to help you out in making the best out of XWiki. What you describe is why we build XWiki. We needed a flexible wiki allowing to handle unstructured and structured information.

One thing is the since the Jive guys they didn't built in the platform inside Clearspace, they will have a hard time ever doing what you are asking for.

Now I have another option for you:

Talk with use to replace Jive with a combination of the XWiki Platform and XWiki Workspaces. We can do whatever is needed to have XWiki fill in both the needs that XWiki already fills and the ones Jive fills.

My email is in the email field !