Feral computing

Not all in-house software is written by IT departments. In all organisations we've seen which have PCs on user's desks, there are applications written by users. Sometimes they're only spreadsheets with the odd macro, but sometimes they're full-blown compiled client-server applications.

We have even seen one NSW public service organisation where an employee wrote a system during working hours, passed it around to other departments, and when it was in common use throughout one region of NSW, approached the IT department and asked for payment for the use of 'his' system.

Since Excel and Word both have (almost) a full version of a Visual Basic development environment embedded in them, it's impossible to keep software development tools out of user's hands. And it wouldn't make sense to stop people writing small macros that speed up their work. We often develop single-use macros for tasks like document cleanup and reformatting, that are trashed when the particular task is completed. Banning the development of tools like that would condemn users to do the repetitive tasks that computers are supposed to free us from.

On the other hand, no-one wants applications that grow like Topsy without plan, without structure, without documentation or maintenance. (We're assuming here that all applications developed by IT departments have plan, structure, documentation ... but that's another story).

Prevention

One mechanism for managing user computing projects is to have a clear set of guidelines which set out:

• how large user computing projects can become before they have at least to be brought to the attention of the IT department (number of person.hours?)
• what level of design, maintenance and user documentation users need to provide, and what standards they should use
• how users can request larger software development projects from the IT department (a pointer into the IT department's project initiation process?)

This simple step can prevent situations where critical or personal information (see article on the Privacy Act) ends up on spreadsheets or in Access databases which are not under proper control.

Detection

Often user computing projects go undetected by the IT department, and sometimes even deliberately hidden, in the mistaken belief that the system is 'temporary' or 'a prototype' or 'non-critical'.

An effective mechanism for finding these systems is a knowledge audit (see article in this issue) which looks at a number of aspects of an organisation's use of knowledge, including user-level computing projects.

Cure

Bringing a large user computing project into the IT fold is a difficult - and sometimes impossible - task. Reverse engineering an application is a challenge, but one which we have had a good deal of success with. There are two aspects to reverse engineering:

• Automated: There are numerous tools for reverse engineering, some inexpensive, some very expensive. These tools will typically discover the relationships between tables, and often the relationships between software objects and tables. They will also usually diagram these relationships, and give the impression that they 'understand' the application and the way it works.
• Manual: Unfortunately, automated tools can only read code. All of the information not contained in the code (or the database structure) needs to be captured by hand. This includes essential information such as:
  • What data is actually held in that field called CreditAmtFlag? What's its business context?
  • What is the purpose of the routine called TestCreditAmt().

Manual reverse engineering needs to be done by a technical writer, working either with an existing developer, or with the user interface of the product, plus existing documentation.  

If you would like to discuss any of the above aspects of user computing, please contact us.

This article may be reproduced only with the permission of HCi (email HCi ). Copyright HCi, 2001.