Business Information Technology: Foundations, Architecture, and Culture

BIT is a response to the fact that existing business oriented introductory computing textbooks focus on the wrong thing and are filled with errors of fact, interpretation, and omission - something I discovered by accident while serving as a sessional instructor at the University of Waterloo.

My students were capable of memorizing almost anything long enough to reguritate it on exams, but fundamentally didn't learn anything by doing so. Pick a programming language from the typical textbook's laundry lists of second, third, and fourth generation languages and ask them what generation the book's authors thought it belonged in, and they'd give me the right answer every time. Ask them, however, to classify a language by generation given its main characteristics, and they'd be guessing every time.

Error Free?
I usually tell people that half of what I know is wrong, but that I never know which half until it's too late. In reality, fact checking for BIT proved that both halves are about equally questionable.

The Intel group invented the Microprocessor right? No, Ray Holt and his colleagues working on the F-14 program did. "3rd generation" as in geneology, right? no, as in "code generator;" "Open Source," Torvalds and/or Raymond, right? Well, no, Torvalds actually used an open source kernel to start with, the key ideas go back at least to 1966. The relational database was intended as a data storage technology, Well, of course, right? Actually, no. Its primary purpose was data integration.

My design goals for the new book were therefore first to avoid errors and secondly to provide the information in a way designed to facilitate learning rather than memorization. In other words what I wanted to provide the student was a framework into which new information could be slotted, evaluated, and assimilated or rejected.

The first part of that framework came from simple chronology. Present the information needed to understand business systems architectures in the order in which the tools and technologies were developed and new information simply adds to old. In effect, attaching a date tag to information both removes the ambiguities and allows the student to see how the development of each version affects products he, or she, will be asked to evaluate next year or next decade.

Chronology by itself, however, is inadequate because the technologies did not develop in a single linear stream. People in the fifties, for example, were working on forecasting methods only now being applied in some advanced supply chain packages.

The primary modifier developed to make chronology work as a framework for knowledge assimilation turned out to be the killer issue in the book. This is the Darwinian notion of speciation.

In business, 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. In the Systems context, speciation describes the problem driven co-evolution of hardware, software, and management methods in business.

People who see personal opportunities in solving a particular class of problem will develop the tools and skills needed to do so. If their efforts are successful and those tools and skills become widely used, a specialist culture will develop around them. That's Darwinian speciation at work, creating a culture perfectly adapted to applying the tools they know to problems they understand.

Once a culture succeeds, however, it becomes tremendously change resistant. 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. Drop it on the Serengeti and it will starve, not because it isn't competent as a seal hunter, but because African pronghorns aren't seals.

In a systems context, if Dick and Jane are systems experts from different cultures they'll disagree on most technical solutions, not because they're incompetent or antagonistic but because they'll both see the problem and its solution solely in terms of the cultures they represent.

Apply speciation to the history of business computing and four generally linear chronologies become apparent.

  1. Many of the technologies, management ideas, and organizational design structures that evolved to characterize the professional data processing community of the nineteen twenties and thirties survive, essentially unchanged, in today's IBM zSeries data center.

  2. The leakage of academic research into business uses of optimization and related scheduling technologies during the nineteen sixties gave rise to an "application appliance" culture whose most recent resurgence, in the mid ninties, drove business acceptance of Linux and BSD.

  3. Research computing from the forties evolved directly into what we now recognize as the network oriented, Unix based, open source movement.

  4. Unlike the other three, however, the Microsoft PC Culture is not derived from the combination of a business problem with a successful technological solution: instead it appears to have evolved as a social response to an organizational conflict.

Combine speciation with chronology to hang both a cultural and a date tag on factual materials such as the meaning of "OCR" and its easy to see what slots where and why.

The structure used for each section came from thinking about student needs in working through one of these cultural chronologies. The student, whether this is a future B.Comm, MBA, or CA/CPA, will be mostly focussed on eventually taking up a decision making or advisory role, not a technical one. As a result I decided to focus everything on providing the student not just with technological information, but the ability to assimilate and judge new information in context. That, in turn, led to some quick content selection decisions including:

  1. focus on the decision maker's role in business computer system deployment;

  2. present realistic business cases including real costs and sample resumes for typical players;

  3. forget political correctness; and,

  4. issue no laundry lists - providing detail only where warranted by the need to provide adequate explanatory background.

The result is BIT: Business Information Technology: Foundations, Architecture, and Culture; now just over 400 pages in this version. BIT is unintentionally revolutionary, primarily because speciation provides such a simple (and retrospectively rather obvious) tool for understanding and resolving systems conflicts.