Year: 2009

Jargon

Peter James Thomas business, change management, cultural transformation, it business alignment, technology , , , , , , ,

Alice consulting with an industry expert

  `As I was saying, that seems to be done right — though I haven’t time to look it over thoroughly just now — and that shows that there are three hundred and sixty-four days when you might get un-birthday presents –‘

`Certainly,’ said Alice.

`And only one for birthday presents, you know. There’s glory for you!’

`I don’t know what you mean by “glory”,’ Alice said.

Humpty Dumpty smiled contemptuously. `Of course you don’t — till I tell you. I meant “there’s a nice knock-down argument for you!”‘

`But “glory” doesn’t mean “a nice knock-down argument”,’ Alice objected.

`When I use a word,’ Humpty Dumpty said, in rather a scornful tone, `it means just what I choose it to mean — neither more nor less.’

`The question is,’ said Alice, `whether you can make words mean so many different things.’

`The question is,’ said Humpty Dumpty, `which is to be master — that’s all.’

Through the Looking-Glass and what Alice found there, by Lewis Carroll

  

Yesterday I was moved to post the above section from one of my favourite books on the LinkedIn.com Organisational Change Practitioners forum. The precise thread was entitled, Commitment during Change (as ever you need to be a member of LinkedIn.com and thr group to access the preceding links). The context was an increasingly intricate discussion about what constituted a “burning platform”; if this was a good thing to be standing on, or not; and whether such a situation was likely to lead to a positive or negative reaction on behalf of those standing on it.

My first contribution to this section of the discussion was as follows (with some light editing):

A burning platform tends to suggest panic and an imperative to do something (anything) right now. Think about it; the burning bit and… well… being on a platform. I am not sure that this is the best metaphor for instilling commitment.

Commitment may be passionate, but it is more rational, more of an active choice as opposed to, “what do I have to do to get out of here, my toes are getting hot?”

Telling someone that they are on a burning platform will certainly get their attention – they may also be willing to listen to you if you have some suggestion that might help, but this does not sound like instilling commitment in them to me; more like instilling fear.

Commitment tends to suggest a belief on behalf of the committed that what they are being asked to do is right for them and necessary for the broader organisation (despite it potentially being difficult and/or painful).

Commitment is not fleeing a burning platform – that’s just a survival instinct. Instead commitment might be exhibited by a person deciding to return to a burning platform to rescue some one.

The Alice quote came after I had posted the above thoughts, but before the post that I wanted to focus on in this article. This was about professional jargon and was as follows (again lightly edited):

When I was studying Mathematics, the use of words to mean something other than their ordinary meaning became second nature. The uninitiated would never have guessed the recherché meanings we ascribed to everyday words such as “ring”, “field” or “group”.

Early in my IT career I went over to the dark side, quoting impenetrable acronyms with the best of them. However as my role became more part of the business, I had something of an epiphany. I realised that people were not really that impressed by jargon, that they were more likely to assume (sometimes correctly) that the jargon-user was trying to cover something up or sound clever, and that maybe there was a better way.

Nowadays I am sometimes guilty of using complicated English, but I hope that it is mostly just English (as opposed to English 2.0 – now with even more terminology and even less meaning). I will crave your indulgence about the bit of French above of course :-o.

I think that jargon is both useful and inescapable when communicating efficiently with fellow professionals in a field (no not the Maths meaning of “field”); in all other cases it is mostly a hindrance to being understood.

Now I am sure that an assidious reader would have no problem whatsoever in finding counter-examples to my call for plain-speaking about IT; they are probably sprinkled liberally throughout this blog. Maybe this is a case of doing what I say, rather than what I do. However, it is interesting the number of commentators who have suggested that it would help IT professionals to increase their standing with their colleagues if they dropped the technical jargon and learned to speak more like a business person (e.g. see my comments on Ilya Bogorad’s article about Talking Business).

While getting business people to terminate their love affair with their own version of jargon might be wishful thinking, it is pleasing to go beyond Ilya’s recommendation and contemplate a world where a spade is called a spade and not a terrain relocation appliance.

Sadly it is all too often the case that the number of words used in a business context is inversely proportional to the quantum of meaning that they convey. Perhaps it is time for professionals in all walks of life to take a lead from Humpty Dumpty and begin to better assert their mastery of vocabulary.
 

Century

Peter James Thomas business, technology , , , , ,
Century - with apologies to Paul Collingwood
100 not out!

I started writing articles for this blog back in November 2008 and this post marks the 100th one. Continuing my recent sporting theme (football [soccer] in “Big vs. Small BI” by Ann All at IT Business Edge, mountain biking in Mountain Biking and Systems Integration and rock climbing in Perseverance), this piece draws on another of my passions outside of the business, technology and change arena; cricket.

I appreciate that this pastime is a closed book to many people around the world (and some in even the UK). It can be argued that it suffers from labyrinthine rules, a pace that can be described as measured at best and being confined mostly to outposts of the old British Empire (though that in itself comprises 2.1 billion people). However, for its aficionados, like me, cricket is truly the prince of sports.

For a batsman (cf. batter in baseball[1] – as an aside, even the women are called bastmen – for more on England’s world-beating women’s cricket team, click here), a major achievement is to score 100 runs without the opposition getting you out; a feat that is called a century for obvious reasons.

Perhaps it is the influence of numerology, but scoring 100 has always been seen as somehow more worthy than merely scoring 99. Indeed a tendency to not convert high double-digit scores into triple-digits ones is often seen as a failure in a player’s mental focus. The careers of the most celebrated batsmen are always adorned by the number of centuries that they have scored. The current holder of the record for the most centuries in international matches is Sachin Tendulkar of India with an incredible 42.

A century is a major landmark, but for the best bastmen it is merely a staging post on the way to larger scores. Indeed the highest score recorded in an international cricket match currently stands at a gargantuan 400 runs by Brian Lara of the West Indies. Lara (34 centuries in case you are interested) and Tendulkar have spent the last two decades vying with each other for the accolade of greatest batsman currently playing (Lara retired in 2007, Tendulkar is still playing).

I suppose that you could make the, admittedly rather tenuous, connection that a youthful obsession with cricket statistics contributed to me working in the field of business intelligence; but maybe this is an indulgence too far, even for a 100th post.

Anyway, with these cultural influences as a context, I spent a little while considering how to commemorate my own century of blog articles, debating whether or not to write some sort of retrospective, or perhaps a more personal piece.

Instead, in the spirit of Brian Lara, I am going to wave my bat briefly to the crowd and then settle down to focus on completing my double century. I hope that you will be there to read my 200th article.
 


 
[1] For a great account of the similarities and differences between cricket and baseball, I recommend reading Ed Smith’s excellent book, Playing Hard Ball: County Cricket and Big League Baseball. Ed Smith played cricket for England and Kent and spent several seasons in Spring Training with the New York Mets. He is now a full-time author, writing about cricket and a variety other subjects.
 

“Big vs. Small BI” by Ann All at IT Business Edge

Peter James Thomas business, business intelligence, industry commentary, it business alignment, management, management information, project management, technology , , , , , , , , , , , , , , ,

Introduction

  Ann All IT Business Edge  

Back in February, Dorothy Miller wrote a piece at IT Business Edge entitled, Measuring the Return on Investment for Business Intelligence. I wrote a comment on this, which I subsequently expanded to create my article, Measuring the benefits of Business Intelligence.

This particular wheel has now come full circle with Ann All from the same web site recently interviewing me and several BI industry leaders about our thoughts on the best ways to generate returns from business intelligence projects. This new article is called, Big vs. Small BI: Which Set of Returns Is Right for Your Company? In it Ann weaves together an interesting range of (sometimes divergent) opinions about which BI model is most likely to lead to success. I would recommend you read her work.

The other people that Ann quotes are:

• John Colbert Vice president of research and analytics for consulting company BPM Partners.
• Dorothy Miller Founder of consulting company BI Metrics (and author of the article I mention above).
• Michael Corcoran Chief marketing officer for Information Builders, a provider of BI solutions.
• Nigel Pendse Industry analyst and author of the annual BI Survey.

 
Some differences of opinion

As might be deduced from the title of Ann’s piece the opinions of the different interviewees were not 100% harmonious with each other. There was however a degree of alignment between a few people. As Ann says:

Corcoran, Colbert and Thomas believe pervasive use of BI yields the greatest benefits.

On this topic she quoted me as follows (I have slightly rearranged the text in order to shorten the quote):

If BI can trace all the way from the beginning of a sales process to how much money it made the company, and do it in a way that focuses on questions that matter at the different decision points, that’s where I’ve seen it be most effective.

By way of contrast Pendse favours:

smaller and more tactical BI projects, largely due to what his surveys show are a short life for BI applications at many companies. “The median age of all of the apps we looked at is less than 2.5 years. For one reason or another, within five years the typical BI app is no longer in use. The problem’s gone away, or people are unhappy with the vendor, or the users changed their minds, or you got acquired and the new owner wants you to do something different,” he says. “It’s not like an ERP system, where you really would expect to use it for many years. The whole idea here is go for quick, simple wins and quick payback. If you’re lucky, it’ll last for a long time. If you’re not lucky, at least you’ve got your payback.”

I’m sure that Nigel’s observations are accurate and his statistics impeccable. However I wonder whether what he is doing here is lumping bad BI projects with good ones. For a BI project a lifetime of 2.5 years seems extraordinarily short, given the time and effort that needs to be devoted to delivering good BI. For some projects the useful lifetime must be shorter than the development period!

Of course it may be that Nigel’s survey does not discriminate between tiny, tactical BI initiatives, failed larger ones and successful enterprise BI implementations. If this is the case, then I would not surprised if the first two categories drag down the median. Though you do occasionally hear horror stories of bad BI projects running for multiple years, consuming millions of dollars and not delivering, most bad BI projects will be killed off fairly soon. Equally, presumably tactical BI projects are intended to have a short lifetime. If both of these types of projects are included in Pendse’s calculations, then maybe the the 2.5 years statistic is more understandable. However, if my assumptions about the survey are indeed correct, then I think that this figure is rather misleading and I would hesitate to draw any major conclusions from it.

In order that I am not accused of hidden bias, I should state unequivocally that I am a strong proponent of Enterprise BI (or all-pervasive BI, call it what you will), indeed I have won an award for an Enterprise BI implementation. I should also stress that I have been responsible for developing BI tools that have been in continuous use (and continuously adding value) for in excess of six years. My opinions on Enterprise BI are firmly based in my experiences of successfully implementing it and seeing the value generated.

With that bit of disclosure out of the way, let’s return to the basis of Nigel’s recommendations by way of a sporting analogy (I have developed quite a taste for these, having recently penned artciles relating both rock climbing and mountain biking to themes in business, technology and change).
 
 
A case study

Manchester United versus Liverpool

The [English] Premier League is the world’s most watched Association Football (Soccer) league and the most lucrative, attracting the top players from all over the globe. It has become evident in recent seasons that the demands for club success have become greater than ever. The owners of clubs (be those rich individuals or shareholders of publicly quoted companies) have accordingly become far less tolerant of failure by those primarily charged with bringing about such success; the club managers. This observation was supported by a recent study[1] that found that the average tenure of a dismissed Premier League manager had declined from a historical average of over 3 years to 1.38 years in 2008.

As an aside, the demands for business intelligence to deliver have undeniably increased in recent years; maybe BI managers are not quite paid the same as Football managers, but some of the pressures are the same. Both Football managers and BI managers need to weave together a cohesive unit from disparate parts (the Football manager creating a team from players with different skills, the BI manager creating a system from different data sources). So given, these parallels, I suggest that my analogy is not unreasonable.

Returning to the remarkable statistic of the average tenure of a departing Premier League manger being only 1.38 years and applying Pendse’s logic we reach an interesting conclusion. Football clubs should be striving to have their managers in place for less than twelve months as they can then be booted out before they are obsolete. If this seems totally counter-intutitive, then maybe we could look at things the other way round. Maybe unsuccessful Football managers don’t last long and maybe neither do unsuccessful BI projects. By way of corollary, maybe there are a lot of unsuccessful BI projects out there – something that I would not dispute.

By way of an example that perhaps bears out this second way of thinking about things, the longest serving Premier League manager, Alex Ferguson of Manchester United, is also the most successful. Manchester United have just won their third successive Premier League and have a realistic chance of becoming the first team ever to retain the UEFA Champions League.

Similarly, I submit that the median age of successful BI projects is most likely significantly more than 2.5 years.
 
 
Final thoughts

I am not a slavish adherent to an inflexible credo of big BI; for me what counts is what works. Tactical BI initiatives can be very beneficial in their own right, as well as being indispensible to the successful conduct of larger BI projects; something that I refer to in my earlier article, Tactical Meandering. However, as explained in the same article, it is my firm belief that tactical BI works best when it is part of a strategic framework.

In closing, there may be some very valid reasons why a quick and tactical approach to BI is a good idea in some circumstances. Nevertheless, even if we accept that the median useful lifetime of a BI system is only 2.5 years, I do not believe that this is grounds for focusing on the tactical to the exclusion of the strategic. In my opinion, a balanced tactical / strategic approach that can be adapted to changing circumstances is more likely to yield sustained benefits than Nigel Pendse’s tactical recipe for BI success.
 

 
Nigel Pendse and I also found ourselves on different sides of a BI debate in: Short-term “Trouble for Big Business Intelligence Vendors” may lead to longer-term advantage.
 
[1] Dr Susan Bridgewater of Warwick Business School quoted in The Independent 2008
 

Yet more irony and WordPress.com advertising

Peter James Thomas business, technology

Following on from the previous gem that I spotted at the height of the business analytics versus business intelligence phoney war earlier this year, here is a less pointed, but still amusing second screenshot:

More ironic advertising
More ironic advertising

Anyone for a cheap flight to Mars, or Venus for that matter?
 

 
UPDATE: A further interesting conflation of context today:

Yet more ironic advertising
Yet more ironic advertising

So does IBM think that Mars or Venus is the “smarter planet”?
 

 
For your own chance to catch this ad, the original article appears here.
 

Using multiple business intelligence tools in an implementation – Part II

Peter James Thomas business, business intelligence, dashboards, data warehousing, management information, technology , , , , , , ,

Rather unsurprisingly, this article follows on from: Using multiple business intelligence tools in an implementation – Part I.

On further reflection about this earlier article, I realised that I missed out one important point. This was perhaps implicit in the diagram that I posted (and which I repeat below), but I think that it makes sense for me to make things explicit.

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

The point is that in this architecture with different BI tools in different layers, it remains paramount to have consistency in terminology and behaviour for dimensions and measures. So “Country” and “Profit” must mean the same things in your dashboard as it does in your OLAP cubes. The way that I have achieved this before is to have virtually all of the logic defined in the warehouse itself. Of course some things may need to be calculated “on-the-fly” within the BI tool, in this case care needs to be paid to ensuring consistency.

It has been pointed out that the approach of using the warehouse to drive consistency may circumscribe your ability to fully exploit the functionality of some BI tools. While this is sometimes true, I think it is not just a price worth paying, but a price that it is mandatory to pay. Inconsistency of any kind is the enemy of all BI implementations. If your systems do not have credibility with your users, then all is already lost and no amount of flashy functionality will save you.
 

Using multiple business intelligence tools in an implementation – Part I

Peter James Thomas business, business analytics, business intelligence, change management, cognos, cultural transformation, dashboards, data warehousing, ibm, industry commentary, it business alignment, management information, project management, technology , , , , , , , ,
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
 

Automating the business intelligence process?

Peter James Thomas balanced insight, business, business intelligence, it business alignment, management information, project management, technology , , , , , ,
Balanced Insight Merv Adrian - IT Market Strategies for Suppliers
Balanced Insight Merv Adrian

 
 
Introduction

I enjoy reading the thoughts of vastly experienced industry analyst Merv Adrian on his blog, Market Strategies for IT Suppliers, and also on twitter via @merv. Merv covers industry trends and a wide variety of emerging and established technologies and companies. I would encourage you to subscribe to his RSS feed.

In a recent artcile, Balanced Insight – Automating BI Design to Deployment, Merv reviews the Consensus tool and approach developed by Ohio-based outfit Balanced Insight. I suggest that you read Merv’s thoughts first as I won’t unnecessarily repeat a lot of what he says here. His article also has links to a couple of presentations featuring the use of Consensus to build both Cognos 8 and Proclarity prototypes, which are interesting viewing.
 
 
An overview of Balanced Insight

Disclaimer: I haven’t been the beneficiary of a briefing from Balanced Insight, and so my thoughts are based solely on watching their demos, some information from their site and – of course – Merv’s helpful article.

The company certainly sets expectations high with the strap line of their web site:

Agile & Aligned Business Intelligence - With Balanced Insight Consensus® deliver in half the time without compromising cross project alignment.

Promising to “deliver in half the time without compromising cross project alignment” is a major claim and something that I will try to pay close attention to later.

The presentations / demonstrations start with a set-up of a fictional company (different ones in different demos) who want to find out more about issues in their business: outstanding receivables, or profit margins [Disclosure: the fact that the second demo included margins on mountain bikes initially endeared me to the company]. In considering these challenges, Balanced Insight offers the following slide contrasting IT’s typical response with the, presumably superior, one taken by them:

IT's approach to information problems vs Balanced Insight's
IT's approach to information problems vs Balanced Insight's

I agree with Balanced Insight’s recommendation, but rather take issue with the assumption that IT always starts by looking exclusively at data when asked to partake in information-based initiatives. I have outlined what I see as the four main pillars of a business intelligence project at many places on this blog, most recently in the middle of my piece on Business Intelligence Competency Centres. While of course it is imperative to understand the available data (what would be the alternative?), the first step in any BI project is to understand the business issues and, in particular, the questions that the business wants an answer to. If you search the web for BI case studies or methodologies, I can’t imagine many of these suggesting anything other than Balanced Insight’s recommended approach.

Moving on, the next stage of both the demos introduces the company’s “information packages”. These are panes holding business entities and have two parts; the upper half contains “Topics and Categories” (things such as date or product), the bottom half contains measurements. The “Topics and Categories” can be organised into hierarchies, for example: day is within week, which is within month, quarter and year. At this point most BI professionals will realise that “Topics and Categories” are what we all call “Dimensions” – but maybe Balanced Insight have a point picking a less technical-sounding name. So what the “information package” consists of is a list of measures and dimensions pertaining to a particular subject area – it is essentially a loose specification for a data mart.

The interesting point is what happens next, the Consensus Integrator uses the “information package” to generate what the vendor claims is an optimised star-schema database (in a variety of databases). It then creates a pre-built prototype that references the schema; this can be in a selection of different BI tools. From what I can tell from the demos, the second stage appears to consist of creating an XML file that is then read by the BI tool. In the first example, the “Topics and Categories” become dimensions in Cognos AnalysisStudio and the measures remain measures. In both demos sample data is initially used, but in the ProClarity one a version with full data is also shown – it is unclear whether this was populated via Consensus or not. The “information package” can also be exported to data modelling tools such as ERwin.

One of the Balanced Insight presentations then mentions that “all that’s left to do is then to develop your ETL”. I appreciate that it is difficult to go into everything in detail in a short presentation, but this does rather seem to be glossing over a major area, indeed one of my four pillars of BI projects referred to above. Such rather off-hand comments do not exactly engender confidence. If there is a better story to tell here, then Balanced Insight’s presentations should try to tell it.
 
 
The main themes

There are a few ideas operating here. First that Balanced Insight’s tools can support a process which will promote best practice in defining and documenting the requirements of a BI project and allow a strong degree of user interaction. Second that the same tools can quickly and easily produce functioning prototypes that can be used to refine these same requirements and also make discussions with business stakeholders more concrete. Finally that the prototypes can employ a variety of database and BI tools – so maybe you prototype on a cheap / free database and BI tool, then implement on a more expensive, and industrial strength, combination later.

Balanced Insight suggest that their product helps to address “the communication gap between IT and the business”. I think it is interesting using the “information package” as a document repository, which may be helpful at other stages of the project. But there are other ways of achieving this as well. How business friendly these are probably depends on how the BI team set them up. I have seen Excel and small Access databases work well without even buying a specific tool. Also I think that if a BI team needs a tool to ensure it sticks to a good process, then there is probably a bigger problem to worry about.

Of course, the production of regular prototypes is a key technique to employ in any BI project and it seems that Balanced Insight may be on to something here, particularly if the way that their “information package” presents subject areas makes it easier for the BI team and business people to discuss things. However, it is not that arduous to develop prototypes directly in most BI tools. To put this in a context drawn from my own experience, building Cognos cubes to illustrate the latest iteration of business requirement gathering was often a matter of minutes, compared to business analysts putting in many days of hard work before this stage.

Having decided to use Consensus to capture information about measures and dimensions, the ability to then transfer these to a range of BI tools in interesting. This may offer the opportunity to change tools during the initial stages of the project and to try out different tools with the same schema and data to assess their effectiveness. This may also be something that is a useful tool when negotiating with BI vendors. However, again I am not sure exactly how big of a deal this is. I would be interested in better understanding how users have taken advantage of this feature.
 
 
A potential fly in the ointment

It would be easy to offer a couple of other criticisms of the approach laid out in the demos; namely that it seems to be targeted at developing point solutions rather than a pervasive BI architecture and that (presumably related to this) the examples shown are very basic. However, I’m willing to given them the benefit of the doubt, a sales pitch is probably not the place for a lengthy exploration of broad and complex issues. So I think my overall response to Balanced Insight’s Consensus product could be summed up as guardedly positive.

Nevertheless, there is one thing that rather worries me and this can best be seen by looking at the picture below. [As per the disclaimer above, the following diagram is based on my own understanding of the product and has not been provided by Balanced Insight.]

My perception of how Balanced Insight addresses needs for information
My perception of how Balanced Insight addresses needs for information

I think I understand the single black arrow on the right of the diagram, I’m struggling to work out what Consensus offers (aside from documentation) for the two black arrows on the left hand side. Despite the fact that Balanced Insight disparaged the approach of looking at available data in their presentation, there is no escaping the fact that some one will have to do this at some point. Connections will then have to be made between the available data and the business questions that need answering.

In both demos Consensus is pre-populated with dimensions, measures and linkages of these to sample data. How this happens is not covered, but this is a key area for any BI project. Unless Balanced Insight have some deus ex machina that helps to cut the length of this stage, then I begin to become a little sceptical about their claim to halve the duration of BI work.

Of course my concerns could be unfounded. It will be interesting to see how things develop for the company and whether their bold claims stand the test of time.
 

“Why taking a few punches on the financial crisis just might save IT” by Patrick Gray on TechRepublic

Peter James Thomas business, management, technology , , , , , ,
linkedin TechRepublic

Back on April 27th I wrote an article, The scope of IT’s responsibility when businesses go bad, that was inspired by a thread that Patrick Gray had started on the LinkedIn.com Chief Information Officer (CIO) Network group. This was entitled Is IT partially to blame for the financial crisis? (as ever you need to be a member of LinkedIn.com and the group to view these links).

Since then, there have been nearly 80 comments made by a wide variety of people, with an equally wide range of opinions. As can often happen in on-line discussions, positions were taken, attitudes were hardened and eventually some sort of stalemate was reached; probably as the protagonists were too weary to fight any more. In this respect seasoned IT professionals can be no different to teenagers discussing the merits of different genres of music! I certainly employed my method acting approach at a new level on this thread.

As a result of the overall feedback, Patrick has now composed a blog article on TechRepublic.com, an outlet that has also featured one of my favourite technology writers, Ilya Bogorad (see this earlier blog post). Patrick’s piece is titled Why taking a few punches on the financial crisis just might save IT and takes a thought-provoking stance with respect to the comments that his thread engendered. Here are the introductory remarks:

Patrick Gray believes that IT leaders still looking to find a seat at the C-level table might gain that influential position by taking a share of the responsibility for the failures that led to financial crisis.

It is certainly worth reading this article, but I recommend that you do so with an open mind.
 

 
Patrick Gray is the founder and president of Prevoyance Group, and author of Breakthrough IT: Supercharging Organizational Value through Technology. Prevoyance Group provides strategic IT consulting services to Fortune 500 and 1000 companies. Patrick can be reached at patrick.gray@prevoyancegroup.com.
 

Maureen Clarry stresses the need for change skills in business intelligence on BeyeNetwork

Peter James Thomas business, business intelligence, change management, cultural transformation, education, it business alignment, management, management information, technology , , , , , , , , , ,

The article

beyenetwork2

Maureen Clarry begins her latest BeyeNETWORK article, Leading Change in Business Intelligence, by stating:

If there was a standard list of core competencies for leaders of business intelligence (BI) initiatives, the ability to manage complex change should be near the top of the list.

I strongly concur with Maureen’s observation and indeed the confluence of BI and change management is a major theme of this blog; as well as the title of one of my articles on the subject. Maureen clearly makes the case that “business intelligence is central to supporting […] organizational changes” and then spends some time on Prosci’s ADKAR model for leading change; bringing this deftly back into the BI sphere. Her closing thoughts are that such a framework can help a lot in driving the success of a BI project.
 
 
My reflections

I find it immensely encouraging that an increasing number of BI professionals and consultants are acknowledging the major role that change plays in our industry and in the success of our projects. In fact it is hard to find some one who has run a truly successful BI project without paying a lot of attention to how better information will drive different behaviour – if it fails to do this, then “why bother?” as Maureen succinctly puts it.

Without describing it as anything so grand as a framework, I have put together a trilogy of articles on the subject of driving cultural transformation via BI. These are as follows:

• Marketing Change
• Education and cultural transformation
• Sustaining Cultural Change

However the good news about many BI professionals and consultants embracing change management as a necessary discipline does not seem to have filtered through to all quarters of the IT world. Many people in senior roles still seem to see BI as just another technology area. This observation is born out of the multitude of BI management roles that request an intimate knowledge of specific technology stacks. These tend to make only a passing reference to experience of the industry in question and only very infrequently mention the change management aspects of BI at all.

Of course there are counterexamples, but the main exceptions to this trend seem to be where BI is part of a more business focused area, maybe Strategic Change, or the Change Management Office. Here it would be surprising if change management skills were not stressed. When BI is part of IT it seems that the list of requirements tends to be very technology focussed.

In an earlier article, BI implementations are like icebergs I argued that, in BI projects, the technology – at least in the shape of front-end slice-and-dice tools – is not nearly as important as understanding the key business questions that need to be answered and the data available to answer them with. In “All that glisters is not gold” – some thoughts on dashboards, I made similar points about this aspect of BI technology.

I am not alone in holding these opinions, many of the BI consultants and experienced BI managers that I speak to feel the same way. Given this, why is there the disconnect that I refer to above? It is a reasonable assumption that when a company is looking to set up a new BI department within IT, it is the CIO who sets the tone. Does this lead us inescapably to the the conclusion that many CIOs just don’t get BI?

I hope that this is not the case, but I see increasing evidence that there may be a problem. I suppose the sliver lining to this cloud is that, while such attitudes exist, they will lead to opportunities for more enlightened outfits, such as the one fronted by Maureen Clarry. However it would be even better to see the ideas that Maureen espouses moving into the mainstream thinking of corporate IT.
 

 
Maureen Clarry is the Founder and President/CEO of CONNECT: The Knowledge Network, a consulting firm that specializes in helping IT people and organizations to achieve their strategic potential in business. CONNECT was recognized as the 2000 South Metro Denver Small Business of the Year and has been listed in the Top 25 Women-Owned Businesses and the Top 150 Privately Owned Businesses in Colorado. Maureen also participates on the Data Warehousing Advisory Board for The Daniels College of Business at the University of Denver and was recognized by the Denver Business Journal as one of Denver’s Top Women Business Leaders in 2004. She has been on the faculty of The Data Warehousing Institute since 1997, has spoken at numerous other seminars, and has published several articles and white papers. Maureen regularly consults and teaches on organizational and leadership issues related to information technology, business intelligence and business.
 

Mountain Biking and Systems Integration

Peter James Thomas business, systems integration, technology , , , , , , , , , , , , ,

Introduction

Mountain Biking

This is another in my occasional series in which I draw conclusions about business, technology and change from my experiences in various of the sports that I enjoy. The first article in this series was Perseverance, which compared the degree of effort required to succeed in rock climbing with that necessary in change management. Here I am going to focus on another of my pastimes, mountain biking.
 
 
Some background on Mountain Biking

Mountain biking (invariably abbreviated to MTBing, with the bikes themselves called MTBs) is something that I have got into more recently than rock climbing, but I suppose there are some parallels between the two. My path into rock climbing started with loving walking in the outdoors, which became hill-walking, which became scrambling (hill-walking where you have to use your hands to get through steeper sections), which eventually became rock climbing. Starting at the same place, MTBing is another logical progression from general and hill-walking. While rock climbing was about increasing the angle at which I moved (to vertical and then over-hanging), MTBing was about increasing my speed.

Another thing that rock climbing and MTBing have in common is their adherents’ obsession with equipment. With rock climbing this ranges from the shoes you use, to bouldering mats, to ropes, to the various pieces of equipment that you use to protect yourself. With MTBing, the focus is mostly on the bike itself.

There are two main types of mountain bikes: hard tails and full suspension bikes. Hard tails have a shock absorber at the front, but the rear is essentially the same as in a road bike. An example of two hard tails appears below – these are actually my bike and my partner’s, both rather muddy from a day out.

Two hard tail mountain bikes
Two hard tail mountain bikes

Full suspension bikes (as the name suggests) have suspension at both front and rear. The fact that you also need to drive the suspended rear wheel with the pedals makes these types of bikes much more complicated from an engineering perspective (and inevitably more expensive). While some zealots aver that all you ever really need is a hard tail, regardless of the conditions, the majority accept that a full suspension MTB will allow you to take on more challenging terrain with greater comfort and security. It is full suspension bikes that I will devote the rest of this article to.
 
 
The anatomy of a full suspension mountain bike

The following is a diagram showing the general anatomy of a full suspension bike; the UK version of a Specialized Stumpjumper FSR Elite (the US one currently being black). The image is copyright Specialized, one of the most well-know bike manufacturers, but the annotations are mine.

Full suspension mountain bike. Image © Specialized Bicycle Components
Full suspension mountain bike. Photo © Specialized Bicycle Components

As you might expect, one of the major factors influencing the performance of a MTB is the frame – this is the main structure of the bike, generally made from steel or alloy tubing, or sometimes carbon fibre in more expensive models. Helpfully in the diagram, the frame is essentially all the white bits. As we are talking about a full suspension bike, the back of the frame needs to flex in order to allow the rear wheel to move up and down.

The above design is for a cross country bike. This is the least aggressive type of MTBing and consequently places least stress on the frame. In this bike, the seat and chain stays (the triangular white bits at the back extending back to meet at the axle of the rear wheel) are both pivoted and their movement is damped by the rear shock absorber. In more full-on types of mountain biking (all mountain, free ride and down hill) the bikes can begin to resemble tanks – think of a 4×4 (SUV) compared to a regular car. Designs with a single, beefy swing arm at the rear are more common in these types of bikes.

However it is not the frame that I really want to focus on here, but the other components that go to make up the bike. Most of these are labelled in the diagram. Sometimes a bike comes complete with all of these and ready to ride. Other times you buy the frame only (or maybe the frame and shocks) and then add the other components that you would like to have. In this second approach the idea is to tailor the components to the type of riding that you want to do and of course to your wallet.

Often, even with a ready-to-ride bike, the owner might decide to upgrade some components, for example by purchasing a better front fork. Some of the manufacturers will sell you a ready to ride bike that has essentially all of their own components, but even then it is highly likely that the equipment for pedalling, changing gears and braking will be made by another organisation. On the bike in the diagram above, a lot of the components are from manufacturers other than Specialized. The range of other companies involved in the above bike includes:

  • Fox – the front and rear shock absorbers
  • SRAM – the chain
  • Shimano – the crank arm, chain rings, pedals, front and rear derailleurs, gear shifters and rear sprocket
  • Avid – the brake assemblies and levers (Avid are now part of SRAM)
  • DT Swiss – the rear hub (the front one being by Specialized)

It is also worth noting that Specialized, more than most other frame manufacturers, are known for producing their own components – they even make the shock absorbers for many of their models. On a bike from another company, the seat post, saddle, head stem, handle bars and tyres would all also be from another organisation; often different ones to those listed above.
 
 
The connection with Systems Integration

While, as mentioned above, the frame plays a very important role in determining how well a bike performs (and it is generally the most expensive part of the bike), what really leads to a great bike is how all of the different components are blended together. While Component A may be great on Frame X, working with Component B, it will be a much less good choice for Frame Y, working with Component C. The other factor that comes into this is of course cost and this makes a balance even harder to find.

It is in the above area that I see some similarities with systems integration. Here too the aim is to make products from different organisations work in harmony in order to deliver the greatest level of effectiveness at the lowest cost. Here too trade-offs will be necessary to meet the often incompatible goals of performance/functionality and cost. In systems integration, as in MTBing above, Product A may work well with Product B in Industry X, but be a bad option to run with Product C in Industry Y.
 
 
The most expensive is not necessarily the best

An interesting observation in MTBing is that simply picking the most expensive component in each category will not necessarily lead to the best performing bike. Some components suit the geometry of some bikes and work well in conjunction with other components regardless of cost. Here is just one example from a review of a bike in a magazine I subscribe to, Mountain Bike Rider (or MBR). The bike in question is a Giant Trance X5 and it just came first in MBR’s review of full suspension bikes under £1,000 ($1,500 – though it is probably cheaper than that in the US). This bike received a rating of 9/10 from MBR. Here is a picture of it:

Giant X5 full suspension mountain bike. Image © Giant U.K. Ltd
Giant X5 full suspension mountain bike. © Giant U.K. Ltd

This bike features an OEM rear shock as below (image copyright MBR):

Giant rear shock. © MBR magazine
Giant rear shock. © MBR magazine

Here is what MBR had to say about it (note that Fox – whose shocks were featured on the Specialized Stumpjumper above – produce both the most respected and most expensive shocks in the industry):

We found this presumably cheap own-brand unit to be the best we’ve ridden on a Maestro linkage [the type of rear pivot arrangement featured on the bike], whether by chance or design. It felt like it had less compression damping and married with the linkage better than any Fox unit we’ve tried. It was a lot more active, allowing the Maestro design to track the terrain better on this bike than on any other Giant Trance we’ve ridden previously.

It is worth noting that MBR terminology can be just as confusing as IT jargon until you get used to it. The above quote is actually relatively light on terminology.
 
 
Closing thoughts

While it is dangerous to extend some analogies too far, I think that there is something to be learnt here about how to run systems integration projects. It is the systems that work best with the other parts of the design that should be selected, not those that have the best features when considered in isolation, or those that come from the most prestigious companies.

It used to be said that buying the products of some IT vendors was a sure way to avoid getting fired (the vendors mentioned have varied over time). The above insight from the world of mountain biking suggests that looking beyond the obvious (and often more expensive) products may sometimes yield significant benefits.