Author: JP

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.

Thanks to John Wilson for letting me know about this conference. If any of you is interested, there’s still time to register.

I intend to attend the following sessions:

• Take Control of Your Team’s Decisions NOW! by Ken Schwaber
• Avoiding the Seven Pitfalls of Lean by Mary Poppendieck
• Pair Managing: Two Managers per Programmer by Jim Highsmith
• Two-Phase Waterfall: Implementation Considered Harmful by Robert C. Martin
• User Interaction: It Was Hard to Build, It Should Be Hard to Use by Jeff Patton
• FIT Testing In When You Can; Otherwise Skip It by Ward Cunningham
• The Joy of Silence: Cube Farm Designs That Cut Out Conversation by Alistair Cockburn

There’s something in it for everyone, and it comes well recommended. Do cascade the information to others who should attend.