One of the other "futures" sessions I attended at SAS Global Forum was The New SAS Programming Language: DS2 with SAS's Jason Secosky. Jason was at pains to point out that DS2 is not intended as a replacement for the good old DATA step. DS2 is an alternative to DATA step and has more of a focus than the generalistic DATA step.
Generally available in 9.4, PROC DS2 is currently available in SAS V9.3 as an experimental technology. Its focus is on high performance for data manipulation and data analysis. It incorporates threading.
DATA steps are in control of their data; they specify the source of their input data, and they specify the location of their output data. In contrast, DS2 is simply a node in a flow; DS2 uses data streams rather than specific data objects. So, DS2 is not a DATA step replacement, it's new technology.
DS2's syntax is similar in parts to DATA step, with DATA and SET statements, if/then/else statements, expressions and functions. However, DS2 adds structure to code. Some of its syntax will be familiar to SAS/AF SCL coders; it includes methods (including init, term, and run). It has lots more types of variables when compared with DATA step, e.g. integer and varchar. DS2 integrates with other languages (such as R, C, C+ +, IML, and SAS fcmp functions) through the concept of a package. Interestingly, we'll be able to edit our DS2 code in the Eclipse editor, wherein a debugger will be included.
In essence, DS2 is the means of taking code to data (ref: big data) and promises linear scalability.
Wednesday, 2 May 2012
Tuesday, 1 May 2012
NOTE: Libnames, Who Needs 'Em?
My team received what turned out to be an interesting call for help from one of our clients today. We resolved the client's coding error but it also served as a reminder of a little used feature of BASE SAS, namely the ability to specify directory names in code rather than bother with libnames. There are pro's and con's for doing this. I'll discuss these below after I explain the feature.
We're used to specifying data sets on DATA statements in the "libname.dataset" style. However, instead of using a data set name, you can specify the physical pathname to the file, using syntax that your operating system understands. The pathname must be enclosed in single or double quotation marks. Here's an example:
data "c:\mydata\mydataset";
In the foregoing example, the DATA step would create a SAS data set file named mydataset.sas7bdat in the c:\mydata directory.
There's more information in the section titled "Accessing Permanent SAS Files without a Libref" in the SAS 9.3 Language Reference: Concepts. You will see that we can use the same naming technique in almost any situation where a library and data set name are expected, e.g. a SET statement, a MERGE statement, an UPDATE statement, a MODIFY statement, the DATA= option of a SAS procedure, and the OPEN function.
My client's coding error resulted from the fact that they had specified a macro parameter intended as a data set name and they had surrounded it with quotes. The call %demo("name") resulted in a DATA statement like this: data "name". As a result, SAS tried to create a file named name.sas7bdat in the SAS session's current directory. That directory was the root directory of the SASApp server, the user didn't have permission to write to it, and hence the code failed. The intention was to create a data set named "name" in the work directory, the actuality was significantly different. It was all caused by a common misunderstanding/mistake - using quotes around character strings in macros.
So, we understand how we can dispense with LIBNAME statements, but should we take advantage of this capability? Well, I can't see too many advantages, but I can see plenty of disadvantages!
The disadvantages include i) need to accurately specify directory paths throughout the program (rather than eight character libnames), ii) cannot quickly and easily change a directory location (as can be useful when testing), and iii) cannot specify an engine for the library.
Can you think of any advantages? Let us know your suggestions in a comment.
We're used to specifying data sets on DATA statements in the "libname.dataset" style. However, instead of using a data set name, you can specify the physical pathname to the file, using syntax that your operating system understands. The pathname must be enclosed in single or double quotation marks. Here's an example:
data "c:\mydata\mydataset";
In the foregoing example, the DATA step would create a SAS data set file named mydataset.sas7bdat in the c:\mydata directory.
There's more information in the section titled "Accessing Permanent SAS Files without a Libref" in the SAS 9.3 Language Reference: Concepts. You will see that we can use the same naming technique in almost any situation where a library and data set name are expected, e.g. a SET statement, a MERGE statement, an UPDATE statement, a MODIFY statement, the DATA= option of a SAS procedure, and the OPEN function.
My client's coding error resulted from the fact that they had specified a macro parameter intended as a data set name and they had surrounded it with quotes. The call %demo("name") resulted in a DATA statement like this: data "name". As a result, SAS tried to create a file named name.sas7bdat in the SAS session's current directory. That directory was the root directory of the SASApp server, the user didn't have permission to write to it, and hence the code failed. The intention was to create a data set named "name" in the work directory, the actuality was significantly different. It was all caused by a common misunderstanding/mistake - using quotes around character strings in macros.
So, we understand how we can dispense with LIBNAME statements, but should we take advantage of this capability? Well, I can't see too many advantages, but I can see plenty of disadvantages!
The disadvantages include i) need to accurately specify directory paths throughout the program (rather than eight character libnames), ii) cannot quickly and easily change a directory location (as can be useful when testing), and iii) cannot specify an engine for the library.
Can you think of any advantages? Let us know your suggestions in a comment.
Monday, 30 April 2012
Requirements. Whose Responsibility? #sasgf12
One paper I attended opined that "requirements are developed by the end user of the software and not by the developer". The paper had a lot to commend it, but on this one point I strongly disagree.
Capturing requirements is a skill. It is not easy to gather all facets of the business requirements, and it is not easy to document them in a fashion that best serves all the needs of the development process (and beyond). Thus, it is unreasonable to expect users (or developers) to possess these skills unless they have been explicitly trained.
If training is required (e.g. in the absence of trained Analysts), does it not make more economic sense to train developers? They can be trained once and then use their skills (and growing experience) multiple times on subsequent projects. If you train a user, they are unlikely to re-use those skills (unless their application is in a constant state of change).
There are a variety of tools and techniques for performing analysis for requirements capture. One of the key skills is the ability to see beyond the current business process and to capture the true needs of the new business process. It is not apparent that users have a proper understanding of all aspects of their current business process; it is far from likely that they can accurately specify their target requirements. If requirements are to be of use, they must be documented in a form that facilitates their subsequent use by a) architects and designers, b) test case authors, and c) maintenance developers.
In my opinion, it is a developer's responsibility to help the user understand their current business process (particularly the processes for dealing with abnormal situations), and to guide them in the art of the possible for their target requirements. Developers need people-skills in addition to knowledge of tools and techniques for requirements capture.
The art of the possible is a key element of the requirements capture phase. We've all had experience of i) users asking for features that seem simple to them but are difficult/expensive for us to implement, and ii) users not asking for features that would be of high value to them but which they thought were too hard for us to deliver. I've seen countless examples of users telling me that they need the ability to:
a) email various reports to groups of people, and
b) write reports as spreadsheets.
Users typically express requirements in terms of things with which they are familiar, i.e. existing technology. We can advise them of the extended capabilities of:
a) portal and publish/subscribe capabilities that avoid the need to clog-up the email system with uncontrolled copies of report, and
b) web report studio and add-in for Microsoft office that give the user the ability to "interact" with the data, without the need for the data to leave the data centre.
If you're a developer, and you don't have professional Analysts to help you, take an interest in requirements capture; appreciate the skills, techniques and tools at your disposal, and (if possible) get some training to enhance your ability.
Delivering a successful project is a result of good teamwork. It is not the users' sole responsibility to produce good requirements; nor am I saying that it is the developers' sole responsibility. It's a question of what each party brings to the table. The users have to be committed and provide their time in addition to their knowledge and experience of the business; the developers must be willing and able to help the users express their requirements. You will succeed as a team.
Garbage in, garbage out. If all of the project's stakeholders are not clear on what is to be delivered, the chances of meeting everybody's expectations are much reduced. The capture of good quality requirements is crucial for ensuring the success of your projects. Play your part!
Papers Without SAS?! #sasgf12
I was pleased to see a number of papers at this year's SAS Global Forum that dared to focus on topics outside of SAS technology and syntax. Two papers that particularly caught my interest were How to Create a Business Intelligence Strategy by Guy Garrett, and The Systems Development Life Cycle (SDLC) as a Standard: Beyond the Documentation by Dianne Rhodes. These papers were good demonstrations of the fact that you can buy the best software in the world, but you'll not optimise your return on investment if you don't put it to use in a planned, structured manner.
The focus of SAS Global Forum should always be SAS software and solutions. I'm not suggesting the event should be turned into a computer science conference, but there's a balance that can be struck. In my opinion, the balance lies at a point whereby attendees' interest in planning and process can be piqued such that they want to find out more once they return to their office.
The focus of SAS Global Forum should always be SAS software and solutions. I'm not suggesting the event should be turned into a computer science conference, but there's a balance that can be struck. In my opinion, the balance lies at a point whereby attendees' interest in planning and process can be piqued such that they want to find out more once they return to their office.
Wednesday, 25 April 2012
NOTE: SAS Global Forum 2012 - Futures #sasgf12
Due to the failure of my Asus Transformer tablet I'm still reduced to posting from my phone. So please forgive my brevity!
Yesterday was a good day for me at the conference. I attended a number of futures sessions in the morning and gained some insights into a few developments at SAS.
Firstly, collaboration and search with Murali Nori. SAS see an evolutionary path from reporting, to analytics, to collaboration. This can be public or private communities. Collaboration covers many themes, aside from discussion it can include participation in approval processes, integration with Sharepoint, email, or IM. One key element is, perhaps, the creation of the ability to audit and report on the decision making process that surrounds some of your SAS outputs.
Ultimately, the SAS Collaboration Framework should produce better decisions, quicker decisions, with the right people. It'll be like Facebook for the enterprise (secure and auditable)
As a small step in this direction, the new Visual Analytics tool will get the ability to add text comments at the end of this year.
In addition to the collaboration efforts, SAS are also aiming to provide much improved search capabilities; for structured and unstructured data. This means that a search in the portal might return you a list of "related" information items rather just items that precisely match your search (think of "Google for my SAS report"). We might see ranking of the results too.
Yesterday was a good day for me at the conference. I attended a number of futures sessions in the morning and gained some insights into a few developments at SAS.
Firstly, collaboration and search with Murali Nori. SAS see an evolutionary path from reporting, to analytics, to collaboration. This can be public or private communities. Collaboration covers many themes, aside from discussion it can include participation in approval processes, integration with Sharepoint, email, or IM. One key element is, perhaps, the creation of the ability to audit and report on the decision making process that surrounds some of your SAS outputs.
Ultimately, the SAS Collaboration Framework should produce better decisions, quicker decisions, with the right people. It'll be like Facebook for the enterprise (secure and auditable)
As a small step in this direction, the new Visual Analytics tool will get the ability to add text comments at the end of this year.
In addition to the collaboration efforts, SAS are also aiming to provide much improved search capabilities; for structured and unstructured data. This means that a search in the portal might return you a list of "related" information items rather just items that precisely match your search (think of "Google for my SAS report"). We might see ranking of the results too.
Tuesday, 24 April 2012
NOTE: SAS Global Forum 2012 - Workflow Management #sasgf12
The capabilities are not intended to be a commercial offering that might compete with established business process workflow management; rather, the SAS capabilities are intended to serve SAS solutions' specific requirements. The SAS EGRC solution, for example, encompasses workflow for management of the operational risks that are recorded within the solution; SAS Model Manager encompasses the management of the lifecycle of a model through workflow.
If you have a SAS solution that doesn't explicitly use workflow, you can still surface it and use it. It's a choice you need to make at install time, so making a choice to use it retrospectively can involve some considerable work.
Once you have it installed and working, its Workflow Studio allows you to design workflows using a combination of data objects, swimlanes, roles, decision points,events and notifications. Diane and her colleagues showed an example workfloe process that they had created for demo purposes. The example allowed the creation of a Web Report Studio report in a development area, approval of the finished report, and automated deployment of the report to a production area.
Workflow processes are stored in metadata and can be checked-out and checked-in, allowing release management.
Instances can be driven by 3rd party application, or by event signalling (providing good decoupling between parts of the workflow), or from SAS solutions.
Subscribe to:
Posts (Atom)