Maintaining IOMS Technology

Overview

There are three aspects to supporting the IOMS system on an on-going basis.

First is the general IOMS application maintenance. This involves fixing faults that arise and carrying out minor enhancements to the system that would not normally be justified as a separate release.

Second is the on-going upgrade to the underlying technologies that the IOMS system is built on. This enables the introduction of new technologies as required, and also enables the on-going support of the system through resource availability. This follows the approach in the IT Strategic Plan of ensuring that technologies employed are at similar levels to those currently used in the general marketplace.

The third aspect is the review and refinement of the development process that is used to maintain existing or develop new functionality within the IOMS system. This is required to ensure that development is carried out in the manner that reduces risk, yet at the same time ensures changes in the IOMS system are made in the most efficient and effective manner.

This section explores these three aspects in greater detail.

IOMS Application Maintenance

Application maintenance is essential to ensure system reliability and usability on an on-going basis.

Application maintenance can be broken down into the following general areas:

• fixing faults
• minor enhancements to meet evolutionary changes in business processes as part of continuous improvement
• attention to the underlying architectures to maintain version currency to a reasonable level
• technical and business support (e.g. training, help desk)
• administration and management overheads.

During the OPR in 2003/04, work that defined the required maintenance work for the IOMS system was completed. At the time funding was set at a level to cover both minor Change Requests (CRs) and the level of faults logged historically.

As this review proposes no major replacement of the IOMS system, rather a process of gradual enhancement and refinement of business requirements, and maintenance of the existing application, there is no reason to expect that the level of funding currently allocated to maintenance of the system will not be adequate.

The existing funding will effectively cover:

• fixing existing faults
• implementing minor change requests
• maintaining support structures.

Funding is also at a level were it can support the system through the number and scale of changes proposed in this review, and can be maintained at this level for the next five years.

Underlying Technology Upgrades

Since the IOMS system was initially developed (based on established technologies available in 1997) the underlying technologies that support the application have been upgraded where possible to ensure that the system continues to be maintainable and supportable. This has involved upgrading versions of the Visual Basic toolset, the Oracle database, and the use of new tools such as COM+ components where appropriate.

The IOMS system has been maintained to a position where it is compatible with existing and current technologies in the market.

To ensure that the IOMS system continues to support the business to 2012 in a reliable manner, this approach will continue - specifically:

• continuing to maintain the version of the development tools to those commonly used in the market (not leading edge)
• implementing new tools where they have a technology advantage.

This approach, however, does entail a number of caveats that must be clearly understood:

• upgrades in technology will be carried out in a manner that do not put at risk the development of functionality to support business needs
• any changes in technology will follow the strategies laid out in the Department's IT Operation Strategy, which sets the direction for IT at Corrections
• the use of new technologies will meet the current and future operational needs of Corrections
• any changes in technology will be carried out in an incremental manner, and will be done as part of wider work, not as a delivery in its own right.

Architecture Principles

A set of key architecture principles have been developed to enable effective and efficient support for the future direction of the IOMS system and changing business needs. These principles are:

• Component Reusability:
  That a business object should be developed once. It needs to deliver functionality that is usable in multiple business processes.
• Device Independence:
  The software should be available to run on any hardware device, be it computer, laptop, or PDA. The Graphical User Interface (GUI) will dictate what data is collected from the user and which and how returned data is presented by the device.
• Use of Software Engines:
  Any third party product being considered, even if there is no requirement to interface with the IOMS system, must conform to an n-tier architecture. It also must expose business objects, preferably as web services, so it can be integrated with the Department's other web services and/or GUI in an easy and seamless manner.
•  Workflow Definition:
  That workflow is defined at the business object layer so that it can be modified easily as appropriate.

These key principles help define future architecture direction.

Architecture Direction

Based on the principles above, the high level architecture for the IOMS system will be aligned to fit with an open, componentised, n-tier architecture as it is updated over the next few years.

This involves moving from a 3-tier architecture to a multi-tier architecture. The structure of these layers are:

• The Graphic User Interface (GUI) layer:
  Provides for the user presentation and input of data. The GUI may be forms or browser based and may perform input validation. Business processing logic is to be avoided at this layer, other than the knowledge of which business objects to call and in what order.
• The Integration layer:
  Provides a central interface both for real-time messages and batch files sent to and received from external organisations. Security and formatting validation are performed at this layer.
• The Business Objects layer:
  Provides the business functionality. This is the layer that provides the calculation, related data driven validation, extraction and update processing. Many of the business functions will be exposed as small, stateless objects. This strategy allows for the easy integration of multiple front end systems i.e. channel independence - ideally a PDA running over a wireless network should be able to utilise the same business object calls that a Windows forms-based application at head office uses. It is necessary for business objects to call other business objects.
• The Data layer:
  Where all the databases reside. Data may be shared or replicated between databases. Stored procedures for data collection and update functions are encouraged. It is preferable that these are as generic as possible as long as processing efficiency is optimised.

Effectively this moves the environment from a technology structure as in diagram A (with business logic at every level) to the one in diagram B (with distinct layers for user logic, business logic, information management, and database).

The Path Forward

Given the architecture caveats, principles and directions above, and the development tools the IOMS system is currently written in, it is appropriate to continue with the identified migration paths for these tools, effectively moving to an architecture based on the Microsoft .Net set of tools. This will ensure a continual development path, and compatibility of existing code.

As modules and functions in the system need major patching, or re-development because of business need they will be re-developed in the .Net tools, and will be structured to co-exist with the existing IOMS code. This will need to be managed within the caveats above.

This will lead to a situation where the existing IOMS system functionality co-exists with new functionality developed in .Net.

Review and Refinement of Development Approach for the IOMS system

The development approach has been reviewed to ensure the Department gains the maximum benefits from the technologies that are now available.

The Department has been successful with the development of IOMS by working to a model that has ensured the active involvement of business users in the development life cycle. It is essential that this approach continues irrespective of which development approach or technology are used.

Current Development Approach

The Department has followed a traditional "waterfall" development approach for its bespoke development in previous years. The current waterfall approach has the following characteristics:

• it is a formal and highly structured process
• there are structured checks and sign off points at regular intervals
• the business participates in the process in a very defined manner, typically only during the analysis and testing phases.

Alternative Development Approach

Alternative approach that will work within the Departments' environment. The alternative "fast track" approach has the following characteristics:

• a more dynamic, or "agile" process
• less structured formal checks and sign off points
• the business participates fully in the process, typically supplying up to half the resource requirements during the design, planning, and testing cycles.

This approach has the advantage of increasing the speed of development, and reflecting a refinement of the product as it evolves. However there are risks around this approach, which are:

larger business involvement for longer (i.e. it is more business resource intensive than the waterfall approach)

an acceptance that the formal signoff points inherent in the waterfall approach do not exist in this agile approach, so the result can be different than expected

involvement is limited to the business people on the project

the level of functionality is variable.

The two approaches are illustrated below.

Click here to view large image (jpg: 53KB)

Preferred Approach

A combination of the two approaches is recommended.

Which development approach will be used when, will depend on the work requirements. The decision will be based on an assessment of the following criteria:

• What is the level of business resource available to participate in the project?
• How defined is the boundaries of the work to be developed?
• How complex is the piece of work to be developed?
• What are the required timelines for delivery of the work?
• How well understood is the final deliverable, and how well defined is it?

Business resource availability can be a major constraint on future development, and does impact the work programme and the definition of business requirements. These business resources cannot be replaced by external resources, and are impacted by other demands within the Department (i.e. other business demands or legislative change). The approach to IOMS development is that critical business functions take priority over the system development, and if there is a resource constraint then system development may be impacted.

Supporting IT Unit Structure

There are also changes required to where functions are carried out within the IT Unit to ensure the best possible output from available resources. These changes are in the location of functions, and there may be some re-allocation of staff within IT, however no reductions in staff levels are envisaged.

The changes in functions that are envisaged are:

• The IT Architecture team will take an overview role of the development process to ensure that development standards are met and that the development fits within the overall Corrections architecture. They will also ensure that the development meets high-level requirements, and will have signoff on package selection.
• The use of outsourced resource for the development of the IOMS system will be reviewed to ensure that it is the most effective approach.
• Information structures, definitions, rules, flows and metadata will be defined by the Information Services team early in the development process (rather than by the BSD team), based on business requirements. Logical database structures will be developed from the information model. This will ensure that information structure fits with overall department standards, and will also speed up time for the set-up of data warehouse functionality to use IOMS data.
• Development will be modular.
• Overall integration testing will be reviewed and integrated with certification functions to ensure that any new functionality does not put the production environment at risk.
• Business Analyst and Testing teams will be expanded using business resource, rather than hiring additional external resources where possible.
• Potentially Business Systems Development (BSD) teams may be split into waterfall and agile teams, with separate management.