Applying the design and standards strategies

• Overview
• Design technical components of systems to enable better record creation
• Responsibilities for technical design
• Steps involved in technical design
• Conduct regular design reviews
• Develop a migration and/or conversion strategy
• Documenting technical design

Overview

If in Step E: Identification of strategies for recordkeeping, you selected design and standards as strategies that would be of use to your organisation, this section examines how you can develop and use technical solutions a means to improve organisational recordkeeping.

Design technical components of systems to enable better record creation

Depending on the strategies selected in Step E, or the nature of the systems with which you are working, it may be necessary to design significant electronic components for your recordkeeping system, or to integrate some automation into existing paper-based systems.

Responsibilities for technical design

The technical design of your recordkeeping system may be conducted by:

• the IT and business analysis staff on your project team
• external consultants
• system vendors, or
• a combination of the above.

The range of staff you may want to include in your DIRKS project is outlined in the Introduction to DIRKS.

Tip: Staff with recordkeeping responsibilities should be involved in technical design
Staff with recordkeeping responsibilities have a key role to play in technical design. Even if you have no interest or expertise in technical design you must be prepared to provide a professional opinion on the recordkeeping functionality of the electronic system as it is being designed. Ask questions or speak out if it appears that the recordkeeping functionality of the system is being compromised, or if your requirements are being misinterpreted.

Obtaining IT involvement

If you are having trouble in convincing your IT staff that they should be involved in your system redesign projects, there are a number of points you can emphasise to demonstrate the utility of your project to both organisational and IT objectives.

Example: 'Sell it' the project your IT staff

To demonstrate your project's relevance, objectives and validity to IT personnel, discuss it using IT terms and concepts. You could emphasise that your project is:

• concerned with better management of organisational data - its implementation will help IT deal with this key objective
• identifying and rectifying data redundancies, another key IT objective
• seeking to establish better control over corporate information
• developing more comprehensive disposal coverage to enable the legal destruction of inactive records
• improving metadata capture to better document the use of records
• improving record accessibility, including those records that have been 'archived'
• improving information accessibility rates, or
• concerned with the better management of organisational e-mail.

Your project will have many synergies with organisational IT objectives, and highlighting these should help to give you the IT or system development support you need. Better positioning your requirements, and demonstrating how they serve broader information management needs, will help you to obtain the support you require.

Example: Work together

In its assessments of organisational systems, Indiana University noted that to the university's IT managers that the 'standard back-up procedures were not creating an environment where records could be easily retrieved and were not preserving the kind of records that would be useful in  the future'. [4] Specifically examining IT procedures and discussing their concerns from an IT viewpoint helped both IT and records staff to agree that there was a problem and to work together to rectify it.

Tip: Sign a 'memorandum of understanding' (MOU)
Consider establishing an MOU with the IT Department and build responsibilities for your project into IT planning. If IT staff have written responsibilities as part of the project this indicates their significant commitment to the project.

Before you talk to IT staff about the type of technical components you want, make sure you have a very good idea about the functionality you want from your system:

• what should it be able to do?
• what type of metadata do you want to capture?
• what types of records should it administer?
• should it be capable of resolving access permissions?
• does it need to integrate with other business systems?
• do you want to employ classification schemes?

Clearly outlining these and other requirements will greatly assist IT and system designers to understand your needs and help all participants build a system that meets business needs. The ideas you outline should not just be preliminary. You must provide solid information so that the designers can create specific functionality that enables your organisation to meet its recordkeeping requirements.

You do not need to become an IT or technology expert to effectively undertake this step. You do however need a good understanding of how you want your system to operate and be able to explain this, using appropriate terminology and concepts, to IT or system design staff.

Example: Do not assume understanding
Staff at IndianaUniversity found that when dealing with IT staff or those with data management responsibilities, IT personnel had a good understanding of functional assessment, metadata and how data is managed within systems. They did not tend to have a great degree of familiarity with records as defined by AS ISO 15489, the role and importance of contextual information and the value of evidence in organisational business systems. Informational content is often regarded as more valuable and of more organisational importance than the preservation of evidence. [5] Therefore do not assume that all your colleagues will have the same understanding of concepts and issues. Be sure everyone is working from the same definitions and understandings before you commence any specific design work.

Steps involved in technical design

It is not the purpose of this step to describe in detail the different modelling tools used in computer system design. The following outline simply provides a brief introduction to the process and focusses on:

• determining whether to buy or build
• conducting logical systems design
• conducting physical systems design, and
• developing a systems testing plan.

Tip: Do not do the work, but advise on your requirements
If you are a recordkeeping professional, you do not need to undertake these technical design processes yourself. You should, however, be aware of what they involve and be prepared to advise IT staff on your requirements in relation to them.

Determine whether to buy, build or both

When it comes to designing or redesigning the technical components of your system, it is necessary to determine whether:

• existing in-house technology can be utilised
• additional technology should be bought and/or tailored, and
• additional technology should be designed and by whom.

The recordkeeping requirements that you articulated in Step C, the recordkeeping gaps identified in Step D and the overall design strategies determined in Step E will indicate the complexity and scope of the technological components that you need.

Factors likely to influence the decisions you make about the technical components include in your decision to adapt, acquire or design include:

• cost of the proposed strategy
• the flexibility or lack of flexibility it contributes
• the speed and/or ease of integration with existing technical and other system components, and
• availability of staff or contractors to perform design work.

Conduct logical system design

Logical design pertains to the 'what and when' of a system, that is, its functions and processes. It focuses on what the system should do, and how it should appear to the users. Logical design involves the use of various conventions and modelling tools to translate the requirements identified and documented in steps C and E into detailed technical specifications for system inputs, outputs, interfaces and data stores.

Logical design includes the design of:

• forms and templates, such as metadata templates, which enable the presentation and collection of information
• user interfaces, such as menus and dialogue boxes, which enable users to interact with a system, and
• data stores, such as databases, which enable data or information objects to be stored in a structured way.

During the logical design of an electronic system, users need to be actively involved in reviewing the design to verify that the system is usable and continues to meet requirements as it evolves.

Tip: Build good interfaces
Do not forget the importance of good user interface design. A good design will encourage and facilitate people's use of the system and is important to the success of the system you are designing.

Example: Metadata redesign
If, in the course of your Step D: Assessment of existing systems analysis you noted that your business system is not specifying adequate metadata, and you opted for the design strategy in Step E: Identification of strategies for recordkeeping, you should incorporate metadata redesign into your Step F work.
Consider the types of metadata required to meet your recordkeeping requirements and build these into your system design. Consider means by which metadata capture can be simplified through such means as automatic metadata attribution, metadata inheritance etc.
Consider how record classification can assist with metadata attribution. Can certain metadata elements - such as disposal, access, preservation, function etc - be applied to aggregates of records that have been similarly classified, to save you or your users from having to attribute metadata to each individual record? The business classification scheme you developed in Step B will help you to simplify your metadata management in this way.
Consider too, how you want staff to apply metadata. Do you want to include a lot of guidance in the system to help staff choose appropriate metadata? Do you want to build thesauri or other tools into the system, or a range of default values, to limit user choices and control the type of data that is input into the system? Choosing to follow this approach can be labour intensive in the design phase, but can help to reduce mistakes and the amounts of invalid data that is input into the system.
Metadata can be used in many different ways to help you meet your recordkeeping and other business objectives, so consider how you can make this happen during the course of your Step F deliberations.
You may also want to examine the NSW Recordkeeping Metadata Standard for additional guidance in this area.

Conduct physical system design

Physical design deals with the 'how and where' of a system. It involves specifying the technological characteristics of the system, including:

• overall system structure
• system integration
• software program structures
• hardware configuration, and
• data (information) processing, storage, access and protection.

Tip: Use open systems and technical standards where possible
In their physical system design, it is strongly recommended that organisations specify and adopt open systems architecture and non-proprietary information technology standards to manage electronic records required for long-term access.

Note that system integration can include:

• integration with existing electronic systems or applications (for example, an organisation's legacy system, current electronic document management system or suite of document authoring applications), and
• integration of specific recordkeeping tools (such as thesauri, retention and disposal authorities, or metadata creation tools) to enhance the recordkeeping functionality of the system.

A system integration plan should be compiled for use during implementation phase (Step G). This plan is similar in concept and structure to the system implementation plan, but it relates only to the technological components of the system.

Decisions made earlier about whether to buy, build or combine both approaches will impact on the physical design of the system. In one sense, the decisions made at that time really constitute a part of the physical design. Inevitably, the choice of particular technologies will place constraints on the functional capabilities of system being designed.

It is possible that problems or errors will occur during physical design which can be traced back to the logical design stage. This may reflect inconsistencies in the requirements. Even at this late stage, you need to continue consulting with users, gathering additional information and, where necessary, making and documenting changes to the requirements and/or the system design.

As the final design activity before system implementation, physical design provides the last opportunity to ensure that the system design is consistent, complete, and meets the requirements. Changes to design after this time will prove both costly and time-consuming. It is therefore strongly recommended that system auditors and security specialists contribute to this activity.

Tip: Considerations when developing a database solution

If it has been decided that your solution will involve the development of a database within which to conduct your organisational business, make sure that recordkeeping is adequately built into this solution.

The Public Record Office of Victoria says that the following issues need to be considered during database design, to ensure that the solution you are constructing is able to meet your recordkeeping requirements:

• The record - identify exactly what is being recorded, and what is the evidence required of this business?
• The schema - create full documentation of the database tables and relationships (this is usually done as part of the design specifications for the database)
• Standards - be sure to consider use of open data standards for both database construction and data formats
• Export - ensure you have the ability to extract (export) all the components of the record (which may include tables, audit logs, report templates and other design information) from the database in usable formats

For further guidance see Public Record Office of Victoria, Preserving Records in Databases, May 2003.

Example: What if the system I have developed is too large?

You have developed a technical component for your system that meets all identified recordkeeping requirements. Unfortunately, however, it is too big. Storage costs are getting cheaper in the electronic environment, but infrastructure required to support systems is getting more expensive. Therefore your solution may be too costly for your organisation to implement or may require too much network space than can be allocated.

If you find yourself in this position you can:

• negotiate with management and IT - demonstrate how your project is trying to provide solutions for key organisational issues and the extra cost required to complete the project is therefore justified
• use risk management techniques as a means of scaling back your solution - have you built in functionality that addresses only medium level concerns? Can some functionality that deals with such matters be removed as a means of decreasing system size? Is the system scalable - can the desired functionality be incorporated in full later when greater system capacity may be possible?
• utilise other Step E tactics - if your full design plans are just not feasible, can you use policy or implementation tactics to meet your recordkeeping requirements? Will a combination of rules and training lead to the same outcome?

Develop technical application testing plan

One final activity in the design of the technical components of your system is to develop an overall testing plan. This plan is a sub-element of the testing processes referred to in Step G.

The system testing plan details the different kinds of testing which need to be carried out during implementation of the system, and specifies what form(s) the testing should take. Testing of electronic systems involves using test data and scenarios to verify that each component, and the system as a whole, works as intended under both normal and unusual circumstances. Working 'as intended' means meeting requirements as documented in the requirements specification.

Some examples of what needs to be tested during the implementation of an electronic recordkeeping system, or during the incorporation of recordkeeping functionality into an existing system, include:

• system functionality (does the system do what it is required to do?)
• system integration (how well do the different components work together?)
• user interfaces (are menus, forms and templates understandable and usable?)
• validation of inputs and outputs (does the system produce or allow the entry of erroneous data?), and
• system response and recovery times (how quickly does the system perform tasks and how long does it take to recover from crashes or interrupts?).

As discussed above, system operating procedures will also need to undergo testing to ensure correctness, usability and understandability.

Tip: Competing priorities may affect timetables
Remember DIRKS projects, particularly if they involve technical design components, are very reliant on the efforts of a range of people across your organisation. These people will have a range of other demands on their time, and so making long term commitments to achieving your DIRKS requirements may be difficult. Be prepared for compromises and delays that may be unavoidable due to competing priorities amongst your DIRKS team members.

Conduct regular design reviews

Remember that it is important to involve system users in the process of the design or redesign of your technical components. Liaise with users about aspects of the design that affect them through both formal and informal means, and use this as a mechanism for obtaining useful feedback. Do not forget to have formal design reviews at critical stages in the design process, such as the completion of the design of a major system component.

Design reviews help to maintain links between the requirements you are aware of or articulated in Step C of your analysis, and the design activities you are now undertaking. These reviews will highlight requirements which have:

• not been properly addressed
• changed, or
• become infeasible due to other changes or new constraints.

Design reviews often result in requests for changes to requirements and/or to parts of the design itself. For this reason, it is essential to document the outcomes of the review. It is also vital that you maintain a visible documentary trail from the requests for change to resulting changes in requirements or design. Requested changes which are not implemented, or which are implemented only partially, must also be documented.

Tip: Remember to separate development and operational facilities

According to ISO 17799, the International code of practice for information security management, it is important to ensure that design and testing operations for significant system redevelopment are separated from your operational environment. In clause 8.1.5, the standard states that the following controls should be in place:

a) development and operational software should, where possible, run on different computer processors, or in different domains or directories

b) development and testing activities should be separated as far as possible

c) compilers, editors and other system utilities should not be accessible from operational systems when not required

d) different log-on procedures should be used for operational and test systems, to reduce the risk of error. Users should be encouraged to use different passwords for these systems, and menus should display appropriate identification messages

e) development staff should only have access to operational passwords where controls are in place for issuing passwords for the support of operational systems. Controls should ensure that such passwords are changed after use.

The standard also states that 'rules for the transfer of software from development to operational status should be defined and documented.'

ISO 17799 can be purchased from Standards Australia.

Develop a migration and/or conversion strategy

If, at the end of your work in applying the design and standards tactics, you have developed new systems or redeveloped old ones, you may need to develop record migration and conversion strategies to ensure records are carried forward from old frameworks into new ones. You plan for and undertake these activities in Step F, Design of recordkeeping systems.

Migration is the 'act of moving records from one system to another, while maintaining the records' authenticity, integrity, reliability and useability'. [6] Conversion is the 'process of changing records from one medium to another or from one format to another'. [7]

Example: When migration is needed

You would need to undertake migration activities if:

• business information systems were to be decommissioned or superseded as a result of your DIRKS work and the records they contain need to be maintained in an active system,
• as a result of your system assessment it has been decided to upgrade to the next version of a software application and records need to be carried over into this new environment, or
• existing business information systems have undergone significant transformation and records need to be migrated into new system components.

Example: When conversion is needed

You would need to undertake conversion activities if:

• you have decided to implement technical standards for records management and need to convert existing records to the new standard format
• you have decided to adopt a digitisation strategy and need to convert all paper records into an electronic format, or
• you have identified that records stored on one format are at risk, such as records stored on floppy disks, and want to move these to a more secure format, such as CD-ROM.

Both migration and conversion activities need to be conducted carefully and need to be tested and well documented. See State Records' guideline Managing digital records. This document contains a range of clear guidelines to help ensure you conduct conversion and migration activities in an accountable and efficient manner.

Documenting technical design

In most design projects documentation is an ongoing and prolific activity. System design documentation is developed progressively at different stages (or 'milestones') in the design process. In addition to the policies and procedures you may develop, each design solution generated by the project team or tendered by an external party should incorporate extensive design documentation, including:

• design diaries, detailing original design decisions and rationale, and documenting changes made to the design over time
• introductory, non-technical design descriptions which can be understood by senior management, staff and other stakeholders
• descriptions of redesigned or newly designed business processes
• logical and physical models of different aspects of the system
• metadata specifications
• structured, precise hardware and software design specification(s), aimed at computer system developers and vendors
• initial testing plans
• initial training plans, and
• skeletal system implementation plan.

Footnotes

[4] Philip C Bantin, 'Developing a Strategy for Managing Electronic Records - The Findings of the Indiana University Electronic Records Project', The American Archivist, Volume 61 (Fall 1998), 359-360

[5] Ibid, 360

[6] Definition provided in AS ISO 15489, Clause 3.13

[7] Definition provided in AS ISO 15489, Clause 3.7