It’s Ok To Call Software “Enterprise”
Tuesday, February 27th, 2007“Enterprise” is a dirty word in some circles. It is typically taken to mean:
- Big and impressive (or, they’d like you to think so).
- Overengineered, overdesigned, and generally far more complicated than necessary.
- Weighed down with legacy cruft.
I avoided the word for a long time myself, associating it with the sort of overwrought J2EE apps that require 10 developers to support, and probably could be replaced with a 200 line Perl script.
With a name like Patterns of Enterprise Application Architecture, it’s a wonder I ever bothered to pick up and read Martin Fowler’s book. As it turns out, he gives an enlightened definition of enterprise which showed me that the word is pretty useful when used correctly.
Enterprise doesn’t mean big, but it does mean complicated. It means necessary complexity, because the application is modeling some sort of real-world business process which is, well, actually complicated. LiveJournal is not an enterprise app even though it’s very, very big. It has tons of users but its basic function is simple, and it’s not modeling any sort of complex real world activity. (Though one could probably make a good argument that tracking the current moods of ten million teenage girls is a special kind of complexity all its own.)
On the other hand, you could have an order processing system for a small business which doesn’t handle a lot of volume, but is correctly called an enterprise app because it is encoding a series of detailed business processes.
Perhaps a good example of an enterprise system would be a package tracker for a carrier like FedEx or UPS. Although the front end is simple (type in a tracking number and see where your package is), the internally facing components of the software system are numerous and varied. You’ve got labels being printed through a website and an API, you’ve got scanning the packages as they go in and out of facilities, which has its own specialized hardware setup; you’ve got the handheld devices carried by the door-to-door guys that is also specialized hardware; and you’ve got billing systems on the backend, which almost need to be able to handle claims for failed deliveries. Now think of all the different states a package can be in as it travels. There are a huge variety of exceptions that can happen. This stuff is all in the real world, so you can’t easily say, “Well, we’ll simplify the code by just ignoring this case over here.” A tracking system which can’t track the package’s state and location at all times would be pretty much useless. You’re forced to have a huge amount of complexity, like it or not.
Now for the punchline: a good technical design correctly models all of that external complexity, while being as simple internally as it can possible be. You’re encoding a business process that is really complicated - why make things worse for yourself by having the software add complexity?
Of course no one really intends to add complexity (I hope). It’s just that, well, a streamlined design that covers many cases with a minimal amount of code is really quite difficult. People that can do it well (this trait seems to run in the Fowler family, for instance) can make a lot of money doing it.
The difficulty is further enhanced by the fact that enterprise software tends to have a lot of legacy baggage due to its organic growth and long lifetimes. You thought that migrating your mom from Windows to OS X was difficult? Try moving 100,000 employees spread out across the globe from the historic app to your shiny new one. They depend on this thing to do their job, day in and day out. If it was a consumer app, it wouldn’t be a big deal: they could move across one at a time. For an enterprise app, the only real choice is to run both systems side by side for some period of time. But just think of the package tracker again: when the systems get out of sync (and it will happen), mass confusion ensues. Not good.
Since I’m in the enterprise app business, you might think the purpose of my post is either to scare away potential competitors (”What we do is hard, don’t even try it buddy!”) or attract recruits (”What we do is hard: you’re a developer and you like hard problems, so come work for us.”). Actually it’s neither, although if one of those things happens as a result I’m all for it. My goal is actually to get people using the word “enterprise” properly, because it really is useful for describing certain types of software development, and we need a term for this class of software.