Module 2 Reivew

Module two covered a lot of ground - all focused on tracking performance, understanding and making decisions within an organization. The data used was all internal to an organization. Governing these action is the Date Warehouse Design Cycle which is used to translate the Online Transaction Processing (OLTP) systems to the Online Analytical Processing (OLAP) system(s). This process involves the extraction, transformation and loading of the data from disparate source systems - like an ERP or CRM - into a single data warehouse. This allows for the organization to agree upon definitions of terms and for the data quality to be checked.  Before the data warehouse can be populated it has be to be designed which we learned about the star schema to design. A star schema is made up of a fact table with dimension tables. The facts represent business measures and the dimensions represent the grain.

Creating a star schema should reflect the business events the company wants to track and make decisions about. This is done using a four-step dimensional modeling process. The steps are (1) selecting the business process to model, (2) declare the grain of the business process, (3) choose dimensions that apply to each fact row, and (4) identify the number facts.

I've spent my professional career with OLTP type databases. The data is normalized as much as possible with minimal duplication of data. As we began reading about and designing star schemas it felt wrong - there were more efficient ways of doing it! In the class readings, Ralph Kimball and Margy Ross mention several times that it's a natural instinct to normalize but there's not enough savings to merit the extra effort it would cause users. As I read more and focused on the purpose of this database - not real time for the purpose of a transaction in the moment but for analysis for trends, direction, and performance it started to change my perspective on the need for data warehouses. Data warehouses don't mean the data is significantly lagging behind - it can be updated in any cadence but it's not the production system - like a point of sales system. Data warehouses aren't meant for the programmers but for the end user. The end user knows how to run reports but the underlying structure is optimized for those reports.

Let's be honest though - I'm still more comfortable with a normalized, OLTP database but this module really helped me see the importance of the data warehouse.

The beginning of the module focused on the balanced scorecard which really took me until the end of the module to understand why. Interestingly, the day before I listened to the lecture on the balanced scorecard my company introduced one for the first time. It was replacing a program that had been in use for 3 years to help us make commitments and ensure our execution was aligned with the strategy. No one ever felt that program was effective. As a Systems Integration Engineer I can tell you how I directly impact revenue and profitability. Unfortunately, my impact is often delayed - I will have an impact in a year or two - my work rarely impacts the current year. Instead of focusing on projects that had strategic value in the medium to long term we were asked to do what felt like busy work, in addition to our day jobs, to show impact that year. We were promised something new this year that would better track our progress. So the scorecard was unveiled. None of us had any idea what it meant. As this article from the Harvard Business School "Why Strategy Execution Unravels - and What to Do About it" indicates though - alignment doesn't always mean success. The balanced scorecard has the organization focus on all the areas indicating success. Now, just having a scorecard won't bring you success but it's a good way to track measurement. If you don't seem improvement or sufficient improvement it can be an early warning system some part of the execution plan is off. Which leads back to big data and data warehouses and how they help answer strategic questions.

An organization amasses so much data on a daily basis and it’s a gold mine for analysis but data is only as useful as its quality. You must be able to access the data, terms must be consistent, and the data quality has to be good. If all of this is in place, which the ETL process is supposed to make happen, now the executives have a treasure trove of data to draw from to keep track of company progress and to make course corrections along the way. Without good data the scorecard stops being an accurate picture of company success. Without the scorecard, or other strategic requirements for data, the data warehouse has little merit. All of these efforts are to support and help organizations receive a competitive edge.

Citations

Sull, Donald, Rebecca Homkes, and Charles Sull. 'Why Strategy Execution Unravels - And What To Do About It'. Harvard Business Review 2015: Web. 14 Feb. 2015.