IT Solutions, Software & Licences

A Managed Service Contract, or Managed Service Agreement (often abbreviated to MSA) is a contract under which a business outsources the responsibility for maintaining its IT systems to a third party.

It is often contrasted with the break/fix outsourcing model where a service provider performs on-demand services only when needed and requested by the client business because something has gone wrong.

Services provided under an MSA may well require the provider to respond to requests on demand because things have broken, but the services will typically include ongoing monitoring of software and hardware, proactive updating and patching of systems, virus checking, conducting back-ups and other services to minimise the occurrence of problems before they happen.

A Managed Service Agreement can also be contrasted with a Master Services Agreement. The latter is a master contract with terms that govern multiple separate contracts made under it, for multiple separate projects. Usually each project is governed by a “Statement of Work” (often abbreviated to SOW).

Managed Service Agreements typically contain a list of the services that the service provider will perform and, for some of those services, it will include service levels – setting the standard to which the services will be performed. Therefore, sometimes, MSA’s might be casually referred to a Service Level Agreements or “SLA’”s. The schedule of an MSA that contains the service levels might also be called the “SLA”.

This model is a sequential style of software development that breaks down project activities into linear stages. These stages are followed successively, where each project phase depends on the deliverables of the previous one, hence the concept of a ‘waterfall’. There tends to be a series of initial phases of analysis and design to establish the full scope of work, before moving on to the build phase, system and user testing, acceptance, go live and maintenance. In between phases, a deliverable is expected and/or a document is signed off. All phases are passed through and completed only once, so all requirements are gathered as much as possible at the start to provide the information in creating the scope of work, plans, schedules, budget, and resources. This type of development is driven by clear planning and delivery milestones, so any changes after the project has started would offset the original plan and require a restart.

This linear methodology has benefits – it approaches the design of the system as a whole; it has a defined scope of work which means that there is clarity and transparency on development resource for the developer and subsequently cost for the customer; progress can be measured in terms of milestones and projects should stay on track in terms of delivery dates.

However, for others (both customers and developers alike) this approach is too structured, defined requirements can stifle innovation, it does not readily permit change and flexibility and as a result, particularly because testing only comes at the end of the project, the development runs the risk of becoming governed by the process rather than the customer’s wishes. Also, there is a danger that the development can end up costing more than originally envisaged; even though stakeholders may be confident that they know exactly what they require, their needs may change throughout the development process. By defining pre-requisites in the beginning, this makes adjusting to new changes more difficult to manage and implement and overall more costly. In the Waterfall methodology, all requirements must be completely documented and approved before any development can occur. This means that a lot of the work is done before moving onto the building phase and of course, this can either be beneficial or detrimental to the project’s success.

A privacy policy (also called a privacy notice) tells individuals how you process their personal information. The information that needs to be included in a privacy policy is listed in the UK GDPR. There are also rules about how you write a privacy policy, such as the requirement that you use clear and plain language.

You can target a privacy policy at a particular group of people. For example, having a privacy policy just for users of your software.

One of the simplest ways of providing fair processing information to your data subjects (i.e. telling people how you process their personal data) is to have a privacy policy on your website. Your website is often the first place a data subject will look for information about what happens to their data. If you already tell people what you do with their personal data using a different method of communication then it might not be strictly necessary to have a website privacy policy.

PaaS is a cloud computing model where a provider delivers hardware and software tools to users over the internet. Usually, these tools are needed for application development for example, services such as application hosting and Java development.

Examples of PaaS products include AWS Elastic Beanstalk and Google App Engine.

A PaaS provider hosts software environment and tools so that the end user doesn’t require its own infrastructure.

Whilst PaaS does not replace a company’s entire IT infrastructure for software development it does free developers from having to install in-house hardware and software to develop or run a new application.

Users will normally have to pay for PaaS on a per-use basis. However, some providers charge a flat monthly fee for access to the platform and its applications.

A software licence is essentially the ‘authorisation’ granted by the software proprietor to you as the user, to access and use the software under certain terms and conditions. Those are all set out in the licence, together with a cost, the duration of the authorisation and restrictions about what you can and cannot do with the software.

In an IT context, system procurement means purchasing any aspect of an IT system for your business, whether it be hardware, software or IT services related to your IT systems.

In its broadest sense, it the term system procurement can refer to every stage of the procurement process, from determining requirements for IT systems, choosing and then communicating with suppliers, entering into procurement contracts, through to managing the assets acquired.

IT systems can be a significant purchase, so it is important to get your IT procurement contracts right before you invest.

Software as a service (or SaaS) moves away from the traditional method of licensing software as a tangible ‘product’ and moves towards the provision of software as a secondary consideration to the provision of the overall service offered under the software. It tends to be a hosted service so that there is no in-premise installation on the client’s own systems. There is less focus on ‘design, acceptance and maintenance’ as distinct phases of a software project and more of a view towards the provision of a more rounded service.

Although SaaS can be modified for specific users, and often is, the premise is that it is more widely available to multiple users in the similar format so that everyone benefits from upgrades and there is no longer a requirement for the client to implement patches as this is done at server level by the proprietor.