|Data and Operations
Richard Veryard, August 1994
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:
|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]|
|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
|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.|
If you want to make this distinction, or for that matter any distinction, you need to have a purpose for making it. The exact distinction will then be driven by your purpose.
From the above discussion, we can infer some of the possible reasons for distinguishing between data and operations, as follows:
|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?|
Richard Veryard is a technology consultant, based in London.
Written 13th Aug 1994.
Thanks to Michael Mills for asking the question.
Last technical update on March 30th, 1999.
Copyright © 1994 Richard Veryard