Cloud hosted software adoption guidance (SaaS)

Cloud Centre of Excellence - NHS Cloud strategy

Let us know what you think about the Cloud Centre of Excellence (CCOE) strategy.

Software as a Service often referred to as SaaS is a service model in which a provider hosts the application and makes it available to customers over the Internet. This is a significant departure from the on-premises software delivery model allowing organisations to outsource most of the IT responsibilities. With its immediate availability and cost-effectiveness (pay-as-you-go model), SaaS enables enterprises to scale the infrastructure up and down, depending on their needs, without setting up additional hardware and infrastructure, resulting in more flexible and scalable operations with dramatically reduced deployment times. Enterprises also have the ability to integrate most SaaS applications with other software using application programming interfaces (APIs).

NHS and healthcare services can finally abandon time-consuming tasks such as the setup and maintenance of servers, updating applications or operating systems, as well as the deactivation and disposal of hardware when it is out of date. Additionally, SaaS functionality complements the infrastructure services, ranging from billing, monitoring, log access, security services, backup, recovery and more.

Thanks to its easy web delivery model, with SaaS, providers manage all of the potential technical issues such as data, middleware, servers, and storage, while businesses can simply streamline their maintenance and support.

For an enterprise the key benefits of this are obvious:

fast time-to-market with a low TCO
scalability and flexibility
focus on business and innovation growth

By choosing cloud SaaS you can be sure that your technology is up-to-date and can scale up to meet your business requirements. This will allow you to allocate the budget and resources in a smart way and focus on the innovation of your applications and services.

Health and social care bodies MUST adopt software as a service applications first before using self-hosted software.

Software vendor selection considerations

When buying a SaaS product, there are many points you need to evaluate. The track record of the vendor, the similar businesses using the same or similar software, and the long-term value of the solution all need consideration.

The seven considerations below that should be evaluated when buying a SaaS product.

1. Will buying a SaaS product solve your problem?

Starting with the obvious, will buying a SaaS product solve a current problem the organisation is facing? Make sure you have a clear definition of the problem(s) you are looking to solve. A list of must-have features can also aid your evaluation. If the SaaS product you’re considering doesn’t solve the problem better than your current system, speak to your current system provider to see if SaaS will be an option they will be providing.

2. What security features and backup plans does the vendor use?

In an age of increased cybercrime, constant data breach scandals, and GDPR, security is a top priority. When buying a SaaS product, remember to examine not only the security of the solution itself but the vendor too. Read their privacy policies and ask questions about their infrastructure. Make sure you are satisfied with their security strategies for keeping your data safe

3. What’s the vendor’s track record?

Looking at the track record of a vendor can be a helpful indicator of whether a company is trustworthy with a SaaS offering. So, before buying a SaaS product, consider more than one review and case study of the product in action. This way, you reduce the chance of being deceived by an anomalous success or failure. It’s better to pay a little more for a SaaS product that comes with good service and genuine support than less for a service tainted with multiple negative experiences handled badly.

4. What will the initial impact of buying a SaaS solution be?

Most solutions require some form of training to use them effectively. Your team will need time to get used to the new solution. So, when buying a SaaS product, a top consideration on your checklist should be evaluating the time, cost and available support of the initial implementation. Ask what training the vendor provides. Will you be able to request refresher training if needed? Finally, evaluate whether the cost of implementation and training is justified by the benefits of using the product.

5. What are the support options?

The level of support and service a SaaS vendor must provide is best defined in a service level agreement (SLA). Before buying a SaaS product, ensure that you understand clearly and are satisfied with the responsibilities of service on the vendor. An SLA should cover the performance required of the vendor, how that performance is monitored, and the time frame for fixing issues. It’s also good to outline the repercussions on the vendor for failing to meet these agreed terms. Plus, the SLA ensures you’re aware of your responsibilities and how to report issues when they happen.

6. How flexible is the product?

When buying a SaaS product, consider its flexibility. There’s no point buying a solution if it can’t work with your current processes. So, consider whether the software will be able to integrate with your existing systems and strategies. Consider the long-term goals of your business, and whether the software will be able to fit in and grow with you.

7. What’s your exit strategy if you want to leave later down the line?

In the case of a break up with your new SaaS vendor, you need to know how to end the relationship. Before buying a SaaS solution, examine whether you can leave at any time, or will be bound to a fixed term. You should also consider how to retain custody of your data, and how much of your data the vendor can retain if you do leave. Having a clear exit strategy at the start can help reduce the costs and stresses of a messy escape.

Developing SaaS Solutions

Creating a SaaS based solution enables new opportunities and can dramatically cut the cost of your operating infrastructure. At the same time, there are some considerations you should make when starting to build and design your SaaS based applications. Several things should be considered when designing your application for SaaS or cloud infrastructure to fully leverage the benefits delivered by the cloud. Traditional applications are designed for limited computing resource, whereas applications in the cloud can take advantage of near unlimited resource. This is just one essential factor for the development team to keep in mind when developing SaaS and cloud applications to ensure a quality product and viable business.

There are several criteria you should evaluate carefully if you have not yet decided upon a cloud provider for your SaaS service. You will want to evaluate the options that different providers offer and look at how each support your unique business characteristics and objectives.

The primary evaluating criteria should at minimum include the following

Security

Security should always be the number one priority in any aspect of your application when dealing with both your own data, and the NHS and/or healthcare data. With respect to choosing the correct cloud provider, you will need to make sure you completely understand how the responsibilities are shared between your application and your cloud provider.

Compliance

Compliance with customer requirements as well as UK regulatory requirements need to be evaluated. You will need to identify which ISO standards, regulatory requirements (for example data storage geographical locations) and possible GDPR criteria you and your cloud provider will need to adhere to.

Architecture

Your cloud provider should fully support all aspects of your present application architecture, but also support the roadmap for future versions.

Manageability

Many projects and products fail because they grossly underestimate the operational cost with respect to management of the service. Spending some time evaluating what level of effort is needed to manage your service on potential cloud providers is time well spent.

Service level

It is critical that you make sure that the cloud provider’s SLA on the products you need for your solutions compliment the SLA you promise your customers. Evaluate the effort needed to get a sufficient SLA. Some cloud providers will increase your SLA at a click of a button and handle all the backend work related to that. Others will need clever, and often expensive, programming to reach your target SLA.

Support

Support level can be critical for your operations. When your service goes down due to changes on the cloud provider side, it is paramount that they provide sufficient and immediate support. All cloud providers have different support models, response times and partner levels etc., and the level of support will depend on your partner agreement level and cost.

Cost

All business comes down to cost. It should not be the single most important factor, but it will definitely be a factor in your cloud provider selection. In particular, you should investigate exactly how the most expensive parts of your operation are invoiced. Some services are rounded up to the nearest second, hour, day, month, or year. For the most expensive services, the difference can be substantial.

Vendor Information for developing with Native Cloud technologies first to align with the Health and Social care directives

Often SaaS based offerings are Native Cloud Applications (NCA), which is a method that is designed specifically for a cloud computing architecture. To fully utilise the benefits of cloud-based technology, there are some principles that may help deliver your SaaS offering to become more widely adopted within Health and Social care.

Decoupling

The new generation of Native Cloud Applications requires separation between the process and the underlying software and hardware platforms. The application's ability to execute a process must survive changes to the underlying infrastructure on which the process runs. In the past, applications had the luxury of depending on the designed hardware on which it runs. That would still typically be the case for IaaS, where not only the specific hardware, but also how it is configured can be critical to operation. When designing an application, we must assume that the underlying infrastructure will evolve, and applications must be able to cope with this evolution.

Robustness

As applications moved to the cloud and their functions are distributed, each service becomes a potential point of failure. Additionally, the dispersion of resources across the cloud introduces an element of variability due to cloud latency.

Statelessness

In order to be able to scale out, it will be beneficial to design the NCA as stateless. In this case the server does not store any state about the client session. Instead, the session data is stored on the client and passed to the server as needed. Then the state can be designed to be persistent across all instances of the application.

API first

API-first architecture is key to any NCA, where every process is abstracted as an input, an operation and an output accessible via the API service. By doing so, any element of the application that requires operation has access to the best-suited micro-service.

Component based user interface

With the decentralisation of components, the User Interface (UI) must be adaptable to a plethora of form factors (for example phone, tablet). In addition, micro-services-based architectures essentially transform an application into the “patching” of various services that are exposed to the user via a single interface. You will experience that which services are exposed depends on the persona of the user for whom the UI was intended. To handle this the UI must be an independent entity, taking multiple forms as deemed appropriate.

Last edited: 4 July 2023 5:59 pm