It’s amazing how resilient basic IT organizational design has been in the face of change.
From residual CIO offices (where everything is outsourced) still laid out as “the infrastructure maven”, “the solution delivery manager”, “the policy guy”, and so on to sophisticated global IT groups that, once you peel away a veneer of corporate program management, vendor management and the like still have 85% of their resources in “operations”, “development”, etc., we continue to stick to the model for IT that has been in effect since the early 1970s.
Since then, we’ve put networking in with operations and called it Infrastructure, and we split away some design work and created Architecture, and in some cases we’ve made a go of Client Relationship Management … but otherwise a visitor from the early days of in-house mainframes running the very early online transactional systems would find him- or herself right at home.
All things come to an end, however, and for the traditional IT organization the end is at hand. Here’s why.
The underlying premise of traditional organization was that we needed to conserve IT’s knowledge of the business.
To do this, we kept teams together: they would build an application, then maintain it and expand it into posterity. Once home-grown code, for many this is now package implementation, but the structure remains the same.
Not only does this structure reinforce the idea that the IT portfolio does not need managing, that “software has an unending usefulness”, and that there’s no economic barrier to continuously opening up code and making modifications to it, but it also reinforces the idea that these units are about skills.
This “field service” group has all the applications for this area of the business — which all just happen to be residual mainframe applications in COBOL & CICS or PL/1 & IMS. This other group looks after finance, and spends its time mucking around with SAP. Owning a portfolio like this and organizing around it in this way is great for job security, and lousy for progress.
(The situation is often the same on the Infrastructure side of the house, where each platform has its own team, with an overlay of “system management tools” to see the infrastructure as a whole.)
The spin-out groups: Client Relations, Architecture, and the Project/Program Office, often become the “opponents” of the traditional IT organization still down at the roots.
Worse still, each of these has legitimate reasons to go to the business — as do the development heads (to their “aligned” business areas) and infrastructure people (in their service and implementation roles). In enterprise after enterprise I see the same thing: business leadership which is frustrated and deeply confused about who in IT to talk to.
I think IT will be primarily, in future, a consultancy, divided into practice areas.
Some of these are subject to decisions as to how to do the work: do you run your own infrastructure or do your own portfolio maintenance, or do you hire another firm to do it for you?
Some specialize in aspects that are “about the business”, but are focused on particular skills: change deployment and integration, for instance, or process modelling.
Others are a build-to-order “factory” run akin to product development efforts in a software company: their model is a Service Oriented Architecture and the populating of the layers needed to build up to or integrate business solutions.
Another is engaged in retrofitting: allowing yesterday’s portfolio to play in tomorrow’s world (until the elements of that portfolio are all replaced).
Client Relations becomes the true expert on the business in the sense of driving demand for IT services: they are the equivalent of the “partner in charge of an account” at a major consulting firm.
With this model, the team-by-platform, team-by-tools, or team-by-historical-application fade to black. Yes, even if you want to go there today it will take a few years: transitions that step beyond a forty- to fifty-year model don’t come easily. But it’s where IT is going.
Or else, “IT is going”. What it is today in far too many places is something that can be bought cheaper elsewhere — and will be.