Why is Business Intelligence innovation so slow?

[ This was originally posted on an old blog: Why is Business Intelligence innovation so slow? ]

You might have gathered that I'm a big fan of Business Intelligence. The potential that it has to impact a business is incredible (and largely unrealized - but that's another post).

I'm also a big fan of innovation. I had subscriptions to Popular Science and Omni as a kid (can you tell?) and now I get my fix for innovation thinking from the Killer Innovations podcast.

The point is that I've been wondering why the pace of innovation is slow in Business Intelligence.

One reason could be entrenchment. Classical BI/DW projects have been so costly and so complicated that the solutions, once delivered, have an incredibly high level of entrenchment. After all, the business thinks, now that we've spent so much on this solution we need squeeze every last bit of value out of it. I see this in action across all the elements of the solution.

How many BI "shops" do you know that have changed from, say, Oracle to SQL Server of from Cognos to BusinessObjects. I honestly don't know of any significant examples of an established shop switching (maybe a couple of instances of DW appliances being added on top). It seems that once the vendor is in it takes dynamite to get them out again.

This level of entrenchment is potentially extremely costly. If your vendor wants to double your "suport" fees or gouge you on additional licenses then you're pretty much forced to put up with it because you don't have an easy way out.

Another reason may be time. BI projects take time and lots of it. Kimball has taught us that successful BI projects are incremental and iterative (and big bang projects fail) but this implies a long term vision and the timescale to go with it. My hunch is that most shops aren't that receptive to "new and improved" tech when they're knee deep in the political quagmire half way through a project.

I could probably come up with more reasons... but (at the risk of repeating myself) I think it comes down to open standards and how thin they are in the BI space.

Sure we have ODBC, which is brilliant, but many key technologies don't use it, particularly if you're in a dedicated Oracle or SQL Server environment. For example, SQL Server Integration Services doesn't even give you the option to use ODBC against SQL Server databases (AFAIK). Meaning that you have to keep your warehouse on SQL Server of face up to the nightmare of re-writing all your ETL packages.

My plea to the vendors is this:

• implement open standards in your products  (this will help me trust you)
• make migration to your product easy, whatever it takes (or else I'll never change).

You (BI vendors) will have to take the risk of being the first to open up. You'll have to give me a good reason to move and proof that I can trust you. After all, most of the businesses who want BI now have it, so you future health depends on converting your competitor's customers into your customers (and surely that's cheaper than just buying your competitors!).

[ All of this reminds me that I need to do a post on open source BI. ]

The enterprise software business model is broken

[This was originally posted on an old blog: The enterprise software business model is broken ]

Andy asks whether enterprise software is finished. 

My view from the trenches is that the business model for enterprise software (and hardware…) is broken. They (particularly the BI guys) reportedly spend as much as 90% of their income on sales and marketing.

The number of sales people that I deal with at these companies is mind numbing. The number of reseller layers that get a cut of my license fees is shocking.

These companies could learn a huge lesson from the “web2.0″ upstarts by shortening their development cycles and moving their engineers out towards their customers. How do they know what needs to be improved, what needs to be simplified or what needs to be added? It certainly isn’t because I’ve told them.

What I really want are a set of building blocks that stack together nicely, use industry standards, can be interchanged if I’ not happy, can be managed by fewer (possibly better) people and can be consumedly easily across networks.

Is that too much to ask for?

BTW, my favourite example of getting this right is Netezza. I load my data into their box and my queries instantly run 1000x faster. It uses no proprietary SQL, has no indexes or tuning and I only need 1 DBA. Awesome.

Future post to come on this topic, but I think the market is looking for a complete solution that is relatively hardware and OS agnostic but does everything else. It also needs to come totally pre-configured with best practice set-ups. I'm not holding my breath.

The occupation of an Analyst

[ This was originally posted on an old blog: The occupation of an Analyst ]

This is the first instalment of my "book", as explained here. It’s a work in progress and your feedback would be a great help.

What is an Analyst? Recently it seems that every second job includes the term analyst.

When I was (briefly) at college, a friend had a mentor who would go on for hours (literally) about how devalued the term doctor had become. His premise was that there were too many people who were "officially" doctors of this or that but had just "cruised" through grad school and didn't deserve the accolade.

Now, 12 years later, I feel very much the same way about the title of Analyst. Everywhere I look in organisation charts I see people who are ostensibly employed as analysts. Sadly very few of these seem to actually do any analysis. Such as a Network Support Analyst who's job is correctly route the LAN cabling or a Helpdesk Analyst who's job is to deal with support calls to reset user passwords. Important jobs but not really analysts.

The occupation of an Analyst is to analyse. To paraphrase Webster's, analysis is the “resolution of anything into its constituent elements” or the creation of a “brief methodical illustration of the principles” of a subject.

For me, an Analyst seeks to:

• understand the present
  
  • by examining the past
    
    • in order to influence the future.

For instance a Psychoanalyst seeks to understand the patient’s mental state by examining how the patient’s past life experiences have influenced them so that the patient can improve that state in the future. A Business Analyst seeks to understand a business situation by examining how it has operated in the past so that new processes can be implemented to improve future operations.

If you can twist what you do into this framework then I salute you as a fellow analyst.

Now get back to work.

A book unwritten...

[ This was originally posted on an old blog: A book unwritten... ]

About a year ago, I wrote up the outline of a book I want to write about what it means to be an analyst and the difference between a good analyst and most analysts. ;-) You can see it below.

I want it to be a Tufte style book, very tightly written and driven by good examples. Basically practicing what it preaches.

Needless to say, it's gone pretty much unwritten, so in a Tony Robbins style of "chunking" it down into manageable parts, I'll try writing it here in very small pieces. Let's see how it goes...
The Occupation of an Analyst
Discerning the Truth from Trends, Lies and Politics.

The “why” of analysis.

• A brief history of analytic thought.
• The gap between facts and intuition.

The “what” of analysis.

• The occupation of an Analyst.
• The obligations of an Analyst

The “how” of analysis.

• The skills of critical thought.
• The skills of analytical calculation.
• The skills of meaningful presentation.

An Introduction to the Perfect Information blog

[ This was originally posted on an old blog: An Introduction to the Perfect Information blog ]

So the title is "Perfect Information"... Why? Perfect information means knowing everything that relates to a decision .

In economics (stick with me...), perfect competition can only exist when all parties are rational and have perfect information about their available alternatives. Of course, in the real world this never happens (outside of chess).

This blog is called Perfect Information because:

• I love it when information comes a little bit closer to being perfect.
• I love good information design.
• I love the way the internet is helping us come closer to having perfect information.
• I work in Business Intelligence and spend way too much time thinking about this stuff.

Thanks for visiting, y'all come back now!