Deployment Of Software Into Service
[ Home Page - Surveys - Documents - Presentations - Search ]
The start of your project will involve a great deal of planning and work scheduling. If you will be developing software, this is also the best time to consider and plan for its long-term future and viability. Decisions on software development made in the early stages of a project are important as they will often govern the options open to you for deployment beyond the life of the project. Although some choices may be influenced by the current technical environment of your institution, early consideration of a range of deployment issues will allow the possibility of a greater number of hosting options at the end of project, so ensuring continued existence of the software you have developed, and long-term access to it.
Careful choices will also reduce the cost of the work required for deployment, and allow you to minimize the portion of your budget that you have to allocate to the Service Provider.
If possible, software should be developed on the same platform that will eventually be used for service delivery. Microsoft Windows and Unix (especially Solaris) servers are the main options.
Porting software developed on one platform to another may not be straightforward, even if the chosen application software is claimed to run on both platforms. Proven technical solutions are preferred - do you have examples where your chosen application software has been used on both platforms?
If software licenses are required by the Service Provider, these must be available at a cost within the service budget. Be aware of licensing conditions: a Service Provider may require a commercial license if a charge is to be made for the service, whereas the project may be able to use an educational license. The cost of the various types of license may vary.
Care is also needed when choosing software that is free at the point of use to project staff, such as a University site licence for a commercial database system. Even though the project itself may incur no additional costs, licences could be prohibitively expensive for the Service Provider.
Consider the use of open source software [1] to avoid most licence problems! Good quality open source software can greatly reduce the cost of software development. Developers should be aware, however, that some 'open source' software is poorly written, inadequately documented, and entirely unsupported. Be aware that the costs of ongoing software maintenance, often undertaken by staff outside the original project, should also be factored in.
Good programming practice and documentation is very important. Well-written and structured software with comprehensive documentation will ease transition to a service environment and aid the work of the Service Provider [2]. It is better for a project to recruit a good engineer used to working in a professional development environment, than to recruit purely on the basis of specific technical skills. Also, try to code in languages commonly adopted in your application area: for example Java or Perl for Web programming. You can write Web applications in Fortran, but don't.
If possible a modular architecture is best. It will maximise the options for transfer to a Service Provider and also any future development. For example, if one application were used for a Web user interface and another for a database back end then, provided these communicate using open standards (Z39.50, standard SQL, for example), Web Services might be added to the service at a future date. A service built with a fully integrated single package of components that use proprietary native protocols might have to be scrapped and rebuilt to satisfy even fairly minor new requirements.
Use of Open Standards [3] should ensure portability, but there will still need to be technical structures supporting their use and deployment, whether in a project or service environment. You will need to document all the technical layers that need to be reproduced by the Service Provider in order for your software to run. Open standards can also give flexibility; for example the project and the service provider do not necessarily need to use the same SQL database, provided the standard is followed.
Be aware of your intended user base. Ensure that any user interface developed during the project has been through usability tests and allow time for any feedback to be incorporated into the final design. A well-designed interface will mean less support calls for the Service Provider.
When designing your user interface remember that there are legal requirements to fulfil with regard to disability access which the Service Provider will need to be satisfied are met. The JISC TechDis [4] service provides information and advice. You may wish to consider provision of user documentation and training documentation in support of the service, which the Service Provider could use and make available.
Comprehensive error reporting should be a feature of the deployed application. This will aid the Service Provider in identifying and solving problems. You should consider building comprehensive error reporting mechanisms into your software from the beginning, along with various mechanisms for escalating the severity of reported errors that threaten the viability of the service. These may range from simply logging errors to a file, through to emailing key personnel.
Services must be monitored. It should be possible to use a simple HTTP request (or equivalent for non-Web interfaces) to test the service is available and running, without requiring a multi-step process (such as log in, initiate session and run a search).
Logging is crucial for services, especially subscription services where customers need to monitor usage to assess value for money. Project COUNTER [5] defines best practice in this area. If project staff are still available, the Service Provider will then be able to provide you with logging information and potentially seek your input on future activity and development.
Authentication and authorisation should be flexible since requirements are subject to change. Enable the service provider to execute an external script, or at least write their own module or object, rather than embedding the authentication mechanism in the user interface code.
Where the product makes use of external middleware services (an example being for OpenURL support), ensure these are totally configurable by the service provider. Configuration files are good; but the ability to add modules or objects for these features is better.
Although not a technical consideration, it is important and worth emphasising that the Service Provider will require that all copyright and IPR issues be clarified. Where software has been developed, does the institution at which project staff work have any IPR guidelines that must be followed? What provision is needed to allow the Service Provider to make changes to the software? Is a formal agreement between the project institution and the Service Provider needed?
If you have identified where your software could be hosted then make early contact with the Service Provider to discuss costs and any constraints that may arise in deployment.
The Service Provider will need to be confident that your application will be stable, will scale, and will perform acceptably in response to user demand. If this is not the case then the application will eventually bottleneck and tie up machine resources unproductively which will lead to unresponsiveness.
You should ensure that the application is stress tested by an appropriate number of users issuing a representative number of service requests. There are also several tools available to stress test an application, but a prerequisite to this step is that the project team should be aware of their intended user base and the anticipated number of users and requests. The project team should also be aware of project and service machine architectures as divergence in architecture will affect the viability of any stress testing metrics generated. The Service Provider will want estimates of memory and processor use scaled by the number of simultaneous users. Performance and scalability will remain unresolved issues unless the project software can be tested in a service environment. If this is the case it is especially important to stick to proven technical solutions. You should discuss stress-testing results with your Service Provider as soon as possible.
Adopting best practices is a good start to ensuring that your application will be stable. The discipline of producing well-written and properly documented code is one safeguard against the generation of bugs within code.
If there are likely to be service updates you will need to consider the procedures involved and detail how the new data will be made available and incorporated into the service. Service Providers will generally wish to store two copies of databases that require updates; one being used for service with the other instance being used for updates and testing. Updated databases will also require frequent backups whilst static data requires only one copy of the database without regular backups. Consider splitting large data sets into separate segments: a portion that is static (for example archive data added prior to 2001) and a smaller portion that is updated (data added since 2001). Also, aim to keep data and application software as separate as possible. Again, this will aid a backup regime in a service environment.
You should anticipate that the Service Provider may need to make changes to your software. This may be due to possible technical conflicts with other services hosted by the Service Provider, or may be due to their implementation policy or house style. Again, early contact with a possible Service Provider will highlight these issues and help avoid potential difficulties. Also consider if project staff will be available for referrals of errors or omissions in functionality. If not, you will need to allow the Service Provider to make changes to your software.
If further development of the software beyond the project is feasible you should agree a development schedule and a timetable for transfer to production, as provision of a continued and stable service will be of prime importance to the Service Provider. Major changes to a user interface will also have implications for support and user documentation. If no continued development is planned, the Service Provider may still wish to introduce bug fixes or new versions of any software you have used. Again, good documentation and well-documented code will ensure that problems are minimised.
You should consider under what circumstances your software should be withdrawn and cease to be made available through a Service Provider. If you would expect to be involved in the decision to withdraw the service then contact with project personnel will need to be maintained, or you will need to provide guidance at time of transfer to service about the possible lifetime of the hosting agreement.
Allow time before the end of the project to work with the Service Provider. The availability and expertise of project staff will influence the success of moving to service deployment and ultimately the associated costs.
A complete handover of the software without good contact with the project team and without support may well cause problems and will also take longer. This is particularly true if the application contains technologies unfamiliar to the Service Provider. The project team should be prepared to assist the Service Provider in areas where it has specialist expertise and, if possible, factor in continued access to project personnel beyond the end of the project.
Complete and full documentation detailing the necessary steps for installation and deployment of your software and the service architecture, will aid an optimum transition to hosting by a Service Provider. The Service Provider may not have exactly the same understanding and skill set as the project team itself, and will require explicit instructions. Alternatively, the Service Provider may request help from the project team in identifying a particular aspect of the service architecture that could be replaced with a preferred and known component. Deploying technologies that are unfamiliar to the Service Provider will reduce their responsiveness and effectiveness in handling problems with the application.
Consideration should be given to development of a test bed and test scripts that will allow the Service Provider to confirm correct operation of your software once installed in the service environment.
Backup and disaster recovery procedures are the responsibility of the Service Provider; do not waste project time on defining specific procedures for the service (but do, of course, back up your project work for your own benefit).
Project activity is by its nature about exploring possibilities to develop new service functionality, and you may choose, or need, to utilise emerging tools and technologies. This approach to development and the software it produces may not fit comfortably with the desire of the Service Provider. A Service Provider wants software of service quality based on known solutions that ensures good use of resources and sustainability in a service environment. It is recognised that these opposing drives may be inevitable and that projects must be allowed to explore new technologies and methods, even at the expense of placing additional demands on Service Providers to resolve the problems of deployment.
If relatively immature technologies are being used it is very important that modular development procedures are used as much as possible. Where software has been developed in a modular fashion it will often be relatively straightforward to replace individual components; for example, to change to a different database application or servlet container. During the development process this means competing technologies, which may be at different stages of maturity, can be benchmarked against each other. At the deployment stage it means the option that provides best 'service quality' can be adopted.
Whatever choice of software environment is made, it is always wise to follow best practise by producing well-written and documented code.
It is worth stressing the benefits of contacting possible Service Providers to explore options at the start of a project: they too may be considering future strategy and it is possible that both your and their plans might benefit from co-operation.
[ Home Page - Surveys - Documents - Presentations - Search ]
Web page by Amanda Closier of UKOLN.
Last Modified 11-August-2004
Email comments to webmaster@ukoln.ac.uk