Many developments occurred to make computers more adaptable to institutional requirements

 

 

From the 1970s to the 1990s there were great advances in the world of institutional computing in spite of the functional infighting within organizations referred to earlier. The 1970s brought changes to computing that resulted in more functional, flexible support of critical business requirements. These included the invention and development of semiconductors--allowing for greater processing power and increased functionality both as a factor of size and of cost. High level programming languages were developed and improved, which increased capacity to provide for powerful data classification and storage tools for a new breed of programmers and data managers. Relational databases were developed to provide for flexible access to data previously bound up in hierarchical data stores.

 

In the 1980s, models for improved systems-based classification tools were developed, but they were positioned in markets for engineers and technical professionals and were overwhelmed by more heavily promoted expert systems. Personal computers, word processors, and spreadsheets provide data management capabilities to business managers other than accountants and other workers fortunate to have dedicated systems. Open standards, distributed processing, and ubiquitous networking encouraged digitization of data and information of all types--a movement that was spurred on by improved scanning, imaging, character recognition, networking capabilities. Ubiquitous networks--most particularly the Internet--signaled great potential for progress in the control of institutional operations.

 

Two widespread movements occurred in the late 1980s that promised to make computers more capable of supporting requirements of the many types of users within an organization. First of these was the Open Systems movement--an effort to establish a standards-based computing environment in which institutional users of computers had more options for mixing and matching system components and tools. This was an effort to get out of proprietary computing environments in which choice is strictly limited. The second development was the highly touted promise of expert systems, which were represented as means of finally turning the tide on computers to make them our slaves, not our masters.

 

With respect to the Open Systems movement, it is important to know that it was not the idea of organizations making and marketing IT products.

 

What has made it [the Open Systems movement] happen, and will continue to do so, is the fact that most vendors will tolerate the [price] spiral no longer. All vendors have now acknowledged a role for open systems, and all but the very largest have declared that their major future product development will be in the open-systems arena.

   

Such consumers of computer-based products and services faced a dilemma in the late 1980s. First, they had experienced the benefits and pitfalls of a monopolistic market for computers from the 1950s and 1960s by virtue of IBM's dominant position. Largely due to IBM's own approach to the market, it required that all aspects of a company's system had to be purchased or rented from IBM. Cost factors aside, such an arrangement could only function effectively if IBM had what everyone wanted. In the early years IBM probably did--given that most managers and workers did not know what to expect.

 

When the computing industry broadened in the early 1970s, several other firms gained significant positions in the market--providing competing architectures and tools to those provided by IBM. These included providers of mainframe systems as well as new types of systems, such as mini-computers, supercomputers, distributed processing systems, personal computers, etc. The problem faced by consumers of such systems by the late 1980s was that these new competitive system providers showed a tendency to build proprietary systems as IBM had done earlier. Given that institutional consumers of computer-related products had by the 1980s developed high degrees of expertise in their own right, they decided on a structured approach to solving what had emerged as a serious problem.

     

Over time, all users have seen their investment in IT grow. Despite occasional cutbacks, false starts, restarts and some well-publicized disasters, the march of IT investment over time has been inexorable. It is sometimes said that the principal part of this investment is in staff skills, and data rather than machinery and programs. Be that as it may, it is all more or less locked into proprietary environments; and the greater the investment, the more the user is locked in.  

     

. . . Modern management thinking, however, proposes a flexible role for IT, suggesting a major role for it as a marketing tool, exploiting opportunities for new services aimed at gaining competitive edge. That stance conflicts directly with the dead weight of investment in proprietary systems. With the best will in the world, IT departments cannot introduce new business solutions from an arbitrary variety of different vendors and hope to survive. They must look to their major supplier for nearly all their requirements.  

 

The Open Systems movement addressed the issue of competition by computer products suppliers in an environment of open standards at all industry levels--including operating systems, peripherals, system components, and underlying languages and protocols.

     

Open systems are those that conform to internationally agreed standards defining computing environments that allow users to develop, run and interconnect applications and the hardware they run on, from whatever source, without significant conversion cost.  

     

  The really key factors for the users are that no single supplier actually "owns" the environments involved, and that the mixing and matching of applications and hardware can be achieved without significant cost. . . The point here is that users should not be denied better products or services because of incompatibility between proprietary environments, and that internationally agreed standards, where they exist, should be used.  

   

 

The Open Systems movement was principally a tug-of-war between IT departments of major institutions and IT supplier companies. It did not incorporate the idea that non-IT managers and workers would have any capabilities for designing and managing system logic. The solution to the management of system logic provided from the IT community was introduced at the time as 'object-oriented' programming. This concept was introduced under the rubric of 'practicality.'

 

So what is an object in computer terms? Essentially, an object can be anything you like--anything that you care to isolate as a separate item in your thinking about a particular problem or application. It is simply a higher-order abstraction than any of the items mentioned above (records, documents, images, arrays). In practice, because the ultimate purpose is to produce a representation of an application that we can process, we impose some order on the objects we select by grouping them in classes [that is, by classifying them]. The class any given object belongs to depends on the significant characteristics, for given purposes, that it shares with other objects. Classes can be broken down into sub-classes, sub-classes into sub-sub-classes, etc.  

 

. . . All aspects of object orientation in fact recognize explicitly what software developers have failed to recognize generally at great cost: namely, that all computing is modeling--creating a representation of some aspect of reality for some purpose at some point in time.  

 

The object-oriented world was based then on the tasks and requirements of classification and modeling. This was an important and beneficial distinction from programming models of the past, but it backfired in the 1990s in a major way, as will soon be outlined.

 

There was a furtive effort in the 1980s to make computers more useful and relevant to those in organizations that had not taken the time and effort to use computers--even when they took up space on their desks. This was the phenomenon called Artificial Intelligence (AI)--a promise to make computers work better by means of expert systems. Most AI systems made use of an expert systems language called Lisp. AI failed to capture any significant share of the market for 'operational logic' largely because of the limitations of Lisp.

     

It might seem odd today that artificial intelligence and Lisp were hot items in the mid-1980s. AI promised to eliminate the drudgery of using computers, to bring human-level intelligence to computers and hence to companies.  

 

AI has been described in a number of ways. In essence, it boils down to a really good computer program that is able to elevate a user's decision making power so that he or she can function as an expert without being one. Such programs can be designed using any programming language, but Lisp was designed in 1958 for this specific purpose--with considerable amplification by academicians since then. There are a number of approaches to creating an AI environment--in part due to various kinds of logical patterns we as humans use to make decisions. Both AI and Lisp are thus very ambitious projects in that they attempt to synthesize all of these methods--rather than simply to classify and calculate--tasks that are most in demand to support institutional operations.

 

Lisp was never designed with computer novices in mind as logical designers. The informal specification for Common Lisp as of 1984 was 600 pages long and contained almost 800 functions. In at least one example of alternatives to Lisp for AI applications was the C language. Typically, AI applications are designed by "knowledge engineers" who understand the complexities of the expert system software working in conjunction with subject matter experts.

 

AI did not achieve expected levels of success in the last decade--a fact that mystified many. What lessons can be drawn from this failure that can help in understanding how to use computers to achieve a state of Dual Control in an organization? Richard Gabriel, the founder of one of the leading AI/Lisp companies, lists the following characteristics of a logic design environment.

 

In 1990 I proposed a theory, called Worse Is Better, of why software would be more likely to succeed if it was developed with minimal invention . . . Here are the characteristics of a worse-is-better software design for a new system, listed in order of importance:  

 

  1)   Simplicity: The design is simple in implementation. The interface should be simple, but anything adequate will do. Implementation simplicity is the most important consideration in a design.  

  2)   Completeness: The design covers only necessary situations. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized.  

  3)   Correctness: The design is correct in all observable aspects.  

  4)   Consistency: The design is consistent as far as it goes. Consistency is less of a problem because you always choose the smallest scope for the first implementation. . .  

 

Gabriel does not go so far as advocating a logic design language for the masses of non-programmers. He does, however, indicate that a successful language for such a purpose should be aimed at "the largest marketplace you can . . ." Truly, this would point to a language that was at least more common than most--a phenomenon that is supported by the experience in symphonic music.