% fortune -ae paul murphy

From Chapter Four: The Unix and Open source Culture

This is the 43rd excerpt from the second book in the Defen series: BIT: Business Information Technology: Foundations, Infrastructure, and Culture

Controls

The most important thing to note about the operation of a successful Unix data center is the relative invisibility of hierarchal control. Most people work in teams that form for specific projects and disband just as quickly. Management facilitates, it does not direct. Most new work is user initiated, annual budgets are more or less fixed but re-allocations are done on the fly. Most of the CoBiT controls simply do not apply. Most of the process documentation expected by the traditional auditor has no internal purpose and either does not exist or exists only in a form designed to satisfy an auditor.

The concerns underlying many of the CoBiT controls apply, but the way these are addressed is very different. For example, the Unix data center will have documented backup and recovery processes, but the emphasis will be on the processes, not the documentation. An audit test will consist of someone pulling the power plug on a machine - a routine drill - not of someone pulling a plan out of a filing cabinet.

The fundamental Unix control is functionality. Users are active participants in systems operations and decisions. When asked, for example, why there is no formal service level agreement, a Unix CIO to whom you explained the concept is likely to say something like: "most of my team members are, or think they are, users; why would we have a peace treaty when there hasn't been a war?"

Because a well run Unix environment requires very few technical staff but places significant technical and managerial demands on those few, succession is almost always a problem.

Three things tend to happen:

1. In larger shops people who train up to the point that they can take over operations, tend to leave this stable environment for one where they can more effectively advance their own careers - thereby leaving the organization bereft of internal successors;

2. In smaller shops the company tends to grow dependent on a key individual. Over time that person will accumulate small conflicts with more traditional managers in the organization who seize power over Systems as soon the key person leaves - and often plunge the whole organization into chaos as they bring in people from other computer cultures who then attempt to impose their inappropriate, but more orthodox, views; and,

3. In mergers or acquisitions the larger, more entrenched, IT group tends to dominate - and that's usually not the Unix shop because their budgets tend to be much smaller and the IT head tend to lack organizational visibility precisely because his systems work.

Thus the most important question to ask in a small organization with a well run Unix data center is: "does top management know and value what they have?" If they don't, succession will be a problem when the key person leaves and the company will be at risk of systems failure when it happens.

Some notes:

1. These excerpts don't (usually) include footnotes and most illustrations have been dropped as simply too hard to insert correctly. (The wordpress html "editor" as used here enables a limited html subset and is implemented to force frustrations like the CPM line delimiters from MS-DOS).

2. The feedback I'm looking for is what you guys do best: call me on mistakes, add thoughts/corrections on stuff I've missed or gotten wrong, and generally help make the thing better.

   Notice that getting the facts right is particularly important for BIT - and that the length of the thing plus the complexity of the terminology and ideas introduced suggest that any explanatory anecdotes anyone may want to contribute could be valuable.

3. When I make changes suggested in the comments, I make those changes only in the original, not in the excerpts reproduced here.