When IT doesn’t matter

April 12, 2007 / / No Comments

I’m currently reading ‘The Labyrinths of Information: Challenging the Wisdom of Systems‘ by Claudio Ciborra. I haven’t gotten very far through the book yet, it is written in an academic tone which always slows me down. But early on, I stumbled across a very interesting point of view.

IT architecture is popular topic right now. You can get enterprise architects, software architects, infrastructure architects, information architects… the list goes on. One of the focus areas for architecture is the adoption of standards and consist methods for the design, development and deployment of IT systems. All sounds very sensible and measurable.

But Claudio makes a simple observation that suggests such architecture doesn’t matter, in that it does not help an organisation to become successful. Instead, architecture is a simple necessity of doing business digitally. This argument concurs with Nicholas Carr’s controversial article (and subsequent book) ‘IT doesn’t matter‘

A sample from the book: (note – SIS refers to strategic information systems)

“…market analysis of and the identification of SIS applications are research and consultancy services that can be purchased. They are carried out according to common frameworks, use standard data sources, and, if performed professionally, will reach similar results and recommend similar applications to similar firms.”

So what do you need to do to become an innovative company? Claudio suggests:

“…To avoid easy imitation, the quest for a strategic application must be based on such intangible, and even opaque, areas as organisational culture. The investigation and enactment of unique sources of practice, know-how, and culture at firm and industry level can be a source of sustained advantage…

See, I have been telling those techie-oriented IT folk for years, collaboration and knowledge sharing are far more important than your boring transaction-based systems 🙂

…Developing an SIS is much closer to prototyping and the deployment of end-user’s ingenuity than has so far been appreciated: most strategic applications have merged out of plain hacking. The capacity to integrate unique ideas and practical design solutions at the end-user level turns out to be more important than the adoption of structured approaches to systems development…”

Sounds like an argument in favour of mash-ups and wikis to me. See also: Let’s make SharePoint dirty

How buildings learn

December 4, 2006 / / No Comments

I had come across several recommendations to read ‘How Buildings Learn‘, by Stewart Brand, during the past year and finally picked up a copy of the book. Here are some snippets to (hopefully) help explain the valuable lessons this book can teach the IT industry, particularly the newer architect-style roles that are cropping up (enterprise-, solution-, software-, system-, information- etc.):

“…Almost no buildings adapt well. They’re designed not to adapt… But all buildings (except monuments) adapt anyway, however poorly, because the usages in and around them are changing constantly… Architecture, we imagine, is permanent. And so our buildings thwart us.”

The book describes the concept of time layering and its relevance to buildings. The six layers (simplified here): SITE (geographical setting, duration: eternal); STRUCTURE (foundations and load-bearing elements, duration: 30 – 300 years); SKIN (exterior surfaces, duration: 2o years); SERVICES (inner workings of the building – wiring, elevators, etc., duration: 7 – 15 years); SPACE PLAN (interior layout, duration: 3+ years); STUFF (furniture and movable items, duration: mobile).

“…Ecosystems could be better understood by observing the rate of change of different components. Hummingbirds and flowers are quick, redwood trees are slow and whole redwood forests even slower. Most interaction is within the same pace level. The dynamics of the system will be dominated by the slow components… The same goes with buildings. Site dominates structure (location determines foundations), which dominates skin, which dominates services etc.”

Interestingly, the reverse becomes true in extreme situations.

“Ecologist Buzz Holling points out that it is at times of major change in a system that the quick processes can most influence the slow.”

New ‘stuff’ (e.g. replacing desktop computers with laptops, wireless technologies, switching from individual working in cubicles to group collaboration in open plan environments) may demand adjustments to space plans and services. And the need to change services can even result in the premature demolition of buildings. This issue leads on to some interesting comments that IT solution architects should consider:

“An adaptive building has to allow slippage between the differently-paced systems of site, structure, skin, services, space plan and stuff. Otherwise the slow systems block the flow of the quick ones, and the quick ones tear up the slow ones with their constant change. Embedding the systems together may look efficient at first, but over time it is the opposite… and destructive as well.”

The book recommends an alternate approach to traditional building methods: the use of scenarios:

The benefits of scenario-planning are simple – design a building/system to accomodate multiple different possible outcomes. This can help avoid the problems that occur when the designers idea of expected use does not match the actual use.

There is another book that follows this theme, applying it to the design of everyday things and how we conform to, or adapt, their purpose: ‘Thoughtless Acts?‘ by Jane Fulton Suri + IDEO

Practical planning

February 15, 2006 / / 2 Comments

Having been buried in a couple of customer projects for the past few weeks, yesterday morning the sun was shining and I finally had time to ride one of the horses… and naturally spotted some similarities between riding and the projects…

Both projects involved reviewing and updating existing information systems – one focused more on content management, one focused on collaboration, both introducing new working methods into the organisation. And introducing new methods means introducing change.

Project number 3 – Harry, the horse I was riding – shares this last point. Harry has been rested for over 6 months and is unfit with a thick winter coat and not much muscle – looks more like a seaside donkey than the show jumper pictured on my Contacts page. This was our first session together, and the rider’s condition is not much better than the horse, with the exception of the hairy coat 🙂 Some serious change is required.

When you bring a competition horse back into work after a period of rest, you go through three initial steps:

    • assess the current condition of the horse: fitness, muscle tone, suppleness

 

  • estimate time to first competition (how much work is required before we’ll be ready for our first event)

 

 

  • identify target competition (the first ‘serious’ event we want to aim for)

 

 

1. Assess current condition:

The only way to do this is to get on and ride, discover what works and what doesn’t. Despite the long rest, Harry went better than expected. Completely unfit, (clipping scheduled for the weekend, goodbye hairy coat), muscle tone not great but not bad, and suppleness is still there (thanks to his breeding – part Lusitano, the breed of horse traditionally used in Spanish bull fights and they are naturally very agile)

2. Estimate time to first competition

Thanks to his suppleness, we’ll get to a competition earlier than with other horses as long as we do some basic fitness and muscle work. Provided he’s ridden regularly, we’ll be ready to start competing in about 4 weeks (normally it would be 6 – 8 weeks)

3. Identify target competition

Here in the UK, we have a Winter National Championships held in April, and he would be ready by then… unfortunately, qualifiers run from October through to 2nd week in March. I should have started 6 weeks ago because we aren’t going to be ready in time for the last round of qualifiers. In a word – tough. The Winter champs are out, so we’ll focus on preparing for the Summer season. The first major outdoor show we usually go to is Leicester County show, held over May Bank Holiday, so that’s our target. Our stretch target will be the Royal Windsor Horse Show, held 2 weeks later with an annual championship class that we will be eligible for this year… and it’s held in Queenie’s back garden, – it’s a cool show to be at. Our ‘quick win’ target will be to compete in the warm-up classes at the Winter champs, that don’t require pre-qualification.

And there’s a fourth step that spans all three – me. As the rider, I also have to commit to change – I’m not much use to Harry if I’m unfit and slopping about the saddle like a sack of potatoes, and I’ve got to be prepared to put in the time and effort riding him – he won’t put his own saddle on and exercise himself in the arena.

So what does all that have to do with I.T. projects? … 🙂

1. Assess current system

Too often, organisations fail to assess what they’ve already got before implementing new systems. I highlighted this in ‘why is KM so difficult?‘. You need to know what you are working with – existing solutions should be examined and a decision made regarding their role in the new system. Understand what those existing solutions actually do – what works and what doesn’t. And don’t guess, don’t make assumptions – find out for real (example: I.T. dept “our people just use Office for basic stuff, word processing and the like”, Accountant: “yup, we pretty much run the business off these 14 spreadsheets…”, Me (on investigation) “you mean, those 14 spreadsheets linked to 100+ other spreadsheets and a handful of databases?”)

Just like with horses, you can’t build an accurate plan if you don’t truly know your starting point.

2. Estimate time to first milestone

How long will it take to provide something (anything) for the business to try out? I often get strange looks from I.T folk when I ask this one. The usual plan is to spend an inordinate amount of time designing the taxonomy, process and other gumpf, and then launch the perfect, tightly controlled, system upon the end-users, perhaps with a small managed pilot along the way. And wonder why it gets ignored as people carry on doing their work as normal…

If there’s one thing I’ve learned over the years with knowledge-based systems, they rarely get used the way you anticipated. You need to test them live, in their real working environment, and then tweak based on the results. With horses, you don’t really know how well the training plan is going until you’ve completed your first competition. Sure, you can hire out an arena and school round a set of show jumps, but that’s just a pilot test. The first competition is the real milestone – seeing how we perform under show conditions. The same is true for many I.T. projects – the sooner you get a live test, the better. A pilot is just a practice run, it’s not real.

3. Identify the target achievement

Most I.T. projects have an end goal, a vision to be achieved (and hopefully a benefits case to prove some return on investment). That’s all fine and dandy, but knowledge-based projects are not 5-minute affairs. They take time to bed-in and become a seamless part of the organisation. A target set 2 years in the distance will seem a long way away at the start of the project. I’ve got an idea where I want Harry to be competing in 2 years time, but to get there I need to focus on the here and now. The same can apply to I.T. projects – identify a strong short-term target to focus your efforts and demonstrate significant value to the business at the earliest possible opportunity. But don’t get all giddy and excited about ‘ideal’ targets. Be tough, focus on what can be done, not what you’d like to do. (Just like I have to accept I’ve left it too late to qualify for this year’s Winter champs.)

Once you’ve got your first big target and your initial milestone, look for the quick-wins – goals that can be achieved along the journey that serve as regular check points that the strategy is on track. Quick wins help maintain momentum and commitment to the changes being introduced – they also provide instant feedback that can help adjust the plan if needed.

And as for that fourth step – I.T. projects cannot be successful on their own, they need the organisation to be fully committed to the change being introduced. Without support across the organisation, any new knowledge-based system is at high risk of failure. Just like with horses – whilst it is the horse that has to do the jumping, the rider has to commit to presenting the horse at the right jump, at the right pace, and at the right time. It’s a partnership.

See, I keep telling people that working with I.T is just like working with horses 🙂

…and then it all goes horribly wrong