Car racing was in its infancy in Australia back in the
1950s and for the majority of readers of this blog, the name Jack Murray likely
means very little. What captured the minds of many Australians was the idea of
a round-Australia car rally when few roads were to be found in the harsh
interior of this oldest of all continents. And yet, “the thought of driving
around Australia was unheard of, and they were concerned that there would be blockages
on narrow roads of trees and so forth," (Jack’s son), Phil Murray said.
A solution came from an unlikely source. “Jack's
navigator, a construction expert, suggested they take along some gelignite for
quick removal. This never occurred, but after all who's going to cart three
boxes of gelignite around the country without letting off a stick or two?"
Mr. Murray said. But then again, it was reported in the July 1954 issue of the
Canberra Times “that police questioned Mr. Murray and his co-driver Bill Murray
‘concerning a mysterious explosion en route to Melbourne’, but the pair denied
having any "gelly" in the car.
With that, the legend of “Gelignite Jack” became a
household name that attracted a following among a population still recovering
from WWII. A hero to many, perhaps given such antics, but to his fellow racers
a huge distraction such that whenever his car approached that of a competitor,
he was given a wide berth. Then again, it wasn’t the first time a sportsman
went to great lengths to throw a competitor off their game.
For many years at Tandem Computers it wasn’t unheard of
to reference Substitution and Distraction, or as it was better known as,
S&D. As the need for software escalated it wasn’t uncommon for Tandem to
enter the marketplace with a barely finished product. Tandem faced stiff
competition from established vendors where its only plan was to distract the prospect.
Gelignite Jack may have thrown a stick of “gelly” into the fray but for Tandem
it was more a case that a PowerPoint slide or two was all that was needed to
unsettle the competition. This was something I experienced firsthand on two
separate occasions; once as a program manager the other as a product manager.
Many in the NonStop community will remember NonStop
NET/MASTER. I had the pleasure of being the program manager and relished the
idea of bringing a product to market. The opportunity to do so meant that I
would leave Sydney, Australia, to pursue a career change in the U.S. All good.
However, even as the program was gaining momentum along came a competing
product originating as it so happened in Sydney. A product called Prognosis
that would become very popular with the Tandem community of the day. How to
slow down its progress and call into question its viability?
The distraction came quickly. Tandem executives rallied
behind NonStop NET/MASTER calling it a strategic product initiative with wide
ramifications across all that was being undertaken in development. Not just a
network monitoring tool but one that would monitor and manage systems and
applications along with the network. After all, calling out a product as being
strategic to the company had to count for something after all. As for
substitution that was easy enough; play the IBM compatibility card. NonStop
NET/MASTER complemented the IBM implementation of NET/MASTER – what could
possibly be better than that?
History now records that indeed it was the independent
development of Prognosis that prevailed long term and remains the primary tool
for monitoring and managing modern NonStop systems to this day. With this in
mind, you could say that once bitten twice shy, but that was just the
beginning. Moving to product management brought about another instance of
deploying S&D. This time, on an even grander stage! Remember SNAX? Even
today, where NonStop systems are subject to ongoing development, SNAX remains a
constant reminder that architectures and products can change with just the
blink of an eye.
With one of the biggest development groups behind it,
SNAX delivered solutions with which NonStop systems were able to give IBM
mainframes a superior way to interface to mission-critical networks. SNAX was a
dealmaker and without SNAX, connectivity would have been limited and when the
SNAX team rolled our SNAX/CDF, the IT community took notice as no other vendor
had ever managed such an achievement.
However, even as CDF was gaining a foothold, along came
a competitor from another Sydney based startup called ICE and almost out of
nowhere, the SNAX organization was under threat, this time with an
implementation that they had longed to pursue but had failed to get management
buy in. S&D? Absolutely and without remorse! If the approach against
Prognosis was to play the strategic card when it came to ICE, it was much
better to play the technology experience card.
Networking for NonStop was just that critical. Why turn
to a two or three man company this important product for the NonStop user?
Surely, it would be risky to entrust something that important to a new entrant
into the marketplace? You would have to be crazy, right? The NonStop team had a
demonstrable track record with support for the most important of all middleware
offerings on NonStop after all. As for substitution that was easy as well. We
took a page out of the IBM playbook and went with FUD – fear, uncertainty and
doubt. Experience trumps novelty every time.
When reality finally overtakes perception, you just
have to turn to distracting potential clients. This has been apparent from the
NonStop regional events that have been held. When multiple development organizations
have chosen an industry standard approach complemented with open solutions then
it becomes all too easy for a proprietary approach to dig deep into the S&D
parts bin. In this case, it is only natural to turn the spotlight onto
availability and question all those choosing to go down the industry standard
and open solution path about their commitments to supporting availability.
Whenever you have competing architectures you will
always have competing arguments. It’s just second nature to go all-in on the
architecture that you have chosen. For the NonStop community this is a positive
outcome from having multiple vendors committing their dimes in support of
solutions meeting an all-important and critical aspect of NonStop operations.
Like all good architects, the question of S&D in this case may as well be
as explosive as Jack hurling a stick of gelignite into the discussion.
When it comes to availability there is little
difference between synchronous communication and asynchronous communication, particularly
when it pertains to supporting business continuity. Getting down this deep into
the chosen architecture matters little as both achieve the same ends – keeping
that most important of all currency consistent. That currency being business
data; data created on NonStop. Both architectures strive to avoid data loss but
here’s the big news. After nearly four decades supporting business continuity
via asynchronous communication, there has not been a single reported instance
of data loss.
Not only is reality overtaking perception but when it
comes to possible, then yes, as the word suggests, it’s possible. But not
probable as history has shown: What is considered probable is likely to happen,
but not for certain. And for nearly four decades this has been borne out by the
many NonStop vendors who have relied upon asynchronous communication even as
such communications has provided improved performance with greater consistency in
response times. Turns out, Gelignite Jack looks to have forgotten to light the
wick!
For all the time I have been associated with NonStop
there has been numerous times where competition has led to some serious S&D
and when it comes to business continuity it’s proving to be no exception. Going
alone with one communication model versus the industry certainly qualifies as
substitution but ultimately, it’s just a distraction. Discussion among software
architects is a good thing for the NonStop community as it represents a healthy
regard for providing the best possible solution to any business requirements.
But let’s not forget that in this case, it’s more a distraction than anything
else and should never substitute for the value that comes with offerings that
are committed to the pursuit of higher performance, conforming to industry
standards complemented with open solutions.
Comments