Adam @ Bitscribe

“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.

Let’s imagine that you had never before tried to open any canned food. Someone hands you a canopener. What do you think of this device?

It appears completely pointless. You can speculate on what it might be useful for, but mostly it will just seem like a contrivance of gears, blades, and levers without purpose or meaning. Probably you won’t even be able to remember the details of what it looks like if asked a day later to describe it.

Now further imagine you are handed a can of food and asked to open it. After variously trying to twist off the top, cut it open with a knife, and beat it against the countertop to open it, you give up in frustration. Then someone hands you the canopener - the same one you saw yesterday - and some basic instruction on its use (perhaps just a drawing of the right position to hold it in).

A light goes on in your head. The formerly pointless contrivance transforms into a magic wand that allows you easy, neat access to the delictable contents of the can. After using it you marvel at the clever contraption. Asked the next day to describe the can opener, you breathlessly go on and on about how this amazing series of gears and circular blades can be used to perform a most impressive feat.

The canopener prior to trying to open the can was a solution without a problem. Meaningless, arbitrary, an apparent waste of materials and complex design. But once you’ve grappled with the problem that the tool is designed to solve, you gain a unique insight and appreciation into the tool’s usefulness.

And so my clumsy metaphor closes, leading us to my true point: software tools. If you’ve never written a program that needed to manipulate data records with hundreds of thousands of entries, a SQL database seems like bloated, overly complex, contrived tool. If your web applications have always been limited to a few short PHP scripts, objects and model-view-controller frameworks probably look like nothing more than huge amounts of red tape.

Here’s the interesting bit: these observations are actually true. Canopeners without cans are just some much useless metal and plastic. SQL is not worth all the necessary infrastructure and specialized knoweldge for a program which is going to store a dozen phone numbers. And MVC on a simple web script is a hinderance rather than a help.

The solutions-without-problems concept is good to keep in your head for two reasons. One, when you show a useful tool to someone and they don’t get it, chances are they just have not grappled with the right problem yet. If you wish to enlighten them, then what you want to do is show them the problem instead of the tool. Once they have fully come to grips with the problem, it should only take a casual inspection of the tool to see its value.

In a parallel fashion, when you read or otherwise learn about a new tool and it seems pointless, then you should assume that haven’t come face-to-face with the problem yet. To understand the tool you’ll need to find them problem first, then get more details on the tool.

The worst offender of solutions-without-problems is academia. In high school I failed to grasp trigonometry in any serious way because I couldn’t see what possible benefit it was to compute the sine or cosine of an angle. Later on when I began writing programs to calculate geometry in 3D games, the usefulness of trig dawned on me like a revelation. “Why the hell didn’t my teachers tell me that this was actually _useful_?” I thought. Well, they probably tried, but without a (real) problem to solve, sine and cosine were just arbitrary functions.

I see this pattern heavily in CS courses: for example, teaching object-oriented programming on a small, one-person project where the benefits of OO are nearly non-existent. (In fact the extra overhead imposed in terms of writing header files probably makes it a worse alternative to procedural code.)

How can we get away from this approach to learning? I like to take what I call the Throw Them To The Wolves approach. Also known as the School of Hard Knocks. Throw yourself at a hard problem, let yourself get intellectually torn to bits, and then retreat to seek possible tools designed for the problem.

Recently I recorded a few of my developer workshop presentations for public consumption on the Bitscribe site:

http://bitscribe.net/screencasts

Sure, screencasts are trendy, but you gotta admit they are fun. (Acknoweldgements to pyvnc2swf, which as near as I can tell is the only real option right now for recording cross-platform screencasts.)

I spend a lot of time thinking about software. In this, I am hardly different from most software geeks. But I have always gotten the impression that most geeks enjoy technology for its own sake, and in that I differ. Software (and technology in general) interests me because of what you can do with it. In 2006, software can and does serve as an incredibly powerful tool - and we’ve only barely begun to scratch the surface.

Although I do get plenty of chance to talk about software with the incredible team of developers at Bitscribe, there’s a different satisfaction which can be gained by writing about it. Structuring ideas in a way that is suitable for the page helps to crystallize the ideas in the mind of the author. Hence, this blog.

I got interested in programming at a very young age, which is not uncommon. Like most kid-programmer-wannabes, I dreamed of writing video games. This remained a passion of mine throughout my teens and into early adulthood. Sadly, my dream was shattered by the very act of achieving it. After working as a programmer in the video game industry for many years, I figured out that this wasn’t quite what I was looking for in a career. But I emerged from that experience with a passion that ran deeper than my original dream, a passion for software development itself.

In the early days, anyone who wanted to make software had to interface with the computer at a pretty low level. Graphics, for example, required a knowledge of bafflingly arcane interfaces to access the video and audio hardware directly. (For a walk down memory lane, check out this article I wrote as a teenager.) In a certain way it could be very satisfying to finally discover the techniques necessary to do something like displaying an image on the screen. But the fact was that it made the creation of even relatively simple programs long and arduous. Yep, we definitely walked uphill both ways in the snow.

I dreamed of the day when programmers would use high-level scripting languages and abstraction layers which didn’t require them to interface directly to the hardware. I imagined that cutting out all the red tape required to program - semi-mysterious language constructs like #include, compiling and linking steps, varying CPU byte order and byte depths - would someday be automatically handled, leaving the programmer with nothing to do but focus on the purpose of the program itself.

I’m pleased to say that that day is here.

Of course, it’s not quite perfect. There’s plenty of red tape issues that modern programmers bump their heads against, usually related to installing and managing all the tools and layers of abstraction that allow us to create software at a high level. But it’s extremely minimal compared to even just a decade ago. It’s true: nowadays I really do spend most of my programming time programming.