Data and Operations

Richard Veryard, August 1994


 

Contents

Summary

Possible ways of distinguishing data and operations

Possible ways of confusing data and operations

Conclusions

Keywords

Data retrieval

Operations retrieval

Summary

Someone asked me whether I saw a distinction between data retrieval and operations retrieval, and whether I thought users saw such a distinction. My immediate reaction was that such a distinction was problematic, and that users were probably confused. This document provides a more considered response to the question.

Of course people distinguish data retrieval from operations. It turns out that there are several alternative ways of making this distinction; each stakeholder is likely to describe the distinction differently, according to perspective.

It also turns out that there are some anomalies and grey areas, some cases whose classification as either data retrieval or operations retrieval is debatable.

This raises the following questions:

  1. Do the distinctions made by the different stakeholders coincide? If not, what are the implications of different perspectives?
  2. Can the anomalies be contained, or do they altogether undermine the distinction?
  3. Does the distinction make sense? What is the purpose of making the distinction?
My current position is that I don’t know for sure why we want to distinguish between data and operations, and it is because of this that I don’t know exactly where any meaningful distinction lies.

Possible ways of distinguishing data and operations

 
Database administrators’ view read versus update ‘Data retrieval involves the read-only access to a server or host database. Operations retrieval involves an update to server or host data. We don’t care what the user does on her PC, as long as it doesn’t affect our (sic) data.’  This is a technically oriented distinction, that probably doesn’t make much sense to the end-users. They might be informed which data are located where, but they probably wouldn’t understand the logic. However, they do need to know which data are being backed-up centrally, and which data they may have to back-up and recover themselves.
Developers’ view adhoc versus programmed ‘Data retrieval involves an adhoc unpredictable use of data. Operations retrieval involves a predictable use of data, following programmed business rules. We (developers) preserve data integrity by building the business rules into the operations. We cannot control data retrieval, but what we can do is prevent the users doing any adhoc updates.’  Both the database administrator and the developer are dividing the computing environment into two spaces: one in which ‘we’ control and one in which ‘they’ fail to control. However, it is not clear that the dba and the developer would agree the exact position of the boundary between these two spaces, especially if the dba doesn’t trust the developer (a common enough situation).
Development toolmakers’ view dynamic versus static ‘Data retrieval involves dynamic SQL or its equivalent. Operations involves static SQL. This alters the practicality of building applications from simple action diagrams and prefabricated objects.’ This is similar to the developer’s view, but at a higher level of abstration. It addresses not just the predictability of what the end-user wants to do, but also the predictability of what the developer wants to do.
IT planners’ view predictability of machine usage and costs ‘The machine requirements of operations are more or less determined by business volumes. Data retrieval is much more difficult to predict. So although we can do capacity planning for operations, and provide a reasonably reliable machine performance, we cannot do the same for data retrieval. Therefore we prefer to manage the two areas separately.’ This view is related to those of the dba and developer.
IS planners’ view types of application ‘We divide information systems into four levels: operational, monitoring and control, planning and analysis, and strategic. As a rule, the bottom two levels are programmed applications while for the upper two levels we provide end-user PC tools, although there are some exceptions to this rule.’ Many organizations are trying to implement Executive Information Systems (EIS), which are semi-programmed applications, intended to support analysis and strategic planning requirements. This use of the word ‘operational’ is probably a red herring, as it cuts across the other users of the word. Perhaps we need to distinguish between business operations (as opposed to monitoring, analysis and strategy) and data operations, which is what is implied by the dba’s and developers’ view.
Users’ view private versus public ‘Data retrieval allows me to explore data without affecting anyone else. I can use spreadsheets and any other analysis tools the data processing people allow me to have. When I want to make my results available to other people, I may need to carry out some operations on the central computer system.’  Analysis is not always carried out in isolation. Managers take their spreadsheets to meetings. Data and their interpretations may circulate the company through channels uncontrolled by central data management. This means that the end-user notion of shared data may not coincide with the dba’s notion of shared data.
Auditor’s view access and accuracy ‘For data retrieval, I merely need to control access. For operational control, I also need to control accuracy.’ What the auditor should be controlling is the business system, not just the computer system. If the computer system is providing wrong data to the user, this may causing the user to make bad business decisions. For example, if the user were misled as to the current value of a capital item, she might decide to sell it for a price that causes serious financial loss to the business. This would certainly be of interest to a financial auditor: not just the sale itself, but the link between the sale and the data that supported the pricing decision. 
Philosophers’ view knowing versus doing ‘Data retrieval is an act of cognition: I want to know something. Operations retrieval is an act of execution: I want to do something. There is a clear distinction between knowing and doing.’  Many modern philosophers deny this distinction. For example: ‘All doing is knowing, and all knowing is doing.’ [Maturana & Varela]

Possible ways of confusing data and operations

 
Data operations versus business operations Any programmed application that implements such entity types as plan or budget or forecast is going to involve data operations that are (at least in some sense) not business operations.
Business processes Any end-user activity, including data browsing, can be assumed to have some business purpose. It is therefore potentially identifiable as a business process, with a defined end-result.
Data retrieval procedures Data retrieval may involve any of the following, and these may be wholly or partially invisible to the end-user:
    • assembly of the data from multiple physical locations
    • assembly of apparently homogeneous data from heterogeneous sources
    • selection and formatting of data according to a stored user profile
    • execution of stored algorithms, to calculate data values
    • creation of an audit log, to record the fact of access to these data by this user on this occasion
    • creation of accounting information, to enable appropriate financial cross-charging
    • security checks, to confirm that this user is authorized to view these data
    • purchase of data from external sources (e.g. automatic lookup of exchange rates)
Stored procedures and parametrized business rules These are concepts that allow data to be executable. There is a link between these concepts and the concepts of object-orientation. Does the use of a business object count as data retrieval or operation retrieval?
Cooperative work Group decision-making and group knowledge-creation blur the line between private data manipulation and public data operations. 

Conclusions

 
Payment Who pays for the retrieval? Out of which budget?
Reversibility What happens if you make a mistake? Can/should you erase the traces of the mistake?
Backup and recovery Whose responsibility is it to protect the data? Does/can the dba recover lost data?
Control What (if any) business rules are enforced?