Enterprise IT: How Many Are Doing It Wrong
Tim Bray on how so many are doing Enterprise IT wrong, most notably not learning anything from the dynamic language web culture and the small, light, simple, iterative mindset of modern web dev shops:
Here’s a thought experiment: Suppose you asked one of the blue-suit solution providers to quote you on building Ravelry or Twitter or Basecamp. What would the costs be like? And how much confidence would you have in a good result? Consider the same questions for a new mobile-network billing system.
The point is that that kind of thing simply cannot be built if you start with large formal specifications and fixed-price contracts and change-control procedures and so on. So if your enterprise wants the sort of outcomes we’re seeing on the Web (and a lot more should), you’re going to have to adopt some of the cultures and technologies that got them built.
It’s not going to be easy; Enterprise IT has spent decades growing a defensive culture based on the premise that you only get noticed when you screw up, so that must be avoided at all costs.
I’m not the only one thinking about how we can get Enterprise Systems unjammed and make them once again part of the solution, not part of the problem. It’s a good thing to be thinking about.
And Rafe over at RC3.org has an interesting ancillary:
The first question everyone should ask when thinking about building custom software is, does building this give me a tangible strategic advantage over the competition? Specifically, does it provide enough of an advantage to make up for the amount you’ll spend on initial development and on maintenance and improvements going forward. Account for the fact that packaged software will likely be improving over time as well, so your custom solution may be great today, but the feature set in the packaged solution may blow away what you have two years down the road.
In a past life I worked for a software vendor that developed datacenter-class application management solutions. I saw firsthand the oceanic requirements docs each major release generated. I saw the flailing as each functional area gathered and tried to assemble a coherent final requirements package for the strategic GA release. I saw confusion prevail, clarification meetings spawn from every corner, and directional doubt set in. I saw routine 6-8 month delays from the projected GA date. I saw the beta product get its doors kicked in the minute it got outside the sandbox of a controlled environment.
Yet, during all of this, I heard everything you’re supposed to be saying as you swim upstream against traditional enterprise development: agile, extreme, ‘crossing the chasm’ – you name it, it was bandied about. Geoffrey Moore was an organizational hero for a while, right up to the point the next populist development idiom came down the chimney.
Never in a million years could that culture, process or team produce a Twitter, Facebook, TripIt or Posterous.
And that’s not to say there aren’t web failures; there are. Many of them. But I suspect web failures happen because not only does a company have to conceive solid technology very quickly, but it also must scratch and claw for user adoption (customers) in perhaps the most competitive market of them all: webland. Enterprise IT projects get aircover from additional investment dollars, support, training and maintenance.
Just some thoughts.
But as fledgling as some of these realizations may be, Bray and Rafe are onto something that might be perhaps the most pronounced IT development trend this decade. Nicholas Carr crystallizes it in The Big Switch as he extols the the coming cloud upheaval. And smart enterprises are beginning to see that if they want web-like project results (and they should), they need to adjust not only their technologies and dev process frameworks, but also their cultures.
Through all of this, I’m thinking that Gall’s Law is more prominent than ever these days.
