Colin,

I have not ignored the opinions expressed by you or others; I have disagreed with them and explained the nature of my disagreement. You say that you “don’t like vendors being brought into the discussion again,” but a significant portion of your article involved stating a vendor’s position. The only difference is that I named the vendor, which is appropriate and adds to the discussion. No one should participate in discussions of this nature anonymously. People’s motivations should be taken into account when evaluating their arguments.

You say that my definition of BI is different from yours and outdated, but you haven’t provided your definition, nor did I provide a definition in my comments, so there’s no way of knowing if and how our definitions differ. I believe that the term BI was originally coined and promoted as a way to breathe new life into the data warehousing industry, which had grown stagnant. Although there is no consensus regarding the definition of “business intelligence,” which I believe is a problem, essentially I define it as “technologies, practices, and activities that enable businesses (and organizations of all types) to use information to achieve the level of understanding that’s needed to pursue their objectives based on intelligent decisions.” This is the focus of my work. Is my understanding of business intelligence antiquated? I assume that you and Claudia have coined the new term “decision intelligence” either because you feel that the term “business intelligence” lacks clarity or an emphasis on what’s needed, or that the BI industry has failed to deliver what’s needed, so its time to come up with a new term to push things in the right direction.

I’ve worked in the business intelligence industry for many years, just as you and Claudia have. I’ve grown frustrated with the degree to which, after all these years, this industry continues to throw technologies at customers that are often poorly designed, largely ineffective, and rarely provide people with the tools they need to make sense of data and therefore use it to achieve their goals. In the last few years, I’ve been encouraged by the efforts of a new breed of vendors that address this need. I cringe whenever I see a new product hit the market from the narrow technology-centric, human-ignorant mindset that does nothing to address the real needs that people who work with data face.

This discussion began after I critiqued LyzaSoft new product Lyza, exposing the fact that many of it’s marketing claims were false and that its attempts to provide data analysis and data visualization functionality, which were featured in their claims, were poorly designed and ineffective. At no point during the discussion that has since ensued has anyone responded to the substance of my claims by attempting to show how my assessment was incorrect. Instead, you and apparently LyzaSoft (based on the quotes that you included in your article) have argued that I should open myself to definitions of “data analysis” and “data visualization” that in my opinion rob these terms of all useful meaning by assigning to them every single activity that people engage in related to data. As I’ve said from the beginning, Lyza might do things that are useful and effective outside of the realm of data analysis and data visualization. For the sake of the folks who work at LyzaSoft and anyone who buys the product, I hope it does.

I responded to your article here in my blog to invite all who are interested to offer ideas and engage with one another around those ideas. You’ve suggested that you have fresh ideas about business intelligence (what you call “decision intelligence”) that relate to this discussion. I invite you to share them so I and others can respond.

I like your definition of data analysis as data sense-making, Stephen. I assume you don´t mean to exclude all kinds of data transformations from the task of data analysis. There are things you need to do to prepare data for analysis but I also think that data transformations sometimes are an integral part of the analysis. In fact one could argue that BI solutions sometimes do too much “preparation” of the data before it´s given to the analyst and that they thereby end up restricting the analyst and limit the kinds of questions that the analyst can ask. In that sense I think it is indeed difficult to “clearly delineate data transformation from data analysis” as Colin points out.

There are some interesting papers on sense-making in the human computer interaction literature. I am thinking in particular of a paper by Russell, Stefik, Pirolli and Card (The cost structure of sense-making. Proceedings of INTERCHI ’93; 1993 April 24-29; Amsterdam; the Netherlands. Amsterdam: IOS Press; 1993; 269-276.). The authors describe the process of sense-making as an iterative search for a representation of the problem, that reduces the information processing cost. Ideally you´d like to finally end up with a representation of the problem that makes the answer obvious. The authors argue that this view of sense-making has implications for the integrated design of user interfaces, representational tools and information retrieval systems.

I´ve noticed that tools that tries to provide an integrated user experience for both data retrieval and data representation fall into two broad classes:

1) Process-centric tools allow the analyst to manipulate a representation of the analysis process until she arrives at an output that produce a good results. This is the approach taken by tools such as Spotfire Miner, SPSS Clementine, SAS Enterprise Miner, Pipeline Pilot etc. It seems to me that Lyza falls into this camp as well. A benefit of the process-centric approach is that it´s self-documenting and it´s easy to see how the final process could be automated. The downside is that the UI is somewhat indirect. Instead of manipulating the data directly you are describing how data should be manipulated. This may appeal more to engineers and software programmers (a common programmer joke is that a programmer rather writes programs that writes programs that writes programs than writes programs) than to the business community at large although I haven´t seen any specific research to support this claim in the context of data analysis.

2) Data centric tools allow the analyst to manipulate representations of the data directly until she arrives at a conclusion. This is the approach taken by Spotfire Professional, Tableau, Excel etc. The benefit is that the analyst works on the problem more directly and the solution may be obvious when a well-designed tool is used. However the downside is that it is not always easy to see how you arrived at the end result.

Whatever the shortcomings are of the tools mentioned above it would be interesting to see which approach works best for what kinds of users and what kinds of analysis tasks. I´m not prepared to make a judgement one way or another yet, although I do suspect that the answer is going to be “it depends”.

Perhaps to use the word “definition” with respect to our views on BI was misleading. It’s just that throughout your blog reply you constantly use the word BI when you really mean data warehousing. You confuse the two terms which suggests you have this outdated view that BI and data warehousing are the same thing. They are not. The constant association of BI with data warehousing is why Claudia and I use the term decision intelligence instead. Our objective is to break the connection between BI and data warehousing and hope people such as yourself stop perpetuating this misconception.

I view you as specializing in visual data analysis. This is a combined subset of the separate fields of data analysis and data visualization, which have a much broader scope. I think not seeing this distinction is why you fail to see and understand where other folks such as me are coming from. I will write another blog on this. A good example here is the comment from Tobias which says, “I assume you don´t mean to exclude all kinds of data transformations from the task of data analysis.” The answer to this question is that you do exclude all forms of data transformation (in data preparation) from data analysis. This is one of the key areas where you and I disagree.

I also think another point Tobias made is also very important. He talked about process centric tools. This is a growing field of BI. One problem with your outdated view of BI is that data warehousing is primarily data centric. As we move toward the use of operational BI we need to have a more process centric view of our business. Data centric approaches don’t work in this environment. More on this to come. I hope I have added to the conversation. Colin.

I’m reminded by this discussion of the old, rather gruesome and probably very un-PC saying “there’s more than one way to skin a cat”! This particular cat has arguably been tortured to death, so I’ve been hesitating to add to its pain. But as “Blogger 3” in Colin’s article (www.b-eye-network.com/view/9336), the author of a white paper sponsored by Lyzasoft (see my own blog for details and reference http://www.b-eye-network.co.uk/blogs/devlin/) and one of the original “inventors” of data warehousing, I’d like to try to apply some healing balm to this long-suffering animal.
Harking back to Stephen’s original post in September, he used the phrase “a data analyst’s nightmare” in the title. While the debate since then has ranged far and wide into the possible meanings of data analysis, Business Intelligence, visualization, data integration and many other terms, I believe the key questions are: what do data analysts do and what do we believe they should do?
After more than 20 years of experience in what data analysts do, I suggest that the most accurate answer to the first question is: whatever they need to do in order to get results to the real business problems with which they’re faced. Their actions are driven by factors such as (1) data availability, cleanliness and consistency, or lack thereof, (2) their own personal way of seeing and processing information and (3) the tools available to them.
The first factor often determines the extent to which they see data cleansing and integration as part of data analysis. One of the original goals of data warehousing and BI was to reduce the cleansing and integration burden on data analysts. Over the years, I’ve learned that this goal can only ever be “mostly” achieved. Skilled and innovative data analysts can and do come up with very obscure and unexpected data sourcing needs.
With regard to the second factor, there are certainly any number of best practices that can be brought to bear on how to see and process information. Whether these best practices are all agreed and consistent with one another I leave to others who know that field better that I do. However, my experience is that there is much variability between data analysts in how they see and process information. Some are very visual and like to start from the overview. Others prefer to see detail and tabular information. Still others are process-oriented and -driven.
I believe that factors (1) and (2) lead directly to the conclusion that there is no single answer to the tooling needed by data analysts. Spreadsheets, although widely derided by the mainstream BI community, are used by data analysts because they do the job and they work in a way that has become familiar. Mining, OLAP, visualization and other tools are widely used by other data analysts and certainly have their strengths and weaknesses too. Furthermore, these two same factors lead businesses and their data analysts to choose the tool(s) that work for them.
Which leads to the second part of my question above: what do we (industry experts and consultants) believe data analysts should do? Of course, the question is bigger than data analysts, but, in general our role is to try to give independent and unbiased thought leadership in the wide and ill-defined field of Business Intelligence. Certainly, if marketers go overboard in their claims or commonly understood terms get stood on their heads, we need to make clear what’s happening. But we all have our own opinions and positions, and there is always more than one valid point of view (or way to skin a cat). We cannot hope to come down to one, single, agreed and unchanging set of definitions of the terms used in the industry. But we can all agree to respect the fact the one person’s “nightmare” may be another’s “dream”.
In the spirit of the day that’s in it – I wish you all a peaceful and joyous Christmas.
Barry.

At the risk of continuing a debate that has probably gone on too long already, I’d like to cautiously provide my own opinion. As Director of 2 overlapping yet distinct depts (BI and Analytics) my respective staffs are responsible for the end to end processes to get from raw data to analytical insight.

There are many steps involved, and we do them in this order:
1) Understanding Business Neeeds. (BI)
2) Translating that to table and schema layouts in the various disparate systems so we may instruct IT and the DBAs on how to setup the ETL process, the timings and frequencies, what latency to use when pulling the data, any formulas or filters to apply when moving the data to the data warehouse (BI).
3) Authoring reports to enable business users to get the data on demand from a single BI tool (BI).
4) Then the Analytics staff takes over. Their skill set overlaps the BI team’s somewhat, but they are more adept at working with large data sets (not the raw data, but the data from the warehouse).
5) They also understand visual best practices, and how to explore and iteratively analyze the datasets for outliers, trends, drivers, etc.
6) Finally they convey results and insights in brief analyses and narrative “white papers” with supportng graphs, to more senior Business users.

This, to me, represents the full lifecycle, from raw data to insight. The BI folks would take the process up to the point where the average business user could get tactical and operational info via reports on their own. The Analytics staff would proactively support strategy and Leadership with data easily obtained from BI’s efforts, the same data the average business users utilizes, but in aggregate, over a longer time frame, to identify issues in process, strategy, etc. To use an analogy, the typical users worry about getting their flight from NY to LA on time, with no lost luggage, etc. The more executive staff want to know if the NY to LA flight is profitable, whether to add additional flights, etc.

Lyzasoft would make life somewhat easier for the BI process described above in the short run, IF you had no formal BI team or BI toolset. But it would actually complicate matters over the long run. The last thing you want is a proliferation of spreadmarts, and it seems the product offers false theoretical rigor to those data manipulations by “documenting” transformations and combining of data.

I ultimately would really only want data transformations to be applied once, by a centralized team to ensure consistency, and in the ETL process or embedded in a calculation in my centralized BI tool, instead of in some new semantic layer of logic. Further, the root problems with doing stuff in Excel spreadmarts are not solved with Lyzasoft…you can still have too many incompetent hands in the soup…each sorting incorrectly, applying incorrect formulas, saving in the lower version of Excel and losing records past row 16,000, etc.

If you’re going to leverage your data right, you have to have staff whose core competency aligns with those I described above. Having some accountant or accounts payable clerk use a tool like Lyzasoft should not help anyone who relies on the output sleep any better at night. Sure it will document their errors, but how readily apparent will they be?

In conclusion, I’d like to use a famous American phrase: “thanks… but no thanks, on that bridge to nowhere”.