What is our primary use case?
The company I worked for needed to use SAS/ACCESS to connect to various database platforms within the company. While I have not worked with any customers where they need SAS scripting or SAS administrative support or environment design, up until the present I was using SAS (Statistical Analysis System) and SAS/ACCESS a lot to resolve access issues.
I currently work for a consultancy and we do a lot of different things. Primarily we help customers from two perspectives: a project-oriented perspective or an evaluation and white paper perspective. This is to help evaluate where they are within their DevOps concepts or structures. We either help them move a project through a DevOps oriented environment or shift them to cloud or give them an evaluation of what their DevOps scenario currently looks like.
I just joined the company I currently work for back in late September of 2018. In the company previous to that, I worked in data warehousing almost exclusively on-premises doing database design across multiple platforms. We did everything from your standard RDBMS (Relational Database Management System) to massive parallel processing projects using several different ETL (Extract, Transform and Load) tools like IBM InfoSphere DataStage, Ab Initio, and Sagent. I have also used some of the SSAS (SQL Server Analysis Services) solutions, but not a whole lot.
Before I left the company I was at, I was working as a primary SAS administrator and environment design for SAS processing and financial analysis.
The primary need was to connect to various databases within the company. This included connections to the enterprise warehouse but also to transactional systems and the data stores behind the transactional systems. At the time that I started there, what they were doing was actually forcing those transactional systems to export a CSV data file. Then the business customers would actually manually read that data file with SAS code. By giving them SAS/ACCESS and working out the necessary permissions to query databases, they basically could start using PROC SQL (SQL implementation within the SAS System), so they had direct connectivity to data. It no longer required the extra steps of somebody writing a job to export data at a particular time and then moving it from one system to another. That was inefficient. With SAS/ACCESS, we established the database connectivity, established the ODBC (Open Database Connectivity) connection, and off we went.
How has it helped my organization?
SAS/ACCESS improved the company I was working for by streamlining database access issues, trimming inefficiency, and creating self-sufficiency for those needing access to data.
What is most valuable?
The most valuable part of SAS/ACCESS is what it is made for: connecting to remote systems that are not part of your physical SAS environment. The whole point of the product is to provide access to various different data stores. For example, with SAS/ACCESS you can connect to two different Oracle databases. We were connecting to Db2 on the mainframe. We were connecting to Netezza on an MPP (Massively Parallel Processing) appliance and Informix. We were using SAS/ACCESS for its main purpose, but most of the business customers would not know how to administer that or set that up. Once the access is created it is easy for the business users to directly access what they need.
The SAS/ACCESS ability to connect creates an elegant simplicity. All your administrator has to do is set up the connection between SAS and this or that database with the proper permissions and that is it. From then on it is up to the user to go get the data. They are going directly to the data source; you do not have to have somebody writing code or exporting data files and then shipping them around the network. There are no additional people involved and it is completely self-serve from that point on.
Creating this kind of solution is stuff I had been doing and that I had done before at other places, but the company I introduced SAS/ACCESS to did not even have a true SAS administrator. They did not have anybody who knew how to do this kind of thing. I used the most valuable feature of SAS/ACCESS to make the process of accessing data easier. That ability to create direct access is why it is a valuable tool.
What needs improvement?
The primary way that this product can be improved is by adjusting their pricing model. Their product is a little expensive. It is sometimes hard for people to justify it. It does give you access to multiple platforms of data and it is good at what it does. But the problem is that you have to purchase the full access package for each platform. So, for example, if you want to connect to SQL Server and your SAS is on a Unix box, then you have to purchase their connection package for that scenario.
The price point is where I find most companies balk at the product more than anything. The customers simply do not want to spend the money. Every time they have got a new database they want to connect to and it is a different flavor, they do not want to spend the money on a new connection package. When you go through the access module, you have to have an ODBC driver manager. If you are not on a Windows platform, you do not get a driver manager, so you have got to go find one and that costs. You either pay SAS for their product or you go manage it yourself manually. It is one or the other and I have been down both roads. SAS is far more efficient.
From a price-point perspective, it would be nicer, in my opinion, if SAS/ACCESS had a fixed price structure. They package up the solutions, charge a little more, and it is a fixed price no matter what platform you are on or what size your platform is. That way you do not have to keep going back to SAS when you need something else. But that is just not the way it is priced right now.
I can not really think of any features that the product would need that it is missing. It is a pretty self-contained solution and having worked with it quite a lot, there is not anything else I need.
For how long have I used the solution?
We were using SAS/ACCESS at the previous company I worked for from the time that I joined and suggested it as a solution. That was over four years ago.
What do I think about the stability of the solution?
The SAS/ACCESS product is as stable as you can get. SAS will give you plenty of heads up if you have a licensing issue or if there is a newer version coming out. They will send you a full download link and a link to information that explains why you need to upgrade, along with the timeframe you have to apply the upgrade. They stay on top of keeping the product running. It is about as stable from a software environment perspective as I can imagine. It really goes along with their whole philosophy of the support picture.
What do I think about the scalability of the solution?
The scalability of the product is very good. It will handle as much volume as your network and systems will support.
Almost all of our users at the previous company were business analysts in one form or another, be it regulatory or analytics. They were using the solution consistently. I would say we eventually probably had at least 70 users come onto the product. We did not need any additional people for maintenance because one person can handle it. We continuously had plans to increase usage and the number of users was going up all the time. It gradually just kept on growing.
How are customer service and technical support?
I think that the SAS technical support system is excellent. On a scale of one to ten, they are definitely a nine-point-five to ten-out-of-ten. Most technical support teams I have contacted would not get above a seven or an eight. That is mostly because they take longer to get back to you with answers. IBM, as a comparison, will take a while to get back to you sometimes. It is a huge company with a lot of products, so it almost naturally takes a while for your question to get to the right person. SAS makes the effort to get you a solution while you are on the phone.
Which solution did I use previously and why did I switch?
I basically stopped using this SAS/ACCESS solution several months ago after changing jobs. It was not a matter of switching tools or finding something better. While I do not have any SAS exposure at the current company I work for, I have years of experience with SAS/ACCESS.
The previous company had created a work-around solution and had licensed separate connectivity for their desktop and was indirectly routing data from the desktop into the Unix SAS server. It took too much time and the software that they were using was actually out-of-date. Officially, the software company whose product they were using had been sold to another company, so they were not even under a supported version. That is where I suggested taking a different direction and, instead of moving data around, use SAS/ACCESS to get it directly from the database.
So in the case of the former employer, it could be said that the reason for switching was to bring the solution up to date with current technology.
How was the initial setup?
The initial setup is really straightforward. As a matter of fact, it is a very easy piece of software to set up in my opinion. It is pretty much just a couple of clicks and that is it. You run a script, set some register values in the software, point to the drivers, and you are pretty much done.
Normal deployment would take maybe 15 to 20 minutes with somebody that knows what they are doing. That is pretty fast.
Deploying this is very simple. You run into more problems getting all of the necessary permissions on the other side of the coin. For example, if you are on a Unix box for SAS and you are going to connect to a Db2 mainframe database, you have got to get an ID, you got to get somebody to put you in a correct rack permissions group, et cetera, et cetera. The leg work to complete the set up ends up actually being more time consuming than the software installation itself.
With the setup, you have just got to fill in the blanks. Obviously it has to have the proper permissions to get access to the data that the customer wants.
What about the implementation team?
We did the implementation ourselves. It was just me working with SAS support to download the software and install it.
Their support during the installation is great. SAS, overall, is one of the better support groups around. If you get somebody who can not answer your question, usually what will happen is that they will either ask to call you back, or they will actually route you to somebody else who should be able to answer the question.
What was our ROI?
There is easily a return on investment from using this product. It is nothing but in man hours. I know for a fact that before I configured this solution, on average there were approximately 20 man hours a month used to just create and distribute data files for the business. That expenditure got completely removed once we got ACCESS set up. That creates a lot of resources that can be used more productively by saving all the man-hours that were previously spent on mundane tasks. It also made it more of a self serve environment. That is, you did not have to have several people involved in collecting data and one person could do it alone while doing it more efficiently.
What's my experience with pricing, setup cost, and licensing?
The cost for this SAS product depends heavily on the environment. It is a staged pricing model and it varies quite a bit. You have to pay for each type of platform that you want to connect to. So if I want to connect to Db2, I can either go out and get a generic driver and a generic driver manager or I can buy an existing SAS/ACCESS module for Db2.
Even then the pricing model is not that simple. The price of that module is based on the physical environment I am going to install the purchased package on. If you put it on a virtual machine, SAS gives you a way to price that. But the pricing is based on the sheer scale of the physical environment you are installing too. It is not a fixed price object. The problem is that every time you come across a new connection you want to make, you need to either pay for the package to make the connection or work out a solution manually. So say you have not ever connected to a SQL server. All of a sudden you find that you have got this massive SQL server that you want to connect to. You have to pay for the connection pack and the size of the environment to resolve the connection issue.
The pricing scheme ends up being something like you get in video games. You buy the video game, but there are all kinds of downloadable add-ons that they charge you for. You think you need that component, it will cost you more. It is a very similar thought pattern to what they are doing in the gaming market.
I understand why SAS does it that way. It is because there are people who are perfectly willing to go out and do it the hard way just to save some money. They will go search out something like open ODBC and then they have got to go hunt down the drivers. It can be time-consuming, but they resist buying the packaged solution. The problem is that when you are on a Unix platform and you are trying to connect to a Microsoft product and you find that there really is no defined driver for that. You have to go to SAS to get the drivers. You end up buying stuff anyway even if you thought you could work around it.
Users of the product become a sort of captured audience and you end up continually paying for additional solutions.
What other advice do I have?
My advice to people considering this as a solution would be that if they need a relatively straightforward method for connecting to various data sources, then I would advise using this. It is a particularly good solution if the data sources are not on the same physical platform type or environment. If their SAS is on a Windows server, for example, but they have to connect to Unix based databases or vice versa that is a perfect place to use this tool. If their SAS is on a Unix box and they are now trying to connect to things like Microsoft SQL Server, SAS/ACCESS is worth its weight and cost in resolving that type of issue. It is particularly true if they do not have dedicated support resources internally.
What was interesting about coming to this product as a solution was realizing that a lot of times people will find a way around what is really something that should just be done from a software administrative support level. Where the company I worked for could have just been going directly to the SAS server to get data, they had created a half-functional work-around. It got the job done but it was totally inefficient. When I came in with SAS/ACCESS all that extra effort stopped. It is a matter of learning about efficiency. You can create a solution that functions, but it is like driving your car on one of those little donut spares instead of getting the right tire instead. That donut is not made to be on the car forever.
On a scale from one to ten where one is the worst and ten is the best, I would rate the SAS/ACCESS product as a ten-out-of-ten. If you need this type of solution, it does exactly what you need. You can create access with the full support of the company's technical support. For example, in our most complicated scenario, we were actually able to connect to a vendor's database completely outside of our company network and utilize the data. SAS technical support was perfectly willing to work with me to figure out how to set up that connection under SAS/ACCESS. The combination of the support and the technical capabilities of the product just can not be matched with any other product that I know of.
Which deployment model are you using for this solution?
Which version of this solution are you currently using?
SAS Enterprise 9.1