{'fraction_non_alphanumeric': 0.0274518485720611, 'fraction_numerical': 0.003984945760460483, 'mean_word_length': 4.570900123304562, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Chickens , Eggs , and SAS ® BI : An Evolutionary Approach

Business Intelligence wisdom stresses the need for careful planning before deploying “Your BI Solution,” but successful BI deployments present a chicken/egg dilemma: it’s difficult to know what you need to know until you've gained usage and deployment experience. It’s hard to know if you’ll get it right the first time because BI is multifaceted and each deployment is sensitive to local conditions and contexts. Our approach was to build a small prototype and use that to discover what we did not know. We also needed to better understand likely avenues of BI usage that would let us play to our strengths. We faced severe constraints in terms of budget, staff and specific knowledge. With this in mind we chose Solaris 10 Containers for our BI install as the best way to gain knowledge and prove concept. Chief among the things to be demonstrated was that achieving some of the returns promised by BI need not be as daunting, and strictly major-league, as they may initially seem. Successful deployments don't have to be limited to large, well funded, well staffed, expert efforts. Even your most novice attempts can produce useful artifacts that can be leveraged forward. This paper discusses our approach, specific kinds of challenges, typical problems and the successes that helped us to decide to push out a production iteration and to expand our SAS BI initiative without the need for the usual sales pitch. WHAT LED US TO START DOWN THIS PATH (You Have to Start Somewhere) When we first got the idea of “doing BI” we found the whole thing both intriguing and daunting. We tried asking Google “what is Business Intelligence” and got 30,000 hits. We wanted to deploy more web stuff but we had “staffing issues.” We also feared we were falling behind the times. Numerous presentations and articles stressed the need for rigorous upfront planning and specification. We looked for a roadmap to take us “from here, to there.” The problem was that not much seemed to fit our circumstance (think tiny and poor). As we considered our own investment in SAS code, our backgrounds, and the potential for “good things to happen” from BI, our notions of “here” and “there” began to change. In 2006 we attended SUGI 31 and set about evaluating SAS® BI in terms of our known organizational needs and what parts of the architecture we thought we could handle. We wanted to move quickly and with a low profile. We also were not sure how much of a support load our server group would undertake without balking. In resource constrained environments, the balking zone can be a major consideration. This conference was extremely valuable in that we came away with some answers for our most pressing concern, which was that we didn’t have an implementable development path. We talked to a lot of SAS staff at the campground and bounced around ideas that seemed to always start with “Do you think you could ....” and ended with “.....theoretically that should work, I don’t see why not.” It was like wandering through the parts store picking what we thought we could use. Our curiosity was piqued; we were becoming strangely comfortable with a fuzzy definition of BI. Even as interest in the potential for BI was running high, staffing and dollars were running low. We had existing SAS programming skill sets and a code base used to generate various reports and also to massage data going into and out of our Oracle databases. The prospect of moving SAS paper reports to a quicker, cooler, dynamically generated web distribution was very appealing. As Homer Simpson might say “Multiple Oracle databases, SAS BI, no paper, easy connections – Hmmmmm.” THE INITIAL CHALLENGE OR SMALL SHOP BLUES (Connecting the Local Dots) The fear that the whole thing is overly ambitious must be overcome. You have to decide who to get on board first, your management or your staff. The important thing is that someone gets enthused. We chose staff. Fortunately dynamic report generation appealed to our programmers’ love of not keeping track of static web content. We identified some real business needs. Meeting these forced us to ask ourselves if this was really something we could do. You assess your strengths and weaknesses and identify achievable connections between the skills your staff currently possess, and the skills which you will need them to acquire. It’s the basic SWOT – Strengths, Weaknesses, Opportunities, and Threats review. 1 Systems Architecture SAS Global Forum 2008