What does "enterprise software" mean, anyway?

November 29, 2006 8:16 AM

What is "enterprise software" and how is it different from any other kind of software ever?

Some context: I'm a Software Engineering student in University, and I've taken an "Enterprise Application Architecture" course last year and have read Martin Fowler's Patterns of Enterprise Application Architecture book cover to cover. I'm not satisfied with the Wikipedia definition, either.

As far as I can tell, "Enterprise Software" is no different from any database-driven software project. For example, web sites like del.icio.us that track bookmarks and sites from millions of users... they have to deal with all the same scaling issues as a huge corporation but it's not "enterprise" software. Another example is content management software for a big site. (Does "enterprise" just mean "big"?)

The patterns in the aforementioned Fowler book are all characteristics of any decently designed database-driven application, and I don't see what makes them "Enterprise" at all. J2EE is "Enterprise Edition", which would imply that it's used in "enterprise software", but plenty of non-business applications use J2EE, which throws out the "business software" argument. Ruby on Rails has a lot of Fowler's enterprise architecture patterns in it, but what makes a Rails project "Enterprise"? Is blogging software "enterprise"?

As far as I can tell with my (limited) experience, "enterprise" just means the software is overblown, buggy, has a lot of messy code and costs a few million dollars. (I read a lot of TheDailyWTF and I'm interning at an "enterprise").

So when a teammate on a school project says "We should use C# because it's 'more enterprise'", I cringe and ask "what does that mean"? I still haven't heard a satisfying answer.

Does "enterprise software" mean anything to you, hive mind?

posted by DrSkrud to technology (14 comments total)

I'm a systems analyst at a reasonably large company, and in my company's context "enterprise software" tends to mean large, scalable, "vanilla" software packages (like our client management system) that allow for easy rollout at various nationwide sites with little in the way of "hands on" implentation support.

"enterprise" just means the software is overblown, buggy, has a lot of messy code and costs a few million dollars.

Welcome to corporate America. Most "enterprise apps" probably started life as a beautiful, shiny kernel of code that sang arias, but over the years became patched, added on to, and torn apart and rebuilt so many times that it bears little resemblance to the original - and the original developers are probably not around any more to make sense of the mess.
posted by pdb at 8:27 AM on November 29, 2006

See this thread posted half an hour before yours...
posted by kindall at 8:30 AM on November 29, 2006

Enterprise software that is sold, rather than in-house:

• is scalable.
  
• has central administration.
  
• is customizable.
  
• uses standards like LDAP.
  
• checks all the boxes on an RFP, like SOX and SAS 70.

posted by smackfu at 8:30 AM on November 29, 2006

See this thread posted half an hour before yours...

I don't want to frighten you, kindall, but I think you may be able to time travel.
posted by cowbellemoo at 8:48 AM on November 29, 2006

In a lot of cases it's just a talking point, a way of saying "this sounds important". In other contexts it does have a shred of meaning to it, along smackfu's list. You can definitely classify some software as "hobby grade" or what-have-you, e.g. if it doesn't have a large organization backing it and selling support contracts, it can't be remotely administered and silently installed/upgraded, etc. But more often than not the word just falls into meaninglessness when used in any kind of non-specific context, when it's not referring to some specific set of features.
posted by Rhomboid at 8:50 AM on November 29, 2006

Scale, as others have noted, is key here, as (typically) is uptime/availability, which has led to the concept of "five nines," (99.999% of uptime per year, or about 5 minutes downtime) as a holy grail for enterprise level systems. Small office/home office, and consumer level software/systems don't typically have those kinds of expectations.
posted by kimota at 9:17 AM on November 29, 2006

From a technical standpoint, especially in regard to scaling, Enterprise applications *do* share a lot in common with large-scale consumer applications. However, consumer applications don't need to address smackfu's list, and they also neglect a few key concepts that are integral to (good) enterprise software. These are the goals that smackfu's feature list are in service of:

* Manageability
* Reliability
* Predictability
* Scalability
* Measurability

There's also an enormous difference in the way this kind of software is marketed, sold, and distributed. These applications are typically deployed through professional services organizations, after having been sold through a consultative selling process. (See wikipedia for info on types of selling.) Often, distribution is through major software distributors, and there are explicit commitments to support and service levels.

Finally, most enterprise software vendors also make substantial commitments to their customers in regard to product roadmaps, stability of customization or programming interfaces, and even commitments to development methodologies.
posted by anildash at 9:33 AM on November 29, 2006

An Enterprise Application often comes with a support package.
In other words, some one to yell at/take the blame/fix for free any problems that arise. As an added burecrat bonus, this allows dodgy IT groups to collect/generate requirements rather than solutions, and blame vendors when the solutions don't measure up (regardless of the actual requirements produced).
I wonder if that section made it into your text book?
posted by forforf at 9:33 AM on November 29, 2006

Scale is a big one. Can the product in question handle thousands or tens of thousands or millions of whatever entities it manages/manipulates? Could you imagine a company like IBM or General Motors with hundreds of thousands of potential users be able to use this product effectively.

Control is another one is that is key. Can a centralized group of people control what all the appropriate users can do with a system. Can the appropriate permissions be delegated to others effectively or to scale out administration do you have to handle the keys to the kingdom to too many people.
posted by mmascolino at 9:37 AM on November 29, 2006

As far as I can tell with my (limited) experience, "enterprise" just means the software is overblown, buggy, has a lot of messy code and costs a few million dollars.

My thoughts exactly. While the answers above are well-thought out and really get to the heart of the question, they lack the required snarkiness of Metafilter, esp. when something as loathsome as "Enterprise software" is being discussed.

Without a single exception, every piece of "Enterprise software" my company has purchased has been a horrible choice. It's just unholy how much money we've spent for buggy, messy code that only partially fulfills our requirements.

And, anyone that talks about using C# because it's more "enterprise" clearly has little interest in programming. Double goes for J2EE.

Your favorite Enterprise software sucks. Really, it does.
posted by mcstayinskool at 9:52 AM on November 29, 2006

@anildash: That's a great answer. The non-technical side of things (how it is sold, vendor commitment, etc.) explains a lot. Although I believe that manageability, reliability, predictability and scalability are all tenets of any good software. Measurability to a lesser extent, although efficiency is still important. I can see how measurability would mean more to a larger corporation that's trying to keep track of its process to achieve a standards-compliance like ISO900x or something.

@forforf: Our textbook was talking exclusively about the technical side of things, it didn't talk about how to sell the software or deal with dodgy IT groups. ;)

@mcstayinskool: C# won after a heated argument mostly just because people wanted an excuse to learn it, which I suppose I can sympathize with.
posted by DrSkrud at 10:04 AM on November 29, 2006

I think Kindall meant this thread?
posted by antifuse at 11:27 AM on November 29, 2006

Yeah, that's probably the one. I got stuck in a timeloop for a while.
posted by kindall at 12:39 PM on November 29, 2006

I've led "enterprise software" implementations for quite a while now. In my view, consumer-oriented software is a complex piece of commoditized technology, not unlike a PC, a DVD player or an automobile. Enterprise software is a complex piece of customized, non-commodity technology that is specifically tailored to the particular project, much like a house, a bridge or an interstate highway.

Speaking as an enterprise guy, I am more attracted to the particular requirements and challenges of a highly-customized, mission-critical piece of technology, than a commodity product that above all has to achieve wide acceptance and commercial success. I am not saying that enterprise apps are harder or cooler than consumer apps: they have just different goals, much like a mass-production car is a different problem than a Formula 1 car, or a purpose-built limo.

The challenge with the enterprise space is that customers (i.e. enterprises) don't judge the success of an implementation based on the merits of the application/technology itself, but on the end result of the project: does the end-product do what they wanted? does it fit into their business process? was it delivered on time and on budget? Chances are that it will fail on at least one of these counts, if not all: not only are enterprise implementations judged more harshly than consumer apps (because the expectations are much higher if nothing else), but because there are a lot more variables in the equation than delivering a good piece of technology, there is less of a Darwininian process going on: in the consumer space, successful apps can and often do dominate their particular niche, so you end up having a low number of highly-evolved players.

In the enterprise space, there are too many variables and "survival of the fittest" doesn't quite work: the project has to be managed well, the customer and the implementor (external or in-house) have to communicate well, the scope of the project has to fit the time frames and capabilities of everybody involved, and the list goes on. In the end, you are quite more likely to have failed to deliver what the customer expected --in my particular field for example, surveys show that customers are satisfied with implementations only about 25% of the time! No wonder that half the comments here are negative and pessimistic...

But if you have to remember one thing, remember this: at the end of the day, an enterprise implementation is a peopleware project not a software project.

The upside of all of the above is that good enterprise architects are sought after, that you get to work with a lot more technologies and you get to interact with people a lot more than a cubicle-bound coder. Choose your path wisely...
posted by costas at 1:48 PM on November 29, 2006