“Enterprisey”

I began using the term “enterprisey” along with Tyler, my friend and longtime co-worker, around the time we both read Martin Fowler’s post on Ruby and its relationship with the enterprise world.

Many developers consider enterprisey to be a derogatory term that means “complex; over engineered; too rigid and downright ridiculous.” The term has spawned a lot of discussion, which, I think cuts to the core of professional software: We want to build software that is strong, robust, complete, and a joy to use. But we also want to build software that can change at the same pace our business changes.

A growing business is too fragile and opportunities are too fleeting to allow its software and technology to hold it back. If software can’t change quickly enough or it is constantly derided by the business people when the geeks aren’t around, then the IT group either needs additional people to help meet the need or they aren’t doing a good enough job architecting their system.

Rule #4: There should be a 1:1 ratio between the ability for an organization to leverage a business opportunity and the speed its software can change in order to attend to the new process. A company’s software should never hold back its desire or ability to change the direction of the Bus.

Everybody knows that enterprise software becomes complex and rigid because there are so many requirements around robustness that simply don’t exist when I set to write, for instance, a quick web application for keeping stats in the never ending office foosball tournaments.

But it seems funny to me that in software “enterprisey” means a system that is too leaden to meet changing requirements while in business the term “enterprising” means something that is agile, creative, and capable of succeeding no matter the obstacles.

Because of this drastic dichotomy in meaning of two related words, I tend to think of enterprisey as describing not the over-engineered kind of software, but rather something that has simply been promoted from the quick-and-dirty “rapid application development” phase to something that is robust, auditable and fault-tolerant.

I firmly believe that enterprise-quality software doesn’t have to be enterprisey in the derogatory sense. There is an ever-adjusting balance between robustness and flexibility and good developers must learn the practices of Lightweight Enterprise Software in order to meet the requirements of an enterprising organization.

I also firmly believe that an organization should not have patience for anything less.