Enterprise vs. DCIDWDI
by e. sammer - esammer@lifeless.net

There are two kinds of systems, in my experience. One is flexible, robust, supports easy upgrades and maintenance, doesn't page people at 3AM, scales with business growth, supports existing and new clients with ease, and provides a consistent environment across all aspects of the system. This is what is called an enterprise system. You can refer to it as a unicorn, though, because there's a good chance that you'll never see something that fits all of those pretty descriptions.

The second type of system is the DCIDWDI style system that most of us are familiar with. For those not in the know, this is also short for Don't complain - It does work, doesn't it? This is what the majority of us are familiar with, and with a good reason - it's why most businesses are still in business.

I work at what I can only consider a sucessful place of business. I know this because in addition to paying me, they manage to pay everyone else and still have cash left over to do whatever it is people with power-suits do with money. Our system is much like what you'd find elsewhere. It has grown over time, with the company, allowing for feature additions, bug fixes, and scaling for size and speed. Most importantly, it just works.

That doesn't mean it's always pretty. I've come to feel that this is okay. It doesn't mean that I agree with the way some of it is done or that it is the model of perfection. That's just silly talk. The point is that you have to start with something, prove that it works, and lock it down. This is the normal case of the DCIDWDI system.

What happens at some point is you hit a limit. There's a feature you can't implement or some inherit design problem you simply can't work around without risking too much. Don't despair. It's not nearly as bad as it seems. The good news is that a lot of people have spent a lot of time trying to figure out how to get from A to Z without blowing the budget and risking the company's future on change.

The place one wants to get to is where the system is rethought with the current day business needs and requirements in mind. The evolutionary software design and development approach gets you from A to wherever Z is, without knowing when or how along the way. Every few X units of time, you need to step back and take a look at the larger picture. It's easy to get lost in the details of the day to day work on such a beast, so think about what it might take to tame it every once in a while.

Enter the enterprise system. Something that handles this kind of evolutionary approach by embracing the unknown. The idea behind design patterns, common application foundation (libraries, toolkits, and frameworks), consistent architecture and structure (behavior predictability), is not to solve all problems up front or even to figure out what they are. The real goal is to figure out where things may change and grow and encapsulate that in something that is easier to manage.

For example, pick any large scale application you know of (or invent one in your head for this exercise) and ask these kinds of questions.

Does it need to be scalable by adding machines?
Some applications ultimately need to scale (or could, in the future) by adding machines and load balancing things. A good example is a web application - can you load balance it if you need to? Is there a shared object cache that wouldn't handle being run on multiple machines? Are there concurrency issues if this happens? Do you write temporary state information to local disk that wouldn't work if there were multiple machines serving the application?
Can machines serving the application in question be redundant across networks (or data centers) and still support failover?
Think about it. If you rely purely on load balancers for a web application, what happens when you lose the connection from the upstream provider? What happens if you lose the data center? The cost of solving these issues may not outweigh the cost of the solutions, but it's worth thinking about (remember, the company may need to do this one day after you've sold your stock options). You can defer things by saying this is too far off and would simply require some redesign down the road. That's a perfectly good answer if you need to get an application or system off the ground (i.e. with a new company) but you should note it as a known limitation of the system.
If it's a distributed system, can it be effectively managed with regard to configuration, setup, and daily administration?
For things to work, what is required to setup new machines? What do you need to do if you switch ISPs or an employee leaves the company? What happens if you need to add, remove, or switch firewalls or network topology in the future? There's a lot to consider when you talk about managing a distributed system on a daily basis.
What stages of the system do clients need to interact with?
More so than that, what will they need to interact with in the future? Will they want to call parts of your system via an API from part of one of their internal workflow applications? This is an easy one - the answer is yes. The question you should ask is really what parts will they need to interact with programmatically? What parts will they need to integrate with?
Does your application handle security requirement changes?
Quick check - what if your boss told you that you needed to add audit logging at every stage of the application so clients can see who did what, where, when, and how? Logging and security can cross-cut your application (this is where looking into aspect oriented programming can be useful) and can really mess things up.

These are the kinds of things you need to consider. They define the difference between an enterprise system and a DCIDWDI contraption. In any large system you will need to face some or all of these issues. What sounds entirely unreasonable today is tomorrow's feature request. These kinds of features or structural considerations are what separate the big players from the home-grown solutions. You shouldn't expect to be able to fix everything at once or even implement it from the start (and over-planning and over-design are issues for another article, to be sure), but you always have to keep your eyes and ears open for where the application, the business, the industry, and most importantly, the requirements want to take you next.

Was this interesting? Are there inaccuracies? Could it be better? Do you want to contribute? Send me your comments.