James Governor's Monkchips

A Tribute to Bob Evans From Legacy Boy

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Sad news a couple of days ago of the passing of Bob Evans, one of the key architects of IBM’s System/360, fore-runner to today’s zSeries mainframes. I never had the pleasure of meeting Bob, but that didn’t stop him defining my career.

That is, when i entered the business as a junior reporter, my first news editor told me to cover something called MVS, a weird and wonderful technology with its own associated communities, linguistic tics, prejudices and fears. I had to learn about subsystems such as VTAM and networks running SNA. Heck these machines didn’t even understand ASCII! Mainframe execs from companies like Amdahl and Hitachi Data Systems would look at me skeptically as if to say: “where are the grey hairs?”, which made me all the more eager to deepen my own knowledge on the subject.

Meanwhile my colleagues had “cool” companies and technologies to cover: Allaire, Bluestone, Amazon.com, Bay Networks, Intel, Cisco, FreeMarkets, Netscape, Microsoft, Yahoo, the list was endless. Many of the firms they covered aren’t around any more. Some folks on a networking title down the hall at the time called me Legacy Boy, and the name stuck. AS/400, VMS, UNIX, VM/VSE, CICS, IDMS, IMS, they all went into my intray. Esoteric (now fashionable) disciplines such as application lifecycle management, chargeback, deep instrumentation, job scheduling, system automation, virtualization, and workload management were all heaped on my plate.

I quickly learned that mainframes had longevity on their side because the appications they run often *are* the business. What are you going to do–turn the revenue producing engine of a business off while you migrate to something else that might do as good a job?

Why were so many companies maintaining and extending these apps? Because of the extraordinary engineering efforts of the likes of Eric Bloch, Fred Brooks and Bob Evans, which underpinned IBM’s stark and unprecedented commitment to backwards compatibility. New hardware and performance improvements didn’t require new software and programming models.

Over to Bob in Wired:

Banks would assess the applications they had to run and make the decision about the computing power they needed,” he said. “The beauty of it was that, in most cases, as their business needs grew over time, they could just move to a bigger machine, and run all their applications on it.

Sounds just like On Demand business doesn’t it!

Bill Gates often likens Microsoft operating system development to a moonshot, which points to a certain envy. After all, the S/360 actually got a rocket to the moon and back. Now that is mission critical – and this technology was delivered in the late 60s…Apollo, Mercury, Gemini, those are project names we all remember.

Somewhat ironically Gates choose last week, in an interview in news.com, to favorably compare Microsoft’s efforts to build its once and future operating system, Longhorn, with IBM’s own systems moonshot.

“Our scheduling and predictability on this project has been better than it was on OS 360 (the mainframe operating system created by IBM). So software has not gotten more complex. Software with this kind of scope of features and compatibility has always been complex. That’s the business we’re in.”

What more fitting tribute to Evans and his colleagues, then, than the fact Gates is still comparing his own company’s efforts with theirs, 40 years on? This is not to criticise Microsoft–it has just made a bold, customer-focused decision to decouple the elements underpinning Longhorn in order to better suit developer and customer requirements. The age of the monolith is past, and service orientation requires encapsulated, decoupled services.

There is one other, more formal tribute to note–Bob Evans happily got to see S/360’s 40th birthday earlier this year… with customers still getting business value out of the architecture he helped design.

No Comments

Leave a Reply

Your email address will not be published.