Let's start at the beginning:
1) A single analyst at Mom 'n Pop Analysis, Inc has a single user license of SAS on her desktop Windows machine. She uses SAS Display Manager and batch jobs to read her data and perform her jobs. All the "work" happens on her local machine. The analyst gives Mom and Pop the Listing output results of their analysts and Mom writes the reports for the clients and Pop presents the results to the clients. The analyst has Enterprise Guide available to her, but only uses it to generate SAS Graph and PROC TABULATE code, when she needs that kind of analytic output. Most of the time, she works with DATA step, PROC MEANS and PROC FREQ.
2) At a slightly bigger company, We Do Data, LLC, there are 3 analysts who all work on Unix. Their data and copy of SAS are on a server machine. All 3 analysts share the same server copy of SAS. They write their code using VI and submit their code using a batch submission process; their results are all HTML results and their HTML output files are written from SAS directly to a web server. Static HTML pages/reports are accessed via the company web server.
3) At another company, Data Don't Scare Us, Inc, there are 5 analysts who work for a consulting firm that has a government contract. SAS is on a mainframe computer, the data are on tapes and disk. The consulting firm has network access to the mainframe and each analyst has a copy of SAS Enterprise Guide, which they use as a front end to access their data and perform analytic tasks and submit their program code all using a copy of SAS on the mainframe.
Reports are produced in a variety of formats, mostly RTF and PDF and are delivered via paper or email. Two analysts have single user copies of SAS on their desktop machines because they do highly specialized forecasting based on their own programs and algorithms -- they download sample data to their machines to fine tune their algorithms and then they run their programs against all the mainframe data after their development is done.
In all of the above instances, the analysts are fairly experienced programmers and/or analysts who either use SAS on a desktop machine or use SAS on a server machine. In the #3 situation, SAS Enterprise Guide is acting as a Graphical User Interface between the analyst/programmer and SAS on the server.
Now, let's talk about the SAS Enterprise Intelligence Platform:
4) The Gynormous Corp is a multi-bazillion dollar services company and they have the need to access their data and analyze their current customer account information and forecast future performance. In addition, they do billing, auditing and reporting. Many of their reports have to be available both internally (inside the company) and externally (downloadable by the customers).
The employees who access the data range from folks who work in Excel and Word to managers and executives who "only want the numbers" to their statistical analysts who do the forecasting and performance and risk analysis. The folks who work in Excel and Word aren't programmers, but they need to be able to generate ad-hoc lists of products, customers, or queries against the corporate data and they may need to run canned reports that have been written for them by their analysts.
The executives and managers may want to use canned reports, via web access, or they may be a more computer savvy and want to "poke around" at the numbers a bit and generate reports on the fly -- but without knowing all the ins and outs of data access and programming. The IT department maintains the corporate data bases and data marts and does the fine tuning on the computer systems. The analysts and programmers use a mixture of SAS Enterprise Guide and SAS to do their work, depending on their expertise and the nature of their particular jobs.
You would only see Information Maps, Information Map Studio and Web Report Studio being used along with SAS Enterprise Guide in a SAS Enterprise Intelligence Platform installation, such as #4. It is possible, but unlikely, that company 1, 2 or 3 above would have the Enterprise Intelligence Platform. So the use of Enterprise Guide in 1, 2 or 3 is different from the use of Enterprise Guide in #4. The central component of the SAS Enterprise Intelligence Platform is the Metadata server and the Metadata itself -- which contains one location where the corporate systems, servers, users and data are all defined.
In the Enterprise Intelligence Platform, even if an analyst uses EG, they are likely to be accessing data via the Metadata server, to ensure that they access only the data that they are authorized to view. They can still perform their analysis and create their reports, but instead of issuing a LIBNAME statement to access their data, they use the data as it has been defined in the Metadata server.
In the context of the SAS Enterprise Intelligence Platform, both SAS Enterprise Guide and SAS Web Report Studio act as client applications, which allow users to access, analyze and report on their data from within an application that matches their comfort level and their level of expertise. For example, a statistical analyst may use EG to perform analysis and then it's decided that their report should be made available to the executives on the Web. So the analyst turns the EG project into a Stored Process and the managers and executives run the Stored Process in Web Report Studio. This is an instance where the executive doesn't need to know any programming or anything about the SAS language or anything about the corporate database or data marts, in order to run a report that is using SAS and SAS data.
But Web Report Studio is a web-based application. The only way to submit programs is via SAS Stored Processes. All the other types of reports and analysis that can be performed need to be performed using a SAS Information Map as a data source -- this is because an Information Map represents a description of the data that lives in the Metadata -- so when a Web Report Studio user generates a report, they work with data, as it is described in the Metadata.
For example, imagine that in the corporate data mart, there is a Vendor table, a Vendor Demographic table and a Purchase Order table. Normally to find out how much is being spent with a specific vendor, a programmer has to join the 3 files together -- not a big problem for a programmer/analyst, but perhaps a daunting task for a non-programmer. A data manager could build an Information Map to hide the join from the end user. When the Web Report Studio or EG user or SAS Add-In for Microsoft Office user went to run an adhoc report on vendor information, this information map would allow them to access the information they need without worrying about the join. Or, an Information Map could do something as simple as removing the complexity from the database naming conventions -- what if your corporate database had icky column names like:
With an Information Map, you could also create a data source that just provided meaningful (and shorter) column names for the end users, such as
Or, with an Information Map, you can define one map with the vendor information organized for the purchasing department's most standard report needs and a different map tailored to the general ledger department's needs. These are just a few uses of SAS Information Maps within the SAS Enterprise Intelligence Platform. They act as the primary data source for doing reporting in SAS Web Report Studio. However, Information Maps can also be used in SAS Enterprise Guide and in the SAS Add-In for Microsoft Office -- two other client applications that work within the context of the SAS Enterprise Intelligence Platform.
The bottom line is that SAS Enterprise Guide will work in conjunction with the SAS Enterprise Intelligence Platform or can work in a non-Platform scenario (#1,2,3 above). However, SAS Web Report Studio and SAS Information Maps are designed to work only in the context of a SAS Enterprise Intelligence Platform installation.