Development and Support of Information Systems

The development of information systems to support Business and Community Engagement was an issue for all partners in the project.

Many forms of engagement activity require unique solutions to storing data in terms of both the type and quantity of data to be stored and the reporting output. In the early stages of a new engagement activity the precise data requirement may not be fully identified. Information systems start small. In many cases the requirement can be handled by one or more spreadsheets which are designed, updated and self-supported by the practitioner or team.

However if the initial engagement becomes sustainable and continues, and especially if it grows, the data storage requirement in terms of quantity of data can soon outgrow a spreadsheet approach. A database-driven system becomes necessary. In many cases this can be catered for by the practitioner or team creating a local database using MS Access or similar.

By the time that the data problem becomes large enough to require a more sophisticated and robust approach, the design of which demands a higher degree of skill and experience, the IT or Information Systems development staff are faced with large issues in terms of legacy data and incompatibility with Corporate Systems' data structures.

The problem is two-fold.

• At what point should practitioners approach the IT or Information Systems development staff for assistance? Systems start small. Would the development staff want to, or have they capacity to, take on or assist with the development of a small requirement that may only be used for a single project that may last for a short period? This is an issue that strikes a deep chord with institutional database development staff. Most considered themselves willing to give advice, even where they didn't have capacity to take on the development. It was felt preferable to having to sort out issues of trying to re-code and integrate large amounts of data to interoperate with Corporate Systems at a later date. Yet practitioners' perceptions were that they would not 'want to be bothered'. Even if willing to be involved in development, how long would the development take? We have already reported in this resource that a major consideration in Business and Community Engagement is the need for a speedy response. A solution that might take weeks or months is unlikely to be a viable solution when the opportunity for a new engagement project arises.
• Secondly, few staff, either academic or administrative, have full access to the major information systems or the authority to decide on coding systems and uses for any spare data fields, built into such systems by software companies to be utilised according to local need. Whilst reporting output may be readily available (there is an emphasis on the word 'may'...), in most cases it is not easy to download or even (particularly?) link to the simplest of data from, say, the Student Record System, to reduce the need for duplication in a local database system. Without having access to the database structures field names, data types and lengths in a locally developed database rarely match exactly to their counterparts in Corporate Systems, leading to an exacerbation of problems if the success of a Business and Community Engagement project outgrows the local system.