Ben Metcalfe on Web 2.0 doesn’t work in the mothership, but…

More help on the theme that I am pursuing for the upcoming Collaborative Technologies Conference 2006 from Ben Metcalfe:

[from Web 2.0 doesn’t work in the mothership, but…]

So let’s me start by putting my flag in the ground: Yes, I do think “Web2.0 stuff” (however you choose to define it) has a place in big business/enterprise/etc. But I don’t think it can occur as part of the enterprise itself. (caveat: unless that enterprise is already working a radical way unlike other 99.9% of enterprise setups in existence)

I’ve worked and developed in an enterprise environment. It’s a slow, methodical, complicated business. It has to be. Generally speaking enterprise systems are expensive to develop, require high reliability and have complex architectural and stakeholder structures.

This is not how “Web2.0″ works, but you didn’t need me to tell you that – it’s kind of obvious. Oh, and whether you like it or not, you will always have enterprise systems – the world will always need massive, sophisticated systems.

These systems tend not to suit the aspects of Web2.0 such as social software, rapid development and the permission to experiment with the potential of failure (albeit failure fast).

So if you want to add a bit of “Web2.0″, my quick and straight-to-the-point suggestion is to do your “Web2.0 stuff” in a satellite operation at arms length from the rest of your operation.

Define the goals, create a team of suitable* people and set them free away from the constraints of your enterprise.

[...]

But think about it – do all your projects really need to be that integrated to your enterprise systems? Are there opportunities where a small set of the right APIs could allow suitable projects to be given a greater freedom to evolve organically and take a direction different to the rest of your operation?

Ben is hinting at a serendipitous discovery of the bottom-up nature of web 2.0 apps, and how they can wend their way into the enterprise, a project, or a team at a time.

And the larger question -- whether the enterprise would be more agile, more adaptive, and more of a survivor is it could somehow break away from the need for slow-to-change applications that span the needs of many departments, beholden to many but satisfying none -- has not really been addressed by Ben or the others I am interviewing on the on ramp to CTC 2006.

My gut says yes. Enterprises would be better off if their IT departments could move to small, low cost, web-based apps that satisfy local needs -- a project group, one campus in Denver, the marketing department in Japan -- without having to subordinate local needs to corporate controls. The benefits of enterprise standardization are measured in the IT budget, but the true costs are distributed thoughout the enterprise: less collaboration in the research team leads to slower innovation, a less-thatn-intuitive UI for the sale staff in France leads to lowered sale numbers, and a heavyweight finance solution that slows down invoicing costs serious bank in collection time. This is one of the reasons that ROI studies fail for social tools: the effects are so diffused that ROIs fail to reach far enough.

But Ben's advice is still dead on. Any one else trying to roll out Web 2.0 apps the way Ben outlines?

tags: ben+metcalfe, web+2.0, ctc2006, web+2.0+enterprise

Comments

[/pd]

yes, there are folks out there looking into the echo chambers and creating paradigms that echo's Ben's thought process..'nuff said :)-

[Alex Hutton]

We've been developing an application for enterprise clients. We wanted to put "Web 2.0" into the application, and to us that meant new technology (RoR & Ajax), collaboration, and, to a lesser extent, aesthetic. In terms of your definitions, we were definitely developing an application for a small subset of the enterprise, (40 out of 40,000) but that would have a critical impact on decision making.

We've had to compromise on both the technology and collaboration front. We were faced with a situation where some customers would not allow anything but Java web apps in their IP space, and other clients would only deploy .NET. We created a RoR/MySQL application on a box and called it an "Appliance", followed an SAS model without calling it such (we got creative about being within the network perimeter) and worked around those political issues. I think this really is the way to approach the problem - not letting the customer define too much outside of critical functionality. Going Agile with only the most necessary input is much more preferable to us than Waterfall with overly sophisticated design documentation.

Of course, we were in the position of saying, "We have software that will do XYZ", vs. someone coming to us and saying, "We want software that will do XYZ, please answer this RFP". If the situation is actually the latter, my take is that the enterprise will always choose the most bureaucratic option (i.e. a $300k Java/.NET application with a nine month development cycle over a $80k RoR application that does the same thing, but with a 4 month development cycle). There are multiple reasons for this in my mind, like perception of cheapest bid, preference of internal developers, the Waterfall "speaks" to Project Managers better, etc...

We had to actually remove collaborative parts of the application. Many corporate policies say "no" to things like online forums, and whatever application you build that could be construed as "forum-like" in those environments will be shot down. Anything that could be construed as polling is subject to HR/Marketing/Legal. We knew that the concept of democracy would be antagonistic to the enterprise, but we figured we could package it as "productivity". Those trained on concepts that the application helped facilitate should be "mentoring" other users, and we thought that they should do so online so that future users could reference the answer. Well, it was a good idea...

What we did get to keep was "tagging", but really using meta-data isn't so revolutionary.