In an interesting coincidence, I spoke to IT groups from two different companies with two very different visions for how SAS will be used, on the same day. The first IT group was from a small nonprofit organization that wants to use SAS to analyze member data and design campaigns. The second IT group was from a very large financial company that wants to use SAS to monitor financials for fraud and analyze web traffic. The two companies couldn’t be less alike in size, hardware infrastructure, number of SAS users, and portfolio of SAS products and solutions.

What the two IT groups had in common was a refreshing zeal for getting the SAS infrastructure up and running: both groups were in the process of upgrading servers to accommodate the software; both were excited about providing access to a range of data sources; and both were poised and ready to take SAS Administration training and dive into the installation documentation.

Unfortunately, what both IT groups also had in common was a lack of interest in including the SAS users as they developed their plans to build the infrastructure. The conversations reminded me of a group of mechanics getting together to build a brand new piece of machinery without having any idea what it was going to be used for or by whom.

Mechanics: We just built a car!

Driver:  You built a car! Great! How do you steer it? How do you start and stop it?

Mechanics: What? You want to be able to steer it? And why would you need to make it start and stop?

I did my best to bring up the SAS users as often as possible in these two conversations, but my efforts were met with the equivalent of “We’ll worry about them later.”

In my experience, the shoe is usually on the other foot. It’s most often the business users that make decisions about the sort of environment they’d like for their SAS implementation, the response time they expect, and the data they want at their disposal. The problem here is inevitably that without including IT in the discussion, the users are disappointed and rarely get the optimum environment they need to do their work. Having the IT organization driving the bus is less common, but the result is the same when the two teams don't work together – frustration and wasted effort.

Let's look at some areas where information from the SAS users can help IT make better decisions.

The Infrastructure

The IT organization selects hardware and peripherals based on many factors – vendor partnership, price, availability, urgency of need, latest model, and so on. IT might focus on certain capabilities such as fast processing and large amounts of memory but be unaware that speedy SAS processing depends on the appropriate I/O capability. If the system can’t move data quickly from storage to SAS computing resources, today’s super-fast processors are going to sit idle or run at partial capacity. Newer technologies that SAS can take advantage of such as in-database and in-memory processing have their own sets of requirements to ensure full effectiveness and optimized performance.

At some organizations, instead of acquiring new hardware for the SAS users, IT tries to accommodate their needs by installing SAS on older servers that are just sitting around. This hardware might not meet SAS’ minimum requirements for operating system, mid-tier, cores, processing capability, and so on. Once again, what seems expedient may not create an optimum SAS environment.

It is a really good idea to review the hardware and infrastructure requirements for SAS software to ensure they’re accounted for before the installation of new software or an upgrade to a new release takes place. There is lots of good documentation for the IT organization about SAS system requirements on the SAS support website as well as papers on how to maintain happy SAS users  through tuning and sizing. In addition, SAS’ Enterprise Excellence Center provides sizing recommendations and SAS technical resources can help to architect the optimum environment. Talk to your SAS Account Executive or SAS Customer Account Executive to learn more about these services.

The Purpose

It’s important for IT to know how the environment is going to be used, for example:

• Will the SAS users run large analytical models?
• Will they be performing querying and reporting?
• Are there a lot of interactive (such as Enterprise Guide) users?
• Are most of the jobs run in batch?
• Is there a large contingent of users who will be accessing reports on the web?

Any combination of these and other types of system usage will influence infrastructure requirements and tuning. The only way for IT to learn about this mix of uses is to communicate with the SAS user community.

The Data

A report, a forecast, and a model are only as good as the data used to create them. In addition to issues related to data validity addressed through some sort of data cleansing process, there are also the issues of how the data is accessed and what form it needs to be in to simplify and expedite processing. Without including the SAS community in a discussion about data sources and availability, IT can unintentionally complicate matters.

For example, IT is rightfully concerned about analytics and reporting tasks processing directly against transactional data. This is not a recommended practice. To prevent processing transactional data, IT often follows one of several policies. They may require analysts to request the data they want, and wait for IT to deliver it to them. Requesting the appropriate data can mean a lot of advance planning on the part of the SAS users and a lot of time wasted. Or, IT may make available a subset of data (say, the last six months’ worth of information). The data mart approach can be sufficient for some analysis, but is surely not going to meet all analytical and reporting requirements. Or, IT might even expect that all data queries be handled by them. This last option can be the most restrictive because analysts may simply not know what they need until they can plow through and experiment with the data themselves.

The Solution

Luckily, the solution is an easy one – communication and mutual involvement, early in the process, with an understanding of the role each organization will play. The SAS users determine the tasks they’re going to tackle and how their scope of work might grow and change over time. The IT organization decides the options for hardware, databases, job scheduling, maintenance schedules, and other infrastructure details. Combined, both teams can ensure IT policy compliance and a quick road to business excellence – key elements to a successful SAS shop.

I’m interested in hearing from you about your thoughts on IT and Business collaboration and how you’ve approached creating your own successful SAS shop. I collected a few ideas in my paper on the successful SAS shop delivered at SAS Global Forum 2013. With your input, we can expand and update this paper -- and make sure the cars we build always have a steering wheel.