What’s an IT analyst, anyway?

I’m conscious of a couple of things as I set out to write this, what I hope will be short, entry. First – there is an ongoing debate about the nature of the analyst business, and the credibility of the analysts themselves. Second – many of the people who come to this site have no clue what I do as a day job. I hope to hit both birds with this single stone.

It all starts with buying and selling of Information Technology (IT). There are three kinds of product in IT, which are:

  • – commodity items, where a product has been simplified (I use the term guardedly, I don’t mean it is now simple) and packaged to such an extent that it can be sold off the shelf. Examples include PDAs, office software packages, hard disks and so on.
  • – solution components, where a product can still be packaged, but it doesn’t serve much purpose on its own. Examples are databases, blade servers, storage arrays and so on.
  • – IT solutions, where often-complex combinations of products are packaged and configured to meet often-complex demands. Examples include some of the enterprise applications, storage area networks, enterprise management software and so on.

End-user organisations of all sizes frequently need help, both in deciding what to buy, and what impact their procurement choices may have on their business. That’s where IT analysts fit in. Their primary role is to keep tabs on what technologies are available, what they can be used for and what constraints they impose. Based on this understanding, IT analysts can also offer advice to vendors – the IBMs and Microsofts of this world, to help determine what technologies are more appropriate for which audiences, and indeed where they should be investing their research, development and marketing dollars.

Within this blanket description, there can be a number of sub-types of analysts. End user companies do not require analyst reports on commodity products, for example. For commodity products, analysis is more vendor focused and tends to be oriented more around market research – which countries or regions are buying which products, from whom. Such information can be used to drive advertising and sales campaigns, but the “understanding” work is already done.

For solution components, analysis is done proportionately for both end users and for vendors. Very few organisations need to know what a database is, for example, but a guide to who sells what kinds of databases, and what features are present, is useful to both sides. End users can use such information to produce a shortlist of vendors, and vendors can use it to keep an eye on the competition – or indeed to promote their product as “best in class”.

For IT solutions however, analysis (whether paid for by vendor or end user) tends to be more focused on end user businesses. White papers can explain the ramifications of technology types, or help organisations understand what are the business problems to be solved – this kind of report is often supported by focused market research, for example to help understand which product features give the most benefit, or which issues are the most important to be solved. Longer reports can be produced, explainng the solution area and providing information about which vendors provide products to support the solution concerned.

There are a number of other categories. Some analyst firms choose to focus on specific areas, such as security or data management; other consider only their local regions. Some companies focus on service providers, or consultancy firms, or particular industries. Some are actually end-user consultancies that perform some analysis, and advise vendors almost as a spin-off benefit of their end user knowledge. Still others are market research organisations that specialise in IT, and so on.

When done right, IT analysis can be enormously beneficial to both sides. However there are some potentially major hurdles to be overcome. Not least, the analyst can play an highly influential role in some major buying decisions – either in terms of quantity (at the commodity end of the scale) or deal size (at the IT solution end of the scale). Influence can be direct, indirect or obscure and untraceable – if I was a strong advocate of hosted applications, for example, I might well attract the attention of hosted application vendors to promote the advantages of their products over in-house applications.

Quite rightly, then, analysts should be subjected to considerable scrutiny. Not least, there is a requirement for transparency – any formal analyst recommendation should only be served with equal helpings of context (“who does this apply to, under what circumstances”) and justification. This goes for the simplest of quotes, up to the most detailed of reports – even if the context and justification are not included for space reasons, they must be in some way available.

A second issue comes from the very nature of analysts to be “market makers”. The analyst’s job is to articulate the strengths and weaknesses of what are sometimes very new technology areas. One way to do this is to define the area concerned, generally by naming it in some way: in doing so, advertantly or otherwise, the analyst firm creates a market for that product. This was a reasonable approach in the past, when the majority of software applications were custom coded and most IT purchases were of solution components. These days however, we are in a very different playing field – IT refuses to be pinned down in the same way. SOA, for example, offers a terribly important set of principles that any IT shop should apply, but it does not map onto any set of products in particular.

Trouble is, IT marketing in some ways depends on this need to classify products, and some analyst firms fall into the same trap – areas such as Identity Management, for example, are impossible to characterise in this way. Some analyst firms still insist in trying to apply the old models to these new technology areas, but this just plays into the hands of vendor marketing departments who can then jump on board the bandwagon. However, given the fact that most products can only partially fit the definitions, the main result is confusion on all sides. Disparagingly one could refer to this as bandwagoneering – only in most cases, the wheels fall off the wagon almost the moment it is set off down the hill.

Finally, the vendor’s requirement for analysts is very different from that of the end users. Ultimately vendors are answerable to their shareholders, and they exist primarily to make money out of IT sales. End users require analysts to help them get the best value out of IT, to make their businesses run better. In the fast-moving game of IT, sometimes the end-user requirement for business value has been subordinated to the vendor requirement to make money. I’m not saying that analysts have been directly complicit in this, though of course this is what market research is for. What I would say is that sometimes, the analyst industry as a whole hasn’t always been as vocal as it could have been to protect against it.

I believe it is the combination of these issues that has led to the credibility, relevance and independence of analysts to be called into question. I agree that change is necessary – but I wouldn’t level the finger at any particular firm. Instead I would argue that the IT industry as a whole needs to change its marketing tactics, that the analyst industry needs some new models to help itself help its end user customers, and that finally that these end user customers need to be more demanding of their advisors. All of these things are happening, perhaps a little too slowly for my liking. I don’t believe the final answer lies wholly in blogs, or in open source research, though these are highly valid options, and indeed may be the necessary catalysts for change. Blogging is indeed rocking the foundations of analysis – indeed in some cases there can be a fine line between the two.

Meanwhile, there is some very good work being done by analysts across the globe. Perhaps now is the time to get back to basics, to assess what services IT analysts should provide, to whom, and how. The jury’s out and the only thing I know for certain is that it won’t be me that makes the final decision. I watch, and analyse, with interest.

What’s an IT analyst, anyway?

6 thoughts on “What’s an IT analyst, anyway?

Leave a Reply

Your email address will not be published. Required fields are marked *