Infovark

…It’s how many friends you have. Any self respecting Facebook user knows that, right?

And what’s better than collecting loads of friends? Collecting loads of social networks, that’s what.

In the wake of the Microsoft/Facebook story comes Google OpenSocial (launching this week) - a unified accessible interface to a whole collection of information from Orkut, Salesforce, LinkedIn, Ning, Hi5, Plaxo, Friendster, Viadeo and Oracle. (Details from TechCrunch)

The idea being that Google ties all of this related infomation together, and allows developers to create widget style applications that work across multiple social networks, without having to learn a whole new markup language. (OpenSocial uses standard HTML and javascript, unlike the Facebook API).

It’s going to be interesting to see exactly what can be done with this tool - assuming that the host networks will have the final say as to what can and what can’t be built on their platform. More than 7000 Facebook applications have been built since Facebook opened it’s API. (Most of those applications are really silly.)

The fact that at least two of the OpenSocial host networks (SalesForce and LinkedIn) are veritable goldmines of enterprise worthy information should be of note to anyone working on Enterprise 2.0 solutions. (like um.. us!)

And in the middle of it all, Google controls all the data and the network (in a non-evil way, of course…)

This “Everyone Else vs Facebook” approach reminds me a bit of Microsoft’s catchup play for developers in the early 90’s with .NET - “It’s every other language vs Java”.

That one didn’t work out exactly as Microsoft had planned, but it wasn’t exactly a failure - .NET and Java are both alive and well. I suspect something similar will happen here. Assuming that OpenSocial has legs, it seems safe to assume that developers would much rather target multiple platforms than one.

Does this mean they are going to have to standardize (or at least consolidate) identity across multiple hosts? Now that would be really something…

The lights went out in the infovark burrow this morning. It happens occasionally. We think it’s due to nearby construction work.

Fortunately, our equipment isn’t affected by short term outages. We’ve got a UPS in place for our server and network equipment. Gordon and I do all of our programming on laptops, which have built-in power redundancy through their batteries.

So the lights went out, but the coding went on.

I did have a brief moment of panic. I realized that I hadn’t actually tested the UPS. Part of disaster preparedness is making sure that your back-up equipment is functioning properly and that you can implement your recovery procedures successfully. I’d neglected that part, but our behemoth server kept its cooling turbines humming the whole time. We just passed a real-world test with flying colors.

I’ve been seeing this video, by Michael Wesch, crop up in quite a few of the feeds I’ve been reading, but I hadn’t yet bothered to watch it. If you’ve been doing the same, here’s another chance:

Like Michael’s previous “Web 2.0″ video, it’s very well done - it extends and expounds on the notion that “ontology is overrated” - the title of a defining piece of “2.0″ thinking from Clay Shirky. Clay’s original article can be found here - if you’re trying to understand where all this Enterprise 2.0 thinking is coming from, It’s another great place to start.

Khoi Vinh very elegantly points out what’s wrong with enterprise software:

“Enterprise software, it can hardly be debated, is pretty bad stuff. The high-dollar applications that businesses use to run their internal operations … are some of the least friendly, most difficult systems ever committed to code.”

I don’t think that a truer word was ever spoken.

Jason Fried at 37 Signals chimes in with the notion that it’s because the buyers and the users are different people. I agree, but it’s more than having different user communities involved. Enterprise software is broken because of the way it is purchased. Having just come from the world of enterprise software, I know that most enterprise software is not designed to be used, it’s designed to be bought.

The sales cycle and sales model for enterprise software are among the most ridiculous ways I have ever seen anyone purchase anything, ever. Just to clarify, let’s try a Google experiment. I’m going to sneak over to Google right now, and search for some kind of RFT document (which is the primary purchasing vehicle for enterprise software.) Hang on…

Okay! A quick Google search for “RFT software solution filetype:doc” led me to this document detailing an enterprise software solution for the Irish Customs Service. Like most tenders, it’s a very long and very boring document. There are many, many, extraneous words in the interests of sounding official. Seasoned RFT response guys know that the real meat and potatoes of the document are usually buried at the very end in small print. In this case, it’s Appendix 9, the Requirements Response Table. It’s a giant table of things that the solution has to do. Let’s pick one of these things at random…

“Use the standard ITP Transaction Review (TR) workflow component to meet TR functionality. Please state how the solution will integrate with ITP TR, and what, if any, additional TR functionality is proposed, and how this will interface with existing ITP TR”

There are 128 requirements in this RFT just like this. What is the purpose of this requirement? What are the goals of the system? How will success be measured? There’s not a single comment anywhere in the document about usability, or how users might interact with the system.

It’s clear this RFT wasn’t written by or for users. (They don’t have purchasing authority.) Yet this is the primary buying document. In order to win the business, a vendor will need to answer every question as best they can.

So the whole process quickly becomes little more than a box-checking exercise. The vendors that win are not selected on their ability to understand or improve the business process or help the user community, but rather the ones that have a huge array of “features” that nobody ever uses. And the ugly truth is that these features exist only so that they can be written about in these responses.

At some point, some poor worker in an enterprise will actually try to use one of these “features” and discover this tragic fact. But by then, the vendor is usually long gone. It’s skipped off in a cloud of money into the next RFT process… And the completed RFT remains filed away as protection against criticism of the buying decision.

And after a few years of frustration, the purchasing cycle begins again.