In riffing on an excellent interview with IBM’s Doug Heintzman on John Simonds’ blog, my esteemed colleague distilled out the following lesson from some of Doug’s comments: “I would argue a passion for learning is the single most important character traits in an industry analyst.”
If that statement’s true, and I believe it is, then I’m a poor excuse for an industry analyst. One need look no further than this post of mine from July:
Last November, I expressed some frustration with the generally accepted (in the media, anyway) meaning of the term “service.” The view of a service as something defined and delimited by the boundaries of SOAP, WS-* and so forth was something I saw as not only artificially limiting, but blind to the realities of a world increasingly driven by services over a variety of protocols. This certainly was not the only missive in my campaign to blur the conventional wisdom of what constitued a service: underlying publications like the COA and pleas on behalf of the developer community, it’s been a common theme in these parts.
Fast forward eight months, and what has changed? Very little. Vendors still tout their abilities to generate WSDL for services to be piped from one machine to another via SOAP, which although eminently appopriate in some settings, are just as inappropriate in others. Very little attention is given to non WS-* approaches.
Guess what? We’re yet another six months down the line, and I’m still no closer to my goal of driving ATOM, plain old XML, REST, RSS and the like into the enterprise vendor vernacular. In other words, I’ve learned nothing from my abject failure. Nothing at all; I’m still astride my shaky, knock-kneed steed, tilting futilely at the complexity windmill.
I was reminded of this particular deficiency this morning, when I had the opportunity to speak with notable platform and tools vendors on their latest offerings. Aimed at different audiences and spaces, the lone common thread was a desire to target customers interested in building out Service Oriented Architectures. Both vendors had a lot to be excited about, but it was rather was missing that got me: a definition of SOA that included, say, mashups.
Call me crazy, but I believe that the folks attending Mashup Camp – which is completely booked, incidentally (Larry Lessig’s on the waiting list – and Scoble’s #55?!) – are as important to the future of SOA as any of the major infrastructure vendors.[1] Why? Because they’re showing us – daily – what developers can do when they embrace a services-driven approach. And what they’re showing us is amazing; rapidly generated applications that combine services seamlessly, in a truly 2+2=5 fashion. If I’m talking about the past, present and future of SOA, mashups aren’t going to be the only future I talk about, but they’ll certainly be a part of it.
To their credit, when I discussed the omission of some of these lightweight technologies, the folks on both calls were quick to acknowledge their importance. But the fact is that they weren’t on the slides in the first place, meaning that either they’re not perceived as important by the vendor, their clients, or both. That is, of course, their perogative. It would be foolish to assume, however, that just because most vendors don’t see the opportunities there, that none will. Some, in fact, are all over the concept – and their application is clearly set to benefit.
If we’re using the major enterprise vendors as a metric, I simply can’t learn. But when I look at housingmaps.com, chicagocrime.org and the like, I can’t help but think that there are a couple of vendors in desperate need of schooling. Who knows, maybe they’ll need an analyst 😉
[1] Alex and I were discussing at lunch the other day how ridiculously talented the attendee list is (yours truly being an exception, of course). I’m really looking forward to camp.
