Case Study: Production System Refresh

The organisation had embarked on the replacement and extension of an existing system that controls the manufacture of a range of standard products. The existing application was approaching end of life and there was no suitable package solution that could provide the required functionality. A new solution was not expected to replace the existing system, rather it was intended to work with, and utilise the features and services provided by this system (especially those already in use).

Business Aspect project work started by defining the environmental framework requirements required to support the SOA (services oriented architecture) approach chosen as the basis for the solution system. The solution system comprised a number of components which interacted dynamically to produce the required user outcomes. The interactions between components were defined as services that the component supplied, and those it consumed (supplied by another component).

The philosophy for the establishment of components was reuse, buy, and then build. Thus, if a component existed that could provide most of the services; it would be adopted and used. Otherwise a suitable component would be bought and adapted to suit. Finally a component would be built if no other suitable solution was possible. Each component would need to comply with the architecture as specified in the environment specification.

A number of high level objectives were defined that guided the process of selection, these included:

  • Control – the organisation has control over the components – either through ownership of the source code (i.e. when built) or through the ability to replace if necessary
  • Adaptability – changes and enhancements required by the organisation can be achieved in acceptable timeframes and costs
  • Support – the system and all its components are supported in a manner that provides the organisation with acceptable levels of business risk.

The overall functionality and high level decomposition into components was specified in project documents. System development and implementation was performed one component at a time. The order in which components were developed and implemented was determined by the business. This approach required existing systems to be services-enabled to facilitate the transition.

For each component, the process of defining the requirements proceeded through the following steps:

  1. As Is Requirements – a definition of the current processes and system support as they exist within various operational units. This includes identifying issues and suggestions for improvement
  2. To Be Requirements – a definition of the proposed component solution and how it will operate within the organisation. These were reviewed and approved by business representatives to ensure suitability, completeness and commitment to implementation and support
  3. Selection of realisation approach – i.e. native package component, wrapped package component or built component
  4. Realisation – the development of the solution to meet the To Be requirements
  5. Implementation – after appropriate testing and acceptance

The size of the IT group did not enable it to take responsibility for the development and support. It planned to establish a relationship with a third party to provide these capabilities. This arrangement needed to incorporate safeguards for failure and change of ownership of the company. The IT group would position itself to provide the first and second level of support with a view to being able to provide user and configuration capabilities.