Enterprise systems: "Time to stop the madness"

Enterprise systems: "Time to stop the madness"

Summary: Tension between waste and ubiquity creates a love-hate relationship among those who recognize the need for large systems and folks who consider them inefficient relics of a bygone era.


Despite frequent association with large-scale waste and failure, enterprise systems form a critical part of the global economic infrastructure.

The tension between waste and ubiquity creates a love-hate relationship among those who recognize the need for these systems and folks who consider them inefficient relics of a bygone era of computing.

A thought-provoking post by Tim Bray (respected Internet pioneer, entrepreneur, and one of the inventors of XML) discusses tensions inherent in large systems. Tim highlights important aspects of the problem and does a good job laying out the conundrum of large enterprise systems.

With Tim's permission, I'm reprinting his post on this subject, which is called Doing It Wrong. Tim takes a strong position on the need to address these issues:

I don’t know what my future is right now, but this seems by far the most important thing for my profession to be working on.

Please comment with your view of this issue, which I believe is of fundamental importance to the future of enterprise software.



by Tim Bray

I work at Sun Microsystems. The opinions expressed here are my own, and neither Sun nor any other party necessarily agrees with them.

Enterprise Systems, I mean. And not just a little bit, either. Orders of magnitude wrong. Billions and billions of dollars worth of wrong. Hang-our-heads-in-shame wrong. It’s time to stop the madness.

These last five years at Sun, I’ve been lucky: I live in the Open-Source and “Web 2.0” communities, and at the same time I’ve been given significant quality time with senior IT people among our Enterprise customers.

What I’m writing here is the single most important take-away from my Sun years, and it fits in a sentence: The community of developers whose work you see on the Web, who probably don’t know what ADO or UML or JPA even stand for, deploy better systems at less cost in less time at lower risk than we see in the Enterprise. This is true even when you factor in the greater flexibility and velocity of startups.

This is unacceptable. The Fortune 1,000 are bleeding money and missing huge opportunities to excel and compete. I’m not going to say that these are low-hanging fruit, because if it were easy to bridge this gap, it’d have been bridged. But the gap is so big, the rewards are so huge, that it’s time for some serious bridge-building investment. I don’t know what my future is right now, but this seems by far the most important thing for my profession to be working on.

The Web These Days · It’s like this: The time between having an idea and its public launch is measured in days not months, weeks not years. Same for each subsequent release cycle. Teams are small. Progress is iterative. No oceans are boiled, no monster requirements documents written.

And what do you get? Facebook. Google. Twitter. Ravelry. Basecamp. TripIt. GitHub. And on and on and on.

Obviously, the technology matters. This isn’t the place for details, but apparently the winning mix includes dynamic languages and Web frameworks and TDD and REST and Open Source and NoSQL at varying levels of relative importance.

More important is the culture: iterative development, continuous refactoring, ubiquitous unit testing, starting small, gathering user experience before it seems reasonable. All of which, to be fair, I suppose had its roots in last decade’s Extreme and Agile movements. I don’t hear a lot of talk these days from anyone claiming to “do Extreme” or “be Agile”. But then, in Web-land for damn sure I never hear any talk about large fixed-in-advance specifications, or doing the UML first, or development cycles longer than a single-digit number of weeks.

In The Enterprise · I’m not going to recite the statistics about the proportions of big projects that fail to work out, or flog moribund horses like the failed FBI system or Britain’s monumentally-troubled (to the tune of billions) NHS National Programme for IT. For one thing, the litany of disasters in the private sector is just as big in the aggregate and the batting average isn’t much better; it’s just that businesses can sweep the ashes under the carpet.

If you enjoy this sort of stuff, I recommend Michael Krigsman’s IT Project Failures column over at ZDNet. Also, Bruce Webster is very good. And for some more gloomy numbers, check out The CHAOS Report 2009 on IT Project Failure.

Amusingly, all the IT types who write about this agree that the problem is “excessive complexity”, whatever that means. Predictably, many of them follow the trail-of-tears story with a pitch for their own methodology, which they say will fix the problem. And even if we therefore suspect them of cranking up the gloom-&-doom knob a bit, the figures remain distressing.

So, what is to be done?

Plan A: Don’t Build Systems · The best thing, of course, is to simply not build your own systems. As many in our industry have pointed out, perhaps most eloquently Nicholas Carr, everything would be better if we could do IT the way we do electricity; hook up to the grid, let the IT utility run it all, and get billed per unit of usage.

This is where all the people now running around shouting “Cloud! Cloud! Cloud!” are trying to go. And it’s where Salesforce.com, for example, already is.

If you must run systems in-house, don’t engineer them, get ’em pre-cooked from Oracle or SAP or whoever. I can’t imagine any nonspecialist organization for whom it would make sense to build an HR or accounting application from scratch at this point in history.

Of course, we’re not in the Promised Land yet. I’m actually surprised that Salesforce isn’t a lot bigger than it is; a variety of things are holding back the migration to the utility model. Also, you hear tales of failed implementations at the SAP and Oracle app-levels too, especially CRM. And Oracle is well-known to be ferociously hard at work on a wholesale revision of the app stack with the Fusion Applications. But still, even if things aren’t perfect, nobody is predicting a return to hand-crafted Purchasing or Travel-Expense systems. Thank goodness.

But Sometimes You Have To · I don’t believe we’ll ever go to a pure-utility model for IT. Every world-class business has some sort of core competence, and there are good arguments that sometimes, you should implement your own systems around yours. My favorite example, of the ones I’ve seen over the past few years, is the NASDAQ trading system, which handles a ridiculous number of transactions in 6½ hours every trading day and pushes certain well-known technologies to places that I’d have flatly sworn were impossible if I hadn’t seen it.

Here’s a negative example: One of the world’s most ferocious competitive landscapes is telecoms, which these days means mobile telecoms. One way a telecom might like to compete would be to provide a better customer experience: billing, support, and so on. But to some degree they can’t, because many of them have outsourced much of that stuff to Amdocs.

Given all the colossal high-visibility failures like the ones I mentioned earlier, what responsible telecom executive would authorize going ahead with building an in-house alternative? But at some level that’s insane; if your business is customer service, how can you bypass an opportunity to compete by offering better customer service? The telecom networks around where I live seem to put most of their strategic investments into marketing, which is a bit sad.

Plan B: Do It Better · 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.


[Thanks to Tim Bray for allowing me to reprint his post.

Fish photo showing that one size doesn't fit all is from iStockphoto. Caught in the middle of two evolutionary streams, the fish are probably confused and wondering, "What the hell is going on here?"

Photo of Tim from Alex Waterhouse-Hayward.]

Topics: CXO, Browser, Networking, Oracle, Telcos

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Good Advice but a Solution Looking for a Problem

    That's reasonable advice:

    "Farm out IT-infrastructure/enterprise-software admin and development where it is economically advantageous (based on a complete TCO analysis). Keep it inhouse where one or the other or both will provide your enterprise competitive advantage."

    In fact, I haven't interviewed a CIO or IT staffer in years who doesn't agree. (LinkedIn says Mike Prince is still at Burlington Coat and Google suggests he'd even agree these days.) And market research that documents the growth of packaged enterprise software and Software as a Service (SaaS) in statistically significant computation says the same thing.

    So either the basic premise is wrong. Or something entirely different is happening here. I suggest it's a little bit of both:

    1. All the statistics about trillions of dollars of wasted IT dollars are inaccurate. Best I could come up with, being very pessimistic about human nature, was a measly half a trillion (16% of spend). Granted that's still a lot of money but probably the same as similar statisitcs about waste in an enterprise's manufacturing line, transport network, HR admin costs, and so forth
    2. Because there is less and less in-house software development and enterprise software/IT infrastrucutre to be administered, the IT priesthood thinks there is something wrong.
    • No problem here?

      I'm surprised by the title of your comment. Regardless of the exact cost of IT failure, it's too high and far too common an occurrence.

      Seems to me there's a substantial problem and no easy solutions.

      Thanks for the comment.
  • RE: Enterprise systems:

    The big flaw I see in Tim Bray's argument is that the users get to choose which system to use for the consumer systems, but they do not get to choose with Enterprise systems. The biggest advantage the consumer systems have is they can start small, and they get fast feedback from actual users.

    The Enterprise systems do not work that way. In the Enterprise systems the users do not decide what to use and how it should work. Can you image every HR staffer at a big company selecting their own system, and changing anytime a new one comes along. Enterprise systems also cannot start small. I don't think you could replace your GL system with a bunch of small websites that each handle a small part of the accounting task.

    While shorter iterations and greater use of web frameworks and dynamic languages sound like good ideas to me, they do not really address the biggest problems. Unfortunately the biggest advantages the consumer systems have do not apply to Enterprise systems.
  • He's right about a problem, but not his suggestions are off

    I think his comparison between Web 2.0 and and enterprise systems is way off. But it is a very thought provoking article, and there is certainly something to be learned from it. It got me thinking enough to write a response last night.
    Erik Engbrecht
  • RE: Enterprise systems:

    Great post!
  • RE: Web toys are not enterprise systems

    I think the comparison between cute personal web projects or even social network systems, and enterprise computing, is misleading -yspecifically as to risk. If Facebook or Twitter or my imaginary Daily Show fan page break down for hours or days, as they have or will or may do, the world doesn't stop turning. If enterprise computing fails for a big company, a large number of people aren't earning any revenue at all for as long as it takes to bring it back, because they depend largely or wholly on computers to direct their work within the organisation. An IT failure can annihilate your enterprise.

    Again, security: I was just reading about the people whose full time job is to remove fraud web pages from Facebook and from around Facebook, to counter the people whose full time job is to set those frauds up. Within the enterprise you can't afford to have that happening.

    You can't afford to lose e-mails. It is a regulatory requirement on many enterprises that you audit and retain all significant e-mails. Never mind that President Bush got away with losing his backups, if you let it happen then you can probably go to jail. That doesn't apply to social network services.

    Web toys need to be gaudy and fun. Enterprise computing needs to be dull and rock-solid reliable. And effective, and efficient, and not a juggernaut out of control. Enterprise computing needs to deliver the goods. And it needs to facilitate users' working days, not make them painful and frustrating. But above all, reliable, and that means careful, probably slow design and development and roll-out. Not tightrope-walking without the safety net. That's a good show but a bad bet.
    Robert Carnegie 2009
  • Utility Model...?

    At our company we have been pushing towards a more cloud based suite of offerings. In an attempt to "drink our own cool-aid" we are moving our internal processes over to cloud based apps (Google Apps, Salesforce.com).

    The biggest surprise we have found is the SPEED of customizing these applications, as was mentioned above, no big fat hairy requirements docs, just an idea and a few days to see results. It is very exciting. We've taken this model to our customers and found the ability to deliver lower cost implementations, faster dev cycles, and leave a trail of happy customers in our wake.

    It is a big shift for us culturally as we used to be "The requirements people". We still are, but instead of spending time writing about them, we're just building out the customizations in the application instead.

  • Millions wasted on Facebook development

    I think one important point to remember is that lots of spend
    was wasted in developing Facebook (or whatever chosen web
    success story you could name). In the case of Facebook the
    wasted spend is whatever it cost to create the subsequently
    underutilised capacity of MySpace, Bebo, etc.

    That's not to say we can't learn from the development
    practices of the success organisation though.
  • If it was only that simple

    First, claiming that Web 2.0 technologies will solve all problems, or that one way of working will solve all problems is unrealistic. The concept of "one size fits all" is effectively a lie. Show me a one-size-fits-all dress or slacks and at best I'll show you a person who doesn't look that bad and at worst, I'll show you someone else who looks ridiculous. I've never seen anyone look good.

    Second, complexity is one factor that drives risk that produces failings. Some things are complex because the reality is complex, others are complex because we make them so.

    Tim Bray's point has greater validity for the latter --- when we take something that is fairly simple and make it complex. We do this for any number of reasons: we're thinking sloppily (for whatever reason); we take something that was meant for one purpose and try to use it in ways it was never meant for; or everybody has to make their mark on it and no one can say "No"; and the list goes on.

    But there are also plenty of times where something [i]is[/i] complex because the item being controlled is complex, or the environment in which the product will be used is complex, or we're trying to grab snapshots in time of diverse activities that are asynchronous, and the list goes on.

    The challenge is to know whether something is justifiably complex or whether we are making it so. If it is justifiably complex, the next challenge is to identify where the complexity really lies. Is the business, human, or system environment complex? Is it the user experience that introduces complexity? And so on and so forth.
  • RE: Enterprise systems:

    Right on! We have proven many times that it's
    not only possible, but a de facto reality that
    you can build super scalable business
    applications for a tenth of the budget and no

    It's "not that simple" because of the
    complexity of the requirements - Take control
    and build small, efficient and cheap. It's
    done every day, but you just don't see it
    because you're surrounding by bloated process-
    driven development, which is styled by over-
    hyped buzz phrases manufactured by software
    companies and large
    consulting firms. Leave the heavy lifting to
    the ERP systems and build small with focused
    KPI's for success. Our clients are shocked with
    what we are able to achieve in comparison to
    their internal development teams, who are
    unlucky to be burdened with unrealistic
    expectations every day.
  • RE: Enterprise systems:

    As you may notice from the comments, Enterprise IT people deserves the failures they have.

    Is any IT system more complex in anyway that Google? more demanding?

    There is a lot of over architecting, a lot of over planning, a lot of waste generating activities, but a lot of people making money.

    If we, as an industry, were doctors we would be having our patients drinking poison, not lethal thou, just to make them keep coming back.

    Hopefully I work rescuing Enterprise IT projects, and transforming Enterprise IT organizations, using exactly the kind of things Tim is talking about, sometimes they are so deep into thinking there is no other way that they got completly nuts when they discover that "simple" solutions created by system thinking, and asking why a couple of times, and a lot of lean and agile thinking can change completely the landscape of tears and frustration to fast responding, user satisfaction & value creating organizations.

    But first they need to unlearn a huge amount of "best practices".