Non Volatile Technologies Pty Ltd

SYDNEY  AUSTRALIA   2227    (ABN 96 078 508 264)    Ph:+61 416 27 66 24 

"Helping others to have a future assures our own."

DISCUSSION PAPERS ON ENTERPRISE BASED (COMPUTER) SYSTEMS


BY Kevin Loughrey CPEng

PART 1 – THE CONCEPT OF AN APPLICATION HIERARCHY


Commenced 19 April 2006

Introduction

  1. This the first of a series of papers aimed primarily at the non-technical senior and very senior managers.  They would also be useful for the technical person to skim for the purposes of reaching common ground and an understanding of the thinking of the author when it comes to the design, construction, acquisition, operation and retiring of computer applications/systems.  These papers attempt to build on a series of foundation ideas to reach a final state of thinking that is markedly different to the path most large bureaucracies and businesses have trodden and are presently still following.  Anyone who has been intimately involved with the application of computers to workplaces from the 1960's to the present day, as I have, would conclude that, for all the trillions of dollars that have been spent around the world, little, comparatively speaking, in terms of improved productivity has been achieved.  There is no arguing that there has been an improvement in productivity but could it have been achieved with a lot less expenditure?
  2. Having been involved in the military, the public service, publicly listed companies and in small business, I see the greatest value for money having been achieved in small business.  And there are sound reasons why this is so.  Here lies a lesson from which Government and big business could learn.  These papers attempt to take you on that journey of discovery.
  3. As a starting point, there is a basic and immutable law of computing science that, almost without exception, every large bureaucracy I have worked within has overlooked. That law is that the return on investment is far superior when computers are used to improve the productivity in the workplace and improve the "customer-experience" rather than install them with the prime aim of gathering information for use by senior management in its decision making.  The latter amounts to a gross misuse of computing power.
  4. Yet that has been the pattern up to the present day.  The result of this is that computers are viewed by the workforce, not as helpers, but as a further impost with which they must cope.  Being so, the workforce will do everything possible to short-circuit the inputs required, resulting in the information that is captured being inaccurate, incomplete and out of date.  This neatly leads us to the concept of application hierarchy, the subject of this first paper.

Grouping Applications into Types

  1. Software applications can be grouped into four general types:

      Overlapping of Application Types

      Figure 1: Overlap of all the Various Types of Applications

    1. Scientific Applications.  The purpose of applications of this type is to take input from various sources (such as a keyboard, or sensors and transducers), perform complex mathematical operations and display the results. Although applications such as this often do store and retrieve data, their main function is that of mathematical manipulation and presentation of results. An example of such an application is a finite element analysis program for resolving problems related to structural design.
    2. Equipment Control Applications.  Applications of this nature take input from various sources, perform calculations or simulations and then control a piece of equipment. The fire control computer system in a jet fighter uses applications such as this to identify enemy aircraft and similar threats, and, if necessary, take automatic evasive action or exercise countermeasures. A less exotic application is a garage door opening system.  Because of the need for speed and commercial imperative the device be inexpensive (in the case of garage door openers!) the program software is often in 'firmware' (often in what is referred to as a programmable logic array). Sometimes designers resort to firmware for security reasons as well in order to make it difficult for competitors to determine how the code works or how the code handles security related functions such as encryption.

    3. Office Applications.  These applications provide services to the user such as Word Processing, Spreadsheet and Graphical Display; including the construction and display of publications, presentations and technical drawings (commonly called Publisher and CAD packages).

    4. Database Applications.   The purpose of database applications is to store, retrieve, manipulate (ie, sort, filter and perform calculations upon) and display data in various forms acceptable to the user and customer.

  2. This paper is concerned primarily with Database applications that support the administration/control of operational business units and the management decision-making process.  It is not concerned with the display of data to customers (persons external to the organisation) through content management systems or them performing routine transactions such as, for example, completing Business Activity Statements or renewing motor vehicle registration.

What is a Computer System? - Behind the Concept of Administrative and Operational Computing Systems

  1. The term 'Computer System', though commonly used, is vague.  In its broadest sense, it can mean the hardware, associated networks and software aplications.  In the early days of computing, hardware was expensive and highly specialised.  Each hardware manufacturer developed their own operating system and licensed people to write software applications for that particular computer.  Knowledge about how the hardware and operating system worked was viewed to be extremely sensitive, not only commercially but also from a Defence standpoint.  Hardware of that day was affected by dust and temperature and so had to be housed in specially constructed buildings, complete with filtered air and conditioned electricity supply.  To support these needs, there evolved an infrastructure of staff and facilities devoted to the support and operation of computers.  Like any group of specialists, over a period of time, they became comfortable, resentful of intruders and scrutiny and, most of all, resistant to change.  In many instances, rather than provide a service, they dictated to their users what they would provide and how it would be delivered.  These organisations often went by the name of "Computing Services Division" (CSD). This organisation was usually headed by a senior public servant with no credible qualifications in Computing Science and often little real experience in a workplace or industrial concern such as a warehouse, workshop or manufacturing facility.  CSDs were established to manage all of the computing systems within that organisation.  The Australian Department of Defence was no different.  Large bureaucracies have difficulty accommodating specialist, highly technical persons within their career structure.  The consequence of this is that, even to this day, to be labelled a specialist is to have one's career stunted.  The most senior appointments in the Defence Force go to "Generalists" or "Operators".  Indeed, that might even be the origin the military rank "General".  The consequence of this is that those persons who inevitably end up running CSD-like organisations are under-qualified generalists or failed specialists.  Except on rare occasions, these very senior managers fail to relate to their workforce or to their customers and so there develops an intellectual gap that not only interferes with the gestation and birth of innovative ideas but also with service delivery.
  2. In the case of the Australian Defence Force, there were frequent instances of computers being delivered late and at an unacceptable price.  In response to that, rather than appreciating the basic process was flawed, Defence created new rules to ensure more rigorous accountability for the delivery of computing services and computing systems to Services.  As with centralised economies, with central bureaucracies, computer systems are delivered late, are usually extremely expensive and, once delivered, are often no longer appropriate to the user's needs or expectations. The formation of Computing Services Division was the classic bureaucratic approach to an organisational administrative problem. There were differences in approach in various countries. In the US, the Dept of Defense focused on software standards  1  , CSD did the opposite. One of its tactics to achieve 'order' was to standardise on hardware rather than on software and communications. CSD chose as the Defence Standard Minicomputer the Perkin Elmer range. These computers could only be programmed in Common Assembler Language. Although very fast in execution, programming in this language was slow and so the cost of applications was high. This single decision put Defence Computing back at least 15 years.

  3. In an attempt to break away from this 'dead-hand', the Navy, Army and Air Force introduced the idea of 'Operational' and 'Administrative' computer systems. Those applications that were aimed at supporting logistic functions were deemed to be 'Administrative' and would remain with CSD. Those that supported military operations, such as a tactical Command and Control system, were deemed to be 'Operational' systems. These would be developed by the Services. There was little logic to this demarcation. The underlying reason for it was simply the need to somehow break loose from the stifling controls and bureaucratic processes associated with CSD. The concept of there being Administrative and Operational Computing systems therefore has its genesis, not in any essential logic, but in the failure of CSD-like organisations to deliver a satisfactory service to their customers. It is fact that any system concerned with the administration/operation of the logistic system of any Service has a very real effect on the overall combat power of the Defence Force.  It is therefore as much an integral part of an operational system as something, say, that directs artillery fire.

Database Application Hierarchy

Figure 2: The Database Application Hierarchy


A Coherent Control and Information Management System

Figure 3: A Coherent Control and Information Management System

  1. A group of applications and hardware, encapsulated in doctrine, working towards the same end, exchanging data with each other on an 'as required basis' and supported by standing operating procedures constitutes a system. A database system is also often referred to as a Management Information System but this is only one aspect of its “reason for being”. The ideal Management Information System is comprised of three distinct sub-systems as shown in Figure 2. Another way of looking at this is shown in Figure 3.

  1. As depicted in these figures, the ideal Management Information System is comprised of three subsystems. These are:

    1. The Management Assistance Sub-System (MASS).   The MASS provides data, often statistical, to assist management in its decision-making. (For this reason, MASS are often called decision assistance systems.) Because the first computers were large, expensive and required special accommodation, MASS were amongst the first uses for computers. MASS required that the productive establishments/cost centres within an organisation fill in forms to report their daily activities. These forms were sent to data input centres where the information was input into the central computers using keypunch operators. The provision of this information constituted a sizable clerical impost on line management and operators that interfered with the conduct of daily operations. As much as possible, working units developed ways of satisfying the MASS's edit checks whilst providing minimal information. A consequence of this avoidance action was that the information captured by a MASS was not actually indicative of the real situation. For this reason, most MASS failed to perform and were a waste of money. The Army's Maintenance System MASS, called MODERNISE, introduced in the late 1960's, fell into this category. In 1980, an attempt was made to address this by developing a mobile Administrative Assistance Sub-System called EMEMic; the purpose of which was to help managers in the workplace manage repair activities.  Being stakeholders, and given that EMEMic did in fact help assist people in the workplace, the managers ensured the information being input into EMEMic was indeed complete and accurate.  Information from EMEMic was captured "in background" and fed into EMEDATER 2, the MASS that replaced MODERNISE.  The present Mincom Maintenance Module (MMM) also suffers from the "MODERNISE" problem in that it is difficult to use, complex to learn, not mobile, and is not terribly effective in helping workers do their jobs. Any statistical analysis performed using data from MMM is of highly questionable value because of the inaccuracy of the data being input.

    2. Administrative Assistance Sub-System(AASS).   An AASS assists staff to do their daily work within an organizational unit or cost centre.  AASS encompass applications that perform stores, financial and personnel accounting, a file registry, workshop administration, etc.  As mentioned, EMEMic 3  was designed to be an Administrative Assistance System.  AASS, properly designed, are an indispensable tool for running an operational unit. For that reason, the information contained within an AASS can usually be counted upon as being accurate.  AASS therefore provide the following services to a MASS:

      • AASS serve as a means of collecting information for a MASS.  (Detailed systems analysis in the early 1980's showed conclusively that all the information required by the higher MASS was collected by AASS in the course of the AASS fulfilling its regular workplace administrative support function.)

      • As mentioned, because the AASS plays such an essential role in carrying out daily work at the working level, the data it holds is usually very accurate.  This then ensures that the data being stored by the MASS is accurate and complete.

      •  The AASS performs edit checks as data is being input.  In this manner it saves on labour and reduces the probability of users becoming alienated and hostile towards the system 4.

    3. Clerical Assistance Sub-Systems (CASS).   Even though an AASS provides tangible support to work units (compared to a MASS), an AASS still involves significant clerical effort to perform input of data.  CASS provide a means by which this effort is minimised.  Typically, CASS take data collected by other means, such as from barcode readers, contact or RFID buttons/tags or from a file created by another application, such as a word processor, and input this data into an AASS.  Data may be inserted directly into the database or by use of what is called a “software robot”.  A software robot simply simulates the keystrokes one would normally have to carry out when performing a transaction within an existing system.  In 1988, with the help of Bob Willcox and Doug Bonner, I developed for the British Ministry of Defence a package called GAPac5 , standing for General Application Package.  GAPac served a number of functions but, primarily, was a software robot that input transactional data gathered from other sources, into an AASS called ARROW.  ARROW was an AASS based on ITL minicomputers and semi-intelligent terminals placed around large District and Base Workshops.  Its role was to assist with the management of repair processes and with stores ordering and administration.  GAPac was a development on an earlier package I had used at 1 Base Workshops, in Bulimba, Australia. (See Non Productive Time Accounting System)  GAPac was employed in two projects.  One concerned the ordering of traystores, (For more detail see Tray Store Barcoding Project)the other related to the management of equipment calibration for all units in the South West of England (For more detail see Calibration Management Information System.) and, later the entire British Defence Force.  As an example of how useful a CASS can be, I shall deal briefly with the role of GAPac in the matter of traystore replenishment.  It is typical in large workshops for there to be tray-stores.  These are low cost parts that are provided to workers in trays on an assembly line.  When the number of parts in a tray falls below a certain level, it is necessary for an order to be submitted to the repair parts system to restock the tray before the parts run out.  GAPac was a CASS that consisted of a PC, a PSION Organizer and a Hewlett Packard barcode wand.  A storeman would tour the workshop swiping the barcodes of stores that required reordering.  It was not necessary to type in the amount to be ordered. Each tray had a standard reorder size.  If “one-swipe's-worth” wasn't sufficient, the storeman could swipe the same barcode twice.  This would cause two reorders to occur and future reprovisioning to be modified.  If the storeman swiped the barcode three times, it was an indication that detailed assessment of this store was necessary. The order would not proceed but details of store would be printed out on a separate report for a stores assessor to investigate with a high priority. Once the data had been collected, GAPac would carry out a stores transaction on the PC connected to the ARROW minicomputer.  The PC would emulate a “dumb” ARROW terminal and send to the ARROW minicomputer the  same keystrokes as that required when placing an order manually.   GAPac would do in 20 minutes what it took one person 2 weeks to do manually; without the errors!  The advantage of the software robot approach was that it was not necessary to know anything about how the ARROW database was constructed.  By using an existing transaction on ARROW all of the necessary logging of transactions occurred in the normal fashion and the chances of causing harm to ARROW were totally nullified.   GAPac was used for 15 years in the British MOD and saved around 6 establishment positions per workshop.   Next to AASS, CASS have to be a top priority.  CASS have the capacity to save a great deal of clerical labour and to improve markedly the accuracy of data being input into AASS.

  2. By way of example, consider a supermarket:

    1. CASS. The most prominent CASS in a supermarket are the barcode readers, both those at the checkout and those used by stores staff to conduct stocktakes.  The AASS feed data into the local AASS.  Although centralised ICT bureaucracies will inevitability try to centralise the AASS, this is definitely the wrong thing to do.  It is wrong because it makes the stores day to day operations vulnerable to communications disruptions and its wrong because experience shows it does not, in the long run, save money. Even with good communications, centralising AASS slows down their response time and this then adds to the transactional overheads; resulting in lower productivity in the workplace.

    2. AASS  The AASS in a supermarket handles such things as personnel attendance, local financial accounting and inventory management.

    3. MASS. The MASS is located at the supermarket chain's Headquarters.  It uses consolidated data from all of the various AASS working at the stores within the groups.  The MASS would likely provide the following support to management:

      • keeps track of profitability of stores,
      • monitors turnover of stock in order to determine buying policies,
      • keeps track of return on investment across the whole group,
      • determines the best transport and distribution algorithm so as to minimise the chances of stock-out but keeping transportation and labour costs to a minimum.

Summation

  1. In summary:

    1. A well designed database system consists of three separate subsystems:

      • The Clerical Assistance Sub System. (CASS),

      • The Administrative Assistance Sub System (AASS), and

      • The Management Assistance Sub System (MASS).

    2. Without an AASS, the probability of a MASS capturing accurate information is low.

    3. Without a CASS, the clerical effort of inputting data into the AASS will be a substantial impost on the overall productivity of the unit.

    4. The priority for development should be AASS and their associated CASS. MASS should only be developed once AASS are functioning and stable.

    5. Data input into the MASS should be entirely derived from AASS. There should be no requirement for further manual input by units to meet the MASS information needs.



Footnotes:
1    In the late 60's early 70's, the US Dept of Defence stated it would only purchase computer systems that would run programs written in ANSI standard COBOL. The result of this was that, virtually overnight, COBOL became the standard software language for writing database applications and there appeared on the market a number of mainframe and minicomputers that supported this language such that computer programs, written in COBOL, could be 'ported' from one machine to another with relative ease. This greatly improved competition between vendors, assuring customers of much better value for money.

2    The Electrical and Mechanical Engineering Data on Equipment Repair (EMEDATER) system ran on the Defence UNIVAC mainframe computer. It ran on an Advanced Revelation database. Porting this database to any ANSI standard Structured Query Language Database would have been a relatively simple task.

3    The Electrical and Mechanical Engineering Microprocessor based system EMEMIC was the first system to be specified within Defence to be based on networked Microprocessors (the precursor to what is now referred to as the Personal Computer).

4    One of the lessons learned from the experiences of the 60's, 70' and 80's was the quality of data improves markedly if computer systems are seen by their users to be helpful rather than being an additional task they must perform in the discharge of their duties. For that reason, the introduction of applications that directly assist staff in their work, namely Clerical Assistance and Administrative Assistance Sub Systems(CASS & AASS), should command top development priority. With a CASS and AASS one has the potential to immediately improve the productivity of large numbers of staff and, through this, the efficiency/effectiveness of operational units whilst, at the same time, significantly improving the quality of data that is captured and relayed to Management Assistance Systems (MASS) used senior management. The benefits of a MASS are far less tangible whilst the costs of operating a MASS are both real and significant.

5    GAPac was developed by Lt Col Kevin Loughrey whilst serving as the CO of 1  Base Wksp Bn in 1986 and was used initially to facilitate non-productive time reporting. It was further refined when Loughrey was posted, as an exchange officer to 27 District Workshop in the UK, in 1988, to automate the ordering of tray stores and for the simplified creation of parts indents using the graphical illustrations in Illustrated Spare Parts Manuals.

6    MAWD stood for Machine Assisted Workshop Documentation. It was programmed in Common Assembler Language and ran on the Perkin Elmer range of equipment.

7    This paper was distributed in PDF format and was produced, in its initial publication, using Open Office 2.0 (and later in LibreOffice, the Open Source successor to Open Office when Sun Microsystems was acquired by Oracle).  This is a free suite of programs that are capable of reading and writing Microsoft Office Documents.  The source code for Open Office is freely available and users may alter it as they wish.  Open Office is the product of an organised collaborative effort by volunteers around the world.  Their aim is to accelerate the development of nations less fortunate than Australia by providing these countries with not only the applications necessary for higher productivity and competitiveness but also the knowledge as to how these applications are written; thereby providing the opportunity to participate in the global technology market.  Open Source software is therefore an instrument of Strategic Defence the ADF should embrace.

- End of Paper7-

Copyright © NVTech 2005-2011