Wednesday
Dec122012

The Importance of Being Documented

Documentation of implementations of Business Intelligence platforms, or GIS systems varies greatly from organization to organization. As a new architect or platform administrator you may find yourself scrounging for every little scrap, every tiny morsel of documentation you may be lucky to find. It is often a true hodgepodge, what we find that passes for documentation. Here are some broad categorizations:

1) The IKEA instructions

Those wordless pages with pictures familiar to anyone who has ever shopped at an IKEA can either provide easy guidance or a rather sleepless night. Putting together something called a Hakan (Swedish for either a former NHL’er or meaning “There goes your evening”) can range between easy or rather difficult depending on the visualization interpretation of the person in front of them.

IKEA instructions can be a gem or a bane to a new architect making sense of a production environment. Certainly you can put the screenshots together and learn the steps taken to build the environment. But often, the rationale and the why get lost in the visual interpretation.

Questions like:

  • Why did that install step fail and why was it allowed to go to production?
  • I see a script was run to get past a validation step, why?
  • One server didn’t use an installer account, let me guess why?

For a SAS BI environment, you typically want to extract information like:

  • Which software depot was used where?
  • Is there a plan.xml file and is it used in all cases?
  • Locate the deployment registry and instructions.html file to get more information on the web application server configuration and what was installed.
  • Use the Web Administration console to look at the configurations of all of the web  applications on the midtier.

And this is only the start of piecing together our “Hakan” or BI environment.

Enhancing the documentation involves putting the why and how into it. Use images liberally, but explain any deviations from the norm (i.e. use of non-standard ports, or changes to the normal configuration and why they were made). This will go a long way to make sure documentation leads to repeatable implementations of the platform. You also need to carefully inventory what has been installed, perhaps in a matrix and attribute these applications to an order and license. If there are ever any discrepancies with the vendor, you now have an easy way to track what may or may not be included in a proper software order.

The IKEA instructions give us at a minimum the bread crumbs to find our way out of the forest.

 

2) Where or where has our little documentation gone?

The architects and administrators that fit into this category can only wish they had the handy “IKEAesque” screen captures of installations and configurations. Often a good admin can piece together much of it through looking at the relics of the installation such as deployment registries and if it still exists on the servers, the Software depot or package used. When the deployment deviates from the norm or best practices, we are often in a pinch of trouble from the outset. In a customized environment, perhaps one that utilizes multiple tiers or clusters of servers, it is indeed a challenge if you need to recreate such a thing for a new platform release.

So where do we start?

The SESUG paper from Brian Varney on Documenting an Undocumented Environment gives some great ideas to proceed ahead including examining existing logs to determine who is using what applications. The logs for Web Report Studio and other web applications for example provide some excellent information that can be pulled about their usage. For Linux or UNIX environments, you may find using TOP or TOPAS (depending on availability on the server) to be useful to see what people are commonly running in the environment. Sometimes a quick e-mail or call to some of the “power users” can help fill in the gaps on why an environment was customized or didn’t follow the normal vendor best practices.

There are a few good practices to adhere to in getting documentation going and in good shape:

1) Application matrix – tying installed applications to servers. List the Ports these applications use and include information on dependent programs and locations of files that use these applications.

2) Install directory – subdivide this for all software clearly labeled for order and version.

3) Interaction with vendor – document any hotfixes or internal documentation the vendor may have to fix an application issue.

4) Architectural diagrams tied to applications. In multi-tier or distributed environments, it is good to know both the number of cores on a server as well as what is installed on them.

And for those lucky enough to walk into an organization with stellar documentation, we would suggest a laudatory e-mail, or better yet, offering to buy a beer for your diligent and thoughtful predecessor. That is indeed something worth celebrating.

Monday
Jun182012

Going "All-In" with an Electronic Health Record

There has been a lot written in both the IT press and in healthcare journals around the Electronic Health Record (EHR). You might think that in the interests of providing affordable health care for all citizens, large health care organizations would look more to open source solutions to address the standardization of health care data across the organizational landscape. Steadily, we have seen the opposite.

In the most recent New England Journal of Medicine, Kenneth Mandl and Isaac Kahone share their perspective on EHR systems called “Escaping the EHR Trap – The Future of Health IT.”

The article discusses what the authors regard as the common myth that “medicine requires complex, highly specialized IT systems”, which in turn result in astronomical IT cost increases at the expense of other initiatives. Those health care organizations that have shied away from systems like EPIC often opt for the export from source systems to open source approach. The authors espouse a best of breed approach; combining a number of vendors including EPIC, open source and other solutions.

Recent spending on the one-size fits all approach at several medical centers is quite an eye opener. Forbes cites one recent spend in California on the EPIC EHR at $150 million. It is certainly understandable that there is a growing fear in the populace that these investments will eventually find their way to the cost of care as well as insurance costs for employees and businesses.

What are some health care organizations doing for less money?

  • Health care analysts in Nova Scotia use ESRI ArcGIS, Oracle and SAS amongst other tools for storage, analytics and visualization of health care.
  • Analysts in Ottawa use SAS Social Network Analysis and Fraud Framework to examine incidences of fraudulent claims currently in the pipeline, with the data derived from Oracle databases and other systems.
  • Many others, like Boston Children’s Hospital opt for an EHR coupled with other solutions for storage and analytics.

There is a great excerpt from Scottish crime drama author Ian Rankin in his book “Doors Open”. Rankin’s main character, software mogul Mike MacKenzie describes the complexity of his “Smart House”. Mike admits that his smart house dazzles his guests, but later admits after several halogen bulbs blow out or hidden audio speakers cease working that he is want for a solution, or someone capable of fixing it.

Those that have been most successful with large enterprise systems like SAP, Peoplesoft or EPIC readily admit that one large software purchase for everything does not usually work. A complex system requires highly trained individuals and a framework that requires the business to adapt to it, and not the other way around. The hybrid approach that Mandl and Kohone discuss appears to be a more flexible, less complex and cheaper idea.

What are your experiences with Electronic Health Record systems? What challenges have you faced as an analytics professional in accessing this data?

Thursday
May312012

Analyzing Large Volumes of Data with a Small BI Group

Scenario

You may face a similar scenario to this one. You are the manager of a small business analytics group. Your team is both talented and dedicated, however the volume of BI requests from your organization far outweigh the resources you have. As more investment is occurring in automated processes such as EMR systems in healthcare or trying to capture clicks on a corporate website, the folks at the C-level have discovered the value of this data and want instantaneous access to summarized, meaningful information. And they want it now.

All of us have faced doing more with less. And it is certainly a smidge easier with something like the SAS EBI platform and other solutions in our toolset.  But there is still only so many hours in the day.

In the SAS Voices blog today, Ritu Jain wrote an article about Self-Service BI and its value for small to medium sized organizations.  It was a timely piece since many projects we have worked on have implemented a self-service BI approach to varying results.

Why such a variable return on our efforts? The reasons are numerous. For projects that have been successful in employing self-service BI, there are the following commonalities:

The Champion

The herculean efforts of data analysts, BI developers and administrators will yield few fruit unless the efforts to build self-service BI are not championed by someone with political will and clout. For example, many individual departments want access to their own OLAP cubes, either through Excel or EG. The BI champion sees the organization in a different light than the rest of us at the ground level. They attend the meetings and know all of the stakeholders. Self-service BI is freed up by eliminating silo efforts for departments and understanding what is in the data and who can benefit.

We have seen some great self-service champions in our work. This is a person who attends BI tech meetings, requirements gathering sessions or other meetings in spite of a busy schedule. When developers understand the business needs better, we can build a better BI lineage which is critical to a truly functional self-service BI lineage creation.

The champion can also communicate data quality challenges to the c-level as well. This is a key element to success so individual departments will buy in and invest in a self-service effort.

Organic Growth

You all have seen this. We are walking past a downtown shop and a growing group of people are gathered at the storefront window peering inside. We feel the urge to stop and look at what all the fuss is about. This is the same with self-service BI.

A small group can do wonders with BI tools like SAS.  However, we need buy-in from individual departments within the organization to make this truly work. Why?

The answer is simple. On many projects, we viewed growing SAS BI as an organic process. We identified key stakeholders within a department for a particular BI project they wanted, and bring in the subject matter experts (usually a data analyst dedicated to that department). Often data analysts are diffuse within an organization and it’s difficult to communicate. Self-service BI brings departmental investment to a project, where that organizations analyst is enlisted at the requirements stage. Once a cube is built, BI content added to the portal, perhaps a scorecard developed in SAS Strategy Management, the group works to bring them into the fold.

In our experience, a formalized BI curriculum for new users of BI can work wonders for growing self-service BI. This ensures that new users have the capability to help themselves when working with data in the warehouse, or some of the BI tools now available to them. Programs like this include internal certification of new users which is a great way to make them feel a part of the group after an intensive learning program.

Your group may be small, but getting more people in other departments involved with BI at the requirements stages or earlier, you have the ability to grow beyond traditional departmental staffing limits.

Embedding

At a more mature state of self-service BI within an organization, we have seen the concept of embedding an analyst from a BI Centre of Excellence or other aptly named group within a department to work with new users. Sometimes this is a challenge due to resource constraints but the payoff can be substantial.

Embedding a BI developer or analyst within a department that has recently adopted BI obviously helps to strengthen its usage by educating new users. What it also does is help to evaluate the action-ability of BI deliverables like a balanced scorecard, a web entry form or a dashboard. Some questions that often surface:

  • Who uses the application?
  • What are some of the common workarounds to enhance the output of a report?
  • Do users export data to Excel for presentation?
  • Is this deliverable even used?

After learning how a department uses BI, we can bring this information back to improve requirements gathering and the BI content we develop for the organization. Monitoring logs works too, but often the more personal approach leads to increased buy-in and user understanding.

These are just a few key examples of leveraging self-service BI with a limited number of people. How does your organization define “self-service”? What are some of the challenges you faced in implementing this with SAS or another BI platform tool?

Wednesday
May232012

SAS Strategy Management 5.3

One of the best parts of any SAS Global Forum is the opportunity to chat with SAS Solution developers about new versions of their products. It is amazing how much time SAS folks spend with their customers to steer them in the right direction to address issues or limitations with the out of the box solution software.

A specific opportunity presented itself in the chance to talk with one of the lead developers of the SAS Strategy Management solution.

In working with both health care and logistics organizations that utilize Strategy Management for Balanced Scorecard and Strategy Maps presentation, we routinely stretch the limits of the solution to meet the requirements of physicians, nurses, administrators and marketers.

Here are example of the questions we posed to the SAS StM experts at the conference:

We have a requirement to look at both daily and monthly range data values within a Balanced Scorecard. We also may need some custom time periods. How would we utilize StM to do that?

In SAS StM 5.3, there is a great feature ‘Manage Time Periods’ where both existing and customized time period sets are stored. Some needs for a custom time period set may be a purchasing or delivery schedule that may not conform to normal calendar days, weeks or months.


You can see above the existing and custom time period levels in StM. Checkboxes determine their availability to projects.

In StM 5.2, Strategy Maps cannot be added as an object within the StM Enhanced Portlet that can be surfaced on the SAS Information Delivery Portal. Are there any plans to enhance the product to include them?

We learned from the StM developers on the demo floor that the new Strategy Management 5.3 solution does not support the inclusion of a Strategy Map within the enhanced StM portlet. Thankfully we are not the only customers to make such a request for its addition. The next version of StM we were told will have the ability to add a strategy map object within the portlet. Yeah!


We are looking at a migration from an earlier version of SPM to StM which does not leverage the SAS Batch Management Facility. This migration must include the creation of links within scorecards line items to stored process generated reports (SPC charts, graphs, other visualizations and report tables). What does 5.3 do for us?

Well, by now it is obvious that the SAS BMF tool has replaced older customized load programs that were often used by SPM. We were shown a couple of options on the demo floor in version 5.3 including some greatly enhanced capabilities to manage links. These links not only apply to scorecards, but to gauges and strategy map diagrams.

There are now nine different linkage types which you can take advantage of including stored processes, information maps, and WRS reports amongst others.  You can also specify what information to pass to the URL target, allowing for filtering of results; a cool improvement to the Solution.

Finally, users will see some improved capabilities of utilizing the product using the SAS Add-In for Microsoft Office (specifically Excel and Outlook) to be able to quickly access specific strategy views. In many requirements sessions, users have requested the ability to print out reasonable facsimiles of a Balanced Scorecard for reports or demonstrations.  With the added capabilities with Microsoft Outlook, you can customize strategy management output and automate the process of sending e-mails to appropriate individuals.

The new SAS Strategy Management allows you to take advantage of numerous new features for visualization, importing data, managing links amongst others. How does your organization leverage SAS Strategy Management? If you are considering the use of balanced scorecards or strategy maps and not currently an StM customer, take a look at version 5.3.

Wednesday
May092012

The Curious Story of Sparklines

Organizations that utilize Balanced Scorecards within their BI implementations often take a purely snapshot approach to displaying data. Some of the earlier versions of SAS Strategic Performance Management (now Strategy Management - StM) leveraged indicators (up|down|level) and numeric displays of data. This tells only one piece of the story.

Edward Tufte has a chapter in his book “Beautiful Evidence” on the usage of sparklines to convey meaning to data representation. You don’t even need to read Tufte’s work to see the prevalence of sparklines in the financial news, ESPN or other media that examines performance.


The oft cited graphical representation of Napoleon’s Russia campaign (1812-1813)

Sparklines are most notable in financial publications such as the Wall Street Journal and Bloomberg to provide users some context of changes over time for a particular indicator or investments.

At Maine Medical Center, Balanced Scorecards are used with SAS Strategy Management to show performance and patient satisfaction. Showing a simple table of values and an indicator (up|down|level) only gives us a point in time look at performance. What about the last 6 months? 60 days?

 

Adding a sparkline to performance data for a Balanced Scorecard provides some measure of historical context to current snapshot performance metrics. Tufte included a simple spark table in his work shown to the left:

 

Sparklines are even more effective if they also display “what is normal”. I recently worked on a Fraud Framework project where new SAS users within a healthcare oversight project interacted in the BI layer with Fraud data for the first time. That solution does an excellent job through the use of stored processes to show what is normal in comparison to some of the fraudulent provider behavior they were seeing.

Context is vital to showing deviations beyond what is normal. Traditional BI tools like SAS BI Dashboard have some improving capabilities in this area, but some of the best uses of sparklines have been built through custom stored processes and programs in conjunction with other Portal visualizations. The success of sparklines is to get the user to ask questions and delve deeper into the available data based on this visual cue.

Sometimes, we may not have the proper aspect ratio to convey meaning to sparklines. Tufte provides an example of this in borrowing from another researcher William Cleveland. The width/height of the sparkline makes a difference in how the data is displayed. For financial data, a sparkline with an aspect ratio of 5 to 1 is the most common and useful. To track an NBA basketball season, an aspect ratio of 20 to 1 may be most appropriate.


The dysfunctional New York Knicks provide fodder for chuckles in basketball management circles, but a sparkline examination of team performance published in the New York Times shows another effective method to track their futility over time. The whisker representation of wins and losses for the team depict the daily goings-on of the team over time. Superimposing the coaches above the sparkline attempts to correlate performance with leadership in the visual display. A visual narration of win/loss events.

Unnecessary Clutter

Tufte warns us in his book about clutter. Many BI Dashboarding tools, including SAS have some limitations in producing customizable sparklines in association with a spark table. We often worked around this by linking balanced scorecard measures to stored processes to show sparkline trends in addition to the standard sparkline within the spark table.

The dashboard below has been cited by a number of websites as a great example of using sparklines to attract the attention of those at the C-level of an organization. The Balanced Scorecards that we often work with can benefit from this type of visualization approach.

 

Performance snapshot and historical context  (From Dashboard Insights)

A couple of other examples of sparklines:

Twitter is becoming a more common way for organizations and individuals to quickly convey information. Again, we often look at Twitter to see what is happening at SAS Global Forum, or at a Sara Bareilles concert. Some are using tweets to convey trends such as this one from the Wall Street Journal.


Tufte includes a great sparkline trend from the New York Times showing some of the great home run hitters of all time. As you can see below, not all home run hitters are alike. Some certainly benefited from consistency. Others relied on outlier years (perhaps with a little synthetic assistance).

Sparklines help us to make sense of the voluminous amounts of data that we collect on a daily basis. They often say a picture is worth a thousand words. Through the work of Tufte and other data visualization experts, we learn more and more about our data by using their best practices to display time series information on measures that are important to us.

Do people pay attention when sparklines are included beside a point-in-time performance metric? It certainly appears that way; why else would executives ask data analysts to extract data from SAS, Cognos or other tools to produce “pretty-picture” sparkline dashboards in Excel. I think this alone should inspire the major BI vendors to improve their capabilities with spark tables, sparklines to include more annotation, and the capacity to create layered information (like in ArcGIS) and other capabilities.

How does your organization use sparklines to convey context in performance?