This post originated from an RSS feed registered with Agile Buzz
by Martin Fowler.
Original Post: Bliki: UtilityVsStrategicDichotomy
Feed Title: Martin Fowler's Bliki
Feed URL: http://martinfowler.com/feed.atom
Feed Description: A cross between a blog and wiki of my partly-formed ideas on software development
One of the steady themes I've seen throughout my career is that
of the nature and importance of software development. Recently a
prospect told one of our salespeople that "software is like sewage
pipes, I want it to work reliably and I don't want to know about the
details". This is the kind of approach that Nicholas Carr talked
about in IT Doesn't
Matter.
On a contrasting note we've done work for many businesses where IT
has been a clearer strategic enabler to their business, allowing
them to enter new markets or significantly increase their market
share. So is IT a utility, like sewage pipes, or a strategic
asset?
I take that the view is that it can be either, depending on the
system. A classic example of a utility IT project is payroll,
everyone needs it, but it's something that most people want to 'just
work'.
So what is the distinguishing factor between utility and
strategic projects? To my mind it's all about whether the underlying
business function is a differentiator or not. If how you do this
function is a crucial part of what makes you better than the
competition, then the software that supports this function needs to
be as good as you can make it. Note that this distinction isn't
about the software, but the business function. As Ross Pettit puts
it "This is not a separation of IT by the nature of the
technology, but into what technology does for the host
business".
The most important point about this dichotomy is to realize that
there are two kinds of software projects and they need to be treated
entirely differently. The way you staff, run, and budget a
strategic project is entirely different to how you do a utility
project. Too often people assume that what is good for one is good
for the other - and trouble inevitably follows.
Another consequence is that only a few projects are
strategic. The 80/20 rule applies, except it may be more like
95/5. While certainly it's most common for people to not recognize
the dichotomy at all, it's also common for people to think that too
many projects are strategic.
One of the most important ways in which these efforts differ is
where the risks lie. For utility projects the biggest risk is some
kind of catastrophic error - you don't want the sewage pipe to
break, or to miss payroll. So you need enough attention to make sure
that doesn't happen, but other than that you want costs to be as low
as possible. However with strategic projects, the biggest risk is
not doing something before your competitors do. So you need to be
able to react quickly. Cost is much less of an issue because the
opportunity cost of not doing something is far greater than costs of
software development itself.
This is not a static dichotomy. Business
activities that are strategic can become a utility as time
passes. Less often, a utility can become strategic if a company
figures out how to make that activity a differentiator. (Apple did
something like this with the design of personal computers.)
One way this dichotomy helps is in deciding between building
custom software and installing a package. Since the definition of
utility is that there's no differentiator, the obvious thing is to
go with the package. For a strategic function you don't want the
same software as your competitors because that would cripple your
ability to differentiate.
Often people realize this and buy a package for a utility
project, but then spend huge amounts of money customizing this -
which is just as wasteful. My view is that for a utility function
you buy the package and adjust your business process to match the
software. Usually this is politically infeasible, so the workaround
is to put a low grade software team to work on it. Provide enough
care to avoid catastrophe, but otherwise you don't need a high-grade
team.
Another way the dichotomy makes its influence felt is the role of
agile methods. Most agilists tend to come from a strategic mindset,
and the flexibility and rapid time-to-market that characterizes
agile is crucial for strategic projects. For utility projects,
however, the advantages of agile don't matter that much. I'm not
sure whether using an agile approach for a utility project would be
the wrong choice, but I am sure that it doesn't matter that much.
Like many classifications, there's a lot of grey in between. Yet
this is one of those rare cases where I think there's a strong
argument to turn up the contrast and force more binary thinking. As
Ross commented in a discussion of a draft of this post: "'shades of
grey' give license to pile things into the wrong category; things
that are really utility will be given an inflated importance, rather
than dispositioned as the utilities they really are." Forcing a
binary decision, tilted to minimize what's in the strategic bucket,
would help provide the focus that's often lacking in IT initiatives.
Ross goes so far as to argue that there
shouldn't be a single IT department that's responsible for both
utility and strategic work. The mindset and management attitudes
that are needed for the two are just too different. It's like
expecting the same people who design warehouses to design an arts
museum.
To explore more...
Ross's
article calls for a Glass-Stegall of IT
departments.
Previous Topic
