January 4, 2007


A kludge (usually pronounced klooj, with the oo and in food) is something thrown together thoughtlessly, and usually quickly, which works, more or less, but which is generally ugly, and may be either underperforming or missing functionality or both. Examples include quick scripts for copying files across the network as a sort of poor-man's backup system, or using system components for purposes for which they were not designed (such as using print queues as a network messaging service — and yes, I've actually seen this done). A kludge is not necessarily broken, but it is necessarily inelegant, often even ugly, and generally offensive to the sensibilities of all right-thinking IT people. In other words, the term is usually an insult.

Posted by jeff at 6:05 PM | TrackBack


An enterprise, in IT terms, is any large, widely-dispersed or otherwise complex organized undertaking. A simple example would be a single organization with employees and systems at more than one site, while a more complex example would be a group of companies cooperating on a joint venture of some sort. The word is, sadly, widely misused, generally as a synonym for "corporation". But "enterprise" implies a much broader context than that.

Of course, this is an example of overloading a non-IT term (for any given business venture), which is part of the source of confusion. In IT, an enterprise is always either large, which is inherently complex, or is complex due to some feature of organization or distribution.

To be more formal, a good general definition of "enterprise" would be any relatively large (say, more than 1000) set of people involved in a joint undertaking using shared IT resources, and meeting any of the following criteria:

  • People involved in the undertaking are dispersed at more than two sites, widely separated, with no more than one fourth of the people at any given site.
  • IT systems used by people for the undertaking are located at widely separated sites.
  • Multiple distinct IT systems are used in the undertaking, and they share infrastructure components, user identities, management practices, administrative reporting structures and/or data.
  • IT systems used by people in the undertaking are required to be available 7x24.

Fundamentally, each of these criteria introduce complexity. Most enterprises share meet all of those criteria. And for enterprise-level IT workers, vendors and management, it is that complexity that requires the need for a new term. While some critics use the term sneeringly, to mean an overly-complex system or application, the reality is that it is a useful term for differentiating systems of high complexity from those that are relatively easy to maintain, or whose availability is not critical.

To use one example, consider the web server this site is hosted on. It is a single server, running Linux off of two not-entirely-mirrored disk drives, in the basement of my house, with a single fairly reliable internet connection (that is, the connection is down less than an hour per week, on average). That is not an enterprise configuration. Let's say that I wanted to have the system available continuously from anywhere under any circumstances; to do that, I would have to eliminate single points of failure, and reduce the possibility of failure even among duplicated components. How would I do that?

First, I would have to have web servers at two different, widely-dispersed sites, so that a natural disaster couldn't shut both (or the networks that connect both) down from the same cause. Given power outages recently, let's say that I host one in Michigan (as now), and the second in Texas. The servers would have to get larger, because they would need more disk drives to allow more redundancy in case of drive failure; and would have to have two power supplies, duplicated processors and memory and so forth. In addition, each would need at least two network connections, through different routers connected to network providers that use different connection points for their physical data links. I would have to have more, and more widely-dispersed, name servers to serve their naming information, and would have to have significantly more complex wiring to connect all of these things. This all also implies both having a dedicated machine room with special air conditioning, racks and wiring harnesses, as well as having a person available 7x24 at each site to administer the systems (which means in practice at least three people per site, and probably more). Finally, I would have to change blogging software, because this software does not have the functionality to publish simultaneously to multiple servers from the same backend database (particularly with dynamic pages, where faking it is much harder because you have to go back to the same database instance). I would have to have a significantly more reliable backup system, preferably with some near-online storage capability and automated offsite library management. I would have to get some kind of distributed authentication system in place, preferably with unified provisioning via an identity management system (of similar complexity to the web server example given).

That is actually a poor example, though, because in a real enterprise, this would be one of many interconnected systems, all of which would include multiple servers, usually on different platforms and often managed by different organizations with not-quite-synchronized goals and incentives. It should, though, give an indication of the complexity of enterprise-level systems in comparison with what one might use for one's personal use. Most small organizations are significantly closer to what I have at home than to what would be suitable for an enterprise.

Posted by jeff at 5:56 PM | TrackBack

January 3, 2007

IT Jargon

One of the problems with explaining any technical field is that there is a large amount of jargon involved, because both precision and concise expression are necessary and jargon provides that. This is certainly true of the IT (information technology — see what I mean about jargon?) world, where the amount of shared jargon is daunting, and where more than a few conversations are almost entirely conducted in acronyms. To make matters worse, or at least more confusing, each enterprise develops its own jargon, or its own definitions of fairly standard jargon, as it goes along. Finally, adding insult to injury, the same term is often overloaded with multiple, similar but distinct meanings. The resulting terminological ambiguity is sometimes comical, and often expensive (miscommunication costs money to fix the resultant mistakes).

When I decided that I really do want to talk more about what I do for a living, the first thing I wanted to address was what makes an enterprise so different from any other computing environment, and why enterprise IT is so difficult to get right. But I realized that in order to do that, I would have to either heavily footnote the entry, or start by explaining a very large number of terms, which would heavily distract from the point.

Fortunately, there is a better way: a jargon dictionary. Such already exist (see here and here for a couple of good ones), but none of them are very complete, and mostly their definitions are themselves laden with jargon. As a result, it appears that I'll just have to write up the jargon as I go along, in entries separate from the topics I'm actually discussing. My definitions may not be canonical, but they will at least allow you to figure out what I'm talking about.

So consider this post both an introduction and a request. Are there any computer or IT terms that baffle you? Ask in the comments, and I'll define them, without unexplained jargon and with examples and maybe even color glossy photographs.

Posted by jeff at 6:02 PM | TrackBack