CIO

Tractors, nuclear powerplants and the bleeding edge

  • Wednesday, 14 July, 2010
  • By:

It is common for organisations to select a major technology leader (such as IBM or Oracle) and ride their product development cycle.  On client I worked for stated that they would:

“not follow a ‘best-of-breed’ approach, but rather select a major technology leader (IBM)… This means we explicitly seek and accept the “80% solution” rather than trying to optimise for each and every possible requirement. …Shortcomings will be made explicit in order that we can escalate with IBM, and influence their product strategy”.

Influence the IBM product strategy.  Good luck.  This one-size-fits all approach to technology maybe appealing on paper, and certainly has its benefits, you recruit a certain type of developer who has skills in that technology stack, if you are big enough your buying power may get a small voice in future releases that you will pay through the nose for.  But is it the best approach for the business?  A colleague, Stuart Hogg, takes three metaphors for enterprise IT.  The tractor, the nuclear power plant and the bleeding edge.

The tractor. This is the technology that keeps the lights on.  It is commodity software, it is the HR system, email, intranet etc.

Nuclear powerplant. This is the (generally bespoke) mission critical software that drives the business.

The Bleeding edge. This is the platform where you do cutting edge stuff, test and learn.  The ideas may one day be migrated to the nuclear powerplant.

All too many organisations get confused between these three models, loose sight of where they should be investing and plump for a one-size-fits-all technology to do all three.  Thus we see tractor technology trying to do the bleeding edge (Is it possible to innovate at speed with those Big Enterprise Solutions?)  By trying to combine utilitarian computing with strategic and speculative innovation, using the same skillsets, timeframes, processes and models, IT will never truly deliver the value for which it is capable.  Another ThoughtWorker, Ross Petit reiterates this point using a banking metaphor of utilitarian retail banking and speculative investment banking. He divides IT into “utility”, around 70 percent of IT investment (tractor and the nuclear powerplant); and “value add” the other (bleeding edge)30 percent.   Like other utilities such as electricity and water, ‘you don’t typically provide your own. You plug into a utility service that provides it for you’.  In IT that means SAAS and outsourcing and taking a strategic decision to differentiate between the different functions that IT performs.  He concludes:

Separating utility from value add will make IT a better performing part of the business. Because they’re comingled today, we project characteristics of “investment” into what are really utilities, and in the process we squandor capital. Conversely, and to ITs disadvantage, we project a great deal of “utility” into the things that are really investments, which impairs returns.

As a business function, IT has no definition on its own. It only has definition as part of a business, which means it needs to be run as a business. The risk tolerance, management, capabilities, retention risks, governance and business objectives of these two functions are vastly different. Indeed, the “business technologist” of value added IT needs a vastly different set of skills, capability, and aptitude than she or he generally has today. Clearly, they’re vastly different businesses, and should be directed accordingly.

Separating the utility from the value add allows us to reduce cost without jeopardizing accessibility to utility functions, and simultaneously build capability to maximize technology investments. Running them as entirely different business units, managed to a different set of hiring expectations, performance goals, incentive and reward systems, will equip each to better fulfill the objectives that maximize their business impact.

Sounds like a case for agile

  • Tuesday, 21 October, 2008
  • By:

..CIOs will be expected to become more and more strategic, delivering greater productivity gains while at the same time ruthlessly cutting costs. There will be a heightened debate about the role of IT in the enterprise. (ComputerWorld)

OK, so we can either spend months writing documents before a line of code is written. Do some application development then manually test what we’ve built and fix the bugs before eventually going live (late and over budget and not to the customers satisfaction).

Alternatively we could get more strategic and focus upon what value we can deliver in the shortest period of time. We could better align IT with the enterprise by delivering early and often, enabling us to test and learn from the enterprise as we go. We could adopt a more ‘just in time’ approach to requirements (whilst starting with a clearly defined vision from the outset). We could build testing into the development to lessen the bugs at the end, we could do automated testing (to ruthlessly cut manual testing costs). Downturn sounds like a case for agile.

.

The best CIOs don’t care about IT

  • Tuesday, 15 January, 2008
  • By:

One of the (many) things about ThoughtWorks developers is that, whilst they are passionate about technology, (and will happily argue for hours amongst themselves about the relative merits of REST over SOAP or ruby on rails over django), more often than not when they start a conversation with a client, technology will be at the back of their mind. I think it is safe to say that generally the primary driver in the ThoughtWorks mind is business value:

  • Why are we building this application?
  • What are the business objectives?
  • What will deliver the greatest value in the shortest timeframe?

Once the requirements of the business are understood, and framed in terms of their business value, then (and only then) should we turn to the technology. This can often be a challenging message; IT professionals like to think in terms of architecture and platforms, yet often these constrain the ability to truly deliver what the busines really needs.

The development team may be a Java shop and only does Java, yet the end users live in a world of Microsoft. So what happens – IT develop user interfaces that expose data in a web browser only for the business users to copy and paste it into the tools of their trade – Microsoft Office. And because IT only do Java that’s the way it has to be.

Value is lost in this thinking. It is easy to argue on the cost to expand the team requiring new skills by introducing .net into the architecture. But what is the cost to the business of time spent through inefficient work practices? All to often IT is an end unto itself, rather than the means. IT needs to remember it only exists to enable organisations. The most refreshing CIOs are those that recognise this. Those who focus upon delivering business value and question every big decision – what value is this giving to the whole organisation rather than thinking in terms of their IT silo. In fact, the sort of way that ThoughtWorkers think.