Dave, a recent book I read, "IT Risk" by Westerman and Hunter, emphasizes "strengthening the base of the pyramid"--that is, building a standard architecture for data storage, messaging, redundancy, etc., as a key element to reduce the risk of IT solutions.

As you say, providing a standardized base also allows for much more responsive and useful applications to emerge.

What I draw from all this is that the future of application software providers may be dim indeed. And that's good, I think.

regards, John

Dave, as I reread this post, it is a really rich and nuanced mistake story. Would you consider reposting, photo included, to the Mistake Bank?

John

At risk of triggering some mutually referential time continuum vortex I'd just like to second the spirit of your post and refer to my own comparison between Sharepoint and Milton Keynes

This type of foolishness comes from confusing "risk management" with "take no risks." And taking no risks implies creating no value.

I see the point about risk avoidance and missed opportunity, and I'm not an IT manager. However, even though Sharepoint or any other enterprise level knowledge management/sharing application is expensive in upfront cost, to make your point effectively it seems to me you need to address "total cost of ownership" and demonstrate that such enterprise scale apps do not decrease that number relative to the opportunities missed.

Euan, the main danger may the total perspective vortex! Great minds think alike etc. Great point John

Larry the problem is that enterprise wide software solutions just don't work for social computing so the up front cost is a waste of money.

Euan, the main danger may the total perspective vortex! Great minds think alike etc. Great point John

Larry the problem is that enterprise wide software solutions just don't work for social computing so the up front cost is a waste of money.

Dave,
At the risk of being argumentative, the trouble is not with enterprise solutions. Like your pictured building, the troubles lie with traditional solutions and the traditional thinking that accompanies them. Or is it traditional thinking followed by traditional solutions, as the IT Director might have it?

Great architecture should be a good analogy for enterprise software. Consider what it takes for a showcase building - it is risky, controversial, hard to sell, and for most, downright ugly. Many projects fail, but the ones that succeed set new styles that are viable for a generation (e.g. buildings by Frank Lloyd Wright, Frank Gehry).

Great architecture grows on you. You keep going back to look, and you drag your friends along to see it too. You can't analyze it, although it is recognizable for being different and innovative.

Would that not be a decent indicator of social software success?

There's a "classic" 1999 7-page paper: http://www.google.com/search?hl=en&q=truex+klein+1999+growing+systems+in+emergent+organizations&btnG=Search which very concisely explains an approach that I use for my work. It works (for me, at least) but linear thinkers don't understand why.
Against: "Lengthy analysis and design are poor investments" (invest in iteration instead). "User statisfaction is improbable" (users can never be satisfied because their needs are always changing). "Abstract requirements are largely imaginary" "A labor-intensive review of the current situation is little more than a history lesson in past organizational states, and future requirtements are abstractions of obscure user guesswork about future organizational states". "Complete and unambiguous specifications are ineffectual". "New System projects denote ISD (Information System Design) failure: A new ISD project arises only from the utter failure of an existing computerbased IS."
In contrast, the paper proposes: Always analysis. Dynamic requirements negotiations. Incomplete and usefully ambiguous specifications. Continuous redevelopment. Adaptability orientation.
It works. But the corporate IT guys ... sigh.

Well to be argumentative Tony, I think in part the problem is with enterprise software (defined as single vendor trying to cover many fields). It was OK for manufacturing process and accounting, but not KM, Decision Support, Collaboration. Otherwise I think we are in agreement

loosely related anecdote: we still don't have an RSS reader for company-internal use that works. Nevertheless, for the tool where I am responsible I wanted to provide RSS feeds (export, write), which would not be too difficult to do. The problem is: they are working on guidelines which XML standard to adapt as "corporate standard". And these guidelines are not ready, since ages.
Which shows how misguided the whole approach is. In reality, the readers understand various writing standards, and the writers provide several "export" standards. So all is fine, you can combine most with most, and in the internet it works since years. But since the standards committees could not agree, internally ...
Which triggers another reminder: 20 years ago, there was an attempt to standardise variable names. So you had to write "For n=1 to 100" and not "For x=1 to 100". When will they every learn?

Christian and Dave,

Comparing notes, our corporate XML standard is circa 2000, and the next edition will be in 2010 or thereabouts. I can feel Christian's pain. Standards are mostly archeological artifacts that describe the buggy whips of their times. We are in violent agreement that corporate standards don't work. Yet they are valuable, because a single vendor's proprietary standards contributes to lock-in, and does not help with KM, Decision Support and Collaboration. There has to be a middle ground, in my opinion, that keeps an enterprise from favoring either extreme. Dave alludes to to that in his recent articles on a different URL (which escapes me at the moment). The title includes "small pieces;" how does the saying go?

Tony, agree on value of standards if they enable reuse and emergence of new things. The morse code. The sizes of the Europalette and shipping cntainers. html. Power plugs (missed opportunity - would have been nice). Or more abstract, and back to architecture where Dave started: In my company, there is a masterplan about the site, detailing e.g. height of buildings. But then there a rule that there has to be a different architect per building. Standards constrain in a meaningful way, and then diversity starts by different people working within an reasonably small, clear, not ovewheliming set of standards.

Whoops, the title is "Everything is Fragmented" and the articles are out on the KMWorld.com website. Dave has written a couple of articles on "fragmentedness" (my term, not his), which are collected at http://www.kmworld.com/Authors/AuthorDetails.aspx?AuthorID=2059

Christian and Tony

To compare notes again... For the past eighteen months I have been trying to build some social networking tools using Sharepoint (because that was all I was allowed to use), with no money and no people available for any customisation work. While we are a Microsfot shop, we generally do not have any budget for them to come in and design applications for us. Our IT guys barely understand how Sharepoint works.
Then, when it comes to RSS, our Helpdesk guys did not even know what it was when I rang them in January!!! (usual IT dept story, they upgraded some stuff on the network and all of a sudden their users RSS readers started falling over or getting buggy.)
Sharepoint has been very useful on some specific projects that we have worked on - as a doc repository it does most of what we want and it means we can show the door to all those vendors that keep sniffing around. But for km work, it is a nightmare.
I finally have approval to load some real tools like MediaWiki and blogs, although currently there is little impetus to do so.
So, what do we do? We work around the system. We have IT policies that would be classed as "light system constraints" and our engineers have been used to working around the rules for years. We can, and are, building a whole comunity outside the firm's network/firewall. Nothing too contentious there yet, but given time, there will be momentum. Yes, it would be better to use the VPN that is the backbone of our organisation, but we can not wait for that to catch up.
Christian - we should compare notes further, and more specific anecdotes - maybe via the ning site?
Talk to you later
Paul