Department of Computer Technology, Monash University, Caulfield
P. O. Box 197, Caulfield East 3145, Australia
chris.avram@fcit.monash.edu.au
This is a working paper describing work in progress aimed at eliciting comment on the direction of proposed research, it is intended that it be widely circulated prior to publication.
Commercial software to assist the task of developing such front end systems has been available since the early 1990s. In this paper, the usefulness of business process re-engineering, the techniques for managing re- engineering, and the importance of information systems for the outcome of re-engineering are taken as given (Moad 1993) (Hammer 1993).
Given that business process re-engineering (BPR) provides opportunities for Information systems and technology (IS/T), the recent and on going wide spread deployment of data networks provide a challenge to IS/T. There are now many new ways to deliver and collect information. Dumb terminals attached to central computer systems are being replaced by personal computers and workstations allowing virtual terminal operation and client server operation (Avram 1988) (Domanski 1993). These are two new models or paradigms for transaction processing systems. Others such as electronic document interchange systems, voice processing systems and more challenge the IS/T system developer to select wisely.
When choosing a technology for transaction processing, the designer must consider factors such as
In the next section some terminology for describing transaction processing systems is developed. This is followed by a discussion of the criteria to be used to evaluate the various technologies. Ten significantly different technologies for the delivery of transaction processing systems are described including, were appropriate, mention of a commercial product or standard.
Transaction processing systems are a kind of information system. The identifying features of a transaction processing system are:-
* transaction processing systems are low level systems, they are the systems which collect an organisations operating data and feed that data to the high level planning systems; to the extent that a transaction processing system feeds information directly to a planner or manager, the information is used by that planner to make short term, limited impact and tactical decisions;
* transaction processing systems are often operated by data entry operators, customer service staff, stores clerks and the like to the extent that these operators make decisions, the individual decisions have limited effects, this is in distinction to decision support systems which are designed to be operated by management decision makers whose decisions are of a more wide ranging nature.
Three important trends in transaction system design have been identified.
1. Whereas in the past, the operator of a transaction processing system acted in a programmed way as the interface between the world and the computer system, BPR has required such operators to make more independent decisions based on sources of data wider than that available from the traditional one function transaction processing system. So increasingly, operators of transaction processing systems need access to a wide range of currently independent computer systems. Personal computers with terminal emulators and other virtual terminal systems are used to provide this functionality (Avram 1988). Recent developments such as Front end systems like Telecom Australia's DRIFT system allow high levels of integration, on one screen, of multiple virtual terminal sessions to multiple mainframes from one personal computer.
2. Increasingly (Johansen 1992), operators of transaction systems are able to use the computer system to improve communications within a group working on related tasks and between groups who previously may have been restricted to communication via slow paper mail systems. Recent developments such as electronic form systems, workflow systems and products like Lotus Notes aid intra work group transaction data flows.
3. Organisations are looking to reduce the cost of systems and to improve responsiveness to customer needs. Automating the task of operating transaction processing systems is one approach. Allowing customers and suppliers to enter data directly into transaction systems and to receive responses from such systems is another approach to design without operators. Transaction systems without operators such as electronic document interchange (EDI) systems and telephone based voice processing systems such as interactive voice response (IVR) systems are recent innovations (Tetschner 1993 page 71 and 153-164). Such systems can be categorised as systems without operators.
These considerations have been used to develop a system of classification of transaction processing systems. The following figure, Figure 1, shows the first level of classification, it shows that transaction processing systems are of three types:-
Figure 1. There are three types of transaction processing system.
The classification in Figure 1 can further be refined as in Figure 2. The next level of refinement is based largely on computer system operational features. Features such as commonality of the computer technology used by transaction processing systems and features such as the responsiveness of the systems to the needs of the operators.
Figure 2. A taxonomy of transaction processing systems.
Batch systems and On line systems are well understood classes of transaction processing computer systems. A description and evaluation of each type of system listed in this classification scheme (Figure 2) can be found in section 4. The next section considers some useful characteristics of transaction processing systems.
When choosing a technology for transaction processing, the designer must consider factors such as those listed here.
An example of this sort of failure has been reported in the work of URCOT, "The Union Research Centre on Office Technology, an organisation established by the Australian Public Sector Union and the Australian Taxation Office as an outcome of their agreement on the priorities and procedures to be pursued in implementation of modernisation of the Taxation Office". In an URCOT working paper, Gibbs (1993) reports that "despite being given high priority in the RFT (request for tender); in practice, user interface requirements were given a low priority during the design and construction stages of the Re-equipmnet Program (re-equiping the Australian Taxation Office)".
Many ergonomic issues are outside the scope of this paper. For example, a common user access (CUA) specification allows operators to transfer skills between systems which adhere to the specification. So if an organisation were to standardise on a particular graphical user interface for much of its computing, then, from an ergonomic point of view, transaction processing systems should also adhere to that standard. However, many of the transaction processing paradigms described in the next section are available in products with both a graphical interface, to CUA standard, and in text based products. For an early paper on CUA standards, see Otte (1982).
From the point of view taken in this paper, the ergonomic features which distinguish between transaction processing systems in an important way are features such as:-
The term modal behaviour comes from the user interface literature. Modal systems are systems which operate in modes modeless systems operate without modes. It is thought that the less modal behaviour a system exhibits, the easier it is to learn and operate. A transaction processing system which allows its operator to choose what task is done next as often as possible is thought better than one which restricts future actions based on past actions.
As an example, consider a system designed to be operated from a dumb terminal running an update/enquiry program. The classic design would involve multiple layers of menus. Designers of such systems identify (at design time) the common actions required to be performed and group the actions together. Lets say for purposes of illustration, this is an order entry system. The client base, at the time the system was designed, was relatively static and small. The screen on which orders are entered does not allow a credit worthiness enquiry to be made for a new customers. As our hypothetical organisation grows, the process of credit control and order taking is merged. This old system is modal. To take an order from a customer, a strict order of events must occur. The operator must move from the mode of operation in which customer credit worthiness is checked, to that in which orders are entered. An alternative design is that offered by a typical transaction processing monitor. In this type of system, operators send to the computer system a transaction code and transaction data. The transaction processing monitor dispatches the transaction data to the appropriate application code. The results are returned to the screen. The operator does not switch between modes. Another example of a modeless system is the graphical user interface. Here the operator if able to choose actions from a visible set of menus called the action bar and if well designed, graphical user interface based systems will tend to keep to a minimum the times that the operator is restricted from choosing an action from the action bar.
Another characteristic feature of transaction processing systems is the degree to which operators and the computer system can operate independently. In a batch system, the operator collects data, places it in a collection called a batch and sends it to the computer. The operator is then free to prepare another batch or work on some other tasks. In a classic terminal-operated on line system, an operator enters some data, waits for a response and often can do nothing until the response arrives and the next operator action is taken. A batch system supports a high degree of operator independence whereas a classic terminal based on line system often requires a high level of synchronisation between the actions of the operator and the computer system.
In the next section, a number of transaction processing models will be described, these models will be judged against the three ergonomic criteria above. There is some support for the propositions that (1) transaction processing systems should be able to be managed within each work group in an organisation, managed that is with respect to work stations in use and functionality available on those workstations. They should (2) exhibit very little modal behaviour. They should (3) support a high degree of operator independence or asynchronaity.
Electronic mail systems used as the data collection and response distribution mechanism for batch transaction processing systems can provide quick response times, efficient mainframe utilisation and a humane (human controlled) work environment. Perhaps system designers should re-evaluate attitudes to batch transaction processing.
Batch legacy systems can be given modern front ends. Personal computer data base and electronic form packages could be developed to facilitate batch data preparation.
Operation in a transaction processing environment is often modeless. The management required is usually highly intrusive and centralised. To add a new transaction type, a programmer develops the code, passes the code to the transaction processing monitor administrator who then installs the code and enables certain terminals to use the new transaction. These systems are little known outside large mainframe operations.
Transaction processing monitor based systems are often highly synchronous systems.
Legacy systems can be given new front ends and operated over virtual terminals. So for example the system could be operated from a windows based personal computer with secondary data bases of useful information displayed in windows along side the legacy systems screen. Data could be automatically copied into and from the legacy system from and to newer systems running entirely on the personal computer or on other computers.
Time sharing system based transaction processing systems are often highly synchronous systems.
These systems often exhibit highly modal operation.
Legacy systems can be given new front ends and operated over virtual terminals. So for example the system could be operated from a windows based personal computer with secondary data bases of useful information displayed in windows along side the legacy systems screen. Data could be automatically copied into and from the legacy system from and to newer systems running entirely on the personal computer or on other computers. This can modernise such systems and reduce the negative effects of the underlying modal behaviour.
In many organisations, the wide spread adoption of personal computers in the late 1980s has seen the elimination of terminals. They have been replaced by personal computers running terminal emulation software. These personal computer based virtual terminals allow many of the productivity benefits of personal computer use to be transferred to the transaction processing operator (Avram 1988).
The taxonomy of transaction processing systems in section 2, did not include virtual terminal systems as a type of transaction processing system. This technology underlies many of the other transaction processing technologies, in particular front end systems technology.
When reengineering legacy systems, there is often a need to alter the interface between the operator and existing transaction processing systems. The personal productivity benefits of personal computer systems and the cut and paste features of widows systems can be added with a simple terminal emulator and virtual terminal operation. Where the legacy system is very badly mismatched to the reengineered operation, a more radical approach is necessary.
Advanced configureable terminal emulator systems, here called front end systems have become available in the 1990s. This paper began with an example of the need for such a system, see section 1. In that example, the need was too allow one operator with one screen to manipulate data in two separate legacy systems. The front end software takes data from the operator, divides it up and sends it to the legacy systems and takes responses from the legacy systems and merges the data and presents the appropriate data to the operator. Commercial software to assist the task of developing such front end systems has been available since the early 1990s. I cite, without recommendation, Telecom Australia's DRIFT system.
This is one of the newest and compared to client server, lesser known technologies for reengineering.
A user programmable front end system can be highly responsive to user needs. The management controls will still lie with the legacy systems management. These systems can be as modal or not, depending on the design. The systems are often used as "new" transaction processing monitor or time sharing like systems and so often require a high level of synchronisation between the actions of operators and the computer system.
There is no inherent reason for high levels of management control over the addition of new client workstations or functionality within a work station.
In addition to this flexibility advantage of the client server design, there are many economic advantages associated with a move to client server systems.
Legacy systems can be upgraded to operate in a client server environment. Tools to assist and automate this process are needed and not yet (mid 1990s) commonly available commercially.
To explain this, compare the operation of a terminal based enquiry system to one based on email. In the former case, the operator chooses an enquiry function and waits while the system responds with an enquiry screen, then the operator enters the enquiry data and waits while the system searches a data base and returns the data. It is, at times, hard too see which is the more mechanical operation, that of the terminal operator or the computer system.
Using email technology (and transaction systems based on email technology), the operator chooses an enquiry type and waits while the local personal computer responds with an enquiry "form", the operator enters the enquiry data and "sends" the form as a mail message to the transaction processing system. Here the synchronaity of operation between the transaction processing system and the operator ends. At a later time, convenient to booth the operator and the transaction processing system, email returns with the results of the enquiry. The operator chooses the time at which this response is read.
I have classified electronic mail and forms systems as groupware systems since this technology supports multiple operator transactions. A transaction (form) could flow through the hands of many operators before it is complete. It is this idea of groupware (Johansen 1992) which has brought email forward as a technology for transaction processing design.
At a technical level, there may not be a data base at all. A whole transaction could involve only the systematic routing of electronic forms between a work group.
Systems with user programmable electronic forms are available (JetForm from the JetForm Corporation and others), centralised management of transaction processing is not required. These systems are not modal and are extremely asynchronous.
In systems like Lotus Notes, centralised management of transaction processing is not required. These systems are not modal and are extremely asynchronous.
Commercial systems of this type are available with user programmability. These systems can be interfaced to legacy systems via this programmability.
Since these systems don't have operators in the conventional sense, the issue of management control of operator functionality does not arise. The three ergonomic factors by which transaction systems have been judged are not are not applicable to IVR systems.
Assuming the customer relationship issues dictate that an IVR system is suitable for a transaction processing system design, then the choice of this type of system should be based on economic and technical issues (see section 3).
In Australia, by far the largest (transactions per year) such systems are the electronic funds transfer systems.
The three ergonomic factors by which transaction systems have been judged are not applicable to EDI systems.
Assuming the customer relationship issues dictate that an EDI system is suitable for a transaction processing system design, then the choice of this type of system should be based on economic and technical issues (see section 3).
It is time that the attention of Information Systems and Technology researchers was re-focussed on these systems. There are significant economic, ergonomic and industrial relations issues involved in their design. These systems at present receive the technical attention they need as evidenced by the proliferation of commercial products in support of the various paradigms outlined here. The following table summarises a first attempt to classify the technologies for transaction processing using non technical factors.
The present paper reports work in progress in this area. The next step is to identify a particular transaction system suitable as a candidate for many of the paradigms presented here. To then develop many systems using the many paradigms presented and to measure and analyse the development, operational management and usability of that one system as embodied in the many developments.
Domanski, D. (1993) ‘A Road map for client/server computing’, Informatics, September 1993, 25-30.
Gibbs, M. (1993) ‘Networking people and computers: A study of the Australian Taxation Office's re-equipment program’, Working Paper No. 2, Union Research Centre on Office Technology, Melbourne.
Hammer, M., Champy, J. (1993) Reengineering the corporation, Allen & Unwin.
International Business Machines Corporation (1987), Common user access panel design and user interaction, IBM.
Johansen, R. (1992) An introduction to computer augmented teamwork, in Boston, Kinney, Watson, ‘Computer augmented teamwork’, Van Norstrand Reinhold.
Moad, J. (1993) ‘Does reengineering really work?’, Datamation, August 1, 1993, 22-28.
Otte, F. (1982) Consistent user interface, in Vassiliou, Y. (Ed.) ‘Human factors and interactive computer systems’, Ablex Publishing Corporation, Norwood, NJ, 261-275.
Tetschner, W. (1993) Voice processing, 2nd edn, Artech House.
File \\discone\c\usr\chris\papers\tr94-02.doc