Analysts vs. Bloggers (Continued)
Over at Sourcing Innovation, Michael Lamoureux has continued and expanded the debate about the differences between analysts and bloggers that I started on these virtual pages earlier in the month. I won't go into the details of his post -- read them if you wish -- but Michael takes a strong stand against analysts who, in his view, are too high level from a technology perspective. According to Michael, an analyst "should know the basics of how software works, how it is built, what good architectures, standards, and protocols are, and why." Personally, while I believe that analysts should have a deeper understanding than most when it comes to analyzing emerging technologies and looking at objective functional comparisons between solutions -- not influenced by vendor PowerPoints, but influenced by their personal experience and perceptions -- I disagree that getting down into the architecture and code level is necessary. And certainly a good analyst should not need the prerequisite capabilities of being able "to build an Excel-like spreadsheet tool in a reasonably modern computing language," as Michael suggests.
If those are Michael's qualifications for analyzing software, then I've been knocked out of the running for more than fifteen years (the last time I coded). But that's not the important point here. What matters is that I could just as easily criticized Michael -- and even myself -- for not having an in-depth understanding of what it's like to be a practitioner working for a company rather than a consulting firm. In the industry analyst world, I think one of the reasons why the perspectives of Mickey North Rizza and Debbie Wilson are worth hearing is specifically because they've worked as practitioners in the past. Neither Michael nor I can claim a similar experience on our resumes.
Granted, I have some sourcing experience under my belt -- and I continue to contribute to global sourcing projects on occasion -- but I'm not an expert in the politics of maneuvering around or within an organization. I also know Michael has worked with clients in the past as a solution provider, but it's not the same as working for or managing a procurement organization. In other words, I could disqualify the two of us from dishing out words of advice just as easily as Michael dismisses the credibility of the analysts. But I believe there's a place for all of us, and there's no need to go there.
Personally, I view myself as a career advisor, strategist, and columnist turned blogger. That's it. I would not pretend to be an industry analyst, but I certainly respect their role in the ecosystem, especially considering the one-on-one advice they give their clients. As to their written words -- with the exception of longer reports -- it's my view that they will become increasingly marginalized as more and more experts and pundits become bloggers and gain a voice in the Spend Management ecosystem. In addition, as is known by one large software enterprise who has invested significantly in blogger relations, it's the bloggers who will own the influence game in the middle market when it comes to technology and solution selection, largely because very few of these types of organizations have industry analyst relationships or contracts.
- Jason Busch
TweetBacks
I have been programming computers more or less continually since I was a mere lad, which at this point adds up to over 30 years of experience in the field. One of the frustrating things about being a technologist has been reading the marketing claims of various companies over the years (including companies I have worked for), and knowing full well that they are fallacious. This frustration is often compounded when reading the comments of analysts and other reviewers of technology products, who for the most part tend to accept those claims at face value, at least initially, since they often haven't the background to do otherwise. Even more frustrating is the analyst who will admit, off the record, that he doesn't believe the claim, but that he's forced (for some reason) to be even-handed in print. I suspect this is essentially what Michael is railing against.
As far as qualifications for analyzing software products are concerned, I think credentials can be earned in a number of different ways. I would argue, for example, that an Excel power user is perfectly capable of reviewing a new spreadsheet product, even if he can't write a spreadsheet himself. And, it's quite possible that an Excel programmer, who has been heads-down on some unpleasant task for the last 11 months in some microscopic area, may know much less about what makes a spreadsheet product truly useful than that power user.
What the Excel power user would not be able to evaluate, though, is a new technology for spreadsheets that could have downstream implications far beyond the external functionality of Revision One Point Zero. For that sort of insight, you do need a reviewer with a strong technical background.
My view is that the next wave of great enterprise app industry analysts/bloggers will have P&G brand marketing -- not coding -- in their backgrounds.
K
"If those are Michael's qualifications for analyzing software, then I've been knocked out of the running for more than fifteen years (the last time I coded)."
To which I say, not necessarily. The fundamental point is do you understand what code and architectures can - and can not - do, or not? Fundamental capabilities don't change over night - in fact, even with the rapid pace of advance over the last ten years, the fundamental capabilities of code and languages haven't changed that much (if at all) - what's changed is the ease of use and deployment. What can Java or Ruby on Rails do that you couldn't do with C++ or JavaScript precursors? Not much - the difference is in the fundamental usability and the productivity tools around the language and language constructs and the best practices that have emerged over the last decade. (Case in point - 10 years ago it was months of effort to build a slick shopping cart using CGI, C++, JavaScript, HTML, and embedded C calls in the C++ to Oracle - today it's just installing an off-the-shelf package and populating the catalogue.) We're still in OO, we're still in multi-tier internet development - and the only fundamental change from a hardware perspective is that multi-core / multi-processor machines are now readily available at affordable costs.
I'm railing against the analyst who has no fundamental understanding of technology and the analyst who has no fundamental understanding of what a spend / supply practitioner does every day. There are some analysts out there, as you point out, who can make the latter claim, just as there are some analyst out there who make the former claim, but, in this space, just as in many other business spaces, there are some out there that can not really make either claim (they haven't worked as a practitioner or in a service role for practitioners and have no fundamental understanding of technology) - and I truly don't believe that's enough to be an "analyst" because, as Eric said, they have to "accept claims at face value", and who knows what snake-oil they're going to be sold by a slimy salesman.
Second point, you took my post much too literally if you believe that I think you need to be able to "build an Excel-like spreadsheet tool in a reasonably modern computing language" in order to be technically competent enough to review products. As far as I'm concerned, if you understand what code is, how it works, can do some first year college programming, know what the differences between various architectures and delivery models are as well as what the various advantages and disadvantages are, and understand the basic standards used, that's enough. With that basic knowledge, the chances of having the wool pulled over your eyes are slim and you can do a very knowledgeable analysis of the vendor's claims and demos.
As blogger's we don't have to write about anything we don't (fully) understand. We can take the time we need to figure it out. If you're an analyst working for an analyst firm that just got $$$ from company X to analyze them, can you always say the same?
As blogger's we don't have to write about anything we don't (fully) understand. We can take the time we need to figure it out. If you're an analyst working for an analyst firm that just got $$$ from company X to analyze them, can you always say the same?
# Posted By the doctor | 11/15/07 8:50 AM "
...Bloggers are blogging for a reason, not for the sake ofit.
They are actually compelled to respond to events almost in real-time, whereas analysts can right a "report. Not saying either an analyst or a blogger is more likely to be insightful or correct, just pointing out that there is a reason for everything, and bloggers usually feel more compelled to write quickly without a lot of incredible depth.
Not to pick on Jason, but how many times have we seen a take that basically says "here's my quick post, but the real details to come later"?????
Great point, but I'm not sure why you referenced my comment.
I said bloggers "don't have to" write about anything we don't (fully understand). "We can" take the time we need to figure it out.
"Don't have to" and "We can" is not the same as "Don't" and "We do". I realize that most bloggers feel compelled to write quickly - as even I do sometimes - but the fact of the matter is that, should we choose, "we can" take time to figure it out because we truly "don't have to" write right away - "we won't" lose our jobs if we don't. I personnally prefer to wait on an in-depth analysis until I get it. Sometimes this happens right away (and especially when the bullshit detector goes into overdrive). Sometimes it doesn't.
But I'm sorry for interrupting. I'll let you get back to arguing against what you hallucinated I said. ( But if you have the time, check out "Yesterday's Post" by Scott Adams. It makes my point.
http://dilbertblog.typepad.com/the_dilbert_blog/20... )