Edward G. Nilges

 

On the Culture of Data Base.

 An Essay in the Critical Theory of Computer Science

 

 Mr. C. J. Date, the founder of modern relational data base theory, has, in addition to an excellent new edition of his text on data base (Date 1999), a book giving his vision of "business rules" as "the what, and not the how" (Date 2000.)

I must, as a data base programmer myself, start off by saying that Date's work has been of inestimable value in meeting technical goals. Put simply, we would not have modern business and other systems without Date and his coworkers.

However, in practical implementations, Date's vision is systematically undercut.

"The what and not the how", in which "business rules" express what the top management of a business wants precisely and in an unordered fashion (so that their sequence expresses nothing and they are time- independent) is both an important idea and not a new idea. It has been used repeatedly to get from a bad data base design to a good data base design.

Data base designers do not read de Saussure.  What results is a nominalization and a reification of active verbs.  But just because asking what we are attempting to encode as we work in data base is a good way of getting above the details of a wrong implementation, we need not become Platonists, for the very structural difference or gap is the key point.  To think Platonically and to ask what would be the contours of an ideal "customer object" (or ideal society) is progressive if performed at the grassroots.  But to arrogate this definition and to command that its contours be frozen on high is alienation.

Because of capillary resistance to power, MIS bureaucracies systematically and silently undercut top management goals in actually implementing this vision in order to preserve their position. This will typically be at key chokepoints of the data base system.

For example, the data will be "denormalized" at one spot, using repetition of values which in an electronic context means that one or both will be incorrect, for the most part.  The technology of “stored procedures” will be used, and misused, to make a key routine an ordered, and in practice unchangeable even if wrong, sequence of "hows." An operation best expressed in set-like notation such as “the set of all male employees” will be actually coded, inefficiently, as a loop that reads records and checks the sex field…on an end-user’s smaller personal computer and not on the larger server system.

You can typically spot where this is being done by a shift in the way people talk about the system, from an open and honest way, to a strikingly anti-intellectual rave about "efficiency" that dismisses concerns as "academic."  If you press the point, you lose your job: in America, with its frayed safety net, this is no laughing matter.

The management and personnel of MIS organizations do this because their interests, while close to that of top management, do not necessarily coincide.

Furthermore, the "what and not the how" silently and without discussion encapsulates two philosophies: Platonism, and "what's good for General Motors is good for America" (and the rest of the world.)

Mathematics arose in ancient India, Africa and Sumeria as a consequence of economic activity. People resolved economic squabbles by algorithms that were strikingly sophisticated.

Thousands of years later, Plato may have denied, or was read as denying, that this work had any value, saying instead that disinterested members of the upper classes discovered a timeless world of "pure forms."

This nonsense indirectly infects the education both of CEOs and data base technicians and it causes them to strive for a timeless world of frozen "business rules." Even from a straightforward bottom-line orientation, this is just silly, for a good CEO knows that today's rules will change tomorrow.

This technological form of Platonism caused disasters years ago in the machine tool industry, as narrated by historian David Noble in his book Forces of Production (Noble 1975.)  Managers envisioned a heaven of total automation in which white collar people off the shop floor would prepare paper tapes that would, from that day forward, drive the machine tools. The machine tools would be operated, not by highly skilled union members but by "low-level people."

Bourdieu (Bourdieu 1990) in the related context of social research describes this as science, without the scientist, a remarkable phrase that encapsulates Adorno's prior research, for it is the consequence in an information society of the dream of a bourgeoisie without a proletariat.  For despite deskilling on both the shop floor and the white collar office, the CEO does not (except in a rhetorical sense) take over the job of the engineer or data base designer.  The hope, known to be vain by all participants, is that the system will encapsulate the subjectivity of the absent engineer and scientist.

Certain German myths (perhaps only dimly understood by me, as my ancestors were unceremoniously booted out of Galicia, probably as a consequence of troublemaking in 1848) may foreshadow these events and point to a repetition.  For they recount the construction of palaces and the elimination of the older gods who actually did the job.  In both Greek and German mythology, the discomfort of the new gods with demands for recompense leads to their elimination, and return at the end of history.  Wagner's encoding indirectly informs our thought, for Siegfried's contempt for mechanicals has echoed ever since.

Noble shows how this attempt to eliminate a humble personage, the machinist, and his stock of post-Enlightenment knowledge produced scrap at high speeds because of the need for day to day changes and the lack of shop floor knowledge on the part of the white collar technicians. 

 We do have to read Noble's work closely and with care, for Noble fails at a critical point.  It was said in America that the machinist's knowledge was at best folk knowledge, and Noble unconsciously supports this by celebrating the machinist's oral and tactile traditions, for in America, this is a popular Left trope, based on our guilt at having eliminated a contemporary Neolithic culture: the elimination of the oral by writing…which neatly ignored the creation of writing by the Five Civilized Tribes in the 18th century colonies.  Our left romanticism implements a capillary program.

 My experience in speaking to expert machinists and in the field of computer programming indicates that Noble may be incorrect, for in the events Noble recounts, the machinists had mastered sophisticated and enlightened physics and chemistry that their managers were in many cases unable to grasp.  In computer technology, the most feared figure by manager is not the easily controlled programmer who works using bricolage and rules of thumb, it is instead the applied mathematician able to spot serious design flaws. 

Both Noble and Date fail ultimately to grasp a post-Enlightenment whole. Understanding is at least in part knowing how, the sort of knowledge that is in the hands as well as the brain. The tragedy is that Platonism and the "what" is an engine of progress (when differentially applied), despite its flaws, because it teaches the hand how to accomplish its goals better. Had Plato never existed, we'd be continually having to "reinvent the wheel" of crude Sumerian algorithms because we would not have modern mathematics.

Also, note that the talk is always about "business rules." This is ideology in technical drag. For people would resist something like "government rules" or "university rules.”

Ever since the Reagan revolution, we've been encouraged in America to think that rules are bad, but, at the same time, we have to work hard to make a living, and this involves obeying countless rules. This makes us angry at some level of our consciousness and this anger needs to find a focus.

It has been focused away from corporations and towards government and other nonprofit institutions. Data base culture has therefore followed this by calling all rules "business" rules.

The result has been that universities and government entities have had to more or less shoehorn themselves into electronic data systems designed with business needs foregrounded. A simple example would be the failure, in many business systems, to produce reports that exhibit enough fields so that the validity of the data can be checked from the paper alone.

In sending a bill to a customer, the business has a certain interest in prompt payment and in avoiding customer questions. It is in the business' interest to avoid phone calls from the customer when totals do not crossfoot and add up properly. Therefore, although modern data base systems can provide all this information, the culture of business rules actually discourages "complex" bills except in cases where laws (such as the Fair Credit Reporting act in America) require additional complexity.

 I started programming in a left-wing, labor-friendly university.  Because of this and because of my naivety I encoded a variety of rules, and English explanations of rules.  My experience in modern environments is one of far stricter control as I experience a dialectical pressure to spend my paid time (and, due to recent developments in intellectual property law, my unpaid time) precisely on the rules of direct interest to the business.  This is probably why, for example, it is easy to find out about new products on a cellular phone service's Web site but next to impossible to find out what one owes.  The programmers are, at one and the same time, writing the law and structure of the site, but under police discipline to avoid an extrabusiness "waste of time."

Universities and government entities are usually based on a more open and democratic vision (not always) and when their MIS staffs must install operational systems, the actual experience has been that it is very difficult for them to use systems developed for business. There have been several stories in the press about this: for example, the state of Virginia spent five years trying to make Peoplesoft human resources software work properly, only to abandon it, last year, for an in-house system developed on the Web (Enterprise Development 2000.)

The culture of "Business Rules", then, silently introduces an ideology, and that is "the business of America is business." Mavens like Mr Date must learn that, at one and the same time, we who are working programmers are impressed with his work but at the same time have other goals as family members and as citizens (we're not all alienated "libertarians.") They also need to know that precisely the same failures and delays are occuring now as occured in the 1960s because while the technology has changed, the social relations have not.

 The technical and human correctness of Date's vision, which essentially would replace today's data systems (which are barbarisms when viewed from the inside) with something like the formalism of Russell's Principia Mathematica, lies in this.  If we are to live in a complex society after 1789 or 1776 (or 1848), then we should have transparency in data systems that implement and structure our lives.  But a reading of Kant indicates that there is no breaking of the connection between transparency, and truth, or opacity and the lie.  Date, unconsciously, would reserve transparent access to the rules of the business (which structure society outside of the business) to a small class of CEOs that is forever shedding its very members.  My claim is that ability to understand a transparent account is (or had damn well better be) Chomskyan, and available to all.  The lesson of Seattle 1999 and Davos 2000 is that data processors, as exposed members of the most sheddable elite, need to think outside the box of "business rules" encoded as sloppy, impossible to understand jargon, and in such a way that the tattered social contract of developed countries is clear, understandable, and as the occasion arises, modifiable.

 

 


References

 

Bourdieu 1990: Pierre Bourdieu, In Other Words : Essays Towards a Reflexive Sociology.  Palo Alto, CA, Stanford University Press.

 Date 2000 (1): Date, C. J., What Not How: the Business Rules Approach to Application Development.  Reading. MA: Addison-Wesley.

 Date 1999: Date, C. J., An Introduction to Data Base Systems, 7th Ed.  Reading. MA: Addison-Wesley.

 Enterprise Development 2000: Anon, “Virginia team stops 'giant sucking sound' with Web”.  Enterprise Development Magazine, May 2000.

 Noble 1975: Noble, David, Forces of Production: a Social History of Machine-Tool Automation.  New York: Oxford.