The market for enterprise systems tools took an enormous step backward in the 1990s

 

 

Making every use of their formidable marketing resources and its hegemony on the 'acronyms' of information technology, a new generation of information processing companies in the mid-1990s has introduced a series of initiatives that run counter to the objectives of the open standards movement. By the same token, they eroded objective of providing increased access to tools that would assist in making systems features more relevant. Open Systems was instigated to encourage integration among the various elements of computer systems to allow end users to 'mix and match' between hardware, networking, and software components. This new breed of 'enterprise management systems' was clearly designed to provide single source solutions to meet all the needs of businesses--contrary to the intent of Open Systems. True, these systems were built using many components that were otherwise based on open standards, but used them in ways that disabled or overrode those features.

 

Such products were brought to market without consideration for their effect on Dual Control. Much was said of the benefits, for example, of 'client-server' environments with very vague considerations of exactly what these terms meant in any particular case. In the beginning, client-server represented shared use architecture for client and server processors. In the final analysis, it meant GUI--graphically oriented mouse-driven colorful screens based on a simulated desktop. Such interfaces have become a must-have characteristic in software in the late 1990s. Regardless of the effects on flexibility and manageability of the enterprise overall, no software/hardware combination is considered marketable without this graphical feature. In its own right, this popularized graphical interface has nothing to do with the client-server model other than that no centralized server model in the world could support all of the graphics required to power up each client machine.

 

Another must-have prerequisite for 'modern' systems is use of the 'object-oriented' software design paradigm, as briefly described earlier. Object-oriented software also grew from the graphics software world. The fundamental idea was that if a personal computer could provide functionality behind graphical icons at the press of a button--allowing users to do some word processing, then some accounting, then maybe some spreadsheet work--the same could be accomplished on a grander scale with more complex programs. Programs could be designed to link together, to inherit properties from other programs up the software hierarchy, and be mixed and matched as needed. Once a program was designed to the liking of the masses, it could be 'easily' linked into a large hierarchy of programs to serve as an 'object' to be used in other related programs. Many things were promised from these technologies--including increased flexibility, lower operating costs, and more integration.

 

 

What has resulted from this line of thinking is a massive infrastructure of arbitrary complexity that runs directly counter to the concept that computers can be used to gain increased control of business operations. The language of choice for object-oriented programming is C++--and now Java--which are massively complex extensions of the C language that can only be understood by elite programmers. The idea that a non-technical manager, supervisor, or knowledgeable worker would manage operational logic by means of these tools is amusing. It is not going to happen.

 

Object-oriented programs result in the ultimate in proprietary supplier-controlled tools. Hierarchies of tens of thousands of related programs--designed by thousands of highly technical programmers--are offered as integrated packages to end user corporations. Such end users are left to sort out and select the features they wish to employ from the thousands of options offered to them--rather than having the tools presented to them to develop exactly what they want.

 

Using tools that are arbitrarily complex in their own right, implementation costs--including costs of employee training and hiring of high-priced system consultants--become exorbitantly high. Of course, cost itself may be considered a relative thing, as they may bring operating savings elsewhere in the firm or may otherwise be easily justified. The problem in these cases is that training and reeducation has typically been in the wrong direction: Computer technologists explaining to end users what they can get rather than end users tutoring the technologists on the unique requirements of their businesses. Better yet--responsible institutional agents (managers, supervisors, workers, process consultants, etc.) actually implementing what they need with infrastructure support from the computer technologists.

 

The real problem introduced by this new generation of monumentally complex applications is in the overwhelming implementation times and loss of control that results from them. Routinely, such projects require implementation times of between one and two years--during which time programmers and analysis bring out their 'hammers and chisels' and carve out a compromised system. Surely there are positive, pleasant surprises in the process--typically in the area of data aggregation, which is an impressive feature of large-scale databases. The problem with the compromises made in the implementation of such a system is that line managers responsible for the logic of how the institution is to be conducted are not given tools to control such matters. They are instructed on how they don't need such control in the first place.

 

The fundamental assumptions brought on by such development models is that the programmers and systems designers know more about the issues in question than the people actually engaged in the work involved. Surely, there are intelligent programmers and designers--but this misses the point. If implementation of the standard product requires over a year--what kind of possibilities exist for changing system logic once the product is in place? In some cases, it is not even worth asking.

 

 

A second rationale for these massive software structures is that modern industries are themselves complex and massive in size--requiring a similarly complicated software environment. The symphony model is an interesting refutation of that idea. The more complex and furious the various parts to be played, all performers continue to rely on the fundamental structures of rhythm, tonality, and unity. Another problem with this presumption is that complexity itself is expressed in every sense by a classification structure--the logic of how the environment in its various parts is supposed to function is a step-by-step process of classification. The question lies as to who should do the classifying and what tools they should use.

 

In a modern institutional environment, comp partners operate. Database technology, processing power, bandwidth, routing and switching, high-volume data storage, concurrent user memory requirements, networking protocols, and other infrastructure requirements fit into this area. Given that such features involve highly technical interfaces with system primitives and require deep understanding of hardware and software features and capabilities, the use of highly technical tools--C, C++, Java, etc.--is entirely necessary and appropriate.

 

Second, the logic representing the defined processes of policy and operations must be highly sophisticated--representing detailed requirements that are instantly and globally responsive to changing conditions and preferences. For this to occur, all responsible parties must easily master the tools used to define and manage such logic. This logic requires a similar classification structure to that described earlier as object-oriented programming, but in a form that is understandable to a much large non-computer-technical audience for both design and execution. By the same token, updating and maintaining such logic must be a straightforward task--available to any authorized person.

 

The most common criticism of the second class of tools is that of how system integrity can be maintained if non-technicians are allowed to be involved in the logic development process. Such would not be possible using traditional design tools that involve compiled programs that require primitive calls, drivers, etc. Thus, a new type of design environment specifically for process logic would be required. Additional concerns such as data integrity, system security, etc. need to be addressed.

 

The second most common concern about a logical tool for non-computer-technical people is that of the logic itself--whether it does what it is supposed to do. There is an implied belief that programmers provide a form of quality control in this way that is more sound than that provided by the people who are actually responsible for the overall performance of the organization. According to the Shewhart/Deming methodology, everyone in the organization in question is responsible to address that very issue. In fact, one of the most common criticisms of the prevalent model is that programmers do not understand enough of the requirements of a process to make them function correctly. Clearly, such a tool would need to function with strong security features and revision controls.

 

As to security in general, the only way to achieve the kind of security a firm requires to support the kind of rigidity and flexibility required by Dual Control, the security classification structure must be an intrinsic part of the overall enterprise logic. Certainly, this security domain must control all system resources and network resources--but it should do so within the logical structure as defined by management. The security domain--to be supportive of Dual Control--should be a subset of the top-down structure of the authority within the firm as well as an outgrowth of the continuous improvement cycle of minimizing variation in processes.

 

To deny assertions as to the underlying importance of mastering complexity with simple tools--is to either dispute the authority of an institution's management structure or negate the importance of the computer system overall. If such a system does not reflect the desires and preferences of management, its value to the organization is minimized. The only way for Dual Control to be supported and expressed by networked systems is to provide a way for management to directly control the logic that makes it work. Of course, an infrastructure is necessary to make such a process viable and dependable, but this task is of primary importance if large-scale institutions are to experience the benefits of being in control, as are the great symphony orchestras.