Laura's profileA Balanced Scorecard, Bu...PhotosBlogListsMore Tools Help

A Balanced Scorecard, Business Intelligence & Six Sigma Blog by Laura Edell Gibbons a.k.a Sassy Data Chic

"In God We Trust...All Others, Bring Data," W. Edwards Deming

Dashboard Design Diva - Read Users Body Language

  Date Added: May 2009 | Date Recorded: February 2009

Executive Scorecard for Online Travel Company

  Date Added: March 2009 | Date Completed: June 2007 | Scorecard Developer: Laura Edell Gibbons
April 28

Optimizing BI Operational Reports with Internal IT Ticketing / CRM Systems

 

How often do you think about optimizing your operational reporting processes with your internal ticketing system / IT CRMs? Probably not as often as you would like -

Being a Lean Six Sigma Black Belt, I can’t help but think about these things.

In the process of promoting a report between a test environment and a production environment often involves customer communication in the form of an email – Why not standardize and automate that process?

First, you should have an inventory of your reports with an ID or CUID. This can be extracted from the BusinessObjects or BI provider auditor universe/logs respectively; in a worst case, start reporting off of your SQL data source instances or event logging tables.

Here is an example of C# code that automates the promotion process and generates a nice user friendly output which is standardized, and calls out the folder class where the report lives, provides a login link or if using SSO, a pass through token to log the user in auto-magically. Anything in maroon are comments for you , dear blog reader; anything in navy is a part of the actual email content.

“Your report has been created and placed on the TEST system for testing.

Please login (by clicking the link below) and test the report.
http://<servername>:<port>//InfoViewApp/logon.jsp

Your report can be found in: \\" target=_blank>\\<LOB folder>\<Department folder>\<Department subfolder>

The report name is: <ReportName>

Hide the CUID, Display the mapped report name only to end users like you see above.

Link using OpenDocument and append to C# code: http://<servername>:<port>/OpenDocument/opendoc/<platformSpecific><parameter1>&<parameter2>&...&<parameterN>

OR, you can go directly and get updated or new report here  :
You will have to login manually if you use this link. Remember to change the default Authentication (on the login window) to "Windows AD" or your respective authentication method (“Enterprise” or “LDAP” are your other choices).
Once the report has been tested please let me know by re-opening the ticket so I can move it to the production system.

Untested reports are purged every 30 days. Should you want to make any further changes to an existing report outside of data quality corrections, please open a new ticket but reference it to the old one for tracking purposes. Thank you for your kind consideration and adherence to the BI team report process.”

Note:
To obtain the document ID, navigate to the document within the Central Management Console (CMC).
The properties page for the document contains the document ID and the CUID. Use this value for the iDocID parameter.

April 27

Libra – a week of house cleaning and independence is in store for you!

Your Horoscope - This Week (April 26 – May 2, 2009)

Don’t start or decide on anything of matter on Monday or Tuesday - Moon and Mars are in your ruling house where the Hermit is deriving a joyous solitude that may surprise you dear Libra, if you choose to listen. Your key word is independent, so break the chains of codependency now. Your love life looks hotter than ever. You can't escape the demands and desires of your lover. The presence of Mars in your relationship zone indicates it's time to clear the air. If there are any issues that have been pushed under the carpet, they're about to be exposed. You may find your partner a lot more argumentative than usual. Talking over difficulties will help the energy in the relationship to move instead of stagnate. There may be some turbulence, but you'll also feel a lot better for having shared your feelings.

 

Your Horoscope - April 2009

You'll be torn between work and personal matters at home and need to find balance on April 1 and 2. Don't let others push you into making decisions quickly. You'll have the chance to establish warm and affectionate bonds and enjoy life on the weekend of April 4. Catch up on a work project on the evening of April 5. Take your obligations very seriously on April 6 and 7. The Moon in your sign on April 8 and 9 will relax you and help you take it easy for a couple of days. You'll have to be proactive and assertive in some situations, though, and not wait for developments. Relationships may be strained on the weekend of April 11 if you don't deal with issues immediately. April 13 and 14 would be a good time to take a day trip if you feel the need for a change of scene. Burn off some excess energy by hitting the gym. Work will be intense on April 15 and 16 and you may need to put in some extra hours to get things finished. You may want to get involved in a humanitarian cause or at least be of help to someone in need on the weekend of April 18. A burst of energy on April 22 and 23 may be short lived but will motivate you to start new projects. Do some reading or call a friend on the evening of April 26. You'll feel frustrated by a critical person in authority on April 27 and 28.

April 23

Attn: Northwest BI Professionals - Register now for the next TDWI NW Chapter Meeting

 

Date: May 14, 2009

Time: 5:30–8:00PM, with billiards and networking to be held at the Parlor immediately following event

Location: Lincoln Square, 700 Bellevue Way NE, Bellevue, WA 98004 (see map below)

Lincoln Square
Lincoln Square
Speaker: Dave Wells, TDWI Research Director and Avid Conference Speaker

Customer Speaker: Vincent Ippolito, Washington Dental Services’ Director of BI

Topic: How to Deploy BI Programs in Time of Economic Hardship

Registration is free. Food is free to attendees. And best of all (unlike those other Data Organizations), you DONT have to be a member to attend, nor pay to attend even if you ARE NOT currently a member.

Space is extremely limited and advanced registration is recommended

Link to Register: http://1105media.inquisiteasp.com/cgi-bin/qwebcorporate.dll?P5RVKQ

TDWI NW Page: http://www.twdi.org/northwest

April 17

Social Intelligence Presentation by Bill Baker, Visible Technologies CTO

 

Re-visiting Organizational Objectives and Values

Simplistically speaking, the BSCOL (Balanced Scorecard Collaborative) defines the cascaded model approach for linking corporate values with individual's performance review goals/objectives. Starting at the bottom and looking at what each individual's personal goals are, and flowing up from there to the departmental goals, the division goals and finally the executive tier strategy/vision/goals/objectives, will help you to see where you have gaps in your values to what your employees are driving your company towards, versus where you have alignment.

 

Restructuring those values either at the top (harder) or at the individual contributor level at the bottom (easier) to ensure alignment will both drive better performance from your people because of the visibility offered to them by demonstrating how what they are tasked to complete in a year are contributing factors to helping the company achieve its organizational values. If your start with existing values, and then add what the existing objectives are as a starting point, see if you can map those together. 9x out of 10, they will NOT be aligned and that is a big AH-HA for many leaders to see on paper.

 

Then start to cascade from there to the division leader tier, the department management tier and lastly, to the individual contributors. That is the vertical alignment process from top to bottom, if that is your preference. Once you have these vertical lines mapped, look to see overlap or conflicting values between divisions, departments and people and find affinity areas that can be mapped logically back to the values where you started (in a top down approach). BSCOL.ORG and my blog (shameless plug) are both great resources offering excellent templates to assist in this process, like strategy maps. (See graphic provided by the TDWI BI Journal below) with a twist = Instead of using the 4 perspectives or in conjunction with (as that is very valuable in and of itself), use your organizational hierarchy instead. Financial becomes CEO's Established Organizational values/objectives, Customer becomes the divisions that report into the CEO where the circles become that divisions values / goals/objectives, Internal becomes the departments and Learning and Growth becomes the Individual Contributors objectives that their manager lists out in those pesky annual performance reviews

 

(sorry to those big believers but until true performance management like what I have outlined is institutional in all companies, the PR system is a bell curved sham where some of the best employees get the short end of the bell curve stick because how could one department have all highest performers even if they are a crackerjack team of employees. One day...A girl can dream right?...)

 

-Laura Edell Gibbons

March 26

New LinkedIn Group: TDWI NW Chapter: Get Your Social Intelligence On!

Copy of TDWI Chapter Logo Having fueled a social networking surge, TDWI has started embracing what is super exciting in my eyes: social networking and BI. TWITTER: http://www.twitter.com/lauragibbons (had to shamelessly self promote)

TDWI NW CHAPTER: http://www.twitter.com/TDWI_NW_CHAPTER

TDWI on TWITTER: http://www.twitter.com/TDWI

LINKEDIN: http://www.linkedin.com/in/lauragibbons

TDWI NW CHAPTER on LINKEDIN: http://www.linkedin.com/groups?about=&gid=820537&trk=anet_ug_grppro

Enjoy! Laura Edell Gibbons, TDWI NW Chapter Board Officer & Chapter Secretary

Go to LinkedIn

 

March 20

TDWI BI Executive Summit post-conference report

http://download.101com.com/pub/TDWI/Files/TDWI_ES_TripReport_LV09.pdf


Sent by Laura Gibbons from her iPhone
February 17

Common errors when using STSADM -o backup/restore to transfer a database to a new farm on MOSS 2007

 

In the past I have seen the following problem a couple of times: a customer creates a backup of a content database on one server farm (e.g. using STSADM -o backup or a DB backup in SQL) and restores the backup on a different farm and attaches the content database to a web application.

After this operation is done several operations (like variations and content deployment) fail to work with the following exception:

System.ArgumentException. Value does not fall within the expected range.    
at Microsoft.SharePoint.Library.SPRequestInternalClass.GetMetadataForUrl(String bstrUrl, Int32 METADATAFLAGS, Guid& pgListId, Int32& plItemId, Int32& plType, Object& pvarFileOrFolder)     
at Microsoft.SharePoint.Library.SPRequest.GetMetadataForUrl(String bstrUrl, Int32 METADATAFLAGS, Guid& pgListId, Int32& plItemId, Int32& plType, Object& pvarFileOrFolder)     
at Microsoft.SharePoint.SPWeb.GetMetadataForUrl(String relUrl, Int32 mondoProcHint, Guid& listId, Int32& itemId, Int32& typeOfObject, Object& fileOrFolder)     
at Microsoft.SharePoint.SPWeb.GetFileOrFolderObject(String strUrl)     
at Microsoft.SharePoint.Publishing.CommonUtilities.GetFileFromUrl(String url, SPWeb web)
...

The reason for this problem is that backup/restore does not adjust the references from the publishing page objects in the Pages library to their Page Layouts. These URLs are sometimes stored as absolute URLs including the server name. And this server name is the server name of the old server farm which cannot be resolved on the new farm.

Be aware that backup/restore of MOSS content databases between server farms are not fully supported! Official documentation of this support limitation is currently in the works. The supported way to transfer content between server farms is to use STSADM -o export/import or content deployment. Backup/restore is only supported for the same server farm.

In case that you have run into the above problem you have two options:

  1. Throw away the database and transfer it correctly using STSADM -o export/import or content deployment
  2. Fix the incorrect links manually using the following steps
    1. Open the web in SharePoint Designer
    2. On the “task panes” window, pick hyperlinks.
    3. For the “hyperlink” heading, click the arrow and pick (custom…)
    4. In the dialog, ask to show rows where the hyperlink begins with a URLs which are not valid on the current server farm
    5. For each of the files, right click and say “Edit hyperlink…” and Replace hyperlink with the hyper link that is valid on the current server farm.
February 08

Strategic Business Intelligence in Times of Economic Turmoil

Ideas for business intelligence practitioners to forge ahead with their BI initiatives in times of economic turmoil - To pursue best-in-class business intelligence and data management without incurring the wrath of the monolithic centralized platforms built when times were marked by economic growth in most revenue bearing verticals - Can this same race hold its pace with its same velocity and momentum when the economy shifts winds against the runners? In this, larger than life uber-BI applications race, marked in the last 13 - 24 months by a high rate of BI mergers and acquisitions, one has to wonder what will happen when the dust settles and the acquired folks realize they are no more a part of the organization that was the little guy you bought out way back when. Imagine how ProClarity felt when giant Microsoft came a callin' - Or, when SAP acquired BusinessObjects; did it become: B-I-C ERP meet B-I-C, well, BI. What about the true R & D exploratory labs like Google Labs, who churns out some interesting advancements in the technology space, offering APIs and SDKs for free to the bold and daring willing to take them up on their offer (oh, and that's no wilting flower of a number folks...Google had a cap of 10000 invitations when their App Store went live in the Spring of 2008. Some of the cool new data warehousing appliances or the process changes that came about with Master Data Management came about from the die harder open source fans who wanted to bring some structure to the masses without the cost of enterprise platforms with their clunky deployment paths and costly upgrades. Let's not forget, the Adobe flash-frenzied dashboard users now introduced to the presentation layer worthy interactive dashboard gauges that made mouths salivate the first through third time viewing it... As was expected, vendors tried to update their applications to mirror such interactivity and integration with the MS Office stacks, though Xcelsius still corners the presentation layer market by far. (Open source has some cool contenders especially when it comes to data visualizations) as the race to the dashboard 2.0 space moves into the collaborative world of social networks. No, there really is a Santa Claus, and I, too, am still smitten with PerformancePoint Planning !! PPS truly rocks the product placement in this arena, much harder to appeal to that broad category of stuffy Financial Budgeting and Planning CFOs, and the likes. So I ask, with the downturn in the economy, can such advancements be made in, as clearly demonstrated, a capitalized business intelligence software industry , whose recent growth spurts marked a growing sense of entitlement yet with subpar execution and results upon implementation, where services and solutions costs drove positive spikes in software sales, and vice versa? In fact, an interdisciplinary and while highly debated, interdependency exists between the BI, social network, collaboration and portals with custom embedded BI apps, web services and more all geared with one goal in mind: to optimize in a cost effective manner in an effort to drive better, more data driven decision making ? Or is this another blue skies and apple pie dream manifested by one girl's love for business intelligence

February 04

Enterprise Architecture Got You Down?

Try this simplified toolkit approach based on standards defined by the Federal Enterprise Architecture (FEA) board, along with NASCIO:

 

Performance Reference Model (PRM) •Inputs, outputs, and outcomes •Uniquely tailored performance indicators  

In this category, you should immediately think Scorecard (Balanced Scorecard and otherwise),:

--Each scorecard have 4-6 perspectives which are logical / categorical groupings of key indicators, or what I like to call 'affinitized' KPIs.

--Each perspective has < 6-7 KPIs (Key Performance Indicators) (if you receive pushback, and you will, as people would define a KPI for the percent of time the Express Grocery queue contains purchasers with more than the specified limit of 12 – 15 items, doll it up for the BBB as a complaint, and deliver it with such ferver one almost winces when they realize said complaint is recycled faster than their next trip to the grocery store

    --Remember the 3 keys to success with defining KPIs: are they actionable, are they measureable (not in a future state, but today can you measure it) and will they drive a performance based behavior change (think incentives, as they represent a perfect example of a performance based behavior changer).

– So, ask the question now… "That's a long list, John or Jane Exec…First, what are you going to do with that information [the so-what question distinguishing actionable from interesting]…can you really drive performance improvements in your business with more than 5 indicators in the case where all 5 go red at the same time or if you don't want to be direct, you can ask "how do those KPIs link to your performance objectives personally – Any leader worth their title will take the time to align the activities and work tasks that they personally, or through delegation, list in their performance reviews.

--This process can be started at any layer in an organizational hierarchy and is called Goals / Objectives Alignment or Cascaded KPIs

--Most leaders you ask have no more than a few KPIs that they ACTUALLY care about – just over the hurt feelings now, or feeling that you have wasted x number of hours measuring and reporting on metrics that top leadership doesn't care about; if you have been in BI long enough, you will have experienced this at least once in your career.

 

Business Reference Model (SRM) • Lines of Business (functions and sub-functions) • Agencies, customers, partners

 

How will the performance KPIs cascade down to the individual contributor from the CEO's goals? Easy – take this example:

CEO sets a goal of wanting to increase revenue by growing the Sales line of business, specifically new customer sales. He sets a goal of 35% growth of new sales revenue, which the VP of Sales is tasked to drive. They , in turn, assign the goal to the account managers in charge of new customer accounts who then add the same goal to their salesforce in the field. The KPI becomes New Sales Growth >= 35%, frequency is set to weekly with hierarchical rollups to monthly and quarterly aggregations.

 

--Now, you may ask yourself, what about the Operations department where Customer Sales and Service (aka Telesales) lives, and bingo! You're getting it now…Even though it was tasked to the VP of Sales, they, or that same CEO, should have realized that the Telesales department can also generate revenue from new sales, just those that come through a different channel. Instead of the typical route of calculating in field sales and measuring the sales department for a goal of this nature, the Operations VP should have the same goal on their performance review as the VP of Sales, which they, in turn, delegate to their Telesales Center Managers, who delegate to the Supervisors who delegate it to the agents on the phone – While it is an implicit delegation as one who is hired to man a Telesales line understands their job is to answer the phone and make sales (thus, encouraging sales growth), it is still an action that is mandated by a supervisor, who received the mandate from their manager, who likely received the goal from the corporate office VP of Operations or person responsible for the Telesales center.

--It flows from top or bottom (vertically) as well as horizontally since in this example, it covers two horizontal business units (Sales and Operations).

--This is why starting with objectives or goals makes this process, that is, cascading KPIs, that much easier because you have a definitive starting point and end point which is that same objective/goal.

 

New Sales Growth >= 35% is the same whether you start with the call center agent whose awesome sales performance on the phones contributes to making her supervisor meet their goal which was to grow sales by 35% who enabled their manager who enabled the VP of Operations and the VP of Sales objectives who then met or exceeded their CEO's original mandate.

 

Service Component Reference Model (SRM) • Service domains, service types • Business and service components

--A service component is defined as "a self contained business process or service with predetermined functionality that may be exposed through a business or technology interface.

 

Data Reference Model (DRM) • Business-focused data standardization • Cross-agency information exchanges

 

Technical Reference Model (TRM) • Service component interfaces, interoperability • Technologies, recommendations

February 01

Today I dub 'Data Services Oriented Architecture' for a Web 2.0 and beyond World

As David Besemer wrote in his May 2007 article for DMReview, 'SOA for BI', "It took Michelangelo nearly five years to complete his famous works at the Sistine Chapel. Your transition to SOA for BI can go much faster if you start with data services."
What are data services? According to Wikipedia, wait, there isnt an existing definition on Wikipedia. First, a definition with I share with the Internet users of the world vis-a-vie WikiPedia:
"A Data Services Oriented Architecture or 'DSOA' framework consists of a combination of schemas, classes and libraries that facilitate and provide the ability to create and consume data services for the web. DSOA reveals the consumer data underlying architecture, exposed using Data Services' Entity Data Model, and provides reusability of your service when developed correctly," Laura Edell-Gibbons, Mantis Technology Group Inc.
portalnavbar
And by correctly, I would highly recommend not getting bogged down by the concept of plug and chug, dubbed by my colleague Tip, or making your code reusable. It is all a balance, remember, young BI padawan.
Select best-in-class data services middleware to help you model, develop and implement your back-end BI services. PowerDesigner is a pretty rocking modeling tool, which covers everything from data element impact analysis to facilitating requirements gathering. Simplistically speaking, I am a big fan of the simplicity of SQL Server Integration Services and the new Data Services, both Microsoft products, though this opinion is certainly one that doesnt necessarily represent the populas vote. I am a big fan of Infomatica and Data Integrator (now called Data services, funnily enough under the SAP/BusinessObjects brand).
During the first and second projects, be sure to track all productive working hours to deliver each phase of your solution and costs savings for the efficiencies I expect you designed your system with the unescapable expectation of being the ROI-generator, a widely accepted expectation that all BI systems have high ROI, and many due. Start small, grow enterprise once the concept has been leaned out and efficiencies expected and beyond are gained. Then, as you expand your deployment from project to enterprise, you can easily self-fund additional licenses and other required resources with the savings or other benefits gained on those 1st two, somewhat painful, 'initiation' projects. We all have to go through the process and while painful at times, the learning experiences offered outweigh any of the difficulties while learning.

It is better to build the new services project by project, always making the predecessor available to other projects in a unified data services tier as you go. You and your team can then choose whether to rhttp://scorecardstreet.spaces.live.com/mmm2008-11-07_18.20/#euse a data service, extend an existing service, buy or to build something from scratch, my least favorite BTW.
Over time, these will change and I suspect 'reuse' will become the greatest portion of the proverbial pie, whereas today, I believe the paradigm shifts more in the direction of 'build from scratch.'
Starting to plan front-end BI services up front, even while deploying your backend BI services, will enable you to make small but meaningful steps without much noticable downtime to the organization, something especially important for those of us working with a '4 x 9s' uptime SLA for our data centers. Plus, remember, if you build these on a powerful data services foundation, you will reduce your time to market, and your TCO over time. By providing the business with their much anticipated and needed operational reports, tactical and strategic dashboards and performance management analytics while infusing the lot into your SOA, one will reep rewards greater than my words could ever portray, dear reader...Til then, remember 'what will come sooner than you think is no more when than how'.

References:

  • David Besener. "SOA for BI." DMReview, May 2007.
  • January 30

    SWF Search-ability Announcement from Adobe and How It Relates to Xcelsius 2008

    Imagine Xcelsius dashboards especially built in 2008 with its flexible add-on component manager making it that much easier to customize components (think objects / widgets like scatterplots which are offered out of the box as a chart type)..

     

    Now, we have a best practice for monetizing the SWF content that is part of your Xcelsius 2008 dashboard...here is what Adobe had to say:

     

    Adobe is teaming up with search industry leaders to dramatically improve search results of dynamic web content and rich Internet applications (RIAs). Adobe is providing optimized Adobe Flash Player technology to Google and Yahoo! to enhance search engine indexing of the Flash file format (SWF) and uncover information that is currently undiscoverable by search engines. This will provide more relevant automatic search rankings of the millions of RIAs and other dynamic content that run in Adobe Flash Player. Moving forward, RIA developers and rich web content producers won't need to amend existing and future content to make it searchable—they can now be confident that it can be found by users around the globe.

    Why is this news important?

    Adobe is working with Google and Yahoo! to enable one of the largest fundamental improvements in web search results by making the Flash file format (SWF) a first-class citizen in searchable web content. This will increase the accuracy of web search results by enabling top search engines to understand what's inside of RIAs and other rich web content created with Adobe Flash technology and add that relevance back to the HTML page.

    Improved search of SWF content will provide immediate benefits to companies leveraging Adobe Flash software. Without additional changes to content, developers can continue to provide experiences that are possible only with Adobe Flash technology without the trade-off of a loss in search indexing. It will also positively affect the Search Engine Optimization community, which will develop best practices for building content and RIAs utilizing Adobe Flash technologies, and enhance the ability to find and monetize SWF content.

    Why is Adobe doing this?

    The openly published SWF specification describes the file format used to deliver rich applications and interactive content via Adobe Flash Player, which is installed on more than 98 percent of Internet-connected computers. Although search engines already index static text and links within SWF files, RIAs and dynamic web content have been generally difficult to fully expose to search engines because of their changing states—a problem also inherent in other RIA technologies.

    Until now it has been extremely challenging to search the millions of RIAs and dynamic content on the web, so we are leading the charge in improving search of content that runs in Adobe Flash Player. We are initially working with Google and Yahoo! to significantly improve search of this rich content on the web, and we intend to broaden the availability of this capability to benefit all content publishers, developers, and end users.

    Which versions of the SWF file format will benefit from this improved indexing and searching?

    This solution works with all existing SWF content, across all versions of the SWF file format.

    What do content owners and developers need to do to their SWF content to benefit from improved search results?

    Content owners and developers do not have to do anything to the millions of deployed SWF files to make them more searchable. Existing SWF content is now searchable using Google search, and in the future Yahoo! Search, dramatically improving the relevance of RIAs and rich media experiences that run in Adobe Flash Player. As with HTML content, best practices will emerge over time for creating SWF content that is more optimized for search engine rankings.

    What technology has Adobe contributed to this effort?

    Adobe has provided Flash Player technology to Google and Yahoo! that allows their search spiders to navigate through a live SWF application as if they were virtual users. The Flash Player technology, optimized for search spiders, runs a SWF file similarly to how the file would run in Adobe Flash Player in the browser, yet it returns all of the text and links that occur at any state of the application back to the search spider, which then appears in search results to the end user.

    How are Google and Yahoo! using the Adobe Flash technology?

    Google is using the Adobe Flash Player technology now and Yahoo! also expects to deliver improved web search capabilities for SWF applications in a future update to Yahoo! Search. Google uses the Adobe Flash Player technology to run SWF content for their search engines to crawl and provide the logic that chooses how to walk through a SWF. All of the extracted information is indexed for relevance according to Google and Yahoo!'s algorithms. The end result is SWF content adding to the searchable information of the web page that hosts the SWF content, thus giving users more information from the web to search through.

    When will the improved SWF searching solutions go live?

    Google has already begun to roll out Adobe Flash Player technology incorporated into its search engine. With Adobe's help, Google can now better read the SWF content on sites, which will help users find more relevant information when conducting searches. As a result, millions of pre-existing RIAs and dynamic web experiences that utilize Adobe Flash technology, including content that loads at runtime, are immediately searchable without the need for companies and developers to alter it. Yahoo! is committed to supporting webmaster needs with plans to support searchable SWF and is working with Adobe to determine the best possible implementation.

    How will this announcement benefit the average user/consumers?

    Consumers will use industry leading search engines, Google now and Yahoo! Search in the future, exactly as they do today. Indexed SWF files will add more data to what the search engine knows about the page in which it's embedded, which will open up more relevant content to users, and could cause pages to appear at a higher ranking level in applicable search results. As a result, millions of pre-existing rich media experiences created with Adobe Flash technology will be immediately searchable without the need for companies and developers to alter content.

    When will the new results register on Google?

    Google is using the optimized Adobe Flash Player technology now, so users will immediately see improved search results. As Google spiders index more SWF content, search results will continue to get better.

    How will this announcement benefit SWF content producers?

    Organizations can now dramatically improve the rich web experiences they deliver to customers and partners by increasing the use of Adobe Flash technology, which is no longer impeding the ability for users to find those experiences in highly relevant search results. RIA creators and other web content producers can now be confident that their rich media and RIA experiences leveraging Adobe Flash technology are fully searchable by users around the globe who use the dominant search engines. Furthermore, the ability to index information extracted throughout the various states of dynamic SWF applications reduces the need to produce an HTML or XHTML backup for the RIA site as a workaround for prior search limitations.

    Does this affect the searchability of video that runs in Adobe Flash Player?

    This initial rollout is to improve the search of dynamic text and links in rich content created with Adobe Flash technology. A SWF that has both video and text may be more easily found by improved SWF search.

    Will Adobe Flex applications now be more easily found by Google search, including those that access remote data?

    Yes, any type of SWF content including Adobe Flex applications and SWF created by Adobe Flash authoring will benefit from improved indexing and search results. The improved SWF search also includes the capability to load and access remote data like XML calls and loaded SWFs.

    Does Adobe recommend a specific process for deep-linking into a SWF RIA?

    Deep-linking, in the case of SWF content and RIAs, is when there is a direct link to a specific state of the application or rich content. A variety of solutions exist today that can be used for deep-linking SWF content and RIAs. It's important that sites make use of deep links so that links coming into a site will drive relevance to the specific parts of an application.

    To generate URLs at runtime that reflect the specific state of SWF content or RIA, developers can use Adobe Flex components that will update the location bar of a browser window with the information that is needed to reconstruct the state of the application.

    For complex sites that have a finite number of entry points, you can highlight the specific URLs to a search spider using techniques such as site map XML files. Even for sites that use a single SWF, you can create multiple HTML files that provide different variables to the SWF and start your application at the correct subsection. By creating multiple entry points, you can get the benefits of a site that is indexed as a suite of pages but still only need to manage one copy of your application. For more information on deep-linking best practices, visit www.sitemaps.org/faq.php.

    Is Adobe planning on providing this capability to other search vendors too?

    Adobe wants to help make all SWF content more easily searchable. As we roll out the solution with Google and Yahoo!, we are also exploring ways to make the technology more broadly available.

    Where to go from here

    For for more information from Google on SWF search, read Improved Flash indexing on the Official Google Webmaster Central Blog.

    .NET vs. Java Consumer SDK - BusinessObjects Enterprise

    The Java and .NET versions of the consumer SDK are identical in functionality. The two versions of the SDK are generated from a common set of Web Service Definition Language (WSDL) files. As a result, they possess identical class names and inheritance patterns. There are differences between the two, however, that are addressed in this section.

    Note:    For more information on the Platform Web Services WSDL, see Using the WSDL instead of the consumer API.

    Organization of plugin classes

    It is the goal of this SDK to provide the same organizational structure of plugin classes as provided in the traditional, non-web services Enterprise SDK.

    In Java, classes are organized in packages where the name of the plugin is part of the package. For example, the CrystalReport class is located in the com.businessobjects.enterprise.crystalreport package, while the Folder class is located in the com.businessobjects.enterprise.folder package.

    In .NET, classes are organized in namespaces based on its plugin type. There are separate namespaces for destination, authentication, desktop, and encylopedia plugin classes. For example, both the CrystalReport and Folder classes are desktop plugins, so they are located in the BusinessObjects.DSWS.BIPlatform.Desktop namespace.

    There is also a separate namespace for system rights in .NET.

    Representation of class properties

    WSDL class properties are generated differently in Java and .NET. In Java, properties are generated as getX and setX methods, where X is the name of the property. In .NET, properties are generated as fields.

    In this guide, the term "property" refers to both the class method in Java and its field equivalent in .NET.

    Capitalization of method names

    In Java, method names begin with a lowercase character. In .NET, method names begin with an uppercase character.

    In this guide, the convention is to refer to a method by its Java case.


    December 28

    Marketing ClickStream Dashboard Example

    Many times, I am brought in to help develop KPI's for an organization. When it comes to the Marketing subject area, I find myself getting most excited by the clickstream data, an often overlooked yet rich source of correlative opportunity for the bold and analytical minds that seem to not exist within the core team itself. While marketing practitioners are some of the most adapt at doing it, I believe they either do not realize themselves to be doing it or more often, the company stigmatizes them as non-analytical, sales oriented as opposed to the true data analysts that they are. After all, didn't Market Research originate out of Marketing, which tend to house the company's statisticians? Here is a sample dashboard for measuring Marketing Efficacy.
     
    November 17

    Graphical Representation of the Process Towards Business Intelligence Enlightenment

    It all begins with an idea...Brain functionwhether an idea that came to you or one which is derived on a senior executive's whim, all business intelligence initiatives start with a single thought: how can I drive more data into our decision making and business processes in order to drive better more accurate decisions for the business, thus enabling world class operations and growth potential. Whew - that was a mouthful. In all reality, let this graphical representation flow as organically as the thought I am trying to emphasize here - BI is a thought process and is a human relative need - So, we, as technologists need to start building software applications that meet that germanely simple conceptual need - to create software that not only improves my efficiencies at home or at work but that marries those efficiencies into human adaptive and behavioral neurological processes. When synapsis' fire in ones brain, and neurological circuitry moves to pass one synapsis into another cortex from an origination point, one can visualize how to tie this metaphor into the systems we use everyday - Take the process of searching the Internet using your favorite search engine. We enter key words or metadata tags that represent nouns, verbs or contextual fragments that represent natural neural processing of the human brain. If search engines were constructed, likewise, BI systems, to more mirror this reflexive neural network within their enterprise application architecture, one might find more usefulness in the long run in terms of end user adoption and sustainment of said adoption after the 1st year after implementation. Let this pictorial represent that behavior marriage between BI technologies and human neural networks.
    americanredmanasianblueladyasianbluelady2asianredladyasianredlady2Atombluelightbulbrealbluerthinkerbrainiconbritishcurrencywomanbrownlightbulbboardroomiconbrownlightbulbboardroomicon2currencywomanthinkingman2Enlightenmentyellownativewoman2enlightmentasakeyboardkeylightbulbeyebrows furrowed icongreeniconthinkericonblack2yellownativewomaniconblackchairbrownlady for thoughtlady stares off in distinceladyformultaladyondockmacman for thoughtmanawayfromcrowdpensivelightbulbglobesmanicon2manpensivegraphicolderthinkerPenandPaperPensive Thinkerpensiveyellowiconphotothinkerpostcardlightbulbpostcardlightbulb2redthinkingmanbluethoughtbubblethoughtcloud2synapsisthreepurplebluepeopleThinkergraphicyellowwomanWavefunctionstatuethinkerbirdthinker2twopurplebluepeopleyellow and blue man icontwopurplebluepeople2yellow and blue man icon2toeducatetypefontthingingstatuewavefunction of  universes cosmology stephen hawking
    November 07

    Increasing Business Value vs. Insights Provided - a Business Intelligence Roadmap

     

    While many companies feel they have strong BI programs, most, in my experience, have operational reporting systems and sometimes, if you are lucky, they also have strategies that go with those systems or even better, are driving those systems (fueled by requirements gleaned from business needs and actual usage scenarios vs. the "way it has always been done/reported on").

    As you can see in figure 1, that level merely tells you the 'WHAT' - it doesn't answer the 'WHY' it happened (root cause), or predict the 'HOW' it might affect you in future, nor the 'WHEN' in terms of monitoring if it is happening currently or just a past event.

    image

     

    Your BI roadmap should have a similar long term plan. If you want to provide increasing value to your organization, one must get out of the business of operational reporting and move towards the real meat and value of BI, which lay in the analysis, monitoring and predicting in terms of how the business views their needs from BI, not how BI believes they can deliver information.

    Capturing Metrics and Their Measurements - A Data Quality Perspective

     

    The techniques that exist within the organization for collecting, presenting, and validating metrics must be evaluated in preparation for automating selected repeatable processes.

    Cataloging existing measurements and qualifying their relevance helps to filter out processes that do not provide business value as well as reducing potential duplication of effort in measuring and monitoring of critical data quality metrics. Surviving

    measurements of relevant metrics are to be collected and presented in a hierarchical manner within a scorecard, reflecting the ways that individual metrics roll up into higher level characterizations of compliance with expectations while allowing for drill-down to isolate the source of specific issues.

    As is shown in Figure 1, collecting the measurements for a data quality scorecard would incorporate:

    1. Standardizing business processes for automatically populating selected metrics into a common repository

    2. Collecting requirements for an appropriate level of design for a data model for capturing data quality metrics

    3. Standardizing a reporting template for reporting and presenting data quality metrics

    4. Automating the extraction of metric data from the repository

    5. Automating the population of the reporting and presentation template, or a data quality scorecard


     

    Figure 1:

    DQ Process
    September 17

    Dimensional World - Understanding Modeling Techniques and Approaches

     

    As a data architect, I am often amazed at how many with the same title really do not understand the core differences between dimensional model structures in my industry.

    In fact, it is a rarity to find the data architect willing to be challenged without personalities coming into the mix. As as we all know, when you fight the person and not the problem, you end up with hurt feelings and resentments in the workplace. For an EDW, this can lead to people resigned and not willing to stand up for what they think, which leads to the 'sheep'-like syndrome called 'Group Think', thus resulting in an EDW that is built off of emotion and not educated beliefs or best practices.

    I thought I would take the time to explain some of the differences between dimensions to enable you, reader, to stand up for the correct approach when you are faced with a contended data model designed by you.

    Remember, they are not attacking you, just the model. Look at it as a chance to grow and learn from others. Maybe, just maybe, having 4 or 6 eyes is better than just your 2 and your model, already attributed to you from a recognition perspective, will be that much better.

    Here we go:

    Slowly Changing Dimensions (SCD - of the Type II variety is where I become a Type II gal)

    • What in the world is a SCD anyway?
    • Ralph Kimball defined this his 1996 book as the following:

    (Kimball, 1996), a slowly changing dimension is a dimension table in which a new row is created each time the underlying component entity changes some important characteristic. Its purpose is to record the state of the dimension entity at the time each transaction took place.

    This concept is hard for for those who have primarily dealt with changes as handled in operational systems: no matter how a customer changes, we want to ensure that we have only one customer row in the customer table.

    Thus each row in a slowly changing dimension does not correspond to a different entity but a different “state” of that entity—a “snapshot” of the entity at a point in time.

    To create a slowly changing dimension table, the following design steps are required:

     

    • Define which attributes of the dimension entity need to be tracked over time. This defines the conditions for creating each new dimensional instance.
    • Generalize the key of the dimensional table to enable tracking of state changes. Usually this involves adding a version number to the original key of the dimension table.

    Apart from the generalized key, the structure of the slowly changing dimension is the same as the original dimension. However, insertion and update processes for the table will need to be modified significantly.

    dimesions Splitting Dimensions: “Tiny-Dimensions”
    In practice, dimension tables often consist of millions of rows, making them unmanageable for browsing purposes. To address this issue, the most heavily used attributes (e.g., demographic fields for customer dimensions) may be separated into a mini-dimension table. This can improve performance significantly for the most common queries. The mini-dimension should contain a subset of attributes that can be efficiently browsed. As a rule of thumb, there should be fewer than 100,000 combinations of attribute values in a mini-dimension (i.e., fewer than 100,000 rows) to facilitate efficient browsing (Kimball, 1996). The number of attribute value combinations in a tiny dimension can be limited by:

    • Including attributes in the mini-dimension that have discrete values (i.e., whose underlying domains consist of a fixed set of values).
    • Grouping continuously valued attributes into “bands.” For example, age could be converted to a set of discrete ranges such as child (0-17), young (18-29), adult (30-45), mature (45-64), and senior (65+).

     Figure 4. Mini-Dimensional Table (Detailed Level Design)

    Figure 4 shows how customer demographics in the Order Item star could be stratified out into a mini-dimension table. Some of the attributes in the original table have been transformed to reduce the number of rows in the mini-dimension table: 

  • # Employees and Revenue have been converted to ranges.

  • Date of First Order has been converted to Years of Service, reducing the number of combinations to years' multiples rather than all dates combos that are possible.

    Rule of Thumb:

    Rather than create a lot of very small dimension tables, these may be combined into a single dimension, with each row representing a valid combination of values. As a rule of thumb, there should be no more than seven dimensions in each star schema to ensure that it is cognitively manageable in size (following the “seven, plus or minus two” principle).

    Dealing with Non-Hierarchical Data

    A major source of complexity in dimensional modeling is dealing with non-hierarchically structured data.

    Dimensional models assume an underlying hierarchical structure and therefore exclude data that is naturally non-hierarchical.

    So what do we do if important decision-making data is stored in the form of many-to-many relationships? In this section, we describe how to handle some particular types of non-hierarchical structures that commonly occur in practice:

    1. Many-to-many relationships: these define network structures among entities, and cause major headaches in dimensional modeling because they occur so frequently in ER models.
    2. Recursive relationships: these represent “hidden” hierarchies, in which the levels of the hierarchy are represented in data instances rather than the data structure.
    3. Generalization hierarchies: subtypes and supertypes require special handling in dimensional modeling, because of the issue of optional attributes. These represent hierarchies at the meta-data level only—data instances are not hierarchically related to each other so they cannot be treated as hierarchies for dimensional modeling purposes.

    First, #1:

    1. Many-To-Many Relationships
      Many-to-many relationships cause major headaches in dimensional modeling for two reasons. Firstly, they define network structures and therefore do not fit the hierarchical structure of a dimensional model. Secondly, they occur very commonly in practice. Here we consider three types of many-to-many relationships which commonly occur in practice:
      • Time-dependent (history) relationships
      • Generic (multiple role) relationships
      • Multi-valued dependencies (“true” many-tomany relationships)

      To include such relationships in a dimensional model generally requires converting them to one-to-many (hierarchical) relationships.

      Type 1. Time-Dependent (Historical) Relationships
      A special type of many-to-many relationship that occurs commonly in data warehousing applications is one which records the history of a single-valued relationship or attribute over time. That is, the attribute or relationship has only one value at a specific point in time, but has multiple values over time. For example, suppose that the history of employee positions is maintained in the example data model. As shown in Figure 5, the many-to-many relationship which results (Employee Position History) breaks the hierarchical chain and Position Type can no longer be collapsed into its associated component entity (Employee).

      timedependenethiuerarch

      Figure 5. Time-Dependent (Historical) Relationship

      There are two ways to handle this situation:

      • Ignore history: Convert the historical relationship to a “point in time” relationship, which records the current value of the relationship or attribute. In the example, this would mean converting Employee Position History to a one-to-many relationship between Employee and Position Type, which records the employee’s current position. Position Type can then be collapsed into the Employee entity, and the Employee dimension will record the employee’s current position (i.e., at the time of the query). The history of previous positions (including their position at the time of the order) will be lost. A disadvantage of this solution is that it may result in (apparently) inconsistent results to queries about past events.
      • Slowly changing dimension: Define Employee as a slowly changing dimension and create a new instance in the Employee dimension table when an employee changes position. This means that Position Type becomes single valued with respect to Employee, since each instance in the Employee table now represents a snapshot at a point in time, and an employee can only have one position at a point in time. Position Type can again be collapsed into the Employee dimension. The difference between this and the previous solution is that the position recorded in the dimension table is the employee’s position at the time of the order, not at the time of the query.

      Type 2. Generic (Multiple Role) Relationships
      Another situation that commonly occurs in practice is when a many-to-many relationship is used to represent a fixed number of different types of relationships between the same two entities. These correspond to different roles that an entity may play in relation to another entity. For example, in the example data model, an employee may have a number of possible roles in an order:

      • They may receive the order
      • They may approve the order
      • They may dispatch the order

      figure6genericmultiplerolerelationships This may be represented in an ER model as a many-to-many relationship with a “role type” entity used to distinguish between the different types of relationships (Figure 6).

      Figure 6. Generic (Multiple Role) Relationship converted to Specific Relationships

      The intersection entity between Employee and Order means that Employee cannot be considered as a component of the Order transaction, and therefore orders cannot be analyzed by employee characteristics. To convert such a structure to dimensional form, the different types of relationships or roles represented by the generic relationship need to be factored out into separate one-to-many relationships (Figure 6). Once this is done, Employee becomes a component of the Order transaction, and can form a dimension in the resulting star schema.

      Type 3. Multi-Valued Dependency (True Many-To-Many Relationship)
      The final type of many-to-many relationship is when a true multi-valued dependency (MVD) exists between two entities: that is, when many entities of one type can be associated in the same type of relationship with many entities of another type at a single point in time. For example, in Figure 7, each customer may be involved in multiple industries. The intersection entity Customer Industry “breaks” the hierarchical chain and the industry hierarchy cannot be collapsed into the Customer component entity.

      muiltivaluedfigure7

      Figure 7. Multi-Valued Dependency (MVD)

      One way of handling this is to convert the Customer Industry relationship to a 1:M relationship, by identifying the main or “principal” industry for each customer.

      While each customer may be involved in many industries, there will generally be one industry in which they are primarily involved (e.g., earn most of their revenue). This converts the relationship into a one-to-many relationship, which means it can then be collapsed into the Customer table (Figure 8). Manual conversion effort may be required to identify which is the main industry if this is not recorded in the underlying production system.

      figure 8_conversion MM to 1M

      Figure 8. Conversion of Many-To-Many Relationships to One-To-Many Recursive Relationships

       

       

      Second, #2 from above:


    2. Recursive Relationships

      Hierarchies are commonly represented in ER models using recursive relationships. Using a recursive relationship, the levels of the hierarchy are represented as data instances rather than as entities. More flexible for sure...However, such structures are less useful in a data warehousing environment, as they reduce understandability to end users and increase complexity of queries.

      In converting an ER model to dimensional form, recursive relationships must be converted to explicit hierarchies, with each level shown as a separate entity. To convert this to dimensional form, each row in the Industry Classification Type entity becomes a separate entity. Once this is done, the levels of the hierarchy (which become classification entities) can be easily collapsed to form dimensions.

      conversionrecursaivetoexplicithierarchy For example, the industry classification hierarchy in the example data model may be shown in ER form as a recursive relationship (Figure 9).

      Figure 9. Conversion of Recursive Relationship to Explicit Hierarchy

       

       

       

      Lastly, #3 from above:


    3. Generalization Hierarchies: Subtypes and Supertypes
      In the simplest case, supertype/subtype relationships can be converted to dimensional form by merging the subtypes into the supertype and creating a “type” entity to distinguish between them. This can then be converted to a dimensional model in a straightforward manner as it forms a simple (two level) hierarchy. This will result in a dimension table with optional attributes for each subtype. This is the recommended approach when there are a relatively small number of subtype specific attributes and/or relationships. In the more complex case—when there are many subtype-specific attributes and when different transaction-entity attributes are applicable for different subtypes—separate dimensional models may need to be created for the supertype and each of the subtypes. These are called heterogeneous star schemas, and are the dimensional equivalent of subtypes and supertypes. In general, this will result in n+1 star schemas, where n is the number of subtypes (see Figure 10):

      figure10hetereogenrstarchema

      Figure 10. Heterogeneous Star Schemas ("Dimensional Subtyping")

       

      • One Core Star Schema (“dimensional supertype”): This consists of a core fact table, a core dimension table plus other (non-subtyped) dimension tables. The core dimension table will contain all attributes of the supertype, while the core fact table will contain transaction attributes (facts) that are common to all subtypes.
      • Multiple Custom Star Schemas (“dimensional subtypes”): A separate Customer Star Schema should be optionally created for each subtype in the underlying ER model. Each custom star schema will consist of a custom fact table, a custom dimension table plus other (non-subtyped) dimension tables.
      • Each custom dimension table will contain all common attributes plus attributes specific to that subtype. The custom fact table will contain all common facts plus facts applicable only to that subtype.

  • Dimensional Structures: A Look Into the Outliers that Often Get Overlooked When Designing Data Structures

     

    Think Star Schema is the only way to go with your EDW? Think again...StarFlake is a Best in Breed Approach that Might Make BI on top of the EDW that much more capable and robust.  Read on... I will cover the following concepts:

     

  • Alternative dimensional structures: snowflake schemas and starflake schemas
  • Slowly changing dimensions
  • Mini-dimensions
  • Heterogeneous star schemas (dimensional subtypes)
  • Dealing with non–hierarchically structured data in the underlying ER model:
    - Many-to-many relationships
    - Recursive relationships
    - Subtypes and supertypes

    snowflake

    Figure 1: Snowflake (the anti-lord of all things good in the data world)

    Kimball (1996) argues that “snowflaking” is undesirable because it adds unnecessary complexity, reduces query performance, and doesn’t substantially reduce storage space.

    However, performance impact of snowflaking depends on the DBMS / OLAP structures in place.  Advantages of the snowflake : explicitly shows the hierarchical structure of each dimension, which can help in understanding how the data can be analyzed.

    Thus, whether a snowflake or a star schema is used at the physical level, views should be used to enable the user to see the structure of each dimension as required.

    Being a star schema girl myself, I am quite interested in the power of the starflake model and thus being a starflake girl <she is reminded of the Tori Amos song 'Cornflake Girl' with this reference>.

     starflake

    Figure 2: Starflake model

    A starflake schema is a star schema in which shared hierarchical segments are separated out into sub-dimension tables. These represent “highest common factors” between dimensions. A starflake schema is formed by collapsing classification entities from the top of each hierarchy until they reach either a branch entity or a component entity. If a branch entity is reached, a subdimension table is formed. Collapsing then begins again after the branch entity. When a component entity is reached, a dimension table is formed.

     

     

    Dimensional Design Trade-Offs

    The alternative dimensional structures considered here represent different trade-offs between complexity and redundancy:

    • The star schema is the simplest structure, as contains the least number of tables—eight tables in the example. However, it also has the highest level of data redundancy, as the dimension tables all violate third normal form (3NF). This maximizes understanding and simplifies queries to pairwise joins between tables.
    • The snowflake schema has the most complex structure and consists of more than five times many tables as the star schema representation (41 in the example). This will require multitable joins to satisfy queries.
    • The starflake schema has a slightly more complex structure than the star schema—nine tables in the example. However, while it has redundancy within each table (the dimension tables and sub-dimension tables all violate 3NF), redundancy between dimensions is eliminated, thus reducing the possibility of inconsistency between them. All of these structures are semantically equivalent: they all contain the same data and support the same set of queries. As a result, views may be used to construct any of these structures from any other.

     

  • September 16

    Bottom's Up Data Mart and Enterprise Data Warehouse Project Implementation Plan

    4dimofmodeling

    SUMMARY: In my consulting practice, I recommend an incremental, 'bottom-up' implementation methodology, similar to that advocated by Ralph Kimball. This has proven to be a successful deployment approach to ensure a short-term return on investment with minimal project risk, while still delivering a data warehousing architecture that provides a standardized, enterprise wide view of information. This column describes a typical project plan based on a bottom-up implementation methodology.

    * REQUIREMENT FOR BOTTOM-UP DEVELOPMENT

    I receive numerous e-mails from both technical and business managers who have become extremely frustrated by the inordinate amount of time and effort required to build data warehouses using traditional, top-down development techniques. Due to the large amount of effort required up front to perform user interviews and enterprise data modeling, organizations using top-down techniques often wait 12 to 14 months to get any return on investment. In some cases, managers complain that they have worked with a systems integrator on a top-down development project for over two years without obtaining any solution to their business problem.

    As described in previous articles, a bottom-up development approach directly addresses the need for a rapid solution of the business problem, at low cost and low risk. A typical requirement is to develop an operational data mart for a specific business area in 90 days, and develop subsequent data marts in 60 to 90 days each. The bottom-up approach meets these requirements without compromising the technical integrity of the data warehousing solution. Data marts are constructed within a long-term enterprise data warehousing architecture, and the development effort is strictly controlled through the use of logical data modeling techniques and integration of all components of the architecture with central meta data.

    * PROJECT PLAN

    The representative project plan described below is based on an incremental, 'bottom-up' implementation methodology. In my experience, this has been the most successful deployment approach to ensure a short-term return on investment with minimal project risk, while still delivering a data warehousing architecture that provides a standardized, enterprise-wide view of information.

    The project plan breaks down into three major phases, as follows:

    1. Data Warehouse Requirements and Architecture - gather user requirements through a series of requirements interviews, assess the current IT architecture and infrastructure, along with current and long-range reporting requirements, and develop an enterprise data warehousing framework that will provide maximum flexibility, generality and responsiveness to change. Define functional requirements for the initial data mart within the enterprise architecture. Optionally, conduct a Proof-of-Concept demonstration to select enterprise-class ETL and/or BI tools.

    2. Implement Initial Data Mart under the New Architecture - prove the new architecture works by implementing a fully operational data mart for a selected subject area within a 90-day time box.

    3. Develop Additional Data Marts under the New Architecture - on a phased basis, develop additional architected data marts within the new framework.

    Timeboxes are placed around each phase of the project plan to strictly limit the duration of the development effort. Phase 1 (specification of architecture and functional requirements) is limited to four weeks. If proof-of-concept testing of ETL and BI tool is conducted, these tests occur outside the timebox for Phase 1, due to the uncertain timing of scheduling vendors to perform the tests. Phase 2 (development of initial data mart) is limited to 90 days. Phase 3 (development of additional data marts) is limited to 60 to 90 days for each subsequent data mart.

    * TASKS AND DELIVERABLES BY PHASE

    The list below summarizes representative tasks, timeframe, and deliverables for each of these three phases.

    **Phase / Task
    1. Requirements and Architecture
    ---Conduct workshop to review/define strategic business drivers, review current application architecture, and define strategic data warehousing architecture.
    ---Elapsed Week :1
    ---Deliverables: strategic requirements, document specifying the recommended long-term enterprise data warehousing architecture

    ---Conduct requirements interviews with personnel from multiple subject areas and document the results of the interviews.
    ---Elapsed Week: 1
    ---Deliverables: Interview summaries, requirements inventory

    ---Conduct workshop to define functional specifications of initial data mart,
    ---Elapsed Weeks: 2
    ---Deliverables: scope statement, reporting and analysis specifications

    ---Develop high-level dimensional data model for initial data mart
    ---Elapsed Weeks: 2
    ---Deliverables: logical data model

    ---Conduct workshop to prepare for a Proof-of-Concept test of leading ETL tool(s)
    ---Elapsed Weeks: 3
    ---Deliverables: specifications for the ETL POC

    ---Conduct workshop to prepare for a Proof-of-Concept test of leading BI tool(s)
    ---Elapsed Weeks: 3
    ---Deliverables: Specifications for the BI POC

    ---Conduct workshop to develop Phase 2 project plan
    ---Elapsed Weeks: 4
    ---Deliverables: Phase 2 project plan

    **Phase / Task
    2. Implement Initial Data Mart in 90-Day Time-Box,
    ---Elapsed Weeks: 12
    ---Deliverables: live architected data mart, live OLAP cubes and reports, central meta data repository, local meta data repository, reusable ETL objects and conformed dimensions

    **Phase / Task
    3. Implement Additional Data Marts
    ---Elapsed Weeks: 8-12 each
    ---Deliverables: Additional architected data marts

    * PHASE 1 IMPLEMENTATION

    The initial task in Phase 1 is to conduct two on-site workshops, limited to 1 to 2 days each. The function of the first workshop is to bring all members of the development team up-to-speed on alternative enterprise data warehousing architectures and 'best practices' in data warehousing. The second workshop is used to achieve consensus on the specification of an enterprise data warehousing architecture capable of meeting the long-term business requirements of the organization.

    Interviews with personnel from multiple subject areas are held to define high-level functional requirements for each subject area. Subject areas often correlate with proposed data marts, in areas such as finance, sales, marketing, HR, supply-chain management, customer touchpoints, etc. As described in a previous column, the interviews are kept deliberately short (one day or less per subject area). The deliverables from each interview include a short, concise requirement specification for the subject area and a top-level dimensional data model representing the data sources, source-to-target mappings, target database, and reports required for a specific subject area. The top-level data models from all subject areas are then synthesized to identify common data sources, conformed dimensions and facts, common transformations and aggregates, etc.

    Following synthesis of functional requirements from all subject areas, a workshop is held to define the functional requirements for the initial data mart, lay out the project plan for the development of the initial data mart, identify required skill sets, and personnel assignments to the project.

    The next task is to define a high-level dimensional data model for the initial data mart, representing an expansion of the model prepared as part of the user interview process.

    If the organization has decided to conduct a proof-of-concept test of competitive ETL tools and BI tools, the next two tasks represent preparation of functional specifications for the tests. Proof-of-concept testing may be required if multiple ETL or BI tools are being evaluated and it is politically expedient to conduct rigorous testing of competitive products prior to making a selection. I have found that an intensive two-day workshop is sufficient to specify the functionality of the tests to be conducted for a proof of concept for either an ETL or BI tool.

    The final task in Phase 1 is to specify a detailed project plan for the implementation of the initial data mart.

    * PHASE 2 IMPLEMENTATION

    In the recommended bottom-up development methodology, the process of implementing the initial data mart is limited to 90 calendar days. Although 90 days is arbitrary, it fits the needs of business managers for a rapid solution of the business problem and meets the needs of CFOs for a 90-day Return-On-Investment. The 90-day timebox starts on the day that the ETL tool, the target DBMS, and the BI tool are successfully installed. To meet the challenge of a 90-day implementation process, utilization of an ETL tool, rather than hand-coding the extractions and transformations, is strongly recommended.

    Implementation of the initial and subsequent data marts is ideally performed by a small team of data warehousing professionals, typically consisting of a data modeling specialist, an ETL specialist, and a BI tool specialist. In my own organization, I emphasize cross-training of personnel, which minimizes the number of personnel that need to be assigned to a project and maximizes their efficiency.

    The first task for the development team is to design the target data base for the initial data mart. Modeling of the target data base for the initial data mart proceeds through three steps: design of an entity-relationship diagram, then a logical dimensional model, and finally a physical model of the target database schema. Although the E-R diagram is not required for the initial data mart, it is required for subsequent data marts to ensure that all physical data models for multiple data marts are derived from a common logical specification.

    The next major task is to specify and implement data mapping, extraction, transformation, and data cleansing rules. The data mapping and transformation rules are defined first in natural language, and then implemented using only the transformation objects supplied with the ETL tool. The objective is to avoid coding any ETL processes. It is hard to predict how long this task will take. For many applications, specification and implementation of the transformation rules should not take more than 3 to 4 weeks. However, some applications may require many months to specify and implement complex transformations. These applications are not likely to fit within a 90-day implementation timebox.

    In parallel with implementation of the transformation logic, developers build aggregation, summarization, partition, and distribution functions. The ETL tool may be used to compute aggregates in one pass of the source data, using incremental aggregation techniques. Pre-computed aggregates are recommended for most data warehousing applications to provide rapid response to predictable queries, reports, and analysis.

    The final task in Phase 2 is delivery of a fully operational, architected data mart for the initial subject area, using an exact subset of the enterprise data warehousing architecture. Ideally, the development team delivers all of the functionality that was specified at the beginning of the 90-day timebox. However, the team is permitted to defer low priority functions in order to make the 90-day timebox. The team is self-managed and organizes its resources to deliver as much functionality as possible within the 90-day development window.

    * PHASE 3 IMPLEMENTATION

    The objective of Phase 3 is to build additional architected data marts. Additional data marts are built by the primary development team using common templates and components, such as conformed dimensions and facts, common transformation objects, data models, central meta data definitions, etc.

    In the bottom-up methodology, a central data warehouse, an operational data store, and a persistent staging file are optional. Data marts are typically developed using a data warehousing backplane schema design, as described by Ralph Kimball in his book 'The Data Warehouse Toolkit, Second Edition.' There may be good technical reasons to incorporate a central data warehouse and an operational data store in the enterprise data warehousing architecture. However, in the bottom-up methodology, development of the central data warehouse and ODS are deferred until they are clearly required. A central data warehouse is often required and when detailed, atomic data from multiple data marts must be accessed to generate cross-business reports, and when there is a low percentage of conformed dimensions across the data marts.

    Maintenance and administration of the data warehousing application is an ongoing function. A secondary team may be used to enhance and maintain completed data marts. The primary team transfers transformation templates, data models, conformed dimensions, conformed facts, meta data, etc. to the secondary team to simplify the enhancement and administration of completed data marts.

    My organization has used this methodology successfully for many clients and has a good deal of experience with it. However, successful implementation of the methodology depends on several critical success factors:
    -a dedicated implementation team;
    -consulting help from an experienced organization at the beginning of the project;
    -backing of a business manager who is hungry for a solution to a painful business problem; and
    -integration of all components of the architecture with central meta data.

    To go Logical or Not...That is the Question?!

     

    bimart Figure 1: Basic star schema for typical point of sale data-mart

    In the current design, the database does not enforce the integrity of data with respect to the definition of the fact tables. The basic fact table should contain rows only for daily sales for a store for all the products sold in a day. If we try to insert an aggregated record in the basic fact table (for week, district and brand), the database would not reject the rows. If we like to separate the fact tables according to the grain, then we would have to rely on the ETL process to enforce the granularity of the fact table. Enforcing rules through ETL process has following drawbacks:

     

       

      

    • ETL processes need to persist the metadata for populating the fact table in the first figure and the aggregated fact from the 2nd figure. 
    • Multiple ETL processes may be responsible for populating the fact table. In such cases, we would need to duplicate the rules to each process. By maintaining rules (business logic) in the database layer, we can minimize maintenance headaches because the logic is now centrally located making change aforethought and less prone to mistakes.
    • ETL processes may not be efficient to enforce rules if the process relies on SQL to enforce the rules. Database integrity constraints are more efficient than SQL.
    • If the ETL process relies on a programming language, then it would be very difficult to maintain the meta data in the ETL process.

    Let us see how the design would change when we partition the dimension table to enforce the granularity of the fact and aggregate table. If we partition the dimension table based on the level of the data in the hierarchy, then we can use these partitioned dimension tables to join with the appropriate fact table. Figure 2 illustrates how the data model will look in the partitioned dimension table approach.

    Partitioned Data mart Figure 2: Constraint Enforced Point of Sale Mart

    In the new design, the basic fact table joins with the basic dimension tables and the aggregate fact table joins with the higher-level dimension tables. In this design, the granularity of the fact table is enforced by the relational constraint defined in the database. We can use SQL to create a view over all partitioned dimension tables using SQL union all to create a logical design that is similar to the basic POS data mart as described in Figure 1. We can also create views over the basic fact table and aggregated fact table to have one fact view with multiple grain, but this depends on how the data modeler wants to present the logical model.

    August 17

    TDWI Executive Summit World Conference San Diego, 2008 - It's On...


    Video: TDWI World Conference 2008 - Sunday, August 18, 2008 Pre-Conference HighlightsTonight, formally starts the Executive Summit portion of the Data Warehouse Institute (TDWI) World Conference 2008, in sunny San Diego...(See @lauragibbons on Twitter for hotel pics).
    Check back often for clips and interviews with the masters of business intelligence, including (hopefully) Bill Baker and Wayne Eckerson (formerly Microsoft and TDWI, respectively). I am speaking on Tuesday on Six Sigma / Process Intelligence, the marriage of BI and Process Excellence and Six Sigma.
     
     
     

    Click in This Working Xcelius Impressions Model

    Office 2007 XML Topics of Interest

    Loading...Loading...

    Social Networking - Topics of Interest

    Loading...Loading...
    Lean Six Sigma For Service
    Lean Six Sigma Pocket Guide
    Six Sigma for Dummies
    Call Center Forecasting & Scheduling...
    Call Center Management on Fast Forward
    Call Center Technology Demystified
    Just my opinion folks, and please feel free to suggest others to add
    Photo 1 of 31

    Got LinkedIn?

    View Laura Edell Gibbons's profile on LinkedIn

    Got Twitter?


    Got FaceBook?

    Shameless SEO Plug

    Laura Edell Gibbons

    Laura Edell Gibbons

    Occupation
    Location
    Interests
    5'10 - roller blading, mountain biking, snowboarding, kite boarding, getting my chic- lit on vis a vie my fashionista-side, enjoying the outdoors (yes, even the fashion-sensed like camping and aren't high maintenance) -- relishing several Choo's and Blahnik's in my closet.

    Custom HTML

    No content has been added yet.

    Gartner Magic Quadrants

    Got Dilbert?

     

    Tweet TDWI NW


    Google Groups
    TDWI Northwest Chapter
    Visit this group

    PerformancePoint Insider Feed

    Loading...Loading...