There are many design methodologies that take these issues into consideration.  There are advantages and disadvantages to both traditional (and non-traditional) methodologies which I do not cover in this post.  My goal is to bring up points of view of why and when a data warehouse may or may  not be used.  What I would like to cover is:

• The Corporate Information Factory (CIF), based on the Inmon approach
• The Kimball Style of data warehousing
• BI using no data warehouse at all

Corporate Information Factory

The Corporate Information Factory methodology, in a nutshell, says there is no way of getting around this inevitable fact of the need for a data warehouse.  In order to have a successful and sustainable BI program, a data warehouse is needed.  Not only is it needed, it needs to be completely designed, built and populated prior to any further analysis or BI work can be done.  This is due to the nature of how business concepts are intertwined within each other necessitating the big picture view.  This style also views the architecture process more from the IT/data perspective compared to the business need point of view.

Kimball Methodology

The Kimball methodology of data warehouse design is not as structured and regimented as the Corporate Information Factory.  The Kimball data warehouse is the sum of its parts; meaning one area of the business could be designed, developed and deployed providing BI insight while other aspects of the business have not been discussed.  This concept will speed the development of the data warehouse compared to the CIF, but the underlying data warehouse can become much more complex as more and more is added to it along with the possibility of rework.  This style views the architecture process from the business needs point of view compared to the IT/data perspective.

No Data Warehouse?

What about not using a data warehouse?  In the new age of Data as a Service (DaaS), Master Data Management along with Service Oriented Architecture (SOA), why re-store data from disparate systems?  Why not store the metadata of where the data is found and attach the business logic to the SOA call?  This can be a very powerful way to gain insight into data.  The idea that the development of a data warehouse can be done without the data warehouse.  There are already tools that will do this.  One of them is Qlikview from Qliktech.  The basic premise behind this tool is to allow the user to develop the Transform and Load aspects of ETL (Extract Transform and Load) in memory to delivery very quick analytics in a solid visual manner.  This tool is not a methodology, but SOA could be used in a larger context with the same principles. This style views the architecture process as something the business could do, but IT does not have to do.

The idea that a data warehouse is necessary for a successful BI implementation is not necessarily true.  A data warehouse is not necessary to have analytics or provide a picture of the data you have.  I believe it is very questionable to say this process is sustainable to leverage every benefit for BI.  The very important aspect of BI that cannot be overcome by SOA, or in-memory analytic tools like Qlikview, is the entire reason the data warehouse first came about. 

The decision for building or not building a datawarehouse is all about the history of the data.  Not the history that is required by law to be kept like financial data or what in many cases is considered ‘facts’ in the Kimball style.  If this were the only history needed, a data warehouse would be less necessary.  The type of history that is important is the history that cannot be reproduced within the source systems.  This is the history of changes made that are not kept by the source system.  In many cases a customer’s address may not be historically important in a transactional/source system so only  the most current record is kept.  If that history is not kept somewhere (like a data warehouse), analytics of historical purchases of products will not show a true picture of what actually happened.  It will only show the picture of what is in the source system at the current point in time.  This situation is the quinticential lynchpinn for why a data warehouse should be necessary.  The ability to track and keep history that is not kept in the source system is something SOA, or in-memory BI is not capable of reproducing.

If the desired BI capability for the business is operational in nature, a data warehouse will not offer any significant benefit over SOA.  This is a short sighted tactical means of looking at data and cannot provide strategic insight, but it certainly could be the best way to answer that need for data given the circumstances.  This would not be the end-all-be-all for BI, but it certainly can provide means to start a program.

So does this completely answer the question “Is a data warehouse necessary for BI?”  The data warehouse is necessary for a complete and sustainable BI program, but it does not have to be the start of the program.  So… of course the answer to that is still…. “It depends…”

… Doug

The main entities of Data Vault are Hub, Link and Satellite.

HUB Entity (HUB_): This is a defining entity. It contains a unique list of business keys. These are the keys that businesses utilize in everyday operations. For example, employee number, SSN number, Product Code. So the attributes of HUB are:

• Surrogate Key – This is a Primary Key of hub and holds 1-to-1 relationship with the Business Keys.
• Business Key – This is a Primary Key of the source system. This can be a composite key. ETL checks this key’s existence in the hub table and inserts one if it doesn’t exist.
• Load Date Time – The datetime of the key / record when it was first loaded into the table.
• Record Source – The name of the source the record originated from. This is useful for data traceability.
• Record Begin Date Time – The datetime when the record became active in the source (if available) or the datetime when ETL has been run.
• Record End Date Time – The datetime when the record is closed. This can only be detected if the logical deletes are supplied or derived in some manner.

LINK Entity (LINK_): LINKS are constructed once all the HUBS are identified. Links are relationship entities.  These are the physical representation of m-to-m 3NF relationship. It represents the relationship or transaction between hubs. The link table contains the unique list of relationships between hub keys. When a relationship arrives, it simply gets loaded into the table if doesn’t exist. Typically, the link tables translate into fact tables in the datamart access layer. For example, the link between employee number and the project number. The other attributes of LINK are:

• Surrogate Key – This is a Primary Key of the table and is useful when a link contains more than two hub keys as composite key might cause performance problems. This is also
  useful when the granularity of the link changes (a hub key is added) or history needs to be maintained on the relationships.
• Hub Key 1 to Hub Key N – The surrogate keys from the hub tables that are involved in the relationship.
• Load Date Time- The datetime when the record was loaded into the table.
• Record Source – The source system name from where the record or relationship was loaded from.

SAT Entity (SAT_): SATS holds descriptive information about the hub keys or the relationships. The satellite is most closely resembles Type 2 Dimension. When the data changes, a delta record is inserted into the table and if the certain columns changes faster than others then these can be split into two different tables to avoid data replication. For example, employee details such as employee name, address, phone number, email address in the satellite off of hub  or time spent by an employee on a certain project in satellite off of LINK that stores the relationship between an employees and projects. The other attributes of SAT are:

• Hub or Link Surrogate Key from HUB or LINK table. This is part of the primary key.
• Load Date Time – The datetime when the record was inserted into the table. This is part of the primary key.
• Surrogate Key – This is optional. It is useful when satellites have multiple values such as multiple home addresses.
• Record Source – The name of the source.
• Record Begin Date Time – The datetime when the record became active in the source (if known) or the datetime when ETL has been run.
• Record End Date Time – The datetime when the record is closed.

And stand-alone tables such as calendars, time, code and description tables may be used.

Below is a snippet of a Data Vault Model housing borrowers who have taken out Student Loans:

Modeling Rules for Each Part of the Entity:

FOR HUBS:

• Hubs keys cannot migrate into other hubs (no parent/child like HUBS).
• Hubs must be connected through links.
• More than two hubs can be connected through links.
• Surrogate keys may be used.
• Business keys are 1 to 1 relationship with surrogate keys.
• Hubs primary keys always migrate outward.
• Hub business keys and primary keys never change.
• If a hub has two or more satellites, then a point-in-time table can be built for ease of joins.
• An ‘UNKNOWN’ business key record can be inserted into Hub that can be used to tie other data in links and sats that has no business keys in source. This kind of data is usually a bad/incomplete source data.

FOR LINKS:

• Links can be connected to other links.
• Links must have atleast two hubs associated with them in order to instantiated.
• Surrogate keys may be used.
• The combination of surrogate business keys made a unique key.
• Does not contain descriptive data.
• Does not contain begin and end dates.

FOR SATS:

• Satellites may be connected to hubs or links.
• Have 1 and only 1 parent table.
• Satellites always contain either a load date-time stamp, or a numeric reference to a stand-alone load date-time sequence table.
• Primary key is a combination of ‘surrogate key’ from either hub or link and the load datetime stamp.
• Surrogate keys may not be used.
• Must have a Load End Date to indicate when the CHANGE to the data set has occurred.
• Satellites are always delta driven. Duplicate rows should not appear.
• Data is separated into satellite structures based on 1) type of information 2) rate of change.

DV model utilize bits of both 3^rd Normal Form and Dimension Modeling concepts.  This approach has made the model simple, flexible, expandable, adaptable and consistent.

• Adapted many-to-many physical relationship structure from 3NF that became a LINK table.
• The LINK table is also similar to factless fact in Start Schema.
• Adapted the notion of 1 to 1 (business key to surrogate key) tracking from dimensional modeling (type 1 dimension).
• Adapted the notion of “data over time in a separate table/structure” from dimensional modeling (type 2 dimension). This resulted in a SAT table however it is fundamentally
  different, in that it is a child dependent table, whereas the dimension is a parent table to the facts.

This is it for now. In next post(s) we will look into some examples which will show how Data Vault technique overcomes the limitations of 3NF and Dimensional Model structures when applied as an Enterprise Data Warehouse.

- Jyothi

Source: tdan.com, danlinstedt.com

BI systems need DATA and every business has terabytes of real data which can provide them with the information and knowledge they need to make the right decisions on time. But the key is to turn that data into information in a timely, efficient and effective manner once the WHAT AND WHY questions are answered i.e., what information is needed, what matters and why that is required.  In today’s market, every business is in a RACE. The race to conquer others. The race to generate more gains/profits. The race to foresee the risks early on so that they can be avoided.  So time is of the essence here.

An optimized BI system integrates large volume of external and internal near real time data to allow management to create opportunities by making intelligent decisions after performing predictive analysis of their approach on the business. A good BI System is like a GPS. An effective GPS is one that not only shows you a route to your destination but also guides you when you hit roadblock, gives up-to-date external conditions (constructions / traffic) information, provides multiple routes to choose from, suggests you with alternatives for shorter and fastest routes, predict the total time based on your driving behavior, tells you what to expect next etc. Just knowing the path to your destination is not sufficient. You need to know many other factors during the whole ride to reach destination on time and without any hurdles.

For a good integrated BI system, a good Data warehouse architecture needs to be in place.  Data warehouse architecture is “an integrated set of products that enable the extraction and transformation of operational data to be loaded into a database for end-user analysis and reporting”. Below are the pictorial representations of different “flavors” of DW architectures.

Methodologies used by different architecture:

Kimball’s DW Architecture – Is based on ‘Bottom-UP’ methodology.

Inmon’s DW Architecture – Is based on ‘Top-Down’ methodology.

Dan Lindstedt’s Data Vault DW Architecture – Is based on ‘HYBRID DESIGN’

The first two design methods have some limitations for Data Warehouse layer such as inflexibility and unresponsiveness to the changing departmental needs during the implementation phase, insufficient auditability of data back to its source system, inability to integrate unstructured data, inability to rapidly respond to changes (organizational changes, new ERP implementations) or difficult to load type 2 dimensions in real time. This is where DATA VAULT came in to rescue. Data Vault follows a ‘HYBRID DESIGN’ methodology which follows ‘TOP-DOWN ARCHITECTURE WITH A BOTTOM-UP DESIGN’.

The model is a mix of normalized modeling components with type 2 dimensional properties. In this model, the DW serves as a backend system that houses historical data which is integrated by the business keys. All data ‘good, bad, incomplete’ gets loaded into the data vault and all the cleansing and application of business rules takes place downstream i.e., out of DW. This means that Data Vault model is geared to be strictly a data warehouse layer, not as a data delivery layer which still requires physical or Virtual star schemas or cubes for Business Users or BI tools to access.

Bill Inmon in 2008 stated that the “Data Vault is the optimal approach for modeling the EDW in the DW2.0 framework.”

In Part 2 and 3, I am going to explain different components of Data Vault and it’s power with the help of some examples.  That will clearly explains why the Data Vault should be a preferred “flavor” for different businesses.

- Jyothi Kaparthi

The first and probably most important non-technical differentiated aspect of iStream is the concept of Alignment.  Many consulting organizations and internal IT organizations have some type of design or planning step often called “Envisioning” as an initial step in their development process.  This is for good reason:  understanding the customer’s end goal or picture of success is critical to the success of the project.  At the same time, this does not procedurally support the fact that many individuals are involved in determining the success of a project, and further, in most cases these individuals are not in detailed agreement in regards to what that success looks like, or how it is defined.  Alignment takes this into account, and is a prescribed process to ensure a common understanding of the success criteria by the key stakeholders involved in any enterprise project, including department heads and/or the Information Technology department.  This includes a focus on ensuring that a miscommunication cannot occur where language is not specific enough, for example in clarifying the accepted definition of the term “Sales” in a company.  To explore this a bit, is “Sales” the number of transactions? The dollar volume closed?  Over what timeframe? By what channel? (sales people, resellers, distributors, telesales, etc.) As simple as this concept may sound – misunderstandings or assumptions in areas as simple as this are generally a key reason for project failure.  In this area, LÛCRUM is unique and differentiated in its development approach.

Another key differentiation of LÛCRUM’s approach, particularly as it relates to Business Intelligence, is in the concept of the iteration of a project.  The iStream methodology allows for iteration in the development of the end result, particularly through the recognition that many pieces may make up the whole.  For example, related to Business Intelligence; we may begin by working with an individual decision maker, say the VP of Marketing.  In working with this person we may offer to them the YourView Instant Analytics solution, allowing them to rapidly see their information in a new way through the combination of several different reports or sources into a single view.  Per the YourView solution, this can take place in a matter of days; however by definition it follows the iStream process – however abbreviated – as it is focused on only a single user.  When that VP is prepared to create a complete solution for the Marketing department, the initial work now functions as a pilot/proof of concept rolling into the Alignment, Discover and Architect components of iStream for the larger YourView 360 (Data Mart) project.  In this fashion, we are “iterating” our development of the data mart through one or more “Instant Analytics” projects.  Both projects follow iStream; however the smaller engagements feed into the larger.  When that organization is prepared to roll out an Enterprise Data Warehouse – the same holds true, the work that had been completed at the Data Mart level for the Marketing department will now be employed in the Alignment, Discover and Architect phases of the Enterprise Data Warehouse project.  In this fashion the work that we accomplish at any level of the Business Intelligence Solution chain is applicable for the next, and all would be accomplished using iStream.

While the items above are not descriptive of the entirety of iStream, nor of the entire list of benefits of the LÛCRUM approach, they are absolutely two of the components of iStream which differentiate it from the plethora of SDLC approaches available in the market, and another aspect of what makes LÛCRUM a unique Business Intelligence Consultancy.

To get at the data that most executives feel they need to make accurate decisions, many turn to the manual modification of existing reports, or the creation of their own “Pet” spreadsheet they use almost daily, or certainly many times a week. 

 In an update to a report cited last spring on this site, a September, 2009 Dartmouth University study suggests that the error rates in formulas on spreadsheets in their study were only .087% of all formulas they audited.  HOWEVER, these were in cases where the formula produced the WRONG RESULT, and actually resulted in 87% OF THE SPREADSHEETS REVIEWED having errors in which the spreadsheet then produced the wrong result. 

How good is good enough?  What if you could reproduce the “Pet” spreadsheet in a true Business Intelligence solution which would ensure that the data and results in the sheet were as solid as the data in your transactional systems in the first place?  How much does the wrong data or the wrong decision cost you, or your company?  I would argue that “good enough” might just be good enough, if you could ensure that the data was accurate, and mitigated the possibility of error, while increasing the timeliness of the information to the decision maker.  We have deployed such systems in a couple weeks’ time leveraging tools like SharePoint, Excel, and other software products that our customers already owned, and quickly delivered a system to our customer where we dramatically increased the accuracy of their information.  These solutions form the basis of our iterative approach to Business Intelligence.

No not the song… There is a story that the IT people like to tell, not sure if it is true but I love it so well…sorry Jimmy B.  It goes something like this.

A manufacturing company with a complex assembly line had a machine break down on them.  The machine was critical in the production of their products, yet try as they might to fix it themselves, they just could not keep it running 24×7.  Pridefully, the plant manager didn’t want to admit that his team couldn’t solve the problem, but he knew that soon enough the company’s product yield would be impacted and someone way above his pay grade would notice.  Time to call an expert.

The following week, the expert arrives at the plant.  The plant manager escorted him to the offending machine.  The expert set down his briefcase and began to ask a few questions of the plant manager and the line supervisor.  He then walked around the machine, climbed up the maintenance ladder looking around.  Climbing back down the ladder, he asked the line supervisor if he had a hammer.  The supervisor looked at him sideways and said, “well, uh, yea, I got one.”  So the supervisor went to his toolbox, retrieved a well worn ball-peen hammer and handed it to the expert.  The expert climbed back up the maintenance ladder and leaned over the side of the ladder to reach the broken machine.  He swing the hammer down sharply with a loud “bang”.  Instantly, the machine began to whir, the indicator panel on the side of the machine lit up with all green lights and production was running again!

The plant manager and line supervisor thanked the expert for his help to which the expert replied that he’d send his invoice for services later that week.

The invoice arrived on the plant manager’s desk and when he opened it the invoice contained a single line item for services.

1. Repair of Machine…………………………………………………………………………………………………….$10,000.00

The plant manager was not happy.  He thought to himself, “How in the world can that guy charge me ten grand for swinging a hammer?”  He immediately called the expert and asked him for a detailed invoice.  The expert told him he’d send out another invoice immediately.  Two days later the invoice arrived.  The plant manager tore open the envelope.  The invoice read:

1. Use of Hammer………………………………………………………………………………………………………..……….$1.00
2. Knowing where to strike hammer………………………………………………………………………………$9,999.00

Isn’t this story much like business today when it comes to knowledge? Many companies are now measuring their enterprise data storage in petabytes.   Yet with all that data, they still struggle to answer questions such as—Who’s my most profitable customer? Or, Who’s my most in-need customer? Or, which customer is likely to leave for my competition?  How can I increase my business?  Where should I focus my efforts?  The answers are very likely embedded deep in the data stores of the company but the decision makers can’t get the answers they need, when they need them, how they need them, and how to apply the answers.  And therefore they aren’t getting the knowledge they need.   They have the “hammers” but they aren’t helping.  Enter Business Intelligence.  Sure, BI has been around for a long time, but it’s evolving just as today’s businesses are.   In today’s world, you need more than data.  You need more than information.  What you need is knowledge.  The fluid, meaningful, applicable evolution of data that allows you to “fix your broken machine”.   BI is your answer to unlocking the knowledge you need.

If you’re asking yourself important questions to which you have no answers, might be time to call the expert.

From an IT perspective, there are a lot of differences between these definitions throughout the years.  At the same time, how do they really differ from a business executive viewpoint?   Are the decisions in business being made today differ significantly from decisions that were made yesterday?  Does the thinking process differ from an analytical viewpoint?  Does having more data mean that you can make better decisions?  Are decision-makers better off with all of the data that is available?   How does the business executive think about “business intelligence” from an information viewpoint?

Here’s a three-part “Maslow’s Triangle” layered model to think about Business Intelligence from a business perspective.

1.  How’s Business?

First, at the base of the triangle, you have to ask “How’s Business?”   This layer really emphasizes “time over periods” of transactions.    Traditionally, this area is termed “transactional reporting” and simply put, is giving the user their numerical tabulation of data at the end of a period.   What would a business person define as “Best in Class” in this area?   Give me my reports as near-time as possible for the period that I am looking at and be able to sub-category my different business lines, product lines, financial divisions, etc.  Most of the data could be described as the data from “double-entry bookkeeping systems.”  With today’s ERP-style systems, this kind of information is fairly accessible as long as you are dependent on internal data only.   Some data feeds may be external feeds or internal non-structured data sources that still have the same timeframe.  Examples would include “customer satisfaction” data, quality data, and other operational inputs.

For example:

“What is the revenue over the last quarter?”

“How many X was sold in the last week?”

“What is the profit for the month?”

2.  Why?

The next layer up the triangle is simply put “Why?”   Why did the business’ Eastern Region have a 5% increase in sales year over year?  Why did we miss our numbers in the last week of the quarter?  Why did our market share grow in our mature product line in the last 2 quarters?

3.  What If?

The last layer of the triangle is “What If?”   If one can receive their business results from “How’s Business” and then is able to determine “Why” the business performed in this fashion, the “What If?” pinnacle of the triangle will provide a roadmap for the decision-maker to model their potential decisions that they have in mind.

For example, if one knows their financial performance and also sees where the business over-achieved and where it under-achieved, it is able to move resources of the business (management & money) to the area of need.  Whether the strategy is to provide more or less resource is up to the person involved.   The numbers themselves are not going to make the decision.

So, then is “Business Intelligence” an oversold phrase in the world of Information Technology? A “Qualified Yes” and a “Qualified No.”   The challenge today is that the tools actually work and work well if the approach taken is right.   At the same time, recent publications and noted experts all agree that the road to Business Intelligence is cluttered with a lot of failed attempts, a lot of capital spend that isn’t going to be realized from an investment viewpoint, and a lot of disenfranchised users.

I’ll write about this dilemma in my next blog.

In this series of posts, I will discuss a number of these capabilities and will give some concrete examples of how to utilize them.

I will be using Excel 2007 for these examples.  Much of this functionality is also available in Excel 2005, it’s just not as easy to use and does not have some of the more advanced features.

Getting the Data
The first step in any effort is to get some data into Excel.  We’ll start out using a simple static list.  You probably already use lists like this regularly.  If you don’t utilize Excel in this way today, think of the reports that you work with from the various systems that you run your organization with.  In most cases, you could probably either copy andhttp://thefuturevalueofbusiness.com/wp-admin/post.php?action=edit&post=745&message=6 paste or import these reports into Excel to get some data to work with.

In future posts, we’ll cover a much more powerful method of acquiring data by connecting to external databases from within Excel.  For now though, we’ll stick with this simple example.

I’ll be working with the sample database that comes with Microsoft’s SQL Server database software.  This sample database contains information about a fictitious company called Adventure Works.  Below, you can see that I have an extract of order information that I’ve pasted into Excel.

This is the most common manner in which people utilize Excel for reporting purposes: simple lists of data pasted or imported from other sources.  In most situations, this data comes from existing reports or queries.  My example above is a very simple query…you can see that we don’t even have names or descriptions for most of the data.  For example, Column F is showing us the Product ID instead of the Product Name.

The best way to solve this problem is to have the author of the report or query modify it to include the Product Name in addition to the Product ID.  Let’s imagine that this is not a realistic option though; there is a way that we can solve this problem using an extremely powerful Excel formula called VLOOKUP.

Using VLOOKUP

To expand on our situation above, let’s imagine that I have a second worksheet in my Excel workbook.  I have an image of this second sheet below.

The Product ID in column A corresponds to the Product ID in column F on the Orders List.  We are going to use VLOOKUP to take the Product ID in the orders list and lookup the Product Name in the product list.

To make the formulas a little more understandable, I am going to rename the Sheet with the order list “Orders” and I am going to rename the Sheet with the products list “Products”.

On the “Orders” sheet, let’s insert a column immediately to the right of the Product ID.  We’ll label it “Product Desc” in Row 1.  In Row 2, we’ll enter the VLOOKUP formula:

The parameters (the information between the parentheses) tell Excel how to lookup the value we want:

• The first parameter, “F2”, tells Excel what value we are performing the lookup for.  In this case, we are looking up the Product ID.
• The second parameter, “Products!A:B”, tells Excel where to go to do the lookup.  Here I selected the first 2 entire columns on the “Products” sheet.
• The third parameter, “2”, tells Excel to bring back the data in column 2 from the lookup list when it finds a match for the value from cell F2.  I know that’s a confusing sentence at best, but it will make sense in a moment.
• The last parameter, “FALSE”, tells Excel that we want it to return only an exact match for the value we are looking for.  If Excel cannot find an exact match for the Product ID, it will return an error indicator.

The Results
Now, let’s take a look at the results of our formula.  The screenshot below shows what I have now.

This screenshot shows a few rows from the “Products” sheet:

Hopefully you can see how VLOOKUP works now.  Excel took the value in F2 in the “Orders” sheet, 776.  It went to the first column of the range we gave it; that range was Columns A and B of the “Products” sheet.  It scanned through that range until it found a match for 776.  It then took the value in the 2^nd column of the range, column B, in the same row and returned the value in that cell (“Mountain-100 Black, 42”).

One thing I didn’t make clear before that I want to point out now.  VLOOKUP is always going to look in the first column of the lookup range for the matching value.  In our example, the lookup range was columns A and B of the “Products” sheet, so Excel looked in column A for the matching value.  There is no way to tell the formula to look anywhere other than the first column; so you either need to cut and paste the columns to get the right one first, or just change the reference so the lookup column is first.

To complete our list, we can just fill down the VLOOKUP formula in column G to the bottom of our orders list.  Now we can analyze our order data with actual Product Names instead of just Product IDs.

Summary
VLOOKUP is useful in many other situations…you can probably imagine a few other uses for it yourself.  It is very handy to use it as we did in this example though.  Even though we could have accomplished the same goal by having someone in IT modify the query or report, now you can be a little more self sufficient with your reporting needs.

In my next post, I’ll cover a few more features like filtering and date manipulation.  Ultimately, we’ll move on to Pivot Tables and External Queries which provide very powerful mechanisms for analyzing data and can compete with some features offered in expensive reporting software.

The whole experience reminded me of what it’s like to be in the operational side of the business requesting services from IT. Think about the SNL sketch with Nick Burns the Help Desk guy.  He speaks a language that his customers don’t understand and then treats them like they are stupid for not getting it.  The customers eyes glaze over thinking, “so…um…ok… how will you fix my problem?”

Is your IT department speaking your language?  If not, then how will they ever help you to solve your business problems?  Chances are they don’t understand you either.  Bridging the gap takes a skilled interpreter who can understand both.  Your best BI architects do this and don’t try to explain ETL, Dimensional Models or ODS to you…cuz really…do you care how it works if it answers your questions and helps to make sense of your data.