DISCUSSION PAPERS ON ENTERPRISE BASED (COMPUTER) SYSTEMS
PART 1 - THE CONCEPT OF AN APPLICATION HIERARCHY
Introduction
Grouping Applications into Types
Software applications can be grouped into four general types:
Figure 1: Overlap of all the Various Types of Applications
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).
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.
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
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.
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.
Figure 2: The Database Application Hierarchy
Figure 3: A Coherent Control and Information Management System
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.
As depicted in these figures, the ideal Management Information System is comprised of three subsystems. These are:
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.
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.
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.
By way of example, consider a supermarket:
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.
AASS The AASS in a supermarket handles such things as personnel attendance, local financial accounting and inventory management.
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:
Summation
In summary:
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).
Without an AASS, the probability of a MASS capturing accurate information is low.
Without a CASS, the clerical effort of inputting data into the AASS will be a substantial impost on the overall productivity of the unit.
The priority for development should be AASS and their associated CASS. MASS should only be developed once AASS are functioning and stable.
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.