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.
Contributions
Comment feed for ongoing:
From: Dan Creswell (Jan 05 2010, at 10:37)
'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”.'
I think this is the essence of it and actually a problem across software development regardless of web or enterprise etc, which brings me to:
'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.'
I'm not sure what Web-land would be as I've worked for a few websites that have had to be coached into doing "the right thing".
Perhaps what drives the difference in behaviour is that some proportion of websites are the core offering of their respective businesses (they are the value generators) and the resulting direct connection to customers makes for more immediate feedback on software development actions.
Even so I'd note that the websites I've worked for have all fallen into the "value-generator" category and yet they've been stuck in "enterprise" development so there's some other factor at work (like the business in question actually recognising the website is it's value).
[link]
From: Peter Keane (Jan 05 2010, at 10:56)
Still no escaping Gall's law http://en.wikipedia.org/wiki/Gall%27s_law I believe.
[link]
From: Chris (Jan 05 2010, at 11:18)
I couldn't agree more! Consider UML and the complexity of some enterprise processes: now adopt the REST mindset and say "what's the simplest thing that could possibly work?" Do we even need a web framework to help us with approval workflows and business rules? If so, what does it look like?
[link]
From: Stefan Tilkov (Jan 05 2010, at 11:52)
There's a lot of truth in what you write, and I'm sure this will spread like wildfire. I strongly agree on many aspects.
But I also think you're wrong in some regards. One is that you equate the use of software that's been built already with using infrastructure that someone else provides. While I agree that it's going to become more and more silly to run one's own datacenter instead of using a Cloud provider, I strongly disagree with regards to standard software – in fact your next paragraph points into exactly this direction: I believe it's essential for a company that wants to stay competitive to build quite a bit of stuff in their own unique way, even if "building" tends to mean integration instead of construction these days.
In other words: I think it's an excellent idea to use commodity services in all areas where you don't have, nor want to have, any competitive advantages. It's essential to build something on your own if you want to innovate – and in information-centric businesses, this tends to mean that you have to develop quite a bit of software on your own.
That this can be done much better than most people do it today is very true, though.
[link]
From: Patrick Logan (Jan 05 2010, at 11:56)
"Oracle is well-known to be ferociously hard at work on a wholesale revision of the app stack with the Fusion Applications."
Looks like this is being built on SOA, BPEL, etc. That in itself is troubling, relative to your key point of the post.
We'll see. Sounds like the kind of thing that's typically late and bloated from Big Vendors with Big Ideas.
[link]
From: JulesLt (Jan 05 2010, at 12:05)
"nobody is predicting a return to hand-crafted Purchasing or Travel-Expense systems" - except, in my experience, companies continually do so, using Excel.
(Which I think is a good example of 'where we are going wrong' - the large number of simple database apps, implemented as shared spreadsheets - because even Access is too difficult for most people).
The other problem I see is with your examples - Twitter, Google (search), Basecamp - is that from a business point of view, they're relatively simple - the complexity is all technical.
Whereas your big classic IT project failure is often technically simple - use a nice off the shelf architecture, or as you suggest, customise some part-baked applications. The complexity largely comes from the business side - how many screens does your average Enterprise app have compared to any of the simple examples?
Of course, the question is whether businesses need to run every process through the same centralised app. (IDE vs assembling best-of-breed tools?)
[link]
From: David Megginson (Jan 05 2010, at 12:38)
It would take a brave (and well-funded) CTO to really emulate the web application development environment: she'd have to authorize (say) 500 one- or two-person projects and wait for natural selection to pick the most viable ones, reassigning people to the winners as the losers drop out, until after a couple of years she has one or two decent, fully-developed apps left standing.
[link]
From: Peter Keane (Jan 05 2010, at 12:44)
I suspect that some of the problems stem from the fact that we don't have the proper tools to handle data from the moment of inception. And the problems snowball from there. I've said as much about libraries/academia http://blogs.law.harvard.edu/pkeane/2010/01/01/what-is-datas-killer-app/ http://blogs.law.harvard.edu/pkeane/2010/01/04/layers/ but I suspect the problem is quite the same in the private/corporate sector.
[link]
From: Tom McCracken (Jan 05 2010, at 12:51)
Love the article. Enterprises love Big Design Up Front and fail because they do too much around things that never get implemented. Although, I find that many Web projects fail for the exact opposite reason, they proceed blindly forward with no risk analysis and unrealistic expectations.
The main project successes you list; Facebook, Google, Twitter, Basecamp, etc, all have one thing in common; product owners are not just close to the project, they are aligned with the team. And yes agile goes a long way to achieving this. Most successful online applications have knowledgeable product owners that give just the right amount of strategy at just the right time; then let their talented team self-organize around the requirements.
In large enterprises you tend to have managers who are ex-technical managers. They may have been technical at one time, but now are far removed from the actual work. The problem with most web projects is you have managers who never were technical, business owners, marketing managers, etc. They know even less about what developers need.
The big famous online successes tend to be driven by those who are still technical enough to give their team what they need and often they are right alongside doing the work.
[link]
From: Laurent Szyster (Jan 05 2010, at 12:58)
Doing it wrong?
Not if you consider the profit margin of enterprise software contractors and their suppliers.
For years they have been selling incompetent labor force at a premium price to develop never-ending projects and deliver ever more bloated software that demand huge hardware resources.
The people who sold those failed projects to the FBI or the NHS did not get the chicks for free but they sure got money for nothing, literally.
When money talks the ADO, UML and JPA bullshit walks ...
[link]
From: David Megginson (Jan 05 2010, at 13:08)
It would take a brave (and well-funded) CTO to really emulate the web application development environment: she'd have to authorize (say) 500 unmanaged one- or two-person projects, wait for natural selection to pick the most viable ones, reassign people to the winners as the losers drop out, then standardize on the one or two left standing after a couple of years.
[link]
From: Tom Passin (Jan 05 2010, at 13:28)
Your prime examples - like Facebook, Google, etc - are cases where the system *is* the business. The Facebook software doesn't do accounting or CRM for its owners. However, in the enterprise systems area, the software is developed to support business processes, and is generally a lot more complex, in terms of the number of steps that have to be coordinated, than what Facebook, etc., provide.
Facebook, etc., provide mass production, if you will, of their relatively simple product. They were able to start out with small volumes and build up. You can't ramp up your company's new accounting system, you have to switch over.
It's not clear to me that the enterprise systems can be developed in comparable ways, because of these differences. OTOH, it *is* clear that the way a lot of systems have gotten developed has been pretty disfunctional. So there seems to be some missing approach beyond what Tim talks about.
[link]
From: Alan Fekete (Jan 05 2010, at 13:39)
An interesting discussion of a case study in webby, agile RESTful approaches to enterprise *integration* tasks is by Jim Webber at http://jim.webber.name/2009/10/30/617410fc-7ec9-489f-a937-f50cf090bf48.aspx
[link]
From: Channing Walton (Jan 05 2010, at 14:05)
Well said. The most irritating thing for me is that the (very few) highly successful projects in banks that result in systems as you describe, are not seized upon by management to try to understand how they do it. The successful projects are dismissed as being 'obviously simple' or lucky!
There is a serious attitude problem at all levels in the enterprise that seems to favour 'traditional' methods and heroic hacking on production systems to pull it all together at the last minute.
[link]
From: Sasha (Jan 05 2010, at 14:05)
A brave CTO and a superstar sales person. I can't imagine walking into an enterprise sale or responding to an RFP saying "We're not going to spec it out. We're going to build you something, a little bit each day, tossing out what doesn't work, and you'll end up with exactly what you need"
I'm developing an app for my own purposes right now, via webland, and I know you're right. But I can't (personally. yet.) see how to run a sale that way.
I might be inspired to try, it would make writing RFP responses so much more pleasant.
[link]
From: Xianhang Zhang (Jan 05 2010, at 14:35)
You forgot to mention the economic forces behind why enterprise software sucks so much. Web software is bought (or at least supported) by users so there's rapid feedback on changes. Enterprise software is bought by purchasing departments who rarely are the end users.
[link]
From: Stefan Tilkov (Jan 05 2010, at 14:43)
One more thing: While it's pretty fashionable to deride the claims that enterprise software is "inherently more complex" than much of the Web stuff, it *is* in fact true sometimes. One of the reasons is the absurd complexity of laws in some countries, and the rate in which more and more complexity is added to them. If you're in a regulated business, this tends to create a huge amount of complexity you simply can't escape from (unless you change the laws, or rather the whole legislative and political process, of course)
Another source of complexity is the business side, coming up with more and more complex product requirements. In many Web companies, there's no difference between the business and technology decision makers – perfect "business/IT alignment". This simply isn't true in most large businesses. As a tech person, you have a choice of quitting or adapting to it …
Again, don't get me wrong: I'm among the first to admit that much, if not most enterprisey technology is unnecessary crap. But even if you are given free choice of weapons in terms of tools and methodology, the typical constraints can ruin your day pretty soon.
[link]
From: Martijn Linssen (Jan 05 2010, at 14:58)
IT utility is a widespread misconception. You don't have TV's, ovens or microwaves coming out of the wall, only the stuff that feeds them. IT utility is never going to get "higher" than the infra level: network, storage, security, all boringly static stuff, far far away from the user. The user is close to the business, the business is dynamic, so forget it, don't even think about it!
So, can you Cloud ERP? Heck no, you just spent zillions on consultancy tailormaking that for your company. CRM? Maybe, if you sell apples. Or oranges. HR then? Sure, if you didn't tailormake that too
So, that's why Salesforce is where it's at. And will stay, especially if they keep reinventing and building in stuff like Chatter in stead of plugging already existing networks into their app
It's business rules versus business exceptions. We're going from one to the other, so actually moving away from Cloudability
Governments? Always leading the way in the new business rules world; which at that point are exceptions, of course
Finally, there's also what could be called the long tail of architecture: http://bit.ly/6wuy1h. A lot of that lives and leads into your plan B
A word on Agile and small communities: it's all good and fun, but has its requirements. You might live your live happily with a wife and 2.1 kids, but imagine having another wife or two, plus a dozen extra kids: you'd really need to drastically change "the way you do life".
Personally I'm in for "managed Agile / piloting" but there's just so many kingdoms and knights-who-say-Ni to pass in an enterprise, they have an entire system of themselves...
[link]
From: addys (Jan 05 2010, at 15:19)
Sorry to say that YOU are doing it wrong.
Issues I have with the article:
1) The crux of the article is that web 2.0 methodologies deliver "better systems at less cost in less time at lower risk than we see in the Enterprise". But you are ignoring the fact that for every Facebook and Twitter there are hundreds of similar efforts which failed. The overall success rate of web startups is *significantly* lower (read: orders of magnitude) than in the enterprise IT field.
2) Comparing an IT project with a fixed budget and known requirements to a web startup is apples to oranges. How many of the Web 2.0 success stories actually delivered their vision “on-time and on-budget”? They typically require multiple rounds of VC investment over several years. The ones that actually survived did so because they eventually found solid business models with which to fund their development and ops costs. Most Enterprises do not fund their IT projects with a “keep on going until the money runs out” mentality, and with good reason…
3) Most of the successes you refer to- "Facebook. Google. Twitter. Ravelry. Basecamp. TripIt" - are not software development stories at all. Facebook and Twitter won their userbase through network effects. Google stumbled on a brilliant ad monetization business model. Their success, and the failure of their competitors, usually has little or nothing to do with their technologies or methodologies. Twitter actually succeeded *despite* an amazingly crappy software platform.
4) For enterprises, IT is usually pure overhead. The budget for a system is derived from the estimated value it will deliver to the business, and the requirements are derived from the demands of the business. Developing an IT system with “no monster requirements documents” is like developing a spark plug for your car without requirements… good luck with that, unless you are willing to “iterate” your entire engine along with it.
[link]
From: John Cowan (Jan 05 2010, at 15:48)
The simple stupid Mickey-Mouse-watch news distribution system I built for Reuters Health back in mid-2000 has been under threat of being steamrollered by The (technically inferior) Big Reuters News Distribution System since mid-2001.
It's still running, even though everyone who worked on it is long gone. The same story is being told, I suspect; no replacement in sight, I suspect.
[link]
From: Adi R (Jan 05 2010, at 16:23)
I think anyone sticking with "you are only noticed when you fail" as their "corporate survival strategy" is bound to be fired sooner rather than later.
I suppose in few largest corporations this may still be going on, but if they are to remain competitive, they will soon trickle down demand for excellence and results, from everyone.
As to overall article -- I think you completely overlooked the aspect of security. Do you really think it would be 100% safe to run something as big and as crucial as FBI on mostly open-source components, with any country having full read/commit access to the sources? And same applies to most other major Corporations, who have many well-funded enemies of all kinds.
Clearly there are cases where Enterprise "from scratch" software is a requirement.
I do agree that big vendors are just now starting to "study" the concepts of distributed computing and cloud computing. Only once they master these concepts, projects of any magnitude given to them have any chance of success.
[link]
From: Robert Young (Jan 05 2010, at 17:36)
Enterprise IT is about COBOL maintenance; most of the infrastructure has grown like Topsy over the last 3 decades. Replacing software that "works" just doesn't happen. Which means yet more COBOL, whether written in COBOL or java. Not to mention that all those middle managers' salaries depend upon keeping staff, at minimum, and growing staff, preferably. Since these managers only understand COBOL, that's what they do. The relational database takes care of most issues very simply, once the catalog is defined (and maintenance of the catalog is not such a big deal).
What you advocate is a return to 1960's siloed COBOL, although written in newer languages. Be it ever so humble, but the data is more important than the code. Put the intelligence in the data, and most development/maintenance problems go away. But to advocate a different code oriented approach is lining up the deck chairs on the Titanic; it's still about writing lots of code and employing coders. The problem is there is too much code being written into too many silos. Dr. Codd showed us the better way, but most of us remain codeheads.
Neither the coders nor their managers want that. Thus messes like NoSql, a very thinly veiled attempt to both sound like something new and still just be the same olde siloed code approach. xml is that, too.
[link]
From: Steven Wittens (Jan 05 2010, at 18:25)
To the commenter above:
"But you are ignoring the fact that for every Facebook and Twitter there are hundreds of similar efforts which failed. The overall success rate of web startups is *significantly* lower (read: orders of magnitude) than in the enterprise IT field."
Perhaps this is because most web start-ups need to build out their customer base from scratch in a fiercely competitive space where inferior products are simply not tolerated.
In my experience, a lot of enterprise software is built and purchased by people who will never actually use it themselves. By the time anyone important notices that the product is crap, too much time and money has been pumped into it. So instead, they throw some more money at training and support in the hopes of making the problems go away.
[link]
From: Erik Engbrecht (Jan 05 2010, at 20:03)
I think you make some good points, but really you're comparing apples and apple jacks. Most of the problems faced in enterprise systems are fundamentally different than those faced by web startups.
http://erikengbrecht.blogspot.com/2010/01/your-companys-app.html
[link]
From: Ed (Jan 05 2010, at 21:17)
Ugh, Tim, I'm not even sure where to begin. As someone who's worked on Enterprise systems and Web 2.0, I can safely say you're choosing the most atypical successes of the Internet world and failures of the IT world. Further, the success of Web 2.0 apps is not directly based on either stability, security, or scalability, it's typically on raw user adoption. Some of the most successful Web 2.0 companies today have regularly suffered major outages and had atrocious security policies. The ones that succeed get brute force applied after the fact to shore up these technical shortcomings. Now, I have to agree that countless IT execs have embarked on developing systems they had no business building, but, in many ways, the projects that get developed in the enterprise world happen because it's more important (i.e. productive, profitable) for the systems to be adapted to the business and organization needs rather than the other way around.
[link]
From: Joe (Jan 05 2010, at 21:50)
This isn't really a surprise given that: 1) most senior managers have a sales/marketing background and don't really understand IT
2) IT is an overhead and not the primary focus for most of these companies, so even if senior management comes from a non sales background and understands something about the product or service produced by the company, they still don't understand IT and
3) many of these managers *love* PowerPoint slides with lots of little interconnected boxes. Especially if they're arranged in triangles or circles.
[link]
From: Paul Prescod (Jan 05 2010, at 23:58)
I agree with those who say that it isn't fair to enterprise developers to compare them to web developers. Web developers fail, and stall and redirect their efforts, and decide to tackle a different problem. Imagine going back to the people building your new CRM and asking: "how is it going?" "Oh: we found that there was more demand in the company for a CMS...maybe someone somewhere else in the company will build the CRM for you." It's going to take changes far beyond the IT department for that to happen.
I do not think that enterprise IT is well-managed, but I don't think it is realistic for it to be compared with startup development.
[link]
From: ariel sommeria (Jan 06 2010, at 00:20)
The one thing that big companies have is a whole lot of cash. So it's feasible to hire a team of a few guys, insulate them from the rest of the company, and tell them to come back when it's done and not meddle with them. It's even feasible to do this with multiple teams and get them to compete against each other. But I haven't seen it yet. So I left the big company I worked for and I freelance.
[link]
From: Aurélien Pelletier (Jan 06 2010, at 01:43)
Any true software developer who likes its job will enjoy your post, I do.
But I also believe enterpriseland can't do what the webland does. Because of risk: "nobody ever got fired for choosing ibm". In webland people take risk, for one twitter or one google how many failures? The failure rate might be higher in enterprise land ( I have no clue about that) but the game is to take no risk, or to transfer the risk to someone else, even if it cost much more.
A fixed priced project, with big design up front, full specification/conception/development/test phases with IBM or Accenture is what everyone does. If it fails nobody will blame you. But if your short/agile/TDD/web like project fails it will be your fault.
[link]
From: Martin Probst (Jan 06 2010, at 02:07)
I've probably been whining about this much too much already, but regarding your praise of pre-cooked solutions: yes, it reduces the risk somewhat because you pay a fixed price, even though I guess it's still possible to screw up the integration project massively.
But on the other hand, I've seen so many off-the-shelve solutions that were so ridiculously bad it's downright unbelievable someone can win a single sales pitch with them. My company runs a bunch of those.
Meaning: just because you left it to a "specialist" doesn't mean you actually get a certain level of quality. And whoever makes those purchase decisions is apparently not really competent to make them. As they say: "if the executives who buy it actually had to use SAP themselves, the software would look a lot different".
[link]
From: Gavin Brook (Jan 06 2010, at 03:50)
I have worked for and with many large Enterprises. There are two factors that plague the enterprise that aren't taken into account in your artcile.
Firstly, most enterprise systems typically have to integrate to a legacy system. For instance it's not easy to move a company's billing system to another provider, so any project related to that will typically have to integrate in some way. Even changing versions of the same piece of software isn't easy.
The second is a general project management issue, and that's to do with stakeholder management. There are usually far too many stakeholders in a project which muddies the water. In a web startup, there are only a handful of people involved. Magnify this to the enterprise and you have a big problem. This is my view on what happened with the NHS CfH project, too many people adding in their requirements and over complicating the system.
What you're saying has a lot of merit, but I believe there are fundamental project management problems that need to be addressed to get enterprise development on the right path.
[link]
From: Webby McWebster (Jan 06 2010, at 04:53)
I love the irconic, and frankly stupid, disdain these enterprise'y chumps seem to have for the web approach. Silo's? Scalability? SERIOUSLY?!
Piss off.
The web won. It pissed, thick gloopy dehydrated wizz all over your boring rectangular faces. Get over it. Learn the one true way. You'll feel better once we're through it and eventually we will all sit back and laugh about it *together* (instead of just us at you like it is now).
Grow some bawls, corpodorks.
[link]
From: John Cook (Jan 06 2010, at 05:16)
Not to be overtly negative, but I could sum up this entry as:
"You should be agile unless you can just buy it but you probably can't so do it better."
Doesn't give us guys slagging away in enterprise-land a great roadmap.
My experience with "going agile" in a previously-not-agile enterprise has been that it's an easy sell to development. It's a less easy sell to QA, but we eventually won them over. The shocking thing to me is that the product owners have been the ones to completely miss the value. But I think it's because there's nothing in being agile that speaks to success as defined by enterprise management.
Don't get me wrong, they love being able to change features shortly before the release. But what it devolves into is a game of setting all the features to the same priority and arguing any changes to story points. Because as it turns out, the upper-level executives to whom they have promised X number of releases per year with a list of Y features don't really care about team velocity or estimation poker or comparisons to Facebook or user feedback loops. They only care about X releases and Y features because that's what their bonuses are tied to.
Happy users are nice to have. But they don't always have anything to do with what motivates product owners.
[link]
From: Chandru (Jan 06 2010, at 05:47)
You're right about Telecoms. Amdocs is everywhere and all they sell is a pile of expensive crap. In the mobile network I work in, our IT systems are one failure story after another. Our "IT Architecture Board" keeps making decisions to "preserve architectural purity" which obviously can't be delievered because we have to get third parties such as Amdocs to deliver the change (which if you ask now, you'll be lucky to get in about 9 months time).
On the other hand, the prgamatic way of doing it will probably take a week, but that means trusting people in the networks domain, who are weird and use, what is that, "functional programming" languages. Who ever heard of that rubbish. That is only for academics.
Jesus, when will these Enterprise teams learn to build systems which are cheap, reliable and on time. It is not that hard.
[link]
From: Bryan Lawrence (Jan 06 2010, at 05:48)
It'd be kind of nice if someone (you?) wrote a summary of the comments as an addendum ... I think there are oodles of truths in what you wrote, and in the comments too (both pro and con).
I think the issue about up-front-design is often one of bringing disparate communities together in requirements and deliverable functionality ... if you can do that with an iterative prototype delivery framework then fine, but sometimes you simply can't ...
Which is not to say that the up-front-design doesn't go over the top in many cases. Often because "Enterprise" has a lot of "less good" folk as well as "pretty good" folk, and the methods the good folk use just don't work for the less good folk ...
... but that hinders web 2.0 and friends too!
[link]
From: Stephen Bounds (Jan 06 2010, at 06:40)
Just finishing reading Nicholas Taleb's book "Fooled By Randomness" and Tim, I'm sorry to say that you've fallen into a classic example of the trap right here.
In short: For any field of endeavour with high volatility, having a large enough sample size of participants virtually guarantees some astonishing successes purely through luck.
Survivorship bias and human nature then means that we assume those who succeed did something right. Really they have just been lucky.
[link]
From: Aaron (Jan 06 2010, at 07:48)
Absurd and Naive.
1. The economics of your conclusion is corrupted. You're omitting the millions of hours of wasted development from all the web companies that have failed. You're selecting only the major successes of the web and only the major failures of enterprise. What sense does that make?
2. Enterprises are inherently more complex. Web systems, by nature of their economic model, are simple and generic so that they can be marginally valuable to as many people as possible. Enterprise systems are complex to align to business processes and to integrate with heterogeneous systems.
3. UML and Requirements are not hard. In fact, understanding requirements are essential for a successful system of any kind. Few people in enterprise software development are using massive requirements documents or unnecessary UML. Waterfall has never been a proscription, regardless of the myths. Instead there's potential for bad luck or bad people (see #1.).
[link]
From: Jeremy Dunck (Jan 06 2010, at 08:00)
addys: "For enterprises, IT is usually pure overhead"
This view is exactly the reason I got out of IT. I actually strongly disagree-- the role of IT is to change data into knowledge, and as such can be a core competitive advantage. But the view is so pervasive that it's soul-crushing to attempt to do something genuinely useful. Enterprise says, "if you're not line-of-business, you're a cost". Bah.
I'll go discover and solve my own problems, thanks.
[link]
From: Drew (Jan 06 2010, at 08:24)
Find the enterprise push back in the comments to be interesting to say the least. My personal favorite is the DBA who clearly _knows_ why everyone who writes code for a living instead of managing great hulking db's is an idiot. I've never seen a piece of software (or database) labeled "Enterprise" that I would call a success or even functional. It boggles my mind that the big companies in this space still exist. On the other hand who would want to write a non-crap PS or SAP or HP-whatever?
[link]
From: len (Jan 06 2010, at 08:31)
Maybe I'm the exception but here I am a development manager with a marketing CEO type who drives requirements fast and furious from the hip to an expensive consultant who claims all our problems can be solved by better requirements as long as he, the consultant, gets to determine them.
So far, the CEO has been more right than wrong and the consultant has been less perspicacious than concerned with next year's technology... which IMO, is as it should be. IME, the more the architects get involved with the requirements, the more money is lost.
Truth be told, this article hawks one approach with specious examples and no size fits all. Success is more a matter of the actual hands on the keyboards than it is the method or methods employed. There is no way to rescind GIGO: it is the law of gravity of systems development. It is like the claim you once made for standards development: success depends on the The Right People.
Basic and simple web technology did not save our projects. Web tech reveals an astounding fragility with respect to reliable systems given complex business requirements. An excellent and adaptible RAD tech was the project saver. As other commenters have pointed out, the majority of your examples are for applications that are used widely but trivial in operational requirements.
The truth here as it often is lies in the murky middle and tends to be awfully local.
[link]
From: Robert Young (Jan 06 2010, at 08:42)
@Stephen:
Survivorship bias and human nature then means that we assume those who succeed did something right. Really they have just been lucky.
Bingo. If Kildall hadn't blown off IBM, and Seattle Computer (Paterson) not been curious enough to build a QDOS, MicroSoft would have been just another rich kid's toy.
[link]
From: Paul Houle (Jan 06 2010, at 08:45)
"Enterprise" software from the likes of Oracle are about as bad as software that's developed in house. Systems integration of COTS software can, in the worst case, be every bit as expensive as developing what you need in house.
It's not really about "Build or Buy" (either one can be a good or bad decision) but really about other factors that impact enterprise software:
(1) Because the web is new, a lot of web software is developed by people who have a long track record developing legacy systems. There is a wide body of "unwritten" web standards that concern user interfaces and technical architectures that (really) work that are entirely unknown to the people who develop business apps. The same dumb mistakes get repeated over and over.
(2) Consumer-facing systems need to seduce people into using them; if amazon.com needed an users manual, it would not succeed. To the contrary, I recently got a letter telling me how to log into a health insurance related web site that described 15 steps I'd need to take to create an account. The issue isn't that the sign-on process is needlessly complex, but that the people would rather send you an intimidating letter than do the work to make the sign-on process self-guiding.
(3) People who develop business apps go out of the way to NOT compare themselves to consumer-facing sites. The mantra is "we can't afford to do it like amazon, we don't have the budget." The health insurance company can spend 50 cents mailing a letter to a million people, but it can't spend $5000 on guerilla usability testing. The average small business e-commerce site can afford more than 50% of potential customers due to UI problems and technical glitches in the shopping car, but they can't afford to do it right. Nobody thinks that "amazon is rich because amazon does it right" rather than "amazon can do it right because they are rich"
[link]
From: Robert Young (Jan 06 2010, at 09:05)
@Tim (and Webby, especially):
Why would a corpodork manager want to build an application in some language that isn't COBOL (the only one s/he might understand, and certainly the only one existing staff does)? Doing so means:
- 1/10 the people (none of whom currently works for him/her, so bureaucratic loyalty is lost in the acquisition of them)
- 1/2 the time
Increasing staff and budgets are the reward for corpodork managers. Not decreasing both. Assuming that said corpodork manager will be rewarded for doing the application with 1/10 the bodies and 1/2 the time is grotesquely false. S/he'll likely get either fired, at least marginalized for assaulting the livelihoods of the rest of the corpodork managers. Doing more with less is the ultimate sin.
[link]
From: Hector Cuevas (Jan 06 2010, at 09:51)
Technical success doesn't mean anything without business success. For that reason alone I would remove any website in your list that doesn't have a clear, profitable business model, most notably Twitter. I like BaseCamp, but since in this case the software *is* the business, I don't think it can be held as an example -Telco's aren't in the customer support business, for one.
Are Enterprise developers a community? You seem to deny them that label, and I think it's important, because it implies they (Enterprise) are The Man, whatever that means, and it influences the argument.
I don't want to believe - I want to see a succesful health care or airport luggagge system done in an Agile way. I want to see an example of Agile succeeding where Enterprise methodologies failed -not at something the Enterprise just isn't interested in doing. I want to see Agile doing Enterprise right.
[link]
From: John Panagulias (Jan 06 2010, at 11:20)
"The community of developers whose work you see on the Web...deploy better systems at less cost in less time at lower risk than we see in the Enterprise."
A wonderfully provocative article - especially if you measure it by the comments -that sets out the covers the ongoing tug-of-war between the business and IT. Of course the business is always ahead of enterprise IT because ideas move faster than can any systems implementation. So, enterprise systems always seem slow and costly. I think everyone agrees: there must be a better way!
Someone asked for a summary of the comments. They fall into two camps, broadly speaking:
Those for Tim's premise: corporate IT is a bureaucracy and they seek to sustain themselves even to the detriment of their known purpose. Down with enterprise IT and their fossilized thinking!
Those against Tim's premise: comparing enterprise IT to Web 2.0 startups is apples and oranges. Lots of Web companies fail, so that proves your premise wrong. Heck with Agile and all the rest - we eat raw meat in the enterprise, not quiche!
My perspective is that enterprise systems and their bureaucracies had better adapt a mix of "Don't Build Systems" and "Do It Better". The reason is that it's the economy (stupid). We're in a lull right now, but the world economy is still very fragile. It will be a lackluster year for economic growth. Costs will have to be significantly managed.
Thus, enterprise IT will have no choice but to adapt by shedding what it doesn't need to own and focusing on the things that give the business a competitive advantage. There are lots of things that can be handed off to cloud computing providers. Certain types of storage, non-mission critical business apps, development and testing - these are all candidates for offloading from the enterprise. For those systems that require enterprise IT, of course, it makes sense to adopt some form of "agile" and flexible processes. To argue, that can't be done is to argue a futile point. Companies will either evolve and prosper, or limp along into a slow decline. Like everything else, computing is an evolution. To think otherwise -now that - "is unacceptable".
[link]
From: Ralf Claussnitzer (Jan 06 2010, at 11:28)
Great debate! But it's not about IT people alone.
It is indeed hard to get why so many enterprise projects fail. They are accused by all these agile-web-coders for their tendency for big upfront design, so they should be more successful right?
My guess is that this is related to the way non-IT management sees IT services - as a way of throwing tools on problems right before knowing the problems real cause. The IT department than has to deal with brittle and half-baked requirements that turn to dust just when developers try to turn them into specifications. Now it's their fault!
Big upfront design seem to be a good self defence technique...
[link]
From: Doug Kretzmann (Jan 06 2010, at 11:45)
"I’m not going to say that these are low-hanging fruit"
Good ;-)
In any problem domain where vast sums of money are involved it's reasonable to assume that many smart people have attempted to solve the problems. That they have all failed to some degree indicates irreducible complexity (since 1968, at least, http://homepages.cs.ncl.ac.uk/brian.randell/NATO/); or quite possibly as others have observed, organizational pathologies.
A small example - as John Cook notes, incentives matter. In Enterprise, the incentives for executives typically are linked to stock prices, in particular stock prices at some arbitrary time point written into their contracts. It's hard for them to link this to delivering the best IT systems for their companies. Usually it produces the cheapest thing that could possibly work, rather than the simplest/best.
On the question of packaged applications, Martin Cook and Paul Houle are accurate. I'd note also that the typical real-world SAP implementation takes five years and the disbursing of large sums of money to herds of consultants. Packaged applications tend to fall between two stools: either they don't provide the functionality the business requires, so the business has to be forced to fit the software; or the configurability required to accommodate multifarious business requirements becomes itself a source of complexity. SAP tends to the latter.
I've had bitter and long experience of CRM packages thrust upon software bug-tracking applications, where they proceed to Epic Fail. We still use a mainframe system from the 70s behind all of the changing CRM packages, because it does what we need.
Packages usually aren't, either. For example Oracle's packages require a vast Oracle infrastructure with undocumented dependencies between the components. Rest assured the big O will bill you separately and in detail for each piece of that infrastructure.
[link]
From: Bob (Jan 06 2010, at 11:57)
When all you have is a hammer...
[link]
From: Doug Kretzmann (Jan 06 2010, at 12:00)
I beg your pardon, "Martin Cook" in my last post should of course be "Martin Probst".
[link]
From: Nick (Jan 06 2010, at 13:38)
The comparison ignores some critical points:
1) startups are a self-selected group of higher talent and drive.
2) the cost of the failures in an open-source market segment need to be considered, not just the cost of success.
3) the self-selected market segments in open source software. The "customers" listened to are the ones that happen to fit the software profile. This is significantly different then building to a fixed market / user population. In fact, one aspect of open-source is that developers usually are the users. Also, users are those who stay with the software. There is no forced, captive audience. Open-source never fails, it just ends up with less users :). Enterprise projects fail if the intended users don't use the software.
4) open source software is incremental improvements of prior examples. In a sense, it has implicit working prototypes in prior generation.
5) competing scopes of packaged software. e.g. customers have vastly differing requirements/needs/wants.
6) all the successes you lauded are simple problems.
I've worked in both industries, and a big issue in Enterprise software is talent and experience. Scope of what is being built is also critical- the bigger the scope, the bigger the number of directions.
Also, for more complex open-source projects, have people ever really accounted for the labour involved? e.g. if you were to privately develop something like Subversion, or Linux, or Apache, just how much would it cost?
Software failure is an issue, but the comparison of enterprise to web is somewhat shaky. Take the Rails core team, and read their blogs and code. Any one of them would probably be in the top 2% of an IT department or ISV services staff. Maybe Agile is like playing piano by ear- it's great if the talent is there for it, but not doable if it's not.
In some respects, I think "big up front design" fails because the team fails. Requirements and design are the first phases, so that's where we see the disease. And we causally link that disease to the death of the patient later on. But maybe it's just a sickly organism, and it'll quick;y progress to disease and death on an time scale. Work Agilely, die agilely.
Incidentally, Twitter and Rails have/are being completely reimplemented. As has Facebook. Cost per feature in all of these are astronomically high. Agile has failed horribly in producing a long-lived codebase. I don't think IT departments can afford costs like these.
Failure and waste are high in open source- they just aren't defined as failure and waste.
Regards,
Nick
[link]
From: G.Irish (Jan 06 2010, at 13:55)
Something I haven't seen anyone mention directly is that a lot of enterprise development efforts go to hell because of inherent weaknesses in the enterprise. If you're trying to build an enterprise app to support business processes that are not documented anywhere, are subject to the whim of many pointy-haired-bosses, and may not be brought to the attention of the development team until the last minute you're going to have huge problems. And that's in addition to the aforementioned legacy app problem.
Enterprise IT simply has a lot of challenges and requirements that Web 2.0 doesn't have at all.
[link]
From: Prakash Murthy (Jan 06 2010, at 14:59)
From my experience a sub-field (Enterprise risk management software for Financial institutions), I would say this is a very accurate summary of the Enterprise software field, and the key aspects. Majority of the players go for a combination of a packaged software (Murex, Summit, SunGard, Calypso,...) and internal custom development in this highly-competitive and secrets-kept-may-mean-millions-made industry. Only a handful go for the complete internal development option for the sake of competitive edge. The immense pressure to get new functionality out to the market in quick time has the Packaged software vendors act like custom development firms at times.
This field could have a jarring impact on not those who swear by 'sound' Software engineering principles - as I used to be in the initial years of my career ;-)
[link]
From: Aaron Longwell (Jan 06 2010, at 16:02)
This triggered something I've been thinking about for some time about how F.A. Hayek's thinking applies to software projects. My post on the subject:
http://aaronlongwell.com/2010/01/fa-hayek-on-software-a-response-to-tim-brays.html
[link]
From: Jeff Turner (Jan 06 2010, at 17:10)
Absolutely agree.
Unfortunately for most enterprises, adopting the new sharper technologies and approaches usually means a large skills gap. This leads to the "outing" of the typical IT architect, developer and business requirements leads. This leads to questions which lead to unfortunate answers for most of the IT team.
How can the tools and approaches become so sharp outside the enterprise while inside they do not change. There is no justification that can be provided that would defend this unfortunate fact.
[link]
From: Jeff Darcy (Jan 06 2010, at 17:50)
There's probably not much I can add to what has already been said, especially regarding issues such as cherry-picking the wins for the "web" approach and the losses for the "enterprise" approach, but here's one more thought. A lot of these supposed success stories could be categorized as solving simple problems with complex technology. I mean, really, *web stuff just isn't that hard*. Get over yourselves. You can adopt all sorts of silly fashion trends and get away with it if what you're doing is inherently easy, but all of that infrastructure you take for granted - networking and storage, operating systems and hypervisors, compilers and interpreters, any number of embedded real-time systems - are much harder. Practically none of them were developed that way, or could have been.
The hardest problems faced by most web developers are the ones created by other web developers - bad frameworks, bad build tools, bad libraries, layer upon layer of cruft each replacing some older set of problems with a new and bigger one. This occurs mostly because somebody didn't take the time to understand the problem/solution space before they started writing code - which they then flung over the wall for you to deal with just before their startup failed. Lucky you. I guess that's what happens when the fashionable methodologies all have built-in incentives to defer problems instead of solving them.
[link]
From: Mark Sigal (Jan 06 2010, at 18:24)
Tim,
Having sold to this customer many a time I can tell you the challenge is two-fold:
1) Typically the amount of legacy that must be integrated with, in itself, creates a threshold on innovation since there are political domain issues, glue code creation/support lifecycle costs, and a general ripple effect of if/then/else that forces a trade-off between orphaning the technology, and thus setting it up to fail, or worse, managing it by committee, and thus, setting it up to fail.
2) The larger issue is that post tech bubble, where IT Innovation was treated as an indispensable asset (sometimes foolishly so), now it's gone the other way. IT Innovation is treated as an asset/liability, and so perception tends to become reality. What should be "ship the idea quickly, fix it quickly, then iterate quickly" becomes instead "define requirements and metrics for success in a way that no one loses their job," often resulting in something akin to a concept car; designed to inspire "oohs and aahs" but never intended to be driven off the lot.
Is it any wonder that whereas innovation used to begin in the enterprise and flow down to the consumer, today the model is inverted?
Read: Innovation, Inevitability and Why R&D is So Hard
http://bit.ly/Y8kcH
Cheers,
Mark
[link]
From: SoulDecision (Jan 07 2010, at 01:20)
1) Yes, there are a multitude of differences between Web 2.0 and the Enterprise, but this does not have to be an all-or-nothing proposition. There are some good elements of Web 2.0 that the Enterprise can adopt to improve their quality of software.
Saying Web 2.0 is not Enterprise, so we can't use Web 2.0 in our Enterprise is just a lame argument and I think is just a coverup for the fact that people are lazy and don't want to change the status quo (especially if certain groups are making money out of clients being stupid).
2) I'd like to retort to the common refrain that IT is an 'overhead'. This is garbage, that's like saying talking is an overhead. Let's remember what IT should be fundamentally about...using technology to communicate more effectively and make better decisions.
[link]
From: David Hull (Jan 07 2010, at 06:24)
I think it's faulty to compare open source successes with enterprise failures. The success stories you talk about are the the well-publicized successes that are born of small groups of talented professionals. The enterprise failures, on the other hand, are the well-publicized stories of massive incompetence.
When small projects fail, and they do every day, you never hear about them. Likewise, when very large projects fail, they're all over the news. This doesn't make either case the norm.
[link]
From: Bimal Shah (Jan 07 2010, at 07:00)
As others have touched on it is the complexity of requirements, rules and stakeholders that are reflected in the complexity of the software that is built. On the web there is greater opportunity to tackle that complexity at source and not in the software. The core challenge is and always has been: to figure out where (business, product or software) as well as how, to simplify.
Now both web companies and existing businesses have a mission, to a greater or lesser degree, to identify and meet end customer needs.
Where these companies get to compete on a level playing it will be down to which companies can meet the ongoing challenge of keeping 'things' simple.
[link]
From: Dorian Taylor (Jan 07 2010, at 07:47)
I am largely on board with the notion that "enterprise" software is ridiculously expensive, and better products can be acquired at a fraction of the cost. Indeed, it seems as if the more expensive software is, the greater the chance of it being garbage.
Despite that, I find the admonition to not "build systems" somewhat troubling. I fully agree with it for what are effectively intermediate components such as standardized frameworks, protocol interfaces, databases, etc. I think it is a mistake, however, to pass summary judgment (e.g. "reinventing the wheel") on the parts that model the business process and those that come in contact with people.
My reason for believing this is that all software ultimately reflects how its authors think you should run your business. If you have a clearer idea than the crop of vendors for how things ought to work, you are probably better off rolling your own system than acquiescing to an ill-fitting solution for the sake of expedience. Clarity, after all, is what makes software acquisition run smoothly.
By no means, however, am I suggesting that business should be suspended until some monolith is erected. Software is about optimizing the allocation of resources and dividing labour between people and machines. You make more of it when there is a clear advantage to doing so.
I must admit that I'm a bigger fan of looking at this kind of thing from an incremental perspective than an iterative one. I don't think software is Darwinian. If you solve a problem once, the first time, it's solved forever, until it ceases to exist or takes a different form. (More specifically, it's the problems that appear to mutate, not the solutions.)
[link]
From: Michael McKechnie (Jan 07 2010, at 08:17)
I see Matt Asay (http://www.cnet.com/profile/Matt+Asay/) has written the same article...
"For all the billions enterprises spend on IT each year, they arguably get far inferior software than Facebook..."
http://news.cnet.com/8301-13505_3-10426409-16.html?part=rss&subj=news&tag=2547-1_3-0-20
[link]
From: Rich Sands (Jan 07 2010, at 09:18)
As has been pointed out in many of these comments, the problem is the unmanageable complexity of enterprise requirements. Web 2.0 methodologies can't fix that. If judiciously applied they might reduce some of the costs and failures. But the real problem is complexity, and that is not IT's problem, it is LOB management's problem to solve. The most successful companies innovate in their core business, killing complexity, reducing costs, and finding new business models that revolutionize their industries. Amazon.com is a retailer. But they looked at retail differently, simplified their logistics by eliminating retail stores, did away with a ton of complexity, leveraged IT to actually do their core business differently and better than their competition. Sure there's regulations and legacy and all of that. It is up to the LOB to innovate and find creative new ways to succeed. Then IT can implement those complexity-busting, cost-reducing new ways to do business, using Web 2.0 techniques where appropriate.
Don't blame IT. Don't think Web 2.0 techniques can solve this problem. It is not a technology problem, it is a management and human problem, whose solution lies outside the realm of IT.
[link]
From: Nico (Jan 07 2010, at 10:01)
Companies that are entirely web-facing tend to build their systems right. They have no choice. Think eBay, Priceline, Facebook, ...
But there are non-web facing companies that get their systems right. Some Wall St banks have a liberal, decentralized development culture, with thousands and thousands of apps deployed, some being simply spreadsheets (note: not simple spreadsheets), some being web apps, some being Java or VB, and a few being big-ass C++ projects (perhaps mostly legacy). On the other hand, you don't want too liberal a development culture in a bank, lest it foster a liberal administration culture, which leads to disasters where front-office people have access to back-office systems and then are able to hide losses, embezzle, etcetera. It is possible to have a culture that encourages light-weight development while keeping an eye on what the apps do. Once an app proves widely useful you can then work on scaling it to the enterprise without a billion dollar budget.
[link]
From: Richard (Jan 07 2010, at 10:08)
Interesting article with more than a hint of truth as I am still trying to work out what "Enterprise" means. There appears to be an interesting parallel with the white space between organisational units and the white space between service packages presumably bridged by web services, xml etc. The point being that typically these interfaces are the areas that cause us the most hassle.
[link]
From: trickydick (Jan 07 2010, at 10:19)
Having lived a few years and worked in large and small organizations, I think you are missing the point.
People who work in large enterprises are not interested in being part of the solution, but have a vested interest in being part of the problem. The fact that there are far better ways to solve problems is largely irrelevant: the design and build approach of large enterprises is designed to be inefficient and creates bureaucratic inertia
And bureaucratic inertia is a safe haven for the less ambitious.
The real problem is not one of methodologies, but of human nature.
[link]
From: mdh (Jan 07 2010, at 10:24)
In my experience, the biggest impediment to success on a lot of enterprise projects is the legacy issue: legacy data, legacy operational (and technology) process and legacy views on 'how we do things round here'. The key advantage that Web firms have in this respect is that they generally don't have 30+ years of legacy issues pulling their project in every direction except up.
[link]
From: oltranscendence (Jan 07 2010, at 11:54)
This discussion is fantastic! Like others, I hope it gets summarized (and probably will by Michael Krigsman and others following this thread). My only comment is to the folks that say that this problem has nothing to do with IT and that it's a 'business' problem that needs to be solved.
It seems that it's the essence of good Enterprise Architecture (and Enterprise Technology Architecture as a subdiscipline within that) to work with the 'requirements generators' (or the 'business' side of the house) to help them frame the problem in such a way that the complexity is managed. It's a two-way conversation that allows the functional requirements to be manageable, and IT can help the business scope and compose the problem successfully. As Dion Hinchcliffe and others have noted, this is where the slow evolution (NOT NECESSARILY revolution) to SOA principles at the business and technology level will help.
[link]
From: Jed (Jan 07 2010, at 13:15)
There's middle ground here. Requirements documents are ok as long as they are real requirements about real things and don't mention code at all.
Fixed costs can be accommodated.
I worked for a company that landed and delivered a significant contract from a government department by simply playing along.
We won the job by providing a working prototype at our very first meeting (1 day well spent).
We then followed the requirements, produced the simplest possible spec which got approved, then built out a modern system based on 'cool' web technologies.
They were so blown away by the fact that we hit every milestone and the system, you know, worked, that they very very quickly got over their concern about code specifics.
That was a glorious triumph back in 2004/5.
In 2006, due to the success of the project, it was expanded to a larger regional area. It also needed to communicate with an as-yet unbuilt national reporting system using some rotten custom enterprise protocols. We did all that. Still on time, still on budget and It all worked. We were the only region in the country that ever got it all working properly. We were the only region in the country ever to successfully post our data to the national system.
And then, in an 'efficiency drive' it was decided to standardise all regional systems. We weren't invited to bid. The enterprisey winners charged more than 50 times what we did, never did get the system running and, within 18 months the entire project had folded nationally because "it couldn't be made to work".
Still sad about that but I remain convinced that I had a glimpse of the future.
[link]
From: stand (Jan 07 2010, at 13:31)
@Nico says:
"It is possible to have a culture that encourages light-weight development while keeping an eye on what the apps do."
I think you just described Apple's App Store!
Though I think the jury is still out on the the "while" part...
[link]
From: Dave Orchard (Jan 07 2010, at 16:37)
I think this misses a very large point which is that many startups fail, for all sorts of reasons. Why is Tripit winning over Dopplr? If you think corporations need to run their projects more like web startups, then the corporation needs to staff multiple project teams for each "deliverable". That deliberate competition is typically seen as evil in the enterprise/corporation.
[link]
From: Phil Simon (Jan 07 2010, at 16:42)
Tim
Great post.
I'd like to point something out:
<b>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.</b>
This is very true but, as we all know, many COTS projects are unmitigated disasters. I've worked on more than I care to remember.
I'm convinced more than ever that data quality and governance are extremely overlooked factors when contracts are signed. On my current engagement, things would have been markedly better if the organization's culture had been stricter about DQ over the last decade. Of course, vendors don't stress this (nor do SIs eager to get a gig, especially in a bad economy).
I could go on but I've already written a book on the subject.
I also agree that Agile methods offer hope but, to your point, it's hard to roll out payroll or financials for part of the organization. There's a part of ERP projects that lend themselves to big bangs and, of course, big failures.
[link]
From: Conor Neill (Jan 08 2010, at 02:54)
I spent 9 years at Accenture. I agree with this post. It is a shame that so many resources are wasted on giant enterprise systems that take on a life of their own and fail to meet the needs of any "real" customer.
In corporate IT, there are some brilliant people, some decent hardworking people and some shysters (no idea what they are talking about but determined to never say so). The challenge is they all do a great job of sounding like they know what they are talking about.
[link]
From: Mark Morrison (Jan 08 2010, at 10:49)
I imagine all of those enterprise idiots said the same things about Web 1.0:
'You know that email and web browser thing will never work in the enterprise, stick to Lotus Notes'
[link]
From: Natural Selection (Jan 08 2010, at 11:50)
The Enterprise Lackey is a common breed. We've all met the type: whenever you propose a new idea (such as web 2.0), the enterprise lackey quickly jumps up and rattles off a laundry list of reasons why your idea will never work.
When you ask them to suggest a better idea they will mention a few vague epithets like: 'Better Project Management', 'Improving Business Processes'.
Sure Web 2.0 methods in the enterprise could fail, but we need to at least TRY. If your not going to contribute go back to brown-nosing your boss and get out of our way.
[link]
From: eelco (Jan 08 2010, at 15:07)
You can use any development methodology you like, but if the organisational complexity (stakeholders are everywhere) of an enterprise is not fundamentally brought down, none of them will help you. And possibly, if you did manage to lower that complexity that much, the development methodology will be agile at once.
Enterprises are doing it wrong indeed. It's just that 'it' is not building systems.
[link]
From: Thomas Lukasik (Jan 08 2010, at 18:29)
>> "The time between having an idea and its public launch is measured in days not months, weeks not years."
>> "And what do you get? Facebook. Google. Twitter."
Seriously now, Tim.. that kind of exaggeration reminds me of Guy Kawasaki waving around his little "Truemors" site as if it were a useful yardstick for measuring every other Web 2.0 initiative in existence.
The Facebook, Google and Twitter that we now know did NOT emerge in days or weeks, and in fact are still undergoing continuous development and remain in a constant flux after many years. This level of volatility and instability may be acceptable to users on the Web, but not in the typical Enterprise -- at least not yet.
Now having said that, I do agree with most of your arguments, and have myself approached Enterprise development in a very Web way for quite some time. An added benefit is that all of the "Enterprise" software that I've built this way has been deployable to the Web/Internet with little or no effort other than configuration changes and dealing with normal and expected hosting and security issues.
It's great that someone with your visibility and platform is advocating this as a way to deal with the insanely pricey, artificial and very clubby "Enterprise Software" space that vendors have cultivated so carefully for decades.
Thomas Lukasik
ISV, Exnihilum
[link]
From: Ricky (Jan 08 2010, at 22:52)
"What I’m writing here is the single most important take-away from my Sun years, and it fits in a sentence"
Yes, but it doesn't fit in 140 characters, damn it!
[link]
From: Isaka Traore (Jan 09 2010, at 07:05)
Good article, insightful and thought provoking. Thanks for sharing. The reactions also make a good read.
The old saying goes like "a fool with a tool is still a fool". I'd fancy a positive version of it like "a smart with a tool is a super smart". In my experience, aptitude should be matched with an equal measure of attitude. Whenever the combination lacks of balance, failure looms. There's a lot of preaching the good message, there's far fewer doing. Anyone claiming to have all the answers is definitely deluding.
I've posted a longer comment on my own blog: http://blog.mimozar.com/2010/01/09/failure-with-enterprise-systems-why-we-dont-learn-and-what-we-can-do-about-it/
[link]
From: Ross Jimenez (Jan 11 2010, at 13:58)
Great Post and Comments!
One key thing is the folks who program on the web generally know how to fail "Quickly and Cheaply" and then iterate until they experience some success. The patterns and practices of web developers are generally geared to this mentality. Agile, quick, iterative...
An opportunity for the Enterprise is to learn how to do the same. Although the Enterprise is full of failures they do not embrace it usually because it is difficult to afford given bloated processes and methods.
[link]
From: Michael Mullany (Jan 11 2010, at 17:41)
Enterprise systems are hard because enterprise businesses can be really, really, really really complicated. In many cases, there are literally decades worth of different businesses, product lines, product versions, contracts, discounts, special one-offs, regulations, etc. etc. etc. that need to be captured in a core system. And there are roomfuls of legacy systems that no-one can figure out -- all they know is that they just work.
Web 2.0 businesses may have enormous levels of scale, but they're far far less complex than let's say a life insurance company's systems with a 100 year book of business. For these businesses, the data model alone can be so complex that no-one person can keep it in memory at once -- which in my mind is the limit for truly effective development.
[link]
From: Julio Hernandez-Miyares (Jan 11 2010, at 18:33)
At some point would like to correlate degree of technical acumen/experience in IT Management (people with the authority) and it's role in malfunctioning IT projects. Usually the Web companies held up as examples of "doing it right" are product engineering/technology focused and have a good idea what it takes to actually write software.
[link]
From: Robert Young (Jan 12 2010, at 07:39)
>> At some point would like to correlate degree of technical acumen/experience in IT Management
Having worked in both small (web and otherwise) stuff and huge corporate stuff, the difference is as one would expect: the small stuff (web and otherwise) tends to be tech driven, while the corporate stuff tends to be sales driven. By the latter, I mean that managers of IT in corps almost always come from sales, occasionally finance, and neither know nor care about the tech. There is a reason that so much Fortune X00 software is still 30 year olde COBOL with 29 years worth of patches. "We've invested 30 years of effort in the POS, and I know it's a POS, but you're just going to have to add Feature XXY anyway you can". Same thing happens when the 30 year olde COBOL application is web-ized: the datastore and application function is java-ized (mostly now; C-ized in prior years) from the original.
We tear down football stadia with more recognition that sunk costs are irrelevant to decision making than we do software applications. It is our fault.
[link]
From: Ron Smits (Jan 12 2010, at 23:49)
One of the main problems is needing to have the costs clear up front in an enterprise system. It is very reasonable that a client wants to know up front what he gets, when and with a clear price tag.
Two big things need to change in my view: The large upfront formal requirements, they will usually change too much or not be valid anymore at the end of the project.
The notion that IT must be cheap. Remember the line from Armageddon "we are itting on 1000000 pounds of explosives built by the lowest bidder". Basically you get what you pay for. Those things (costs and requirements) often even work against the project and lead to long discussions.
Software should be build the unix way again, small simple applications that can only do one thing and do it well.
[link]
From: Robert Young (Jan 13 2010, at 06:55)
>> they're far far less complex than let's say a life insurance company's systems with a 100 year book of business. For these businesses, the data model alone can be so complex that no-one person can keep it in memory at once -- which in my mind is the limit for truly effective development.
An interesting observation, but a bit misleading, in that most life insurance companies, big and small, have ceased writing this function over the last 30 years, and most have bought a system which is, wait for it.... 30 years old with 29 years of patches (and customizations). I wrote some of one of them. Eeew. To say that any of them has a "data model" is way overstated. They have file definitions and millions of lines of COBOL, nothing more. The complexity lies in the fact that there is no "data model". I'm no longer doing that because no one wanted to simplify; there's too much money to be made bleeding the clients. And the same is true for any software vendor with a modicum of lock-in. And all vendors, linux distros possibly excepted, seek just that monopoly power.
Now, it used to be a given that a large organization would never buy-in software for running the core business; after all, this is what makes your business unique. But SAP, in particular, has demonstrated that American Fortune X00 really don't have any core functions any more; at least not important enough to implement unique and better software .
The upshot is that for such Enterprises, IT is over the transom and out of mind. Their "business analysts" argue with the vendor's "business analysts" who argue with the vendor's coders who argue with the vendor's database admins. Some do buy source (although less so in recent years) and do the tweaking themselves, but are still bound to the underlying architecture, which was locked-in 30 years ago, natch.
The notion that one can just "buy-in" SAP or such for administrative stuff is factually wrong. SAP and all the "vertical market" vendors make a plain vanilla version, and then claim "just a few tweaks" will transform it to the perfect solution. The point being: even in Enterprise these days, much of the most important software isn't made by the Enterprise at all. It's made by low bidder (high commission; see Spolsky on this theme) outsiders.
[link]
From: Paulie (Jan 21 2010, at 09:48)
"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."
But you're probably one of the few whose salary doesn't depend on the continued presence of this problem... I hope you will follow up on this post with references to others thinking along these lines, and/or what more we can do.
FWIW, what I see is that most F1000 IT organizations are ponderously large behemoths that concentrate a bunch of unrelated processes under the "IT" label because they somehow have to do with computers. Most of this stuff is commodity and should be outsourced ASAP, if only to remove the political drag produced by all the managers of this quagmire.
Unfortunately, the one part of today's IT orgs that matters - application development tied to business core competency and competitive advantage - usually gets lumped into this same mess.
If nothing else, the AppDev should be separated from the IT dept and become a direct line-item responsibility of the LOBs; this would turn into a bunch of smallish appdev groups, each closely aligned with some part of the business's operations. The advantage is that you have the possibility of creating an entrepreneurial environment where both the techie and business nerds work together to create something cool (and profitable).
Now, all that said, LOB management is going to have to learn some new tricks as well. In particular, they will have to understand and take responsibility for their operations. Just as important, they will have to learn to share costs and have an incentive to effectively team with other LOBs for the benefit of the enterprise.
[link]
From: Robert Young (Jan 23 2010, at 20:26)
>> If nothing else, the AppDev should be separated from the IT dept and become a direct line-item responsibility of the LOBs; this would turn into a bunch of smallish appdev groups, each closely aligned with some part of the business's operations.
The major objection to doing this: we learned in the 1960's that such an approach leads to the Siloed Application. This was tolerable in the days of COBOL and files. Dr. Codd's database approach showed that an integrated, shared, common datastore made more sense.
At least, the datastore should be centrally managed, even if "appdevs" code in siloes; leads to less duplication, collisions, and mess.
[link]
From: Paulie (Jan 26 2010, at 05:21)
Hmmm, centralization has been working so well? I see that most IT projects are separately funded LOB projects with their own... well, everything. IT centralization, as currently implemented by any organization I've ever seen, is part of the problem.
More important though is the lack of knowledge and talent for exploiting IT at the corporate management level... And you can't get this with the funding practices and incentive programs currently in place. Exploiting IT is holistic and transformative; you can't just buy a bunch of systems and system people and expect a desired result.
[link]
From: Satty Bhens (Jan 27 2010, at 08:58)
Tim, nice post and lots of great commentary to go along with it. I agree, the opportunities are big and there's no silver bullet.
Having said that I'm in an enterprise that has made much of the transition from 'doing it wrong' to 'doing it better'. So what you've articulated is achievable despite the complexity, legacy and existing cultures in enterprises shared in the comments.
Four years ago our organization was crippled with legacy "enterprise" apps and never ending multi-million dollar projects. Fast forward to 2010, our typical projects are 90 days and getting shorter, our development organization is one-third the size it once was, our support costs are down 80%, and I believe folks (stakeholders, users and IT) are happier.
Here's what I believe worked for us...
a) Invert typical team hierarchies, enable developers and users to play lead roles, minimize the number of people who proxy these groups (they just add cost and complexity). We've had to significantly re-structure conventional roles for project managers, IT analysts, enterprise architects, IT leaders, project sponsors etc to achieve this.
b) Have both tech and business folks in leadership roles who have an appetite for change and a tolerance for failure. We avoid starting projects that cannot demonstrate user value in 90 day increments, we've established a governance and funding process that enables projects to be deployed in 90 days or less. We've had the odd failure... but it helps when your boss say's "there's very little you can screw up that he can't fix". On the tech side, our preferred development language is Ruby, we build daily, we use and contribute to open source projects, TAFT is the norm.
c) Users are able to remove complexity much better than stakeholders. Get stuff in front of 'actual users' as quickly as possible and iterate. Now we only write code we absolutely have to, we start with open source options, and are not afraid to start over if the users don't like what they see.
Along the way we unearthed some gems too, for example we eliminated our QA group and quality improved dramatically, we had senior developers lead support for a few months and their follow on project had zero support issues during launch.
[link]