Wednesday, February 08, 2006

IT and intranet development

I'm on a mailing list called IntranetUX ; I've been involved off and on in intranet development since 1994, so it's as interesting to watch the evolution of expectations and technologies as it is for those of the "public" web. And I've recently begun a consulting contract for a company doing a very interesting intranet based on Flex /Flash with a Java/Oracle back end. So I'm finally writing about intranets as well as other technology issues.

The moderator of the IntranetUX group, Jeremiah Owyang, pointed out this blog entry by Patrick Cormier. Here's my response:

I'd agree that the capabilities he describes for IM (Information Management) are necessary, but disagree that they should be in a separate group. Here's why:

Traditional IT is about stability: robust and secure infrastructure, software licenses, regulatory compliance, sales recorded and checks paid, no foolin', no monkey business, no changes to anything without authorization.New technologies and applications threaten stability -- hence the typically ponderous pace of application development when it's done by IT. Requirements to the micro level before a line of code gets written, document, document, approve, approve.

But most organizations have a Chief
Information Officer, not a Chief Cables/Servers/Ink Cartridges Officer, and at the end of the day the CIO's job is to deliver the information to end users that they need, in a form they can use.

Agile Development -- eXtreme Programming et al. -- is not an irrelevant-to-non-programmers geek buzzphrase/fad du jour; it's about creating competitive advantage for the organization by delivering the new capabilities that end users need accurately, because it depends on direct, iterative contact with those users as part of the development process, and quickly because in the real modern world, a requirements doc written six months ago may well be utterly worthless.

So the CIO who aspires to live up to the title must incorporate IM thinking and people into IT, put those people into the closest possible contact with their clients, and embrace agile methodology in the context of still providing reliable infrastructure.

Two groups with conflicting goals will always compete for resources and control. When IT controls too rigidly, entreprenuerial business units will always try to roll their own solutions; when IM is the client-facing side of IT, there will be far less need for that, and the synergies Patrick suggests will also be possible.