A fun article for April Fools Day.
Reference:http://www.sascommunity.org/wiki/Special:ListSubBlogs/User:Richard.thesasguy

1. SAS is not like Oracle, your email system, or anything else for that matter. When viewed as a system, SAS software does not behave like a database, or any other operational system. Usually, very little goes on without the direct involvement of users. In fact, it’s the users’ activity which defines how SAS behaves, and is also the direct value product of the system. Traditional pure-play IT management folks are not usually comfortable with systems which are made up of a set of infinitely flexible tools (like SAS is). For this reason alone, SAS deserves special treatment; it is an environment rather than a directed, deterministic system.

2. SAS guys are not like IT guys. Related to point #1 – those experts who are the community of SAS users in your organization are not at all like "programmers". Usually, programmers are driven by specifications and have a very clear picture of their desired product. This isn’t the case with much SAS work – SAS "programmers" often work in an exploratory, data-driven way – the exact nature of the end product is not clear, and technical considerations are secondary to the business problems they are trying to solve.

3. Yes, SAS users really do need all that data. Almost all SAS work is data-oriented. We often see cases where highly skilled quantitative people spend up to 80% of their time in data preparation, often because their IT support has not anticipated the needs of these people. Although it is an investment challenge in terms of development resources, possibly the single most valuable resource for many of the mathematicians we work with would be a well structured Analytic Data Mart. It’s a common scenario that there is no reuse of data integration code between analysts – each individual reinvents the wheel every time, whether or not one of their colleagues has already solved the problem. The SAS Administrator is well placed to lead the charge to provide the right data to the right people, filling a gap between the business (in this case, SAS users) and the IT organization.

4. All problems are your problem. With reference to #2 – as subject area experts, SAS users may not be able to articulate a technical symptom correctly. We often hear of cases where an expired database password has resulted in an obscure log message which in turn led to a multi-week triage effort involving SAS Technical Support, and ultimately a frustrated and non-productive SAS user. Be involved, and be available to help.

5. Sometimes the wood is obscured by the trees. Naturally, SAS tools do not exist in a vacuum. With reference to #1, SAS technologies are always used in support of one or more business processes. This implies that any change in the business process will impact the supporting SAS processes – business rules and logic, analyses, even data currency and granularity can shift without warning. Understand and monitor the business processes supported by SAS technologies. Understand the role SAS plays in the overall process. This allows both an insight into the details of the SAS artifacts which the community has developed, allowing you to more effectively triage problems and understand risks and impacts, and also puts the SAS Administrator in an excellent position to guide the SAS community through business changes.

6. Just because you have a hammer... Pick the "right" tool for the job. To give a very specific but illuminating example: don't bother writing a SAS/C module to decode DICOM image files. The breadth of what can be accomplished with SAS tools constantly amazes us (does anyone remember SAS/AF Blackjack?) This does not, however, mean that everything should be accomplished using SAS tools. Know that it is always possible, for example, to get complex data integration done at source (see #3), if that is technically and economically feasible.

7. All problems are communication problems. Be a steward rather than an administrator. If you do not have an internal user group, make one. Get SAS users to talk about what they do. You learn; they learn; they start reusing data and code. Best Practices are only a symptom of effective communication.

8. Everybody loves a geek. Subscribe to SAS technology news, attend conferences, and talk to your Account Executive regularly. SAS tools are continually revised and new ones invented - maybe one of these is your silver bullet? (see #5)

9. The world is not flat. SAS is always part of a wider technical ecosystem. Many problems arise because of the interfaces between these systems. So, as well as the SAS Administrator’s priority of understanding the business processes, there is also a responsibility to understand the wider technical landscape.