Four Pillars: Thinking more about blogging and enterprise architecture

wren.thumbnail.jpg

If we accept that blogging is the opensourcing of ideas, then we need to expect returns from blogging that are consistent with opensource software. Let’s see how that plays out:

  • Opensource models are open to inspection and are consequently better designed through criticism and error and modification; opensource ideas should similarly reflect learning through conversation
  • Opensource models acquire best-of-breed characteristics through a democratised and intuitive “natural selection” process, a wisdom-of-crowds meets emergence and blink approach, learning through adaptation; opensource ideas should similarly reflect a mashing, a hybridisation, of different schools of thought
  • Opensource models also provide some element of future-proofing, since non-hierarchical routes are used to set priorities and resolve conflict, and only non-hierarchical routes can avoid past-predicts-the-future innovator’s-dilemma tunnel-vision nonsense; learning through discovery of new things rather than rehashing of old, in ideas as much as in software

I don’t know that I am right about this, it’s just the way I think about these things. Comments and flames welcome as usual.

StewartBrandArsElectronica.jpg

Stewart Brand

In this vein, I started re-reading one of my old favourites, How Buildings Learn: What Happens After They’re Built, by Stewart Brand.

0140139966L.jpg

How Buildings Learn

First time around, I really loved the book, but two ideas there kept resonating differently for me. One was really Jane Jacobs rather than Stewart Brand, but it was via Brand that I learnt of it:

Old ideas can sometimes use new buildings. New ideas must come from old buildings.

The second was pure Brand:

Temporary is permanent, and permanent is temporary.

I want to sample bits of those ideas and mash them up in the context of blogging and enterprise architecture. Let me try it and see what happens.

Taking what Brand says in an enterprise architecture context, what can I make of it? The more I build something to solve a specific problem, the more likely it is that it obsolesces. Because problems are not constant. So we have to solve for problem-solving, not solve specific problems. Teach a man to fish.
I guess it’s the architectural equivalent of hard-coding. We need to avoid making problems into layers of lock-in of this sort as well. What does it mean to have lots of temporary things, from a software viewpoint? Is that what David Weinberger’s Small Pieces Loosely Joined was driving at? Is that what Doc Searls’ D-I-Y IT was trying to get to? Are OSX widgets lots of temporary things? Or Firefox plugins? or even WordPress plug-ins?
These temporary spaces were permanent because their foundations were hardwearing and durable, their pillars and infrastructure were strong, there was simple access to core infrastructure, because they did not cost much, because they were high on function and low on frill, and because people there went about their jobs rather than postured about.

Maybe that’s what enterprise architecture should be aiming for.

I tried doing the same thing with Jane Jacobs, applying her new-ideas-old-buildings concepts to the world of blogs. Is an A List blogger an “old building”? Can I apply the “old” to reflect age or experience or both? What relevance does the statement have in the context of blogging?

And the nearest I could come to was the reported conversation between Doc Searls and George Lakoff where Lakoff, I think, described blogging as rolling snowballs downhill. [Doc, did I get this right?] You start them off, but you’re not in control, and yes you get a buzz, but no ownership, just the buzz if and when you see what happens to the snowball, or even snowballs, over time.

And talking about starting the snowballs off and not being in control, you should take a look at The Man In the Doorway’s post on precisely this, being in command but not in control, as he found the time to read Blink. Command is leadership and can happen even in emergent environments, does happen even in emergent environments. Command is not permanent but contextual.

Control, on the other hand, is hierarchical, permanent-and-therefore-temporary, rarely domain or context sensitive. Control is The Emperor’s New Clothes. Everyone knows it’s not there but no one says it aloud. If you need to have it you will never have it.

Let me know what you think