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.
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:
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.