% fortune -ae paul murphy

Introduction to BIT

This is the 1st excerpt from the second book in the Defen series: Business Information Technology: Foundations, Infrastructure, and Culture

Introduction

This book is designed for people who interact with, but do not want to become, professional information systems staff. It is a management guide to information systems for auditors, executives, and business owners who want to understand what the issues are and how to resolve them.

As a manager, business owner, or management advisor you will often find yourself forced to make decisions in situations where systems professionals either hold conflicting opinions or seem to have considered only the alternative they're most comfortable with. Whether what's at stake is Sarbanes-Oxley compliance or a strategic business opportunity doesn't matter: it's their field and their professional vocabulary, but it's your decision and you, not they, will wear the result.

Preparing you for situations like these is the most fundamental thing this book is about. Not just helping you past the jargon barrier so their vocabulary doesn't leave you locked out; but getting right to the hard core of the issue: helping you understand the real relationship between their ideas about computing and the business problem your organization is trying to solve.

Read this book carefully and you'll understand that systems decisions aren't usually about bits, bytes, or gigahertz; but about people and the way their ideas and interactions affect your organization's ability to do its job.

In the long run business success is determined by how technology is applied, by the things people think they know about technology and how to use it, not by the technology itself.

Talk the talk, but understand the people: that's the hidden lesson from ninety years of business data processing - understand it, and making smarter systems decisions will become part of your professional repetoire.

To the non technical manager a computer tends to look a lot like a computer, but that's not true from the expert's perspective. If Dick and Jane are two systems experts with differing views on a technical issue, those views will reflect what Dick and Jane think they know about computers and therefore the differences in the forces which shaped their opinions.

Dick and Jane may genuinely both be experts, people who deal with computing on a professional basis and whom you'd expect to resolve minor differences by working out the facts, but reality doesn't work that way. Instead they will usually try to focus discussion on the differences, rather than the commonalities, in the technology choices they support.

In most cases these differences are minor in the context of the business, but just as the protagonists in racial or religious wars are usually willing to die to perpetuate differences that are invisible or unimportant to outsiders, so too will Dick and Jane unknowingly sacrifice your business to the unalterable certitudes imposed by their backgrounds. In fact, expecting Dick to work with Jane's ideas, or vice versa, will predictably have roughly the same effect as hiring a Catholic principal for a Protestant school in Belfast.

Things got this way through the problem driven co-evolution of hardware, software, and management methods. In business information processing, as in nature, only the fittest survive - but, again as in nature, fitness is determined by local circumstance. A polar bear is superbly adapted to life in the Arctic, but wouldn't last a week in sub-Saharan Africa.

Speciation, the evolutionary response that adapts some bears to the desert and others to the Arctic, is driven by the problems the organism has to solve to survive and prosper. Once that evolution succeeds, however, the change processes stop; freezing both behavior and perception in place. You can put a polar bear in a southern California zoo and feed it chickens, but it will always scan its wading pool for seals.

The same thing happens among groups of professionals confronting problems or opportunities. They rapidly evolve characteristic methods for using the tools available to solve the problems they see, and then recast their perception of the environment around them in terms of the problem set that drove the group's initial development and specialization.

Generally speaking hardware differences are used to label systems cultures, but the real differentiation comes from management practices and habits of thought; not hardware. At the global level a computer really is just a computer, but the management reflexes that are automatic components of the one right way to run a mainframe data center generally constitute obvious insanity to the Unix systems manager and may be utterly incomprehensible to the Microsoft guru.

If Dick is from one camp and Jane from another, their arguments will usually both be right within the context of the information systems culture they belong to. Dick will genuinely see seals where Jane sees berries and anthills, not because they are antagonistic or incompetent, but because those perceptions reflect their systems cultures. In choosing between their positions you need to look beyond their arguments to the cultural coloration through which they filter their perception of both the problem to be addressed and the solutions appropriate to it.

Making systems decisions, choosing between Dick and Jane, is likely to be an every day part of your role as an auditor, a manager, or a business owner. To do it well, you need first of all to be able to communicate effectively with both Dick and Jane. That means much more than learning some acronyms and speaking the words of their language; it means understanding the evolutionary pressures that produced their ideas, their reflexes, and, above all, their verities - the things they never think about but which their particular systems culture treats as eternal and unquestionable truths.

That fundamentally is what this book is about: demystifying jargon while helping you understand how Dick and Jane got their opinions, what their cultural assumptions are, and how to understand and balance the values implicit in those assumptions when you have to choose between them.

---

Some notes:

  1. These excerpts don't 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.

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


Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.