Robust messaging systems, ala JMS, with both pub/sub and queuing.

Good integration with Eclipse, IDEA...etc including code completion

A component-oriented templating system ala Tapestry or WebObjects.

Some big industry players to officially support this new tech. Java and .Net is considered enterprise level partly because there are big companies providing services around them.

I don't think it needs to succeed in "Big Enterprise" to make a dent. Why did we make the Rails decision for our customer? (I'm acting CTO for the start up building Justin's project.) It's cheaper; the development is faster; you can be more responsive to your customer. I think Rails breaks into the huge gap between Visual Basic and Java. I'd be happy with that.

Enterprise software is software that gets sold to a so-called enterprise. If you know English well, you might think an "enterprise" is something brave, noble, and dangerous, like starting a small business, but in this case, "enterprise" is used to mean the opposite: it means a large, risk-averse company, whose executives use the term to flatter themselves by pretending that they're engaged in something brave, noble, and dangerous. Now, these "enterprises" use a lot of software, but most of the software they use doesn't get sold to the "enterprise" itself; it gets sold to one of the employees of the "enterprise", who has the authority to spend $400 or whatever to get the software they personally use to do their job, if it's not free. That's not "enterprise" software, because it's sold to an individual, not a so-called enterprise. Software that has to be sold to an "enterprise", where some manager must be persuaded to use his purchasing authority to buy the software, is different in a variety of ways from other software. None of these ways are strictly technical. The first difference is that "enterprise software" costs more. Software that doesn't cost a lot generally doesn't need managerial buy-in to be bought (although other factors may interfere; for example, everyone has to use the same bug-tracking system for it to work); software that needs managerial buy-in generally needs expensive salespeople to persuade managers to buy their software; and managers everywhere have a well-known perverse incentive to expand their budgets. The second difference is that "enterprise software" doesn't necessarily work, although it can usually be made to work with sufficient effort. If you're spending $50 000 on a piece of software, it seems more reasonable to spend $1000 or $10 000 to customize it to your needs before you can actually use it. In extreme cases, such as ClearCase and Oracle, a team of expensive, specialized full-time employees must be dedicated to keeping the software operational. The nontechnical nature of many managers, in addition to the perverse incentives in many managerial structures, often mean that enterprise software does not have to work at all, no matter how much effort is applied to make it work, in order to sell well. The third difference is that enterprise software is surrounded by consultants who will sell you the service of making it work, as explained above. In some cases, these ecosystems of consultants are competent and highly skilled. In other cases, such as the case of Java, many of them are spectacularly incompetent, vociferous in their ignorance, and prone to attack competing systems. This proceeds directly from the sales process for "enterprise software," in which highly-paid persuaders gull technically incompetent managers into adopting the software. If the managers were technically incompetent in selecting the software in the first place, they will also not be able to distinguish between competent consultants and incompetent consultants, so incompetent consultants will flourish along with the competent ones --- who will eventually get sick of it and go elsewhere. I didn't really understand this until KnowNow, the startup I worked at, got turned into an enterprise software company by its VCs and management; although I had previously had the opportunity to observe most of the pieces of the puzzle, I clung to the idea that "enterprise software" was actually technically better in some way from the software I was used to using. It turns out that the differences are entirely social, not technical, and one of the major differences is that "enterprise software" is under much less pressure to have any technical merit.

Kragen, this is an excellent crystalization of a common enterprise scenario! This deserves a blog posting of its own.

Wonderfully put!

Curt is right, crystalization is a great term for what Kragen's done: basically distilled pretty much everything Joel Spolsky has ever written into a brief and readable manifesto. Kudos!

Yes, amazing insight. One more thing of course, the big consultanting companies, including the outsourcers from India, have immense experience writing contracts that distill down to 'They are not responsible if nothing works as the client expected'. Many customers of these organisations are really ill equipped to enter contract negotiations with the big guys.

There is a lot of BS happening in any big organisation. Any. Software development is not some sort pof exception to a general rule in that sense. In defence of those "technically incompetent" managers (among those I met, most were competent _enough_ for their jobs, by the way), many "enterprise" software systems are naturally risk-averse, not very cost-sensitive, and quite complex. It doesn't matter that much if a billing system for 10 mln customers (that's $3 bln annual revenue) costs 1 or 10 million. It does matter a lot more when it doesn't work and it gets noticed (the main damage is done by churn, not so much in direct costs). By the way, is there any system of such size (say, 100 DB table with 1 to 100 mln rows in each) that is without a "real", expensive database (like Oracle)?

I'm glad other people enjoyed my comment. I don't think it deserves to be lauded as "brilliant" or "amazing", but I'm glad it was readable without being offensive. Alexey: I'm not arguing that "enterprise" software development is "BS"; I'm just arguing that technical merit is not as important to "enterprise" software as to non-"enterprise" software, or at least that its vendors and consultants behave as if it is not, and seem to get away with it. The majority of big ICT projects, such as billing systems for millions of customers, never get deployed because the project sponsors give up hope that they will ever work and cancel them. Many of these projects include purchases of third-party software, and difficulties with third-party software are a commonly-cited reason for project delays and disappointments. Such failures, however, are invariably multifaceted, involving many other risks, and big ICT projects have been high-risk since long before the "enterprise software" industry. From my brief, foolish stint at Keane, I know that there's a culture around big ICT projects that believes that technical risks are less important than nontechnical risks, and I think there's something to be said for that point of view; but I think that while technical risks invariably arise from nontechnical risks, technical costs arise from technical risks, most nontechnical risks arise from costs, and most costs on big ICT projects are technical costs, so I think that point of view is an oversimplification. I don't know of a lot of systems with a billion data items, and I don't know much about the ones I know of, but I know of enough to falsify your apparent claim that "enterprise" databases like Oracle are some kind of panacea for them. In some cases "enterprise" systems can handle such data loads, and in other cases they can't. It really depends on what you're doing with the data. Larger quantities of data demand more specialized databases, so any particular database (such as Oracle) becomes very specialized as you approach the high end. Google's page database is one --- actually, their link database is presumably closer to 100 billion items. "Enterprise" database software like Oracle can't even come close to solving their problem. Oracle's idea of "clustering" involves sharing physical disk access, because it hasn't evolved from its original implementation on VAXclusters in the early 1980s. I don't know if anyone has ever built a 3000-node cluster with shared storage, although there are research projects like the Global File System and Lustre that try. Google built their own software with a replicated, append-only filesystem. In the MapReduce paper, they include a program that sorts ten billion randomly-generated records in around ten or fifteen minutes, despite node failures. That's around ten million records a second. The Internet Archive's Web Collection has 40 billion web pages archived. As far as I know, they don't use any "enterprise" software, for database management, system monitoring, backups, or anything else. The Web Collection is their smallest collection, but may have the largest number of items. I'm not sure. I've worked with 300-million-datum scientific data sets (from Landsat), and I know much larger datasets exist. They are essentially never stored in "enterprise" databases. I don't know why, but I guess that it may be that their essential characteristics (regularity, very small data items, very large numbers of data items, very low computational intensity, very high "insertion" rates with most data items having lifetimes measured in minutes) don't match the relational model very well. There's a lot of multimedia data along these lines these days. Brad Templeton has a 130-megapixel panorama of Burning Man 2002, with small bits of it on his web pages. DVDs are 9 gigabytes in 2054-byte sectors, each of which is a logical record; that's 4.5 million sectors per disc. Presumably there are people who have 200 DVDs on a shelf, which would amount to a "billion-record database". What kind of database you need really depends on what you're doing with the data, not just how much of it there is. Jim Gray claims that the airline industry processes a billion reservations about every four days, so it needs to have several billion records on file at a time. I have the impression that most of these records are in the single database operated by Sabre. I also have the impression that Sabre runs a TPF system with some sort of custom database system (also called SABRE). This may be out of date, as Sabre announced a move to Tandem systems in 2001. LiveJournal presently handles about 300 posts per minute. When they stopped updating their public post-per-day stats in 2003, they had handled almost 73 million posts (ending at 187 thousand per day), all of which are currently online. It appears that their load hasn't more than doubled since then, so they probably have 200 million to 350 million posts online, with maybe 8 comments on each (averaged over 25 posts from my friends list, which is unavoidably biased towards people whose posts have readers and therefore comments), so maybe 1-2 billion records total. They have perhaps 10-100 post reads per post write, and maybe a larger ratio for comments. They run on top of Linux, MySQL, PHP, Apache, and this thing they wrote called "memcached" (because MySQL wasn't fast enough on reads). MySQL handles all the writes. LJ has several days of downtime per year (from the perspective of each user), and they sometimes lose data, so they're not some kind of paragon of stability, but they do manage to handle on the order of 5-50 database writes and 50-5000 reads per second with 99% uptime. Most of their downtime they handle without interfering with reads, but they had more than a day of downtime in January in the wake of someone hitting the hosting center's master "off" switch. (Apparently there was no database corruption, but they spent 24 hours verifying that before they went back online.) See the lj_maintenance journal and http://slashdot.org/comments.pl?sid=136144&cid=11371065 for details. At around the same volume, eBay has processed perhaps 6 billion item listings so far, with perhaps 60 billion total bids to date. It looks like they currently have around 170 thousand item listings per day (hmm, I could be wrong --- I'm just looking at item numbers incrementing, and they claimed around 300 million per day in 1999), and they retain item listings online for 30 days after completion, if I remember correctly, so they "only" need to keep maybe 50 or 60 million records online. Despite this, they had several days of downtime in 1999 when their "enterprise" operating system from Sun corrupted their disks at random when under "heavy load", meaning a small fraction of eBay's (and LiveJournal's) current load. Their market value fell by 20%, despite the fact that they had had five major outages in the previous few months, at least some of which were due to software problems. WikiMedia has around 150 gigabytes of data, total. I don't know how many individual records that represents --- there are maybe 10 or 20 million updates to the English Wikipedia in it, but I'm not really sure. It's all in MySQL. There are around 10-100 million publications with MARC records, and there is apparently a single database that contains 49 million of them. MARC is not in first normal form, however; most fields can occur any number of times in the same MARC record, as a book may have many authors, many titles, many subjects, many copyright dates, and many copies in a particular library. Consequently, most MARC databases are not relational, but most of them fit the description of "enterprise software" pretty well.

> I know of enough to falsify your apparent claim > that “enterprise� databases like Oracle are some kind of panacea for them Kragen, I was _really_ asking a question :) Thanks for answering it in such detail. Alex

Alexey, I'm sorry I misunderstood you! I'm glad you found my response interesting (it was educational to write), and I'm glad I didn't put too much weight on my misinterpretation.

[...] or hating (albeit unreasonably, and with little direct experience) anything calling itself enterprise software. via Brian McCallister Planet Ruby on Rails [...]

[...] ll Those Who Wander Are LostGnu Friday April 22, 2005 enterprise software This is very true. Having worked in an “enterprise” company (Oracle) I saw all of [...]

This can be summarised by the first question that is usually asked by salesmen. "How much were you planning to spend?", or "What's your budget for this project". Seriously. And the greater the cost, the greater the pressure to pretend that it works. Fire the manager and his manager too.

[ I've found this page particularly insightful, and I'd like to add some words to the comments of Kragen Sitaker. ] Kragen, you're right, enterprise software isn't about technical value, it's merely social. However, you describe mostly the ridiculous behavior enterprises have when they sell or buy enterprise software. One could wonder why big companies trying full-time to reduce costs and spare money wherever they can still buy enterprise software. Two good reasons are : support and guarantees. Support shows up in a variety of ways, such as a technical persons to respond to emergencies 24 hours per day. This is something difficult to introduce in a 10 persons company, in particular in an ISV company. Support might also mean you can actually fix deep problems on your product because you have spare resources for such tasks, again this isn't easy for ISV. Guarantees are essential to big companies. Your bank wouldn't have you buy a house if you had no money to pay for it. A big company buys enterprise from other big companies because of the guarantee it represents : the company won't die in a week. Thanks for your prose. [ I'm too lazy to give more real life examples, as you nicely did. ]

Loic Minier, you correctly describe the theory. In practice, I've found that getting competent support from most enterprise software providers is a slow and painful process. Thankfully, some companies include a community based knowledge pool. It's usually easier to just find another user that knows a solution or worker around.

I've ended up working as an IT consultant specialising in one particular company's enterprise software. To call itself enterprise software, it must be scaleable in terms of quantity of data stored and/or the throughput of data (handling high traffic loads perhaps). With the software I work with, there's certainly a focus on scaleability issues, and I think it's this which caused it to be adopted by some big evil bank/telcoms coorporations, and hence acheiving the 'enterprise' label . But working with this software is really horrible. You can see it's designed with stupid managers in mind, making it look like it will solve all of their 'enterprise' problems, when in fact they are commiting themselves to spending vast sums of money on consultants fees to make the system work for them. The job I'm on at the moment is particularly depressing when I think about it. I can't decide who is worse. The enterprise software company who I work for, or the enterprise itself. This is a big 'enterprise' company which is struggling and laying off staff. They are heavy on stupid managers, and short of smart technical people. This is why they made the mistake of calling on us. I (and several other consultants) have been working there for over a year, on accomodation, flight, food expenses all the while. And we've cobbled together a system which is difficult to customise and has only recently got the bugs under control. I believe this has cost them about 4 million dollars. Their application does not present big scaleability issues, so the big advantage we can offer, is wasted on them. Of course the stupid managers believe that their enterprise deserves a super powerful scaleable system. They could have hired a few smart java/web programmers to solve their problem, building a better system at a fraction of the cost. Hell I would've built the system for them single-handedly fresh out of uni, if they'd tossed me say 50 grand, and everyone would've been happy as larry. The software company is providing people like me at a huge cost, to 'support' the customer. And this is why enterprises go for this software? It doesn't make sense to me. I would be more impressed by a company (or open source software group) which is providing good publicly accessible documentation, and answering questions on a support forum. But I guess I'm veering towards the proprietory/open source debate now. So I suppose I'm agreeing with this point. "Enterprise software isn’t about technical value, it’s merely social". But I'm also saying.... why??... Why do managers in these large organisations choose to use an expensive peice of software which doesn't really deliver the 'techinical value' that they need, just because they are then able to benefit from the 'social value' of hiring expensive consultants to install/customise/develop it. ....oh well ...it pays my bills :-)

[...] l, it made me laugh! Wasting a few minutes on Planet GNOME I also came across a link to a scarily accurate description of “enterprise software”. Far too close to home in r [...]

Hi! I've been programming for 20 years now, and I've been wondering what "enterprise software" meant for at least 5-10 of them. For your next trick, can you explain what "business logic" is?

I posted a slightly revised draft of my first comment above at http://lists.canonical.org/pipermail/kragen-tol/2005-April/000772.html --- hope this is helpful!

integration at the level of the business logic, transaction management and application services using component architecture of COM+/DCOM and SOAP/XML framework or the equivalent in the J2EE framework

[...] n a post by Justin Gehtland entitled Rails: What would it take?, which includes an excellent comment thread describing real and perceived issu [...]

[...] ty fixes. I’ve noticed this a machine I administer. I really expect better from Enterprise products. This entry was posted on Thursday, [...]