A bad workman blames his [Business Intelligence] tools

Tools
 
Introduction

This is a proverb with quite some history to it. Indeed its lineage has been traced to 13th Century France in: mauvés ovriers ne trovera ja bon hostill (les mauvais ouvriers ne trouveront jamais un bon outil being a rendition in more contemporary French). To me this timeless observation is applicable to present-day Business Intelligence projects. Browsing through on-line forums, it is all too typical to see discussions that start “What is the best BI software available on the market?”, “Who are the leaders in SaaS BI?” and (rather poignantly in my opinion) “Please help me to pick the best technology for a dashboard.” I feel that these are all rather missing the point. Before I explain why, I am going to offer another of my sporting analogies, which I believe is pertinent. Indeed sporting performace is an area to which the aphorism appearing in the title is frequently applied.

If you would like to skip the sporting analogy and cut to the chase, please click here.
 
 
The importance of having the right shoes

Rock climbing is a sport that certainly has its share of machismo; any climbing magazine or web-site will feature images of testosterone-infused youths whose improbable physiques (often displayed to full advantage by the de rigueur absence of any torso-encumbering clothing) propel them to the top of equally improbable climbs.

Given this, many commentators have noted the irony of climbing being conducted by people wearing the equivalent of rubber-covered ballet slippers. The fact that one of the most iconic rock climbing shoes of all time was a fetching shade of pink merely adds piquancy to this observation. Examples of these, the classic FiveTen Anasazi Lace-ups, are featured in the following photo of top British climber, Steve McClure (yes it is the right way up).

The UK's finest sport climer - Steve McClure - sports the Pink'uns

When I started rock climbing, my first pair of shoes were Zephyrs from Spanish climbing firm Boreal. They looked something like this:

The Zephyr by Boreal - $87 - £67
The Zephyr by Boreal - $87 - £67

Although it might not be apparent from the above image, these are intended to be comfortable shoes. Ones to be worn by more experienced climbers on long mountain days, or suitable for beginners, like myself at the time, on shorter climbs. Although not exactly cheap, they are not prohibitively expensive and the rubber on the soles is quite hard-wearing as well.

The Zephyrs worked well for me, but inevitably over time you begin to notice the shoes worn by better climbers at the crag or at the wall. You also cannot fail to miss the much sexier shoes worn by professional climbers in films, climbing magazine articles and (no coincidence here) advertisements. These other shoes also cost more (again no coincidence) and promise better performance. When you are looking to get better at something, it is tempting to take any advantage that you can get. Also, perhaps especially when you are looking to break into a new area, there is some pressure to conform, to look like the “in-crowd”, maybe even simply to distance yourself from the beginner that you were only a few months previously.

This is very shallow behaviour of course, but it is also the rock on which the advertising industry is founded. I wanted to get better as a climber, but would have to admit that other, less noble, motives also drove me to wanting to purchase new rock shoes.

The Galileo by FiveTen - $130 - £85
The Galileo by FiveTen - $130 - £85

The Galileos shown above are made by US company FiveTen and are representative of the type of shoes that I have worn for most my climbing career. FiveTen shoes have been worn by many top climbers over the years (though there have recently been some quite high-profile defections to start-up brand Evolv, who can never seem to decide whether to append a final ‘e’ to their name or not).

Amongst other things, FiveTens are noted for the stickiness of their rubber, which is provided by an organisation called Stealth Rubber and appears on no other rock climbing shoes. Generally the greater the adhesion between your foot and the rock, the greater the force that you can bring to bear on it to drive yourself upwards. Also it helps to have confidence that your foot has a good chance of staying in place, no matter how glassy the rock may be (and no matter how long the fall may be should this not happen). I have worn FiveTen shoes on all of my hardest climbs (none of which have actually been very hard in the grand scheme of things sad to say).

The Solution by La Sportiva - $155 - £120 (link goes to the Sportiva site)
The Solution by La Sportiva - $155 - £120
(the link loads a Flash page on the Sportiva site)

Nevertheless, with what I admit was rather a sense of guilt, I have recently embarked on a dalliance with another rock shoe manufacturer, La Sportiva of Italy. The Sportiva Solutions which are shown above are both the most expensive rock shoes I have ever owned and the most technical. If NASA made a rock shoe, they would probably not be a million miles away from the Solutions. The radical nature of their design can perhaps best be appreciated in three dimensions and you can do this by clicking on the above image.

The Solutions are very, very good rock shoes. I recently had the opportunity to carry out a before and after comparison on the following climb, A Miller’s Tale:

A Miller's Tale (V4/Font 6b+) - Rubicon Wall, Derbyshire, England
A Miller's Tale (V4/Font 6b+)
Rubicon Wall, Derbyshire, England
© http://77jenn.blogspot.com

My partner, who appears in the photo (incidentally sporting FiveTen shoes), climbed this on her second go. By contrast, I had many fruitless attempts wearing my own pair of FiveTens (that, to be fair to FiveTen, were much less technical than the Galileo’s above and were also probably past the end of their useful life). I frequently found my feet skittering off of the highly polished limestone, which resulted in me rapidly returning to terra firma.

A couple of weeks later, equipped with my shiny new Sportivas, my feet did not slip once. Of course the perfect end to this story would have been to say that I then climbed the problem (for an explanation of why some types of climbs are called problems see my earlier article Perseverance). Sadly, though I made much more progress during my second session, I need to go back to finally tick it off of my list.

So here surely is an example of the tool making a difference, or is it? My partner had climbed A Miller’s Tale quite happily without having the advantage of my new footwear. She is 5’3″ (160cm) compared to my 5’11” (180cm) and the taller you are the easier it is to reach the next hold. Strength is a factor in climbing and I am also stronger in absolute terms than she is. The reason that she succeeded where I failed is simply that she is a better climber than I am. It is an oft-repeated truism in the climbing world that many females have better techniques than men. This, together with the “unfair” advantage of smaller fingers, is the excuse often offered by muscle-bound men who fail to complete a climb that a female then dances her way up. However in my partner’s case, she is also very strong, with her power-to-weight ratio being the key factor. You don’t need to lift massive weights in climbing, just your own body.

So I didn’t really need better rock shoes to prevent my feet from slipping. If I got my body into a better balanced position, then this would have had the same impact. Equally, if my abdominal muscles were stronger, I could have squeezed my feet harder onto the rock, increasing their adhesion (this type of strength, known as core strength for obvious reasons, is crucial to progressing in many types of climbing). What the Solutions did was not to make me a better climber, but to make up for some of my inadequacies. In this way, by allowing me the luxury of not focussing on increasing my strength or improving my technique, you could even argue that they might be bad for my climbing in the long run. I probably protest too much in this last comment, but hopefully the reader can appreciate the point that I am trying to make.

Campus board training

In order to become a better climber I need to do lots of things. I need to strengthen the tendons in my fingers (or at least in nine of them as I ruptured the tendon in my right ring finger playing rugby years ago) so that I can hold on to smaller edges and grasp larger ones for longer. I need to develop my abdominal muscles to hold me onto the rock face better and put more pressure on my feet; particularly when the climb is overhanging. I need to build up muscles in my back, shoulders and arms to be able to move more assuredly between holds that are widely spaced. I must work on my endurance, so that I do not fail climbs because I am worn out by a long series of lower moves. Finally I need to improve my technique: making my footwork more precise; paying more attention to the shape of my body and how this affects my centre of gravity and the purchase I have on holds; getting more comfortable with the tricks of the trade such as heel- and toe-hooks; learning when to be aggressive in my climbing and when to be slow and deliberate; and finally better visualising how my body fits against the rock and the best way to flow economically from one position to the next.

If I can get better in all of these areas, then maybe I will have earned my new technical rock shoes and I will be able to take advantage of the benefits that they offer. Having the right shoes can undoubtedly improve your climbing, but it is no substitute for focussing on the long list in the previous paragraph. There is no real short-cut to becoming a better climber, it just takes an awful lot of work.

A final thing to add in this section is that the Solutions offer advantages to the climber on certain types of climbs. On any overhanging, pocketed rock, they are brilliant. But the way that they shape your foot into a down-turned claw would be a positive disadvantage when trying to pad up a slab. In this second scenario, something like my worn out FiveTens (now sadly consigned to the rubbish tip) would be the tool of choice. It is important to realise that the right tool is often dictated by the task in hand and one that excels in area A may be an also-ran in area B.

Notes:

  1. Lest it be thought that the above manufacturers play only in narrow niches, I should explain that each of Boreal, FiveTen and La Sportiva produce a wide range of rock shoes catering to virtuially every type of climber from the neophyte to the world’s best.
  2. If you think that the pound dollar rates are rather strange in the above exhibits, then a few things are at play. Some are genuine differences, but others are because they are historical rates. for example, I struggled to find a US web-site that still sells Boreal Zephyrs.
  3. If you are interested in finding out more about my adventures in rock climbing, then take a look at my partner’s blog.

 
 
The role of technology in Business Intelligence

I hope that I have established that at least in the world of rock climbing, the technology that you have at your disposal is only one of many factors necessary for success; indeed it is some way from being the most important factor.

Having really poor, or worn out, rock shoes can dent your confidence and even get you into bad habits (such as not using your feet enough). Having really good rock shoes can bring some incremental benefits, but these are not as great as those to be gained by training and experience. Most of the technologically-related benefits will be realised by having reasonably good and reasonably new shoes.

While the level of a professional rock climber’s performance will be undoubtedly be improved by using the best equipment available, a bad climber with $150 rock shoes will still be a bad climber (note this is not intended to be a self-referential comment).

Requirements - Data Analysis - Information - Manage Change
Requirements - Data Analysis - Information - Manage Change

Returning to another of my passions, Business Intelligence, I see some pertinent parallels. In a series of previous articles (including BI implementations are like icebergs, “All that glisters is not gold” – some thoughts on dashboards and Short-term “Trouble for Big Business Intelligence Vendors” may lead to longer-term advantage) , I have laid out my framework for BI success and explained why I feel that technology is not the most important part of a BI programme.

My recommended approach is based on four pillars:

  1. Determine what information is necessary to drive key business decisions.
  2. Understand the various data sources that are available and how they relate to each other.
  3. Transform the data to meet the information needs.
  4. Manage the embedding of BI in the corporate culture.

Obviously good BI technology has a role to play across all of these areas, but it is not the primary concern in any of them. Let us consider what is often one of the most difficult areas to get right, embedding BI in an organisation’s DNA. What is the role of the BI tool here?

Well if you want people to actually use the BI system, it helps if the way that the BI technology operates is not a hindrance to this. Ideally the ease-of-use and intuitiveness of the BI technology deployed should be a plus point for you. However, if you have the ultimate in BI technology, but your BI system does not highlight areas that business people are interested in, does not provide information that influences actual decision-making, or contains numbers that are inaccurate, out-of-date, or unreconciled, then it will not be used. I put this a little more succinctly in a recent article: Using multiple business intelligence tools in an implementation – Part II (an inspired title I realise), which I finished by saying:

If your systems do not have credibility with your users, then all is already lost and no amount of flashy functionality will save you.

Similar points can be made about all of the other pillars. Great BI technology should be the icing on your BI cake, not one of the main ingredients.
 
 
The historical perspective

What Car?

Ajay Ohri from the DecisionStats web-site recently interviewed me in some depth about a range of issues. He specifically asked me about what differentiated the various BI tools and I reproduce my reply here:

The really important question in BI is not which tool is best, but how to make BI projects successful. While many an unsuccessful BI manager may blame the tool or its vendor, this is not where the real issues lie. I firmly believe that successful BI rests on four mutually reinforcing pillars: understand the questions the business needs to answer, understand the data available, transform the data to meet the business needs and embed the use of BI in the organisation’s culture. If you get these things right then you can be successful with almost any of the excellent BI tools available in the marketplace. If you get any one of them wrong, then using the paragon of BI tools is not going to offer you salvation.

I think about BI tools in the same way as I do the car market. Not so many years ago there were major differences between manufacturers. The Japanese offered ultimate reliability, but maybe didn’t often engage the spirit. The Germans prided themselves on engineering excellence, slanted either in the direction of performance or luxury, but were not quite as dependable as the Japanese. The Italians offered out-and-out romance and theatre, with mechanical integrity an afterthought. The French seemed to think that bizarrely shaped cars with wheels as thin as dinner plates were the way forward, but at least they were distinctive. The Swedes majored on a mixture of safety and aerospace cachet, but sometimes struggled to shift their image of being boring. The Americans were still in the middle of their love affair with the large and the rugged, at the expense of convenience and value-for-money. Stereotypically, my fellow-countrymen majored on agricultural charm, or wooden-panelled nostalgia, but struggled with the demands of electronics.

Nowadays, the quality and reliability of cars are much closer to each other. Most manufacturers have products with similar features and performance and economy ratings. If we take financial issues to one side, differences are more likely to related to design, or how people perceive a brand. Today the quality of a Ford is not far behind that of a Toyota. The styling of a Honda can be as dramatic as an Alfa Romeo. Lexus and Audi are playing in areas previously the preserve of BMW and Mercedes and so on. To me this is also where the market for BI tools is at present. It is relatively mature and the differences between product sets are less than before.

Of course this doesn’t mean that the BI field will not be shaken up by some new technology or approach (in-memory BI or SaaS come to mind). This would be the equivalent of the impact that the first hybrid cars had on the auto market. However, from the point of view of implementations, most BI tools will do at least an adequate job and picking one should not be your primary concern in a BI project.

If you are interested, you can read the full interview here.
 
 
The current reality

IBM to acquire SPSS

As my comments to Ajay suggest, maybe in past times there were greater differences between BI vendors and the tools that they supplied. One benefit of the massive consolidation that has occurred in recent years is that the five biggest players: IBM/Cognos, Oracle/Hyperion, SAP/BusinessObjects, Microsoft and (the as yet still independent) SAS all have product portfolios that are both wide and deep. If there is something that you want your BI tool to do, it is likely that any of these organisations can provide you with the software; assuming that your wallet allows it. Both the functionality and scope of offerings from smaller vendors operating in the BI arena have also increased greatly in recent times. Finding a technology that fits your specific needs for functionality, ease-of-use, scalability and reliability should not be a problem.

This general landscape is one against which it is interesting to view the recent acquisition of business analytics firm SPSS by IBM. According to Reuters, IBM’s motivations are as follows:

IBM plans to buy business analytics company SPSS Inc for $1.2 billion in cash to better compete with Oracle Corp and SAP AG in the growing field of business intelligence

Full story here.

As an aside, should both Microsoft and SAS be worried that they are omitted from this list?

Whatever the corporate logic for IBM, to me this is simply more evidence that BI technology is becoming a utility (it should however be noted that this is not the same as BI itself becoming a utility). I believe that this trend will lead to a greater focus on the use of BI technology as part of broad-based BI programmes that drive business value. Though BI has the potential of releasing massive benefits for organisations, the track record has been somewhat patchy. Hopefully as people start to worry less about BI technology and more about the factors that really drive success in BI programmes, this will begin to change.

A precursor to Business Intelligence

As with any technical innovation over the centuries, it is only when the technology itself becomes invisible that the real benefits flow.
 

A blast from the past…

Gutenberg Printing Press

I recently came across a record of my first ever foray into the world of Business Intelligence, which dates back to 1997. This was when I was still predominantly an ERP person and was considering options for getting information out of such systems. The piece in question is a brief memo to my boss (the CFO of the organisation I was working at then) about what I described as the OLAP market.

This was a time of innocence, when Google had not even been incorporated, when no one yet owned an iPod and when, if you tried to talk to someone about social media, they would have assumed that you meant friendly journalists. All this is attested to by the fact that this was a paper memo that was printed and circulated in the internal mail – remember that sort of thing?

Given that the document has just had its twelfth birthday, I don’t think I am breeching any confidences in publishing it, though I have removed the names of the recipients for obvious reasons.
 

INTERNAL MEMORANDUM
To: European CFO
cc: Various interested parties
From: Peter Thomas
Date: 16th June 1997
Subject: What is OLAP?

 
On-Line Analytical Processing (OLAP) is a category of software technology that enables analysts, managers and executives to gain insight into data. This is achieved by providing fast, consistent, interactive access to a wide variety of possible views of information. This has generally been transformed from raw data to reflect the real dimensionality of the enterprise.

There are around 30 vendors claiming to offer OLAP products. A helpful report by Business Intelligence[1] (an independent research company) estimates the market share of these . As many of these companies sell other products, the following cannot be viewed as 100% accurate. However the figures do provide some interesting reading.
 

Vendor

1996

1995

Market Position

Share (%)

Market Position

Share (%)

Oracle

1

19.0%

1

20.0%

Hyperion Software

2

18.0%

2

19.0%

Comshare

3

12.0%

3

16.0%

Cognos

4

9.0%

4

5.0%

Arbor Software

5

4.8%

7

2.9%

Holistic Systems

6

4.3%

6

4.7%

Pilot Software

7

4.0%

5

4.8%

MircoStrategy

8

3.5%

9

2.1%

Planning Sciences

9

2.6%

8

2.3%

Information Advantage

10

1.8%

10

1.4%

 
In this group, some companies (Hyperion, Comshare, Holistic, Pilot Software and Planning Services) provide either complete products or extensive toolkits. In contrast some vendors (such as Arbor and – outside the top ten – Applix) only sell specialist multi-dimensional databases. Others (e.g. Cognos and – outside the top ten – BusinessObjects and Brio Technology), offer client based OLAP tools which are basically sophisticated report writers. The final group (including MicroStrategy and Information Advantage) offer a mixed relational / dimensional approach called Relational OLAP or ROLAP.

If we restrict ourselves to the “one-stop solution” vendors in the above list, it is helpful to consider the relative financial position of the top three.
 

Vendor

Market Cap.[2]

($m)

Turnover

($m)

Profit

($m)

Oracle

32,405

4,223[3]

603

Hyperion Software

335

173[4]

9

Comshare

132

119[5]

(9)

 

[1] The OLAP Report by Nigel Pendse and Richard Creeth © Business Intelligence 1997
[2] As at June 1997
[3] 12 months to March 1997
[4] 12 months to June 1996
[5] 12 months to June 1996

 


 
It is of course also worth pointing out that I used to disagree with what Nigel Pendse wrote a lot less back then!
 

Using multiple business intelligence tools in an implementation – Part I

linkedin The Data Warehousing Institute The Data Warehousing Institute (TDWI™) 2.0

Introduction

This post follows on from a question that was asked on the LinkedIn.com Data Warehousing Institute (TDWI™) 2.0 group. Unfortunately the original thread is no longer available for whatever reason, but the gist of the question was whether anyone had experience with using a number of BI tools to cover different functions within an implementation. So the scenario might be: Tool A for dashboards, Tool B for OLAP, Tool C for Analytics, Tool D for formatted reports and even Tool E for visualisation.

In my initial response I admitted that I had not faced precisely this situation, but that I had worked with the set-up shown in the following diagram, which I felt was not that dissimilar:

An example of a multi-tier BI architecture with different tools
An example of a multi-tier BI architecture with different tools

Here there is no analytics tool (in the statistical modelling sense – Excel played that role) and no true visualisation (unless you count graphs in PowerPlay that is), but each of dashboards, OLAP cubes, formatted reports and simple list reports are present. The reason that this arrangement might not at first sight appear pertinent to the question asked on LinkedIn.com is that two of the layers (and three of the report technologies) are from one vendor; Cognos at the time, IBM-Cognos now. The reason that I felt that there was some relevance was that the Cognos products were from different major releases. The dashboard tool being from their Version 8 architecture and the OLAP cubes and formatted reports from their Version 7 architecture.
 
 
A little history

London Bridge circa 1600
London Bridge circa 1600

Maybe a note of explanation is necessary as clearly we did not plan to have this slight mismatch of technologies. We initially built out our BI infrastructure without a dashboard layer. Partly this was because dashboards weren’t as much of a hot topic for CEOs when we started. However, I also think it also makes sense to overlay dashboards on an established information architecture (something I cover in my earlier article, “All that glisters is not gold” – some thoughts on dashboards, which is also pertinent to these discussions).

When we started to think about adding icing to our BI cake, ReportStudio in Cognos 8 had just come out and we thought that it made sense to look at this; both to deliver dashboards and to assess its potential future role in our BI implementation. At that point, the initial Cognos 8 version of Analysis Studio wasn’t an attractive upgrade path for existing PowerPlay users and so we wanted to stay on PowerPlay 7.3 for a while longer.

The other thing that I should mention is that we had integrated an in-house developed web-based reporting tool with PowerPlay as the drill down tool. The reasons for this were a) we had already trained 750 users in this tool and it seemed sensible to leverage it and b) employing it meant that we didn’t have to buy an additional Cognos 7 product, such as Impromptu, to support this need. This hopefully explains the mild heterogeneity of our set up. I should probably also say that users could directly access any one of the BI tools to get at information and that they could navigate between them as shown by the arrows in the diagram.

I am sure that things have improved immensely in the Cognos toolset since back then, but at the time there was no truly seamless integration between ReportStudio and PowerPlay as they were on different architectures. This meant that we had to code the passing of parameters between the ReportStudio dashboard and PowerPlay cubes ourselves. Although there were some similarities between the two products, there were also some differences at the time and these, plus the custom integration we had to develop, meant that you could also view the two Cognos products as essentially separate tools. Add in here the additional custom integration of our in-house reporting application with PowerPlay and maybe you can begin to see why I felt that there were some similarities between our implementation and one using different vendors for each tool.

I am going to speak a bit about the benefits and disadvantages of having a single vendor approach later, but for now an obvious question is “did our set-up work?” The answer to this was a resounding yes. Though the IT work behind the scenes was maybe not the most elegant (though everything was eminently supportable), from the users’ perspective things were effectively seamless. To slightly pre-empt a later point, I think that the user experience is what really matters, more than what happens on the IT side of the house. Nevertheless let’s move on from some specifics to some general comments.
 
 
The advantages of a single vendor approach to BI

One-stop shopping
One-stop shopping

I think that it makes sense if I lay my cards on the table up-front. I am a paid up member of the BI standardisation club. I think that you only release the true potential of BI when you take a broad based approach and bring as many areas as you can into your warehouse (see my earlier article, Holistic vs Incremental approaches to BI, for my reasons for believing this).

Within the warehouse itself there should be a standardised approach to dimensions (business entities and the hierarchies they are built into should be the same everywhere – I’m sure this will please all my MDM friends out there) and to measures (what is the point if profitability is defined different ways in different reports?). It is almost clichéd nowadays to speak about “the single version of the truth”, but I have always been a proponent of this approach.

I also think that you should have the minimum number of BI tools. Here however the minimum is not necessarily always one. To misquote one of Württemberg’s most famous sons:

Everything should be made as simple as possible, but no simpler.

What he actually said was:

It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.

but maybe the common rendition is itself paying tribute to the principle that he propounded. Let me pause to cover what are the main reasons quoted for adopting a single vendor approach in BI:

  1. Consistent look-and-feel: The tools will have a common look-and-feel, making it easier for people to use them and simplifying training.
  2. Better interoperability: Interoperability between the tools is out-of-the-box, saving on time and effort in developing and maintaining integration.
  3. Clarity in problem resolution: If something goes wrong with your implementation, you don’t get different vendors blaming each other for the problem.
  4. Simpler upgrades: You future proof your architecture, when one element has a new release, it is the vendor’s job to ensure it works with everything else, not yours.
  5. Less people needed: You don’t need to hire an expert for each different vendor tool, thereby reducing the size and cost of your BI team.
  6. Cheaper licensing: It should be cheaper to buy a bundled solution from one vendor and ongoing maintenance fees should also be less.

This all seems to make perfect sense and each of the above points can be seen to be reducing the complexity and cost of your BI solution. Surely it is a no-brainer to adopt this approach? Well maybe. Let me offer some alternative perspectives on each item – none of these wholly negates the point, but I think it is nevertheless worth considering a different perspective before deciding what is best for your organisation.

  1. Consistent look-and-feel: It is not always 100% true that different tools from the same vendor have the same look-and-feel. This might be down to quality control at the vendor, it might be because the vendor has recently acquired part of their product set and not fully integrated it as yet, or – even more basically – it may be because different tools are intended to do different things. To pick one example from outside of BI that has frustrated me endlessly over the years: PowerPoint and Word seem to have very little in common, even in Office 2007. Hopefully different tools from the same vendor will be able to share the same metadata, but this is not always the case. Some research is probably required here before assuming this point is true. Also, picking up on the Bauhaus ethos of form dictating function, you probably don’t want to have your dashboard looking exactly like your OLAP cubes – it wouldn’t be a dashboard then would it? Additional user training will generally be required for each tier in your BI architecture and a single-vendor approach will at best reduce this somewhat.
  2. Better interoperability: I mention an problem with interoperability of the Cognos toolset above. This is is hopefully now a historical oddity, but I would be amazed if similar issues do not arise at least from time to time with most BI vendors. Cognos itself has now been acquired by IBM and I am sure everyone in the new organisation is doing a fine job of consolidating the product lines, but it would be incredible if there were not some mismatches that occur in the process. Even without acquisitions it is likely that elements of a vendor’s product set get slightly out of alignment from time to time.
  3. Clarity in problem resolution: This is hopefully a valid point, however it probably won’t stop your BI tool vendor from suggesting that it is your web-server software, or network topology, or database version that is causing the issue. Call me cynical if you wish, I prefer to think of myself as a seasoned IT professional!
  4. Simpler upgrades: Again this is also most likely to be a plus point, but problems can occur when only parts of a product set have upgrades. Also you may need to upgrade Tool A to the latest version to address a bug or to deliver desired functionality, but have equally valid reasons for keeping Tool B at the previous release. This can cause problems in a single supplier scenario precisely because the elements are likely to be more tightly coupled with each other, something that you may have a chance of being insulated against if you use tools from different vendors.
  5. Less people needed: While there might be half a point here, I think that this is mostly fallacious. The skills required to build an easy-to-use and impactful dashboard are not the same as building OLAP cubes. It may be that you have flexible and creative people who can do both (I have been thus blessed myself in the past in projects I ran), but this type of person would most likely be equally adept whatever tool they were using. Again there may be some efficiencies in sharing metadata, but it is important not to over-state these. You may well still need a dashboard person and an OLAP person, if you don’t then the person who can do both with probably not care about which vendor provides the tools.
  6. Cheaper licensing: Let’s think about this. How many vendors give you Tool B free when you purchase Tool A? Not many is the answer in my experience, they are commercial entities after all. It may be more economical to purchase bundles of products from a vendor, but also having more than one in the game may be an even better way of ensuring that cost are kept down. This is another area that requires further close examination before deciding what to do.

 
A more important consideration

Overall it is still likely that a single-vendor solution is cheaper than a multi-vendor one, but I hope that I have raised enough points to make you think that this is not guaranteed. Also the cost differential may not be as substantial as might be thought initially. You should certainly explore both approaches and figure out what works best for you. However there is another overriding point to consider here, the one I alluded to earlier; your users. The most important thing is that your users have the best experience and that whatever tools you employ are the ones that will deliver this. If you can do this while sticking to a single vendor then great. However if your users will be better served by different tools in different tiers, then this should be your approach, regardless of whether it makes things a bit more complicated for your team.

Of course there may be some additional costs associated with such an approach, but I doubt that this issue is insuperable. One comparison that it may help to keep in mind is that the per user cost of many BI tools is similar to desktop productivity tools such as Office. The main expense of BI programmes is not the tools that you use to deliver information, but all the work that goes on behind the scenes to ensure that it is the right information, at the right time and with the appropriate degree of accuracy. The big chunks of BI project costs are located in the four pillars that I consistently refer to:

  1. Understand the important business decisions and what figures are necessary to support these.
  2. Understand the data available in the organisation, how it relates to other data and to business decisions.
  3. Transform the data to provide information answering business questions.
  4. Focus on embedding the use of information in the corporate DNA.

The cost of the BI tools themselves are only a minor part of the above (see also, BI implementations are like icebergs). Of course any savings made on tools may make funds available for other parts of the project. It is however important not to cut your nose off to spite your face here. Picking right tools for the job, be they from one vendor or two (or even three at a push) will be much more important to the overall payback of your project than saving a few nickels and dimes by sticking to a one-vendor strategy just for the sake of it.
 


 
Continue reading about this area in: Using multiple business intelligence tools in an implementation – Part II
 

Short-term “Trouble for Big Business Intelligence Vendors” may lead to longer-term advantage

linkedin Chief Information Officer (CIO) Network

This post is another that highlights responses I have made on various LinkedIn.com forums. In this case, a news article was posted on the Chief Information Officer (CIO) Network group (as ever you need to be a member of LinkedIn.com and the group to view the original thread).

The news article itself linked to a piece / podcast on The IT-Finance Connection entitled: Big BI Vendors Facing Big Challenges. In this Nigel Pendse, author of the anual BI Survey, was interviewed by IT-Finance Connection about his latest publication and his thoughts about the BI market in general.

Nigel speaks about issues that he sees related to the consolidation of BI vendors. In his opinion this has led to the big players paying more attention to integrating acquisitions and rationalising product lines instead of focusing on customer needs. In one passage, he says:

Within product development, the main theme moved from innovation to integration. So, instead of delivering previously promised product enhancements to existing customers, product releases came out late and the highlights were the new connections to other products owned by the vendor, but which were probably not used by the existing customers. In other words, product development was driven by the priorities of the vendor, not the customer.

Whilst there is undoubtedly truth in Nigel’s observations, I have a slightly different slant on them, which I offered in my comments:

It is my very strong opinion that what the users of BI need to derive value is not the BI vendors “delivering previously promised product enhancements” but using the already enormously extensive capabilities of their existing BI tools better. BI should not be a technology-driven area, the biggest benefits come from BI departments getting to know their users’ needs better and focusing on these rather than the latest snazzy tool.

If this does happen, it may mean less than brilliant news for the BI vendors’ sales in the short-term, but successful BI implementations are going to be a better advert for them than some snazzy BI n.0 feature. The former is more likely to drive revenues for them in the medium term as companies build on successes and expand the scope of their existing BI systems.

See also: BI implementations are like icebergs

While some people see large potential downsides in the acquisition of such companies as BusinessObjects, Hyperion and Cognos by large, non-BI companies, you could argue that their new owners are the sort of organisations that will aim to use BI to drive real-world business success. Who knows whether they will be successful, but if they are and this is at the expense of technological innovation, then I think that this is a reasonable sacrifice.

As to whose vision of the future is right, I guess only time will tell.