Picking the Right Platform

by Greg Nelson, Thotwave

As organizations begin to adopt SAS®9 for their analytic and business intelligence needs, many are taking notice of how feature-rich SAS®9 is. This wealth of features has many adopters assessing whether or not they should simply migrate to SAS®9 and use it as they have in the past, or evaluate the potential of SAS®9 as a platform for process reengineering.

The big question: What can we do to move the technology landscape toward some of the SAS®9 functionality without completely reinventing the tried-and-true world of existing processes and support systems? Before we address that, let's turn to SAS®9 and why we should care about the "new" SAS.

What's changed in SAS®9
Far more accurately than earlier versions, the SAS®9 approach to the analytics and decision-support landscape can be summed up in a single word: integration. While the familiar module-based SAS software is still present, the underlying rationale is profoundly different.

SAS®9 has a strong emphasis on the centralized management of resources. All stakeholders in the enterprise can now be managed and configured with a single point of control.

The concept of the Intelligence Value Chain (IVC) helps us not only visualize the reach of SAS software within the enterprise, but also creates a practical framework for understanding the processes that will be influenced by an integrated approach to corporate information and analytics.

To align the enterprise information ecology with the IVC, there are new clients that are fit to specific tasks – such as the ETL and data quality component, the resource management and storage component, and, of course, the information delivery and analytics components. To mitigate the impact of multiple, complex installations of software, many of the clients are Web- or java-based, using centralized SAS resources to perform their processing. Gone are the days of supporting a PC install of SAS for every analyst ...

Architectural options
Of course, if you really want to run SAS®9 as if it were SAS 8.2, you can still do so. However, this ignores the opportunity you now have to consolidate and control your enterprise intelligence. Think of it this way – distributing and supporting an integrated reporting and analytic solution has now become easier – by an order of magnitude. This means you can deliver more (or just enough) capability to a wider range of people within your organization – from those who need a quick tabular report on the fly via the intranet, to those who must consolidate information from several places and slice it in different ways, to the full-blown analyst who will mine your historical assets for hidden trends, to the real-time decision-support needs of operational staffers.

All these people will use the same centrally managed and standardized sources of information, taking you closer to "one version of the truth." Cost savings emerge by reducing resources once spent (and wasted) verifying reports. Data is cleansed so the resulting intelligence is reliable. The return on your investment arrives in the form of enhanced and improved decision making that is supported with better information where it counts.

The architecture to support such a solution will depend largely on what you expect or need to deliver to the enterprise, which, in turn, depends on where your enterprise is in intelligence terms. It may make sense in your environment to decouple the centralized SAS metadata services from the actual data and analytic processing. You may have an advanced OLAP requirement almost certainly needing dedicated servers and storage. Or you may have a mature, external RDBMS-based data warehousing solution and have very specific requirements for ETL.

Questions such as these have to be addressed as part of the planning phase of the IVC. It is impossible to go into detail for every combination of business requirements, hardware and infrastructure, and each case must be treated on its own merits.

The general principles, however, are always the same: SAS®9 technology provides secure access to data and services, and centrally manages your decision-support infrastructure. You should take advantage of this.

On the subject of data, you are likely to have little option about where it is stored (unless you are in a very fortunate position). Decisions about where to place ETL and analytic services on the application tier will be affected by issues such as network infrastructure and processing capacity. It makes sense to have components of the solution that depend heavily upon the data layer as "close" to that data as possible – this will reduce latency resulting from moving large quantities of data around. On the application tier itself, significant storage for analysis may call for the SAS Scalable Performance Data Server, which facilitates high-speed access to data on disk by using well-proven techniques of striping and parallel I/O processing.

Understanding the tradeoffs
Those of us familiar with the "old" SAS will notice the increased complexity of the new intelligence platform. Fortunately, SAS®9 provides a number of tools to manage this environment in a far more effective way than has previously been possible. While the planning phase of the IVC will still have a significant impact on the situation, organizations should take advantage of the opportunity to really examine the whole enterprise from an informational standpoint. The impact of SAS®9, as we've suggested above, can truly change the way your whole enterprise determines what it knows about itself, and about where it is going.

Because of the importance of centralized services in SAS®9, it is very likely that these services will need dedicated hardware. In fact, to maximize availability and performance, the recommendation is that the SAS Metadata Server component be on a separate machine from the SAS services component.

Distributing and maintaining light (or zero) client software is cheaper and easier than the alternative. Likewise, consolidated services in a central location are cheaper and easier to maintain than a multisite distributed model. These are the benefits you will reap whatever your choices.

Decisions, decisions, decisions
Our experience shows that many of the decisions you must make, particularly early in the planning phase of a SAS®9 deployment, revolve around purely technical matters: how to configure the metadata server to perform authentication and authorization, the selection of hardware to support centralized services and so on. It pays to always remember that with any integrated software, such as SAS®9, your deployment experience will be greatly improved if you consider the "big picture."

Look at your end users – the people who move data around, the people who create reports, the people who spend all day manipulating spreadsheets and e-mailing them to their customers. These are the people whose needs will be addressed by the capabilities of SAS®9, and it can't be stressed enough how important it is to select the most appropriate client software for them. Frequently, these end users perform multiple, concurrent roles in the IVC, creating an overlap in deployment. The question can easily be summarized – who gets what, and how much?

Looking at another part of this same "big picture" – early in your planning stage, be aware that as users experience new capabilities in enterprise information and as intelligence improves, their expectations will increase. They will ask for more and deeper analytics, as your information ecology matures and their own understanding of the enterprise increases. You can anticipate these evolving needs by building in analytic intelligence from the start.

Metadata in SAS®9 software is not just "data about data." The centralized metadata server allows business relationships and data structures to be managed and related. One practical application of this function is that the data management of clinical trials can be controlled via the central metadata repository – allowing you to allocate and control access to the technical components that are needed to run a clinical trial.

Extensive capabilities for data cleansing and verification make for a pragmatic, flexible solution to real-world data. With solutions from SAS, you can identify, for example, duplicate patients or individuals in the same household, streamlining insurance claims and improving the customer experience.

Analytic intelligence can uncover real, previously hidden relationships between risk factors for disease. The models describing these relationships will be applied to your data to discover exactly who is at risk.

Verification and validation
Whether HIPAA, Sarbanes-Oxley, Basel II, Data Protection, CFR 21 Part 11, or any other set of regulations that may affect you, there are some common themes among all regulatory requirements: control of access to information, auditability of processes, and the promotion of accountability within and without the enterprise. These principles represent sound and ethical practices, and the centralized, integrated approach to the information cycle found in SAS®9 is exactly what is needed for regulatory compliance.

SAS' analytics can detect fraud (or indeed any other type of "pattern-breaking" behavior) and are a well-respected, thoroughly tested solution to support Sarbanes-Oxley compliance and the drug development process. Similarly, SAS' risk analytic capabilities give the software particular credibility for Basel II. The relationship between SAS and the FDA is well documented and needs no discussion here. The SAS®9 Open Metadata Architecture promotes the single point of access model to your corporate information store, thus giving a single point at which to record and control access to this information.

Every organization has its own internal quality assurance procedures, which must be thoroughly understood so that the qualification and validation effort is properly scoped, resourced and realistically scheduled. Planning and communication with internal quality assurance personnel is critical to setting expectations for the timing and availability of SAS®9 software across the user base. You don't want to be caught in a situation where everyone expects to be using SAS®9's awesome capabilities sooner than your qualification and validation testing processes are able to deliver results that meet internal and external guidelines.

Installation qualification (IQ) testing demonstrates that the installation of SAS®9 in your IT infrastructure has been completed as specified and that program storage has been documented. SAS provides an automated script that produces a complete set of IQ testing results. Again, this doesn't mean that once you run the script, you're done. You must follow your internal QA guidelines to build a "correct" package of IQ testing plans and results that comply with the software validation requirements of 21 CFR Part 11, as they apply to SAS®9 installations.

Subsequent testing includes operational qualification (OQ) testing that demonstrates SAS®9 operates according to predefined specifications and that data integrity is maintained. Finally, performance qualification (PQ) testing will demonstrate that SAS®9 performs the required functions while operating in a normal production environment.

All of these tests must have the necessary testing plans, results summaries and testing artifacts (screen shots during installation and performance of the test scripts, test program output, reports and appropriate signatures) that are required by your internal QA department to approve your SAS®9 installation for research purposes. Time frames for completing this process depend on your internal procedures and the learning curve of personnel assigned to administer the testing.

Remember, prior planning prevents poor performance ... and unpleasant experiences during the critical phase of software qualification and validation.

Bio: In addition to being SUGI 30 conference chair, Greg Nelson is president and CEO of ThotWave Technologieswhere he leads the consulting and software development for large scale decision support clients.