What We Have Is A Failure To Interoperate. Let's Change The RulesWhat We Have Is A Failure To Interoperate. Let's Change The Rules
E-mail and group calendaring are 1990's technologies. Yet, for some idiotic reason, they still only work well when everyone is on the same vendor's system. Interop's general manager Lenny Heymann, who uses Lotus Notes, can invite me to a meeting that ties in a Cisco MeetingPlace-based teleconference, and thankfully, I can accept that invitation in Gmail. But what if that meeting moves to a different time (as meetings so often do)? That's where the interoperability ends. If Lenny changes the tele
March 3, 2008
E-mail and group calendaring are 1990's technologies. Yet, for some idiotic reason, they still only work well when everyone is on the same vendor's system. Interop's general manager Lenny Heymann, who uses Lotus Notes, can invite me to a meeting that ties in a Cisco MeetingPlace-based teleconference, and thankfully, I can accept that invitation in Gmail. But what if that meeting moves to a different time (as meetings so often do)? That's where the interoperability ends. If Lenny changes the teleconference time in MeetingPlace, the notification I get is an abomination of technology that can't interoperate with the originally booked meeting. Who's to blame?By the time Gmail gets that notification, (a) Gmail doesn't know what to do with it (it doesn't even recognize it as some sort of calendar request), (b) it's indecipherable to the human eye (in other words, I hardly know what to do with it) and (c) I'm left tapping my fingers as I listen to on-hold elevator music for a conference call that, for some strange reason, no one else is attending.
Even worse, with three vendors involved (IBM, Cisco, and Google), there's no remedy. For example, there's really no one for either Lenny or me to call to fix the problem. OK, I actually know who to call because I'm in the press. But if you're in Lenny's spot, do you? Not only do we have a failure to interoperate, we have a failure to communicate. 1991 In addition to Interop, there were two other big week-long IT shows (Comdex and Networld) in the industry in the early 1990s. Shortly after joining PC Week magazine in 1991 as a tester and reviewer of networking products, I got to attend all three events back-to-back, one right after the other, in search of all things-networking to write about. It was a three-week trip that took me from Boston (home) to Dallas (NetWorld) to San Jose (Interop) to Las Vegas (Comdex) and back to Boston where I finally had a chance to position the three mega-events in my mind. NetWorld and Comdex were great events. But, in true trade show fashion (and in the course of every vendor making the most out of the exhibit space they'd been allocated), NetWorld and Comdex felt to me as little more than organized islands of technology. Neither event felt as though it had any lifeblood or soul to it. Rather, they were just temporary malls erected in homage to the annual pilgrimage that so many IT pros were willing to make to both events. The problem with Comdex, NetWorld, and most malls is that they were (and, in the case of malls, are) all about selling. From that moment I set foot on my first Interop show floor in San Jose, I knew that it was about more than selling. Rather than being just another collection of vendors pimping their latest gear, Interop oozed a culture of conversation and community that the other events seemed to lack. Interop was, and still is, part and parcel about selling. But the big difference was that gear-sellers might as well not even show their faces at Interop if they weren't also prepared to demonstrate how well their technologies interoperated with those of the other gear-sellers over the ShowNet (as well as with a toaster or two for those of you who remember ToasterNet). At Interop in 1991, interoperation with dissimilar gear (or the toasters out on the show floor) was as much enigma as it was reality. If it interoperated, it probably involved some last minute ingenuity, a handful of alligator clips, and in many cases, a bit of divine intervention brought on by hand-holding engineers in group prayer. In other words, the challenges that gear-sellers were having in getting their gear to interoperate mirrored those that their customers (and Interop attendees) were having back at home. Even better, unlike with Comdex and NetWorld to which vendors sent their most polished salespeople and public relations personnel, gear-makers sent their engineers to Interop -- a different breed of jean-and-T-shirt clad geek to whom blinking lights (an indicator of interoperability) were so much more exciting than the almighty buck that they could talk for hours about what it took to get those lights to shimmer green. And they did. At standing room-only birds-of-a-feather sessions, instead of a sanitized sales pitch, Interop attendees got the unvarnished truth about what worked, what didn't, the lessons learned (lessons that attendees could take home to their own shops), and the steps that had to be taken in order to achieve that next plateau of interoperability. It was so refreshingly transparent and the conversation was so rich that we all joined it as though the challenges were ones we faced together. That's because we were in it together. Today Sadly, things are different today. Interoperability breakdowns represent the same pain points that they always have for us users. They've just moved upstack from where they were in 1991. Some are gear related (I have to reboot my home network at least once a day to get back on the Net) and others, like group calendaring snafus, live at the application layer. Unfortunately, the issues are no longer co-owned the way they were in 1991. We've grown to accept a top-down world (vendors at the top). If you're having some sort of interoperability challenges, you pretty much have to pray that the people responsible for that lack of interop see the problem at the same priority-level as you do. More than likely, they don't. The solutions you use are constantly getting updated with new features. But somehow, the old ones still don't work the way you expect them to. Interoperability may be your pain point. But, somewhere ahead of that pain point in some vendor's queue is a feature war. We used to have a voice in setting the technology agenda. And isn't that the way it should be? After all, aren't we the ones with the money? Isn't the customer always right? (in other words, shouldn't we be on top...or at least on par)? Now, the agenda gets set for us and so what if our pain-points aren't on the list? When Lenny came to me and asked me if I might be willing to join Interop's ranks as its official blogger and evangelist, we came to an understanding that there was real value in Interop's heritage of playing host to conversations that led to progress for all stakeholders. Interop should, as it always has been, be a great place to discover solutions that can drive your businesses and organizations to greater levels of success. But it's also the perfect forum to aggregate our voice in such a way that holds solution providers accountable for those nagging failures in technology that nothing ever seems to get done about. So now, Lenny has empowered me to provide that forum at Interop. But for it to work, we also need you to step up and take ownership. Not just of the conversation, but of Interop itself. It's time to make the issues your issues and to make Interop your show. While I have a few pain points of my own (and not just in interoperability), I can't promise to know all of yours. But if you tell me what they are, together, we can put them on the Interop agenda and make it clear to our solution providers (all of whom are there because it's the only major IT show left in the business) that there are really only two choices: they can continue to be part of the problem. Or they can be part of the solution. So, what are your pain points? Send me mail. Send me screenshots. Send me video of something going wrong. Send me anything. Let me know at [email protected] and, together, let's see if we can't use the Interop stage (and my blog) as a forum where we can finally bring resolution to real problems.
About the Author(s)
You May Also Like
Cloud Security Maturity Model: Vision, Path, Execution
Processing principles under the GDPR, CCPA, and the EU-US DPF
7 Steps to Build Quantum Resilience
Solution Brief: Fortinet FortiFlex Delivers Usage-Based Security Licensing That Moves at the Speed of Digital Acceleration
2022 Retrospective: The Emergence of the Next Generation of Wi-Fi