Infovark

Laurence Hart over at Word of Pie calls us out on our approach to content management . Dean and I are both big fans of his blog, so we were pretty stoked to see a whole post about us.

Laurence raises a lot of valid concerns, all of which we’ve spent loads of time mulling over, and I’ll get to those in a second.

But first, to really understand our solution, you need to know how we got here. Dean and I absolutely understand where Pie is coming from. We have a long history of working in the ECM space with TOWER Software. We’ve read through countless customer requirement lists about compliance, Sarbanes-Oxley, retention, discovery and authoritative versioning. We’ve spent hours designing taxonomies, file plans, and security and access policies. We’ve drafted tender responses, and drawn large Visio diagrams. We’ve written integrations to nearly all the of ECM products in the market today.

After all this effort, once an organization deployed our tailored solution, we’d observe the same pattern. The content management software met the business needs, but it didn’t help the end users. Instead, It got in their way. It often made it harder to find things, and it made them work to understand things that they weren’t specialists in — like taxonomies and retention. User acceptance and training overheads were huge. We had to work like crazy to get people to use our carefully crafted solutions.

OK, you might say — that’s fine. Work isn’t supposed to be fun. You just do what you’re instructed to do. As long as the enterprise as a whole benefits from the solution, the content management program is doing its job.

Except that the enterprises weren’t really benefiting. The push-back from the user community meant that people wouldn’t actively use the solutions to do their daily work. Large, corporate, and eminently scalable repositories all over the world are filling up with dusty, useless content, most of which is almost certainly never going to be seen again. Traditional content management is extremely effective at preserving things. It’s terrible at solving the kinds of tactical problems that people deal with every day. Sure, retention was up. But productivity was down.

(Pie knows this. That’s why he talks so much about invisible, or transparent ECM . Because yes, preserving things is important, but knowledge workers don’t care.)

So, when we started Infovark, we set out explicitly to solve the other problem. The people problem. The fact that people couldn’t connect and share with each other. We decided to build an enterprise product that people would want to use, first and foremost. The capture and retention come second. The point of a transaction is not to get the paper receipt.

OK, that’s where we came from. Now to answer some of Pie’s more technical questions:

• How do you manage the disk usage? Peer-to-Peer is concerning. I’ve used Groove and it can be a disk hog. You would need a fair subscription model to manage the whole thing.

Groove is a disk hog. Transferring files from a peer through a peer is not what we do. For one thing, Groove places content on your machine that’s merely “passing through”, i.e. unrelated to your work. This can be something of a security nightmare. How do you keep that information secure? For another, Groove is about pushing updates out to subscribers. Infovark works like RSS; we pull updates. And we only pull data relevant to you and to which you have access. The network usage is about the same as if I email a document from my computer to yours.

• Are the wiki pages also stored peer to peer?

The Wiki pages are indeed stored locally and accessed remotely.

• What do you do about items once completed and needed to be kept?

As of right now, we don’t do anything! One of the great things about the REST-based approach that Infovark takes is that that content is accessible and available to the whole enterprise. Any content-spidering search product, like the Google search appliance, can easily scoop up the latest version and index it. Periodic backup or archiving would work in the same way. Use your favorite off-the-shelf tools. We’re also planning some specialized versions of Infovark that can address all three needs in the same package.

• Items are listed on a user’s Wiki. Where does it get listed when a user leaves the company?

That’s up to the IT guys. The user’s Infovark could easily be picked up and hosted on a server. Then all you’d need to do is change a DNS entry or leave behind a permanent redirect. It’s kind of like an “Employee Graveyard”. Creepy…

• How do you track/prevent cross edits? Johnny starts to edit something and then I decide to make some edits as well. How is that managed?

Gah! Stop asking hard questions. We’re working on that right now. We’ll get back to you when we get to Alpha in June.