Archive for May 2012

HP Whitepaper: Five Myths About Cloud Computing

Picture of US Rep. Ed Iron Cloud III

State Rep. Ed Iron Cloud III (D-SD). Because his name is completely awesome and relevant to this post.

The Big Iron vs. Cloud Computing fight drags on.

Today, I was sent a new whitepaper from  Hewlett-Packard wrote “Five Myths About Cloud Computing”.  I thought it was pretty interesting, as vendor-supplied research goes.

I mean, sure, it’s a whitepaper from a cloud vendor. Because that’s where it comes from, the “sell” part of it is right in there — HP’s Cloud offerings are myriad and this paper is at least as much about spreading awareness of HP’s cloud services as it is about properly contextualizing the cloud for enterprise IT folks.

But instead of the expected across-the-board rah-rah, this paper starts by debunking a common myth about the cloud: its cost is not the lowest. “Myth One: The public cloud is the most inexpensive way to procure IT services”.

There’s a subtle twist to this framing: what HP is doing there is not claiming a cloud approach per se to be more expensive, but rather the “public” cloud — a term that can mean different things in different contexts, but in the context of HP talking to enterprise IT, means competing services like Amazon EC2.  More sell.

And of course, baked within this thinking is a statement that leads directly back to Big Iron the kind of app your’re running should determine your best delivery paradigm:

Here’s a surprising fact: For resources that are needed constantly, enterprises can actually reduce costs by leveraging other cloud models, such as shared resources delivered via a private cloud. In cases like this, the private cloud actually is more cost-efficient than even the pay-as-you-use public cloud model. An analogy is the decision to rent or buy a car. For short-term use, a car rental is cost-effective because you pay based on what you consume. However, if you drive frequently and for a longer term, then owning a vehicle makes better financial sense. And beyond
price, there are other important issues to consider such as performance, security, compliance, service-level agreements, and availability.

Nothing surprising about that to the mainframe community! Performance, compliance, security, availability are our enduring strengths; we don’t fear comparison in any cloud context.

What’s the story in your shop?  Who’s advocating moving critical applications to the cloud, and how goes the discussion?

If you’d like to read the whole HP whitepaper, you can grab a copy here.

Ars Technica: How Mad Men sold computers in the 1960s and 1970s

DEC EAI 640 Ad Image from 1967

The DEC EAI 640: FORTRAN in the sunshine

Over at Ars Technica there’s a timely reflection on the marketing history of mainframes between the Kennedy and Carter administrations.  There’s quite a bit of fun learning about how the classic business marketing techniques of the era worked. The industry produced lots of print ads with art direction portraying a future where data entry clerks lounged and let the hardware do all the work.  Sometimes even outside, such as in the above photo  – presumably because stacks of punch-cards were somehow impervious to 1960s wind and weather?

For the full experience of the DEC EAI640 marketing, take a peek at a PDF of the full EAI640 brochure.

Most of the images in the Ars piece come from the truly awesome Computer History Museum of Mountain View, CA, the one place in Silicon Valley where the technologies and problem-solving of yesteryear aren’t forgotten by reflex.



BoA: Mainframe Careers Are Too Big To Fail

A bank entryway

Not bunk

The love affair between banks and mainframes, like all love affairs eventually do, needs some freshening up.

The biggest of the TBTF (Too Big To Fail) banks are a major recruiting presence on college campuses, according to CIO Magazine.

This is because the decline in the number of new college grads with any mainframe training has gotten the attention of (a more charitable way of saying “woken up”) execs at large financial institutions, prompting a type of foresight-fueled action for which these behemoth banks have never before been known.

Quite the opposite. In 2008, TBTF banks did everybody in the world the favor of loudly demonstrating that the underlying assumptions of “free market” capitalism were null and void; that the “most successful” of the banking sector were in fact enormous, staggering failures, and that these failures, huge as they were, carried no real consequences for the responsible parties in the corner offices.

In other words, the financial disaster of 2008 was the biggest job security story in business. By extension, plenty of that security extends to mainframe computing.

Underneath (way underneath) these failures were the mainframe shops, the engine rooms of finance. They did no failing whatsoever. High-volume, high-MIPS jobs running hard on big iron, keeping everything afloat, putting the bank’s money where it had to go.  (And putting plenty of other people’s money into the bank, but that’s for another post).

The criticality of these critical applications — call them “apps” and I’ll personally come over to sock you one — are the driver for this campus recruiting effort by banks and by Big Blue and other vendors.  They are simply too critical to pass along to other hardware.

And a decline in trained professionals plus a steady demand for these applications equals high demand, high pay and high job security.

That’s one reason why Kimberly Grim, SVP of Mainframe Engineering at Bank Of America calls mainframe systems “very safe”.  Because especially in the case of BoA, the business itself is very safe from failure. Its critical systems therefore share that safety.

And that’s also why over 600 colleges, universities and high schools around the world are participants in IBM’s Academic Initiative.  The word needs to get out about mainframes as a hedge against an uncertain technology employment world.




The 3270 Terminal

Howdy.  I’m Blue.  I’ve been around mainframes — Big Iron — since around the Y2K scare.  Sure, that was overblown, but I tell you, we found some bugs. Nothing that would lose track of a billion dollars of course, but misnamed reports and columns, that kind of stuff.

Now the IT world at large might scoff, but I think we did great work.  Given the monumentally limited attention spans and woeful skill sets of the management people in FIRE — finance, insurance and real estate — aka the people that depended on these reports, we actually were saving the world back then.  These corner-office types are people for whom the slightest distraction could lead to millions in lost time.

I’m not the most grizzled veteran.  Hell, I’m not even grizzled generally, and the last COBOL I wrote was on punch cards in high school in the 80s.  But I do have an abiding respect for the high priests of Big Iron and I’m always learning.  That’s what Big Iron Works is about: learning and sharing mainframe systems knowledge.  And trying to figure out how the world is going to run its banks and governments when we’re no longer around to slap the hands of the clueless away from screwing everything up.

So subscribe to the RSS feed, follow us on Twitter* and let’s get serious about Big Iron. Guerilla mainframe.

- Blue



*If you’re not already – there are over 3,100 followers of @bigironworks at press time!