The accidental structures of IT

By Andrew Clifford

IT architecture, organisation and decision making are a by-product of engineering necessity, not a conscious design to best serve the needs of business.

Last week I introduced a journey to show you a heretical view of IT in large businesses.

I want to start the journey by examining the structures we use in IT: the structure of technology, the structure of business applications, our organisational structure, and how we structure management decision making.

Historically, technology has been expensive and difficult to work with. We have developed ingenious ways of dealing with this:

• Different types of hardware to cope with different processing needs.
• Operating systems to simplify development and overcome differences between hardware types.
• High-level programming languages to overcome the difficulties of working with machine code and assembler.
• File systems and databases to manage data storage.
• Transaction processing systems and middleware to co-ordinate data processing and movement.
• Network protocols to simplify and standardise connectivity.
• Components and shareable layers, to reuse our investment and hard work.

On top of these technical structures we have built business applications. Where possible, we have built these into components and shared layers too.

These elements - hardware, operating system, programming language, database, middleware, network, components, layers - have supported the growth of IT and the spread of IT into every part of business.

These elements dictate the organisational structures we use. We split IT work into a business-technology continuum: business analysts, system analysts, programmers, system programmers. In another dimension we split our IT organisations by type of technology: different skills and different teams for different operating systems, programming languages, databases, architectural layers and business applications.

The complexities of IT also require a special approach to management and decision making:

• IT projects require the co-ordination of multiple technical components and resources, which makes IT project management as complicated as any type of project management.
• Shared hardware, databases, middleware and application systems mean that projects need to balance the needs of multiple stakeholders.
• Because we have an army of specialists, we need to schedule work carefully to avoid resourcing problems.
• Because we have built technology layers, we need to run IT-centric projects to manage upgrades and technology refreshes, and we need to balance the need for business and technology changes.
• The overall planning and monitoring of IT work can be a nightmare, and we need sophisticated approaches like project portfolio management to get a grip on the work.

IT is a complicated business. We have created technical, organisational and management structures to deal with this complexity. But most of the complexity can be traced back to our ways of dealing with the cost and difficulty of working with technology. We did not start with a blank sheet and ask "What's the best way of doing IT in large businesses?" Our approach and our structures have evolved through time as a response to the problems we have faced. They are a by-product of engineering necessity, in a sense just an accident of history.

Hopefully you are with me so far on our journey. Next week I will cover how IT structures create an alternative reality that has no meaning outside the IT organisation.

Subscription