My “(Blank) Needs a Mainframe” series of posts, such as the most recent Needs a Mainframe entry, are periodic reminders that there are effective, potent IT solutions that can help prevent catastrophic and costly security breaches: mainframes. Yes, I’m being deliberately provocative, but it’s time to shake some IT people out of complacency and their prejudices. We, the IT community (and its management, including business managers), are failing miserably, repeatedly. We are not protecting our users’ privacy and security. So let’s roll out more mainframes, now, because that’s going to help, a lot.

That said, it’s important to understand that security “magic” isn’t for sale. Most people would agree that mainframes, particularly those with the latest z/OS releases, are the most securable server platforms. They are also often the most secure, but that’s not a given and not automatic. Boeing and Airbus commercial airliners offer the safest mode of passenger transport, but if you’re either determined or careless enough then even those safe airplanes are crashable. Likewise, z/OS is chock full of wonderful security features and securability, but its operators cannot be complacent about security. Achieving and maintaining secure computing requires both the right technologies and talented people, preferably people who are at least slightly paranoid. Often, but not always, so-called “mainframe culture” includes a reasonable, healthy dose of security paranoia.

Another big reason z/OS is so securable is because it’s the only consequential operating system (and probably even the only operating system) that, within a single instance, is inherently multi-tenant and that so smoothly handles mixed workloads with differing SLAs. Other UNIXTM operating systems — yes, z/OS is a certified UNIX operating system — had different development heritages with different demands and development pressures. z/OS evolved in a unique way that’s quite helpful in promoting security. Moreover, because mainframes (and z/OS) are “I/O monsters” supporting mixed workloads, they make it possible to centralize (and recentralize) information, especially personally identifiable information (PII), authorizing (or not) every access, every time. They also uniquely facilitate true continuous business service when suitably configured and operated, and that capability also makes information centralization viable.

Think of it this way. If you’re trying to keep a secret, is it easier to keep a secret if 85 people know the secret or if one person knows the secret? Of course the latter situation is more securable. Likewise, mainframes uniquely facilitate thoroughly centralized information architectures with hundreds or even thousands of authorized application consumers/producers, and they do it with just one (or a couple, for continuous service) z/OS instances. With mainframes you can store, manage, and secure information “once and once well.” You do not have to copy your precious data to 85 (or 855) servers and try to manage that inherently unmanageable security nightmare.

….You can design and implement information architectures in highly centralized fashion with mainframes, and many mainframe owners do, with great results. Unfortunately, many do not. “Oh, just copy that data over here…” may be the spark that eventually ignites a security breach. Another problem: “Oh, just give us a RACF server ID that has access to the whole database….” See the problem?

But aren’t those mainframes impossible to work with and develop for? Expensive? No, and no. If there’s a major (or even minor), industry standard application development technology that a mainframe cannot run (and typically well), let me know. It’s at least hard to think of one. And of course it’s possible and highly desirable to authorize (at least) each and every data access request. For example, the base z/OS operating system comes with its own thoroughly standards-compliant, high volume LDAPv3 server (with TLS-encrypted connectivity) at no additional charge. So why aren’t you using it? I can’t think of a good or even mediocre reason why not.

I’m not happy with the wider IT community’s security performance right now, and I hope you’re not either. Let’s get our act together starting today.

Posted in IBM.

From time to time I check in to offer brief comments on the state of IBM’s mainframe business when IBM releases its quarterly earnings reports. Unfortunately we can only get an incomplete view since the IBM z ecosystem is much, much larger than server hardware revenues alone suggest. Even so, the server hardware revenues in the earnings reports may offer some clues.

IBM reported a massive increase in IBM z Systems sales in the first quarter. Sales more than doubled versus the year ago period, up 118% (130% at constant currency). Capacity deliveries increased 95%. These are phenomenal results, no question.

These results are partly explained by the fact the first quarter of 2015 was the first quarter of availability for the new IBM z13. IBM only started shipping z13 machines last month (March) in any sort of volume, but even with a partial quarter the results were astounding, even considering that the year ago quarter was well along in the previous model cycle. The results suggest IBM will have strong mainframe momentum into the second quarter and beyond.

It’s fair to say that IBM is becoming (or rebecoming?) more of a full scope mainframe company, partly as a consequence of divestitures and acquisitions. But it’s a new mainframe company because it’s also a cloud company. Becoming both simultaneously is not a coincidence; they’re quite related. The IBM mainframe is the original and best-of-breed cloud services environment, and the mainframe is capitalizing on (and driving) industry trends. Most importantly customers are buying, and how.

Simple math suggests that price per unit of capacity increased a bit versus the year ago quarter. That’s obviously good news for IBM since that means the company had huge sales without resorting to discounting. (Anybody can give away a product, especially a great product, but that’s not a sustainable business.) There is a reasonable explanation, though, and it’s one we’ve seen before. Capacity shipments at the beginning of a mainframe model cycle are heavily physical, weighted toward whole new machines and processors. To some extent capacity pricing inevitably reflects the more physical character of those shipments. In fact some mainframe customers don’t add capacity at all when they order the new model, but they still obviously pay for the machine. Later in the model cycle capacity shipments tend to be less physical, more focused on machine upgrades rather than whole machines, and in the past capacity pricing has reflected that shift to some extent. (We could also be seeing product mix effects within “mainframe capacity.”)

While I think we will see some lower capacity pricing consistent with past model cycles, at this point in history my preference would be to see surging capacity demand (check) and gently declining capacity pricing, model cycle to model cycle. That result is good for IBM, but it’s also good for IBM customers who rightly demand continuing innovation. We’ve reached a point where hardware, including mainframe hardware, no longer represents the lion’s share of IT budgets. It’s more like a mouse’s share, so even if hardware prices fall further IT budgets just won’t materially budge. Moreover, given the increasing difficulties working around the limits of physics and IT budgetary math, I don’t think we can reasonably expect hardware prices to continue falling so far quite so fast. Those increasing hardware design challenges should favor mainframes, as it happens.

Posted in IBM.