Month: February 2007

Those of you who’ve made the time to read the kernel for this blog will be familiar with the phrase “connected not channelled”….. that’s what came to mind when I read John Battelle’s fascinating interview of Michael Wesch of That Video fame.

Here are the quotes I really identified with:

For me, cultural anthropology is a continuous exercise in expanding my mind and my empathy, building primarily from one simple principle: everything is connected. This is true on many levels. First, everything including the environment, technology, economy, social structure, politics, religion, art and more are all interconnected. As I tried to illustrate in the video, this means that a change in one area (such as the way we communicate) can have a profound effect on everything else, including family, love, and our sense of being itself. Second, everything is connected throughout all time, and so as anthropologists we take a very broad view of human history, looking thousands or even millions of years into the past and into the future as well. And finally, all people on the planet are connected. This has always been true environmentally because we share the same planet. Today it is even more true with increasing economic and media globalization.

My friends [……..] are experts in relationships and grasp the ways that we are all connected in much more profound ways than we do. They go so far as to suggest that their own health is dependent on strong relations with others. When they get sick they carefully examine their relations with others and try to heal those relations in order to heal their bodies. In contrast, we tend to emphasize our independence and individuality, failing to realize just how interconnected we are with each other and the rest of the world, and disregarding the health of our relationships with others.

So if there is a global village, it is not a very equitable one, and if there is a tragedy of our times, it may be that we are all interconnected but we fail to see it and take care of our relationships with others. For me, the ultimate promise of digital technology is that it might enable us to truly see one another once again and all the ways we are interconnected. It might help us create a truly global view that can spark the kind of empathy we need to create a better world for all of humankind. I’m not being overly utopian and naively saying that the Web will make this happen. In fact, if we don’t understand our digital technology and its effects, it can actually make humans and human needs even more invisible than ever before. But the technology also creates a remarkable opportunity for us to make a profound difference in the world.

That’s why our battles on identity, intellectual property rights, digital rights and the use of the internet are so crucial. If we get the battles right, we can really make an impact. But only if we get them right.

James McGovern asks How Come Enterprise Architects Don’t Embrace Agilism?

It’s a question that’s troubled me for many years now; it belongs to the same class of question as How Come Everyone Hates Architecture Groups But Wants To Hire The Architects and How Come Enterprise Architects Hate Bus Architectures?

Five reasons:

• The dinosaur power of the silo, be it departmental or functional
• The continuing fear, across the enterprise, that standardisation somehow leads to lack of flexibility
• The lack of expertise in process design and management, again across the enterprise
• Executive-level unwillingness to consider enterprise architecture as strategic, and the consequent fossilisation of architecture groups
• Incapacity of current enterprise IT funding models to reflect the creation, consumption and operation of reusable components accurately

Applications by themselves aren’t agile. Architectures by themselves aren’t agile. But they can enable business agility. [Note: For those who are interested, I would recommend the Ross/Weill/Robertson book on Enterprise Architecture as Strategy].

A business can be agile. If its people, processes and partners are themselves agile.

Right now, enterprise agility is hard to come by anywhere you look. The battle between professions is set to continue, we are not yet at that point of consilience. As a result, we have less-than-perfect models of partnering and outsourcing, with political intent often foreshadowing pragmatic value. The consequence of this is that processes are broken dried-up spaghetti, which suits the silo troglodyte.

Generation M will change all that. Tomorrow’s employees will not put up with the organisational treacle that is seen as normal today.

To be continued.

The latest issue of The Economist has an interesting leader called “The end of the cash era”. One of the themes picked up by the article is the power of anonymity, the anonymity inherent in cash. Elsewhere in the article, the writer speaks of the current tendency to trade privacy for some form of implied convenience.

Those of you who have heard me speak at conferences would already be familiar with some of my views on privacy, particularly the difference between eastern and western conceptions and views.

What intrigues me about the article is its coda. I quote:

As Adam Smith would no doubt have observed, just because the state can pry into electronic cash does not mean it should.

I think this is important, and at the heart of many digital debates, including DRM and Identity: Can versus Should.

Region coding on DVDs is a classic example of someone doing something incredibly stupid because they could. Illegal capture of clickstreams is another.

When I first read Lawrence Lessig’s Code, my biggest takeaway was the potential loss of liberty.

We have to be careful. Careful to ensure that the individual, the “customer” of the state, has his rights protected. That information about intentions and behaviour and preference and attitude and expenditure patterns and earnings and and and, are all protected. Otherwise governments will do their equivalent of region coding. Because they can. Not because they should. In fact, because they shouldn’t.

More later.

The blogosphere delights me. I think it’s wonderful, the way things can emerge as a result of different perspectives and experience and ideas acting on the same “theme”. Let’s take a simple for-example:

A short while ago I was musing over a classic problem to do with Agile: the traditional human desire for predictability, how that often influences the creation of flawed plans, how it is that the flawed plans then get funded, and the consequent militant standoff between the Plan and reality. I shared my belief that the thing we had to change was the “contract”. I referred to some work done many years ago by Alistair Cockburn, meandered towards some other stuff (on incomplete contracts) done by Erik Brynjolfsson, and suggested that the answer may lie in something we have yet to see work commercially, a software development contract based on option theory.

A reader I’ve never met (and I’ve met a goodly number), Andrew Ochsner, then commented on how he had been looking serendipitously at something similar, and referred me to a paper by Kent Beck on Optional Scope Contracts. [Thank you, Andrew]. Now I’d read the paper before, but with the blogosphere, I don’t have to go through the process of remembering it, trying to find it, checking its relevance and then publishing its availability. There’s a community that does that, focusing on subjects we care about, but, importantly, subjects we do not necessarily have the same opinions about.

I’m still working my way through Kent’s paper, but what intrigues me is the implication of making quality a constant. For quality read customer satisfaction. For contract read covenant. Suddenly I get very very interested.

A note about contract versus covenant. In a contract, at the slightest sign of trouble, you look for “recourse”. A contract tells you how to punish the other person if something goes wrong. In a covenant, at the slightest sign of trouble, you look for “repair”. A covenant tells you that the two of you will work something out, not sue each other.

The relationship between developers and “the business”, in an Agile setting, must be a covenant. Not a contract. And the common theme that binds the two parties together must be customer satisfaction.

More later.