Procuring a new application can be a daunting task. There's likely to be a significant investment in time and money in order to choose and implement the right solution. Getting it wrong can mean that benefits are not realised, and opportunities to change to something else are likely to be a long way off.

These pages should help to get you on the right track. Please get in touch if you would like to discuss any aspect in more detail.

Where do I start?

If you haven't done so already, you will probably want to review the processes your new application will support, and identify how they can me measured and improved (you won't want to automate inefficient process). Having done that, if you still feel an application is required (don't underestimate how much can be achieved by just improving your processes) you'll need to put together a business case that will support your intention to purchase and implement an application.

The business case will identify what the costs/benefits (both should be measurable) of your project will be, along with details of how the benefits will be realised, as it is unlikely that implementing a new application in itself will be the means to the end.

IT Services can assist with all of the above. First point of contact would be our IT Business and Service Analysts, but you may also want to have a look at our Project Management Services

Buy or Build?

You've analysed and improved your processes, now you need an application to automate them, so that you can deliver all the benefits identified in your business case.

At this point you need to identify whether there is a commercially available product that you can purchase, implement, and configure that will suit your needs. It may not be possible to find something that's a perfect fit, so it may be necessary to go with something that is almost right, and change your processes, or the vendor could modify the application to fit your needs.

BEWARE! Vendors may be willing to do this, particularly if you are an early adopter (try not to be!), but customisation can cause problems for you and the vendor in the future if not managed correctly. If the changes they make for you aren't incorporated into the core application, how will your customised version of the software be supported and maintained through upgrades to the core? Maintaining various versions for different clients is rarely sustainable for the vendor.

If you have unique requirements, that can't be met by a commercially available product, then you may wish to consider having an application built for you.This is likely to be an expensive option, as you would have to carry the cost of development, and on-going support and maintenance on your own. It may be that the solution you have built could then be sold to other customers, creating a broader financial base for support and development, but it's probably best to assume this won't be the case. The vendor will be looking to recoup their on-going costs from their captive market, so you should therefore expect costs to rise, as time goes on, as you carry the full cost of changes and updates to the solution.

You may already have resources available to you that have the skills to be able to create a solution that meets your needs. This can be an attractive option in the short term, but be prepared to build maintenance of those skills into your training budgets and recruitment strategies if you will be relying on the solution being available and up to date in the future.

Hosting

Quite often now, a major consideration when procuring a new application is whether it can/should be hosted by the vendor in the Cloud, rather than installed on servers at the University.

Some things to consider:

If the vendor were to host the application.....

• They would be responsible for its availability and performance. We wouldn’t have the vendor blaming the servers, and the server team blaming the application when issues arose. The vendor would just have to make it work (note: Service Level Agreements need to be suitable and enforceable)
• Accessing a remote service could mean that it is slower than if it was hosted here, and there would be a limit to what the vendor could do about that, as we would be relying on the Internet, which they have no control over.
• It’s possible that the vendor would be able to provide out of hours support, which may be a requirement. IT Services isn’t funded to provide support out of hours, so it’s only available on a good will basis.
• The vendor would carry out upgrades and patches to the Application, Operating System and Database, which would reduce the skill level required for us to manage the application. However, we may be forced to take upgrades we don’t want/need at inconvenient times, that may also have a training overhead.
• Building interfaces and integrating the application into our environment would likely be more difficult if it were in the Cloud. We would be limited by the API, as it would be unusual for a vendor to allow direct access to the Database. The vendor would need to be able to demonstrate how their application would integrate with our authentication mechanisms, and how both large and small amounts of data could be exchanged in a timely and automated manner, if required.
• If the vendor were to cease trading, we would need to be assured that the software would still be hosted and available to us whilst we sought an alternative. If we had the software here on our servers that would be less of a risk.
• Data security becomes more of an issue, as the vendor would have our data on their servers. The location of those servers would need to be considered in addition to how the data would be secured both in transit, and at rest.
• If we decided to change vendors at any point then data migration would likely be more difficult.
• The vendor would generally charge for hosting the application.
• If the vendor hosting option is robust, performant, and affordable, then it would probably be useful to think about why you wouldn't want to take it, rather than why you should.

Security

The level of security required for your appliction will depend upon the type of data it will process:

There is lots of good information about this here: Information Security

If your application will process credit card payments, then you will need to consider the implications of The Payment Card Industry Data Security Standard (PCI DSS) on your implementation. The University's position on this is documented here: PCI DSS

We have experience of implementing systems that process credit card payments, and will be happy to help.

Application Management

Once the application is implemented you will need a mechanism for reporting and resolving any issues, and managing any changes to the application in the future.

The Application Management Service has mature processes for managing Incidents (issues and service requests reported via the Helpdesk), Problems (addressing the route cause of related/serious incidents) and Change (upgrades, etc.). We will also act as an interface between the customer and other service providers, both internal and external to IT Services.

We can't provide this service to everyone, but if you are interested in taking advantage of this facility, then please speak to us as early in the procurement process as possible.