Watch this Ask the Expert session to learn about the key considerations for moving from SAS®9 to SAS Viya.
Watch the Webinar
You will learn:
- Top considerations for moving from SAS®9 to Viya.
- Assessment options for determining your organization’s best path to the cloud.
- Lessons learned from modernizing a SAS estate.
The questions from the Q&A segment held at the end of the webinar are listed below and the slides from the webinar are attached.
Q&A
What is the future of SAS Enterprise Miner projects? SAS Viya asks to transform into workaround. Does it involve a lot of effort from Data Scientists?
SAS Viya has products like Model Manager and Visual Data Mining & Machine Learning (VDMML). There is a compatibility with VDMML that's there in the existing E Miner projects. The extent to which we've been using VDMML, it's easier, it's better. From a data science point of view, it's going to be easier for someone to adapt into the Viya world of it, whether it's about VDMML or leveraging any third-party tool and integrating it. But the analysis and the extent to bits that we fused E Miner projects into VDMML is easier. And it's not something that takes a lot of effort for the data scientists to adapt to.
What is the future of SAS Information Map in SAS 9? How are you going to do the logical mappings?
SAS relational information maps migrate to SAS job definitions in SAS Viya. When executing from SAS Studio, a CAS table is created. Authorized users can view CAS tables in SAS Environment Manager or SAS Studio. To make changes to the job definition, one can edit it using SAS Studio.
What is future of SAS DI jobs in SAS Viya? Is this tool going to exist in SAS Viya? What is the equivalent tool?
SAS Studio flows is the replacement of SAS 9 Data Integration Studio in the Viya world. Today most SAS DI transforms migrate to SAS Studio program steps on SAS Viya. Migration to support SAS 9 Data Integration Studio transforms to SAS Studio UI steps is in progress, with transform support increasing monthly, in the next few releases SAS is expecting to cover most features of SAS DI into SAS Viya.
Some SAS 9 codes are embedded in .net or java applications in some organization, how is SAS 9 to Viya migration going to tackle this?
I think it's similar to how you tackle your mainframe migrations. The embedding is something that needs to be looked upon. It's not straightforward honestly, because it it's not about the SAS codes, because the SAS codes can still be assessed. The coding patterns and everything to a great extent still are there on the similar lines. But when it comes to the wrappers that are important, that migration is key. We're trying to identify if we can. However, utility which can cater to it still something that's there on our list as well.
What type of cloud are you referring to? Are you talking about migration to SAS Viya in Azure?
No, regardless of any cloud provider. So, these Accenture utilities i.e., assessment utility, the migration utility, the cloud builder all can be catered regardless of the target cloud provider. It caters to AWS, Azure and GCP, so all the three major cloud providers are something that can be leveraged across. As a part of our client discussions, one thing that we ensure is we get a feel as to what's the overall roadmap of the modernization because SAS could be just a module in that overall cloud modernization strategy. So, if the client has already come across or identified a cloud provider, we ensure that you know it gets aligned according to that. If the client doesn't have a preference, then there is an interaction that happens to understand apart from SAS what are the other features that they're looking out for. Are there other modules that are being considered and the third part of it obviously would boil down to the cost factor as well. So, we've seen certain clients who do not have a preference, but they say, why don't you give us a top two from a capability standpoint and from a costing point of view. We help do that bifurcation and that's the POV's and the business case that we've rebuilt bases are previous modernizations. Just not limited to SAS, but other modules also into the cloud world so that it gives them a view as to what their TCO would be while moving into the cloud.
Is SAS Viya fully integrated into AWS and GCP?
Yes, SAS announced cloud-native support for AWS and Google Cloud during SAS Global Forum in May 2021.
Based on your experience what are some of the reasons a client doesn't seem invested in migrating to Viya?
There are a couple of key reasons customers may not be adopting SAS Viya right now. First, Viya may not yet support their business needs. SAS is still rolling out offerings on SAS Viya, and for some customers, this means they need to wait a little longer. Second, some customers are concerned about the unknown. To overcome this, we have built the AI Driven SAS transformation utilities which covers the entire lifecycle of a modernization journey I.e. Assessment, Recommendations, Build, Migrate and Operations Support.
When we have Petabytes of SAS data sets on on-premises which are created over the years, how do you decide on what datasets can be moved to cloud and what can’t? Do we have any utility for the same?
That's where the Accenture assessment utility is leveraged. It takes care of your SAS artifacts and log files right from Workspace, Stored Process logs, Batch logs and Grid (LSF) logs. In absence of logs (as enablement of the same and generating the relevant information would take time) and in case of time constraints, SAS codes can also be assessed by the utility. As a part of the assessment the data lineage is captured which helps in identifying which data sources (including SAS datasets) are being used and basis this, the SAS artifacts and datasets required to be migrated can be captured. The approach for migration of the datasets into the cloud can then be decided (using cloud native or agnostic tools) basis the volume.
To what extent does your company (i.e., Accenture) support the migration process with own software/tools? Or is it entirely based on SAS utilities?
Everything that you saw in the session are all Accenture build utilities. We at times use the SAS content assessment because of the metadata construct. Depending on how the SAS footprint is, if it is heavy on both metadata and the non-metadata side of it, we do leverage the content assessment, but all those that we've seen currently with regards to our asset. From the modernization strategy to the discovery and assessment, to the recommendation migration, all these are built by Accenture itself. And yes, they've been integrated to an extent with the SAS content assessment, but it's not something that heavily relies on the content assessment. All those are independent to perform the end-to-end migration.
Can the platform even work where most datasets are small datasets (text and excel) with little or no data governance doing ad hoc analyses?
Yes, if we've got either the code or the logs available to identify those integrations. It can be taken care of, and it gets captured as a part of the data lineage as a part of assessment. Those are key input drivers that we require.
Do you have a migration timeline template to move a client from SAS 9 to Viya?
Yes, that's a part of our Accenture assessment outcomes. The recommendation takes care of that. The way it works is the discovery and assessment provide those level of details that are extracted as a part of deep dives. There's a recommendation with regards to the migration strategy and the high-level timelines. Again, we go deeper into those timelines and into the actual feasibility of the migration once the client has a strategy around it. This gives them the initial inputs that are required for them to decide on their overall cloud modernization because as I mentioned, it could be just one module into that end-to-end strategy. That's where there is a preconfigured Accenture based template that is leveraged and then there are efforts that are coming across not just the timelines but the efforts also that are required to migrate into the cloud.
If we have a whole DWH build with SAS 9.4, do you have any tips on how we migrate our data? We are not sure which datasets should migrate to CAS and which not.
I think, the bifurcation of the artifacts (against workloads) which is using those data sets are important. Things like data management which creates your staging layer needs to be kept outside of CAS. Datasets which are frequently used, whether it is from a dashboarding point of view or from an AI model point of view, it's something that you should primarily target from a CAS standpoint. Having said that, this is not just the permutation and combination that you need to look at. Very honestly, the usage and the criticality of that data set is important. We've done some mapping basis of these kind of scenarios and multiple other scenarios that we have come across to say there are certain artifacts which still needs to remain out of cache because as soon as we talk about cache, it's talking about in-memory and Intel. It drives your infrastructure sizing. It drives your SAS licensing costs as well because SAS license is also based on the CAS node sizing.
How is inventory analysis different from SAS Content analysis?
The SAS content assessment is primarily driven on the metadata construct. There's integration that's required with the SAS metadata server picks in all the registered libraries, users, artifacts from the metadata however there are constraints with regards to the version of SAS that Content Assessment can be used. The Accenture assessment utility has minimal metadata dependency and does assessment of the physical artifacts hence can be done across SAS 9.x platforms further, regardless of the operating system while providing some additional insights and recommendations considering the business layer. Additionally, the Accenture utility can be performed in an offline mode i.e., the artifacts can be transferred altogether on a different server and can be assessed which helps in avoiding any impact on the existing SAS platform utilization and needing to have discussions around execution window.
Can the discovery and assessment process look at historical usage of the SAS platform, or do you monitor the platform for a specific amount of time?
The initial discussion that we have even prior to kicking off the discovery and assessment is around certain set of prerequisites with regards to SAS logging and availability of artifacts and accessibility of it. Depending on the history that's available with the client, we can take care of it. The analysis can be performed if we've got the complementing information available. There are some KPIs that can be missed out when there is logging which is not available, which is 90% of the cases because logs are heavy on the storage, there is a cost associated to it. That's where we've got a middle ground that has come across if I may call it that way. In the traditional world of it, in the SAS world, there's a form-based EEC sizing activity. That sizing activity is primarily driven by your Q wave or template, which has certain questions across the various constructs that the client is using, whether it be data management, analytics, how it is being used, how many users accessing, what's the concurrency, what's the data volume, etc. Those inputs are something that downsizing recommendation comes across logs gives you a real time picture of the actual utilization which can better your sizing decisions and give you a more realistic view of your target state architecture. But in the absence of a log and the reliability of a manual of a user manually punching in the responses for QA template, we have built an AI based model (patent applied) doing pattern analysis and giving you a view of the overall utilization at a SAS program level which can help derive utilization trend of the current platform in-turn help with target state architecture. I think those are important features that we've taken care of to cater to the unavailability of historical data. This model gives you predictability, that analysis of our past experiences. Based on our testing results, the first run of that model gives you an accuracy of around 50 to 55%. When we've kept that model running at a client for few weeks, get those updated inputs that are required for the model, that accuracy has gone as high as 75 to 80%. That's how we take care of that historical data unavailability as well, to an extent.
When you move datasets from on-prem to cloud, SAS 9 has physical storage, and SAS Viya needs persistent storage, which Viya storage do you write to?
It completely depends on the utilization of pattern around it. That's a part of our analysis and mapping as well. Depending on the data set, the underlying artifact which is leveraging it and the frequency at which it is being leveraged. Those are three key factors that we determine when it comes across to the persistent storage that is required to host. All the cache in-memory that is required. We've got certain algorithms that have been created to determine that mapping and then take a decision as to what needs to go where when it comes to the Viya world.
What is the recommended /saswork volume? How perfomant file system do we need to have for CAS?
These recommendations vary by customer.
What is the complexity percentage migrating from SAS to SAS Viya on Cloud?
There are multiple categories which drive the migration complexity i.e., SAS version, tool stack, usage pattern etc. to name a few. The Accenture assessment utility does that work for the client, wherein the detailed analysis provides a view of the feature utilization trend and validates the compatibility of the features into the Viya world. Basis this we provide a view around Viya adaptability and complexity to migrate to Viya as a part of our recommendations.
Is there a strategic timeline for moving SAS 9 to SAS Viya? Will SAS retire SAS 9? If so, when that will be?
There is no specific strategic timeline of moving to SAS Viya, its driven by multiple factors like overall organization roadmap, modernization/cloud initiative, usage pattern, value add.
While the client helps drive the initial factors (roadmap and initiative), the assessment provides the data against usage pattern, value addition and other features which can help make the strategic decision.
More importantly the answer to each assessment is not always movement to SAS Viya, some of our assessments have also resulted in us recommending clients to continue SAS 9 however just upgrading to the latest release or moving from on-prem to cloud while leveraging cloud native features along with SAS or mere optimization of the existing platform.
At the time of webinar the release of SAS 9.4M8 was being speculated however few weeks ago SAS has released the 9.4M8 version which means that SAS 9.4M8 would be supported for the next 5 years as a part of SAS policy, Support Services and Policies | SAS Support
Due to your experience, what could be an indication to better stay with SAS 9, rather than migrating to Viya?
While Viya has been in the market for a few years now it is still maturing and many of the SAS 9 features are still in the roadmap for being ported into Viya. Some customers are concerned about the unknown. Rather than experience we rely on our (Accenture’s) Assessment Utility to help make that decision which is driven by the analysis to look at the code compatibility with Viya and complexity to migrate it.
Recommended Resources
SAS + Accenture
AI Slingshot
Cloud Transformation: From Why to How
Moving from SAS®9 to SAS® Viya®
Please see additional resources in the attached slide deck.
Want more tips? Be sure to subscribe to the Ask the Expert board to receive follow up Q&A, slides and recordings from other SAS Ask the Expert webinars.
Click image to register for webinar