Validated deployments of SAS Viya SCEs
Figure 1:
SAS Viya design for and SCE
However, we had to address the elephant in the room: while we validated plenty of SCEs based on SAS 9, and we had experiences with SAS Viya deployments, we never qualified/validated SCEs based in SAS Viya. After asking SAS Institute, we learnt there were no cases of SCEs based on SAS Viya that managed to be validated.
We came with an idea, which had to be defended, represented in the Figure 2.
Figure 2:
GAMP5’s V-Model for a SAS Viya-based SCE, including relevant roles
The Figure 2, which was later presented in PHUSE 2022 EU Connect with the title “TT14: The Impact of Migrating to SAS Viya 202X (aka SAS Viya 4)” (pdf, slides), represents how SAS Viya integrates in the common V-Model provided by GAMP5. In short, there is an impact for the QMS steps that are more technical, but there is no impact on the QMS/SOPs that are related to Functional requirements or qualification of the studies. It should be the same as done earlier, specially if SAS Studio was used already in the running SCE.
The fact that SAS Viya still can run the code with its SAS Compute, which is basically Base SAS, and the fact Base SAS is compliant with FDA 21CF11 and GxP, and still is, helps a lot. That is a good piece of design in SAS Viya.
These are a couple of ideas that were accepted, and has received a lot of acceptance worldwide.
The PHUSE presentation also describes the aspects needed for a qualified move to SAS Viya, and the qualified installation of the SCE system. We can provide an updated summary as:
1. Installation Qualification (IQ)
- Include requirements and every step of the deployment, as usual
- Qualification via SAS OQ container (in the right SAS Viya version)
- Further qualification with automated python-based viyapytools
- Still some, but less amount of manual GUI qualification (link1, link2)
2. Operational Qualification (OQ)
Usually, the User Acceptance Tests (UATs), although some QMS officers prefer to have what we described in the last 3 steps from the IQ, and bring the UATs to the Performance Qualifications (PQs).
3. Migration Qualification (MQ)
They are a variance of the OQs or PQs, with the difference that there will be other things that change. In SAS Viya, the most notorious change in the studies would be the data. While it can originally be in any encoding, it is highly advised to transcode all the data into UTF-8. Reason being, is that then the data can be further exploited into SAS Viya’s Cloud Analytic Services (CAS), an in-memory analytics engine that can not only make operations much faster, but also enabled Machine Learning, as an example. Customers who already have all or most of the data in UTF-8 encoding, they will experience a notorious easiness during the MQ design and execution.
Long story short, the project was a success and we supported the delivery of one of the first known SAS Viya-based SCE in fully qualified manner. Not only that, we also made the first (qualified and validated) integration of the Azure DataLake Gen2 storage with SAS Viya in the way SAS users like to work most, as a libname!
Colophon / conclusions
OCS Consulting partnered with the first client to have a fully qualified and validated SCE based on SAS Viya. While the deployment and maintenance had a few initial challenges due to the new technologies, we experienced that the deployment and the qualification process on itself was much easier than anyone initially could think of. Putting together a few basic ideas and close discussions with the QMS Officer and the Systems Owner, who supported the full project from the start to the end with much dedication, specially all Kubernetes-related subjects, made it happen.
After this project, SAS Institute and more customer became interested, and SAS Viya is starting to take off as the next alternative for a Statistical Computing Environment and we are working with all of them to make it happen.
Furthermore, companies who want to work with open-source programming in their SCEs, and finding challenges to qualify and validate the open-source systems or subsystems, are finding additional value in the openness of SAS Viya, which does not require to program in SAS anymore, but it is possible in other languages as well. Other companies are interested in qualifying and validating those open-source-based SCEs, mainly R or Python, but are struggling with is for years. We start to see some open-source-based SCEs, yet every single maintenance update or migration means facing the challenge again, which is not very attractive. We strongly believe SAS Viya can enable a simplified validation/qualification of open-source-based SCEs and we are in open discussions to make it happen as well; however, such subject would be worth another article.
Please let us know if you would like to learn more about this or other topics, or if you have any questions. We would be glad to have a chat with you.
Contact information: