Difference between revisions of "User:Shawndouglas/sandbox/sublevel45"

From LIMSWiki
Jump to navigationJump to search
Line 1: Line 1:
This guide has, at least indirectly, addressed the question of what makes a cloud provider what they are. But let's collect some of those disparate thoughts spread across the prior chapters to paint a portrait of an average cloud provider. Broadly speaking, a cloud provider could be a public cloud provider such as Amazon Web Services (AWS) or Google Cloud, a hybrid cloud provider like Dell Technologies Cloud, a multicloud provider such as VMware Cloud, or any of thousands of software developers offering a [[software as a service]] (SaaS) option. These providers offer one or more services under various service models, using either their own cloud computing infrastructure, or—as is the case with some software vendors—through the use of another company's cloud computing infrastructure. But in the end, they are all offering a service. Yes, there is actually something tangible (a cloud product) associated with this service, but the actual provision, maintenance, security management, etc. of the product is part of the offered service to you, the customer.
Admittedly, it may appear that the previous section sets a relatively high bar for providers of cloud services. The reality of some cloud providers may be less than that ideal, however. For example, customer service may be lacking in some companies, or the agent assigned to work with you is having a rough patch and isn't addressing your lab's needs that well. The CSP's contract language may not be clear, the warranty less than ideal, or the security lacking for your lab's needs. It's even possible that the CSP doesn't have much experience working with laboratories to begin with. This requires strong initial reconnaissance (i.e., due diligence) on the part of your laboratory and its cloud project stakeholders, finding available options and running them through iterative filters to better vet those CSPs who are most likely to meet the lab's needs. And even then, after that internal due diligence—which may include a request for information (RFI)—it's possible that what those CSPs are offering doesn't completely agree with your lab's stated requirements, requiring careful evaluation of the differences in order to understand the potential effects and internal changes to organizational goals and service expectations.<ref name="FFIEC_Out04">{{cite web |url=https://ithandbook.ffiec.gov/media/274841/ffiec_itbooklet_outsourcingtechnologyservices.pdf |format=PDF |title=Outsourcing Technology Services |author=Federal Financial Institutions Examination Council |publisher=FFIEC |date=June 2004 |accessdate=23 May 2021}}</ref>


A cloud service being both a service and a tangible product, the average cloud provider will also intertwine their service with their product as part of their interactions with your lab. When engaging with your lab, they will ideally<ref name="Charles7Things20">{{cite web |url=https://smallbiztrends.com/2016/10/selling-services.html |title=7 Things You Need to Know About Selling Services |author=Charles, J. |work=Small Business Trends |date=13 July 2020 |accessdate=21 August 2021}}</ref>:
What should these initial filters look like? Aspects of the answer have been touched upon already in prior chapters, and some haven't. Let's break it down.


* strike up a good rapport with your organization;
'''Service and deployment models offered''': We've already talked at length about the various service and deployment models, their benefits and risks, and what they bring to the table for laboratories. In the end, the specifics of this important filter will be decided by the goals and requirements decided upon in your laboratory's cloud project planning.
* make a genuine attempt to understand your organization's needs;
* assist you with envisioning the positive outcomes using the service;
* be attentive to you feelings and concerns about their service;
* provide testimonials and case studies; and
* demonstrate how they are uniquely positioned to provide their service.


Again, being a service, the CSP will ideally have a knowledgeable and experienced team of individuals who understand the various aspects of providing a cloud service. It may be difficult to ascertain how knowledgeable and experienced the overall team is, but, assuming your communications become more than an initial inquiry, you may eventually reach a point where you're assigned a service agent. That person will hopefully be able to answer all your questions or be able to quickly get answers for you. Based upon the questions you ask of that agent, you should gain confidence in their knowledge about the product, as well as address how it relates to the industry your laboratory serves. If the cloud provider is providing a SaaS solution, they should be able to demonstrate the solution for you and provide additional feedback in a recorded question and answer session, all of which can be referred back to by your lab at a later date. Tangentially, the CSP and its service agent should also be able to guide you to documentation and even case studies demonstrating how they are able to help your laboratory be successful in the cloud, while also finding that success in a secure and regulated manner.
'''Technologies used''': Though cloud providers largely have relatively agnostic open-source architecture components, each may have a few nuances that would affect your deployment onto their service. Your laboratory's cloud project planning will have ideally identified any technology-specific nuances to your applications and data, which will further guide your filters. If other Google applications play a significant role in your organization's operations, Google Cloud may have a slight edge as far as integrations go.


Through their interactions with you, the CSP should also be able to demonstrate expertise in security, compliance, and data migration. They may do this through meaningful conversation, as well as by making critical documents such as their SOC 2 audit report available to you. They will also discuss their shared responsibility model with you and what that means contractually. If certain aspects of security appear to be amiss from a proposed contract, the provider will ideally be flexible enough to attach additional clauses and assurances, where reasonable, to help alleviate your lab's security concerns. Data migration concerns should also be addressed by detailing the infrastructure behind the service you want to use and how that infrastructure may impact your lab and its data. This includes addressing the nuances of the CSP's cloud storage and archiving systems, as well as any risk management strategies that may impact your more sensitive data.
'''Compliance offerings and security''': Most labs work in some sort of regulatory environment. Those regulations may vary slightly from industry to industry (e.g., the regulatory demands for the cannabis testing lab will differ from those of the clinical testing lab), and how each cloud provider addresses them will differ, sometimes significantly. One would assume that, for example, a SaaS vendor offering a cloud-based [[laboratory information management system]] (LIMS) has baked in all the necessary regulatory considerations into their offering and underlying infrastructure, but this can't necessarily be taken for granted. This is where you ask the public cloud provider for their documented compliance certifications, attestations, alignments, and frameworks relevant to your lab that qualify their infrastructure, or ask the SaaS vendor to provide their own documentation on how their software—and, if applicable, any third-party [[infrastructure as a service]] (IaaS)—remains compliant or betters lab compliance in the cloud. Additionally, how the SaaS software vendor handles validation may be an important filter to consider.<ref name="BradyAGuide19">{{cite web |url=https://www.compliantcloud.com/a-guide-to-validated-software-as-a-service-saas/ |title=A Guide to Validated Software as a Service (SaaS) |author=Brady, N. |work=Compliant Cloud |date=06 August 2019 |accessdate=21 August 2021}}</ref>


Finally, the CSP should be upfront about support, warranty, and costs. If your laboratory is operating on a twenty-four hour basis and something goes wrong at 2:00 a.m., the CSP should be there to provide support (as long as its stipulated for the services you're contracted for) at that hour. Those cloud services will also come with appropriate warranties for performance, compliance, non-infringement, etc.<ref name="ParksKey18">{{cite web |url=https://www.internationallawoffice.com/Newsletters/Tech-Data-Telecoms-Media/USA/Hunton-Williams-LLP/Key-Issues-When-Contracting-for-Cloud-Services |archiveurl=https://web.archive.org/web/20210331232429/https://www.internationallawoffice.com/Newsletters/Tech-Data-Telecoms-Media/USA/Hunton-Williams-LLP/Key-Issues-When-Contracting-for-Cloud-Services |title=Key issues when contracting for cloud services |author=Parks, R.S.; Voorheis, K.; Glenn, H.M. |work=International Law Office |date=01 May 2018 |archivedate=21 August 2021 |accessdate=21 August 2021}}</ref> And the costs provided to you, as well as future price changes, should be transparently communicated to you and your lab at all steps of the professional relationship.
'''Shared responsibility''': Whether through an outright model or by explaining in contract language, a CSP should be able to make clear the differences in responsibility for the security of a cloud service offering. It's always a plus when the CSP provides this information on their website, but you may have to ask a representative to explain the CSP's approach. Those who can't, or those whose responsibility burden isn't compatible with your laboratory's needs may get stuck in the filter.
 
'''Risk management and insurance''': While your laboratory will most certainly need to address its own risk management practices, as well as whether or not cybersecurity insurance makes sense, don't forget to investigate these matters with any potential CSP. Are they willing to discuss their risk management strategies as applied to their software and infrastructure? Do they have cyber insurance, and if so, what are the details? These may not be deal-breakers, per se, but if you're splitting hairs between two providers, one with a solid cyber insurance policy and one not so much, it may be a determining factor.
 
'''Interoperability and portability''': The question of interoperability and portability—the vendor lock-in question—may or may not be considered a major risk factor for your laboratory. But if ensuring your laboratory can pick up its data and applications and move them relatively painlessly to another CSP is a concern, you'll investigate these matters before deciding on your CSP. This may be particularly tricky with a SaaS provider; you may be able to extract your data from their application if they go bankrupt or you decide to move to a new application, but how portable will it be for the next migration?
 
'''Pricing, warranty, and support''': Transparency at every pricing step is important for any laboratory trying to determine what the current and future budget for cloud services will be. It's especially imperative for laboratories funded in part by grants. As Navale and Bourne note in their discussion on cloud computing for biomedical science, "[c]loud vendors are seeking an all-in model. Once you commit to using their services, you continue to do so or pay a significant penalty. This, combined with being a pay-as-you-go model, has implications when mapped to the up-front funding models of typical grants."<ref name="NavaleCloud18">{{cite journal |title=Cloud computing applications for biomedical science: A perspective |journal=PLoS Computational Biology |author=Navale, V.; Bourne, P.E. |volume=14 |issue=6 |at=e1006144 |year=2018 |doi=10.1371/journal.pcbi.1006144 |pmid=29902176 |pmc=PMC6002019}}</ref> As such, your lab will not only look for clear pricing but will also ask about any unanticipated "gotcha" fees and penalties that may apply to your use of the service. Investigating CSPs for their approaches to warrantying their services and products, and supporting them when things go wrong, should also not be overlooked.
 
'''Software development practices''': Writing for CSols, a [[laboratory informatics]] consultancy, consultant Bob McDowall emphasizes several areas of a developer's software development practices that laboratories seeking a SaaS solution should consider. Can the SaaS vendor<ref name="McDowallClouds20">{{cite web |url=https://www.csolsinc.com/blog/clouds-or-clods-software-as-a-service-in-gxp-regulated-laboratories/ |title=Clouds or Clods? Software as a Service in GxP Regulated Laboratories |author=McDowall, B. |work=CSols Blog |publisher=CSols, Inc |date=27 August 2020 |accessdate=21 August 2021}}</ref>:
 
* describe their software development life cycle and how it benefits your lab?
* provide reliable support for their application?
* explain the virtual IT infrastructure running the software?
* describe the GxP and other regulatory-based training staff have?
* explain how the application is configured prior to laboratory validation?
* explain its approach to risk management with any underlying IaaS supplier?
* define in a clear manner the work to be performed and how it's expressed in any agreement?
* batch "agile" cloud software releases into a single annual upgrade, vs. updating every quarter, for validated environments such as pharmaceuticals?
 
'''Trust and reputation''': This may be one of the more difficult, or at least time-consuming, investigative steps when considering CSPs. Most CSPs will have a trust center or document explaining the myriad ways you, the customer, should put trust in their services (a one-to-one opinion). However, reputation is based on an aggregate of opinions from a community towards the CSP, which is, broadly speaking, based on experiences concerning the transparency, accountability, and value provided by the CSP.<ref name="HuangTrust13">{{cite journal |title=Trust mechanisms for cloud computing |journal=Journal of Cloud Computing |author=Huang, J.; Nicol, D.M. |volume=2 |at=9 |year=2013 |doi=10.1186/2192-113X-2-9}}</ref> The CSP usually supplies you with information concerning trust, but reputation is discovered not only through, e.g., case studies supplied by the CSP but also by having conversations with past and current clients of the CSP. In both cases, though a non-trivial process, your lab should take the time to pass any prospective CSPs through these filters.
 
'''Service-level agreement''': A service-level agreement (SLA) defines the service expectations between the laboratory and the CSP, how meeting those expectations should be measured, and what should happen if those expectations are not met.<ref name="OverbyWhatIs17">{{cite web |url=https://www.cio.com/article/2438284/outsourcing-sla-definitions-and-solutions.html |title=What is an SLA? Best practices for service-level agreements |author=Overby, S.; Greiner, L.; Paul, L.G. |work=CIO |date=05 July 2017 |accessdate=21 August 2021}}</ref> Let's talk a bit more about that in the next subsection.


==References==
==References==
{{Reflist}}
{{Reflist|colwidth=30em}}

Revision as of 22:26, 21 August 2021

Admittedly, it may appear that the previous section sets a relatively high bar for providers of cloud services. The reality of some cloud providers may be less than that ideal, however. For example, customer service may be lacking in some companies, or the agent assigned to work with you is having a rough patch and isn't addressing your lab's needs that well. The CSP's contract language may not be clear, the warranty less than ideal, or the security lacking for your lab's needs. It's even possible that the CSP doesn't have much experience working with laboratories to begin with. This requires strong initial reconnaissance (i.e., due diligence) on the part of your laboratory and its cloud project stakeholders, finding available options and running them through iterative filters to better vet those CSPs who are most likely to meet the lab's needs. And even then, after that internal due diligence—which may include a request for information (RFI)—it's possible that what those CSPs are offering doesn't completely agree with your lab's stated requirements, requiring careful evaluation of the differences in order to understand the potential effects and internal changes to organizational goals and service expectations.[1]

What should these initial filters look like? Aspects of the answer have been touched upon already in prior chapters, and some haven't. Let's break it down.

Service and deployment models offered: We've already talked at length about the various service and deployment models, their benefits and risks, and what they bring to the table for laboratories. In the end, the specifics of this important filter will be decided by the goals and requirements decided upon in your laboratory's cloud project planning.

Technologies used: Though cloud providers largely have relatively agnostic open-source architecture components, each may have a few nuances that would affect your deployment onto their service. Your laboratory's cloud project planning will have ideally identified any technology-specific nuances to your applications and data, which will further guide your filters. If other Google applications play a significant role in your organization's operations, Google Cloud may have a slight edge as far as integrations go.

Compliance offerings and security: Most labs work in some sort of regulatory environment. Those regulations may vary slightly from industry to industry (e.g., the regulatory demands for the cannabis testing lab will differ from those of the clinical testing lab), and how each cloud provider addresses them will differ, sometimes significantly. One would assume that, for example, a SaaS vendor offering a cloud-based laboratory information management system (LIMS) has baked in all the necessary regulatory considerations into their offering and underlying infrastructure, but this can't necessarily be taken for granted. This is where you ask the public cloud provider for their documented compliance certifications, attestations, alignments, and frameworks relevant to your lab that qualify their infrastructure, or ask the SaaS vendor to provide their own documentation on how their software—and, if applicable, any third-party infrastructure as a service (IaaS)—remains compliant or betters lab compliance in the cloud. Additionally, how the SaaS software vendor handles validation may be an important filter to consider.[2]

Shared responsibility: Whether through an outright model or by explaining in contract language, a CSP should be able to make clear the differences in responsibility for the security of a cloud service offering. It's always a plus when the CSP provides this information on their website, but you may have to ask a representative to explain the CSP's approach. Those who can't, or those whose responsibility burden isn't compatible with your laboratory's needs may get stuck in the filter.

Risk management and insurance: While your laboratory will most certainly need to address its own risk management practices, as well as whether or not cybersecurity insurance makes sense, don't forget to investigate these matters with any potential CSP. Are they willing to discuss their risk management strategies as applied to their software and infrastructure? Do they have cyber insurance, and if so, what are the details? These may not be deal-breakers, per se, but if you're splitting hairs between two providers, one with a solid cyber insurance policy and one not so much, it may be a determining factor.

Interoperability and portability: The question of interoperability and portability—the vendor lock-in question—may or may not be considered a major risk factor for your laboratory. But if ensuring your laboratory can pick up its data and applications and move them relatively painlessly to another CSP is a concern, you'll investigate these matters before deciding on your CSP. This may be particularly tricky with a SaaS provider; you may be able to extract your data from their application if they go bankrupt or you decide to move to a new application, but how portable will it be for the next migration?

Pricing, warranty, and support: Transparency at every pricing step is important for any laboratory trying to determine what the current and future budget for cloud services will be. It's especially imperative for laboratories funded in part by grants. As Navale and Bourne note in their discussion on cloud computing for biomedical science, "[c]loud vendors are seeking an all-in model. Once you commit to using their services, you continue to do so or pay a significant penalty. This, combined with being a pay-as-you-go model, has implications when mapped to the up-front funding models of typical grants."[3] As such, your lab will not only look for clear pricing but will also ask about any unanticipated "gotcha" fees and penalties that may apply to your use of the service. Investigating CSPs for their approaches to warrantying their services and products, and supporting them when things go wrong, should also not be overlooked.

Software development practices: Writing for CSols, a laboratory informatics consultancy, consultant Bob McDowall emphasizes several areas of a developer's software development practices that laboratories seeking a SaaS solution should consider. Can the SaaS vendor[4]:

  • describe their software development life cycle and how it benefits your lab?
  • provide reliable support for their application?
  • explain the virtual IT infrastructure running the software?
  • describe the GxP and other regulatory-based training staff have?
  • explain how the application is configured prior to laboratory validation?
  • explain its approach to risk management with any underlying IaaS supplier?
  • define in a clear manner the work to be performed and how it's expressed in any agreement?
  • batch "agile" cloud software releases into a single annual upgrade, vs. updating every quarter, for validated environments such as pharmaceuticals?

Trust and reputation: This may be one of the more difficult, or at least time-consuming, investigative steps when considering CSPs. Most CSPs will have a trust center or document explaining the myriad ways you, the customer, should put trust in their services (a one-to-one opinion). However, reputation is based on an aggregate of opinions from a community towards the CSP, which is, broadly speaking, based on experiences concerning the transparency, accountability, and value provided by the CSP.[5] The CSP usually supplies you with information concerning trust, but reputation is discovered not only through, e.g., case studies supplied by the CSP but also by having conversations with past and current clients of the CSP. In both cases, though a non-trivial process, your lab should take the time to pass any prospective CSPs through these filters.

Service-level agreement: A service-level agreement (SLA) defines the service expectations between the laboratory and the CSP, how meeting those expectations should be measured, and what should happen if those expectations are not met.[6] Let's talk a bit more about that in the next subsection.

References

  1. Federal Financial Institutions Examination Council (June 2004). "Outsourcing Technology Services" (PDF). FFIEC. https://ithandbook.ffiec.gov/media/274841/ffiec_itbooklet_outsourcingtechnologyservices.pdf. Retrieved 23 May 2021. 
  2. Brady, N. (6 August 2019). "A Guide to Validated Software as a Service (SaaS)". Compliant Cloud. https://www.compliantcloud.com/a-guide-to-validated-software-as-a-service-saas/. Retrieved 21 August 2021. 
  3. Navale, V.; Bourne, P.E. (2018). "Cloud computing applications for biomedical science: A perspective". PLoS Computational Biology 14 (6): e1006144. doi:10.1371/journal.pcbi.1006144. PMC PMC6002019. PMID 29902176. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6002019. 
  4. McDowall, B. (27 August 2020). "Clouds or Clods? Software as a Service in GxP Regulated Laboratories". CSols Blog. CSols, Inc. https://www.csolsinc.com/blog/clouds-or-clods-software-as-a-service-in-gxp-regulated-laboratories/. Retrieved 21 August 2021. 
  5. Huang, J.; Nicol, D.M. (2013). "Trust mechanisms for cloud computing". Journal of Cloud Computing 2: 9. doi:10.1186/2192-113X-2-9. 
  6. Overby, S.; Greiner, L.; Paul, L.G. (5 July 2017). "What is an SLA? Best practices for service-level agreements". CIO. https://www.cio.com/article/2438284/outsourcing-sla-definitions-and-solutions.html. Retrieved 21 August 2021.