Plumbing the Taxonomy: Why? Part F - New Business Value

How appropriate for the first post of the new year: the final value on the "Why" dimension is about new business value.

The fact is, if the mainframe really is the most leading-edge business computer out there, then it must be able to take on some seriously leading-edge new business computing.

This is important for many reasons, including that it's one of the best ways to optimize the value and culture you already have in your mainframe environment. As I identify more thoroughly in a white paper which has been sponsored by Terma Software Labs (click here to download a copy), one way to move your mainframe context forward is by empowering a new generation to become ambassadors between your mainframe culture and the other cultures affected by your mainframe. Another key way is through undertaking new technical initiatives such as installing new generation management and analytics software.

Add to this using the mainframe for brand new business activities, and you have the essence of this final "Why" value.

Now, speaking of new value, I'm also making the decision to remove the monetizing advertisements from this blog.

As the folks on one of my favourite TV shows point out, failure is always an option. In this case, not only have I not found that the ads generate any significant revenue, but more importantly I'm increasingly unhappy with the nature of the ads, and I don't feel they represent the quality that this blog and company are about. This blog is intended to bring value to people whom I respect, and I don't feel like I'm being very respectful by forcing you to see these ads. So, I'm calling the ads a failure and moving on without them.

Plumbing the Taxonomy: Why? Part E - Analysis and Planning

One of the things that really annoys me about modern business IT is that the decision makers and their closest advisers, including IT Architects, often have no clue about the role of the mainframe in their environments, even though they've bet their businesses on this most reliable of platforms decades ago, and would not survive without it.

As a result, you get some very odd and skewed perceptions and depictions. One of these is the IT Architecture diagram, a poster-sized picture of an organization's IT context that the Architect has spent a very long time fine-tuning to make it look just right. If you were to take into account all the time and effort that goes into one of these posters, they could easily be seen to have cost an organization over $100,000 to produce - which is nothing compared to their potential cost to the organization if done wrong.

Which they invariably are if the role of the mainframe is missing or understated - which it almost always is. Because the architect will spend months talking to all the people who have servers and routers, closets full of IT devices, and special projects, and create a politically-correct depiction of what they heard from all the people they talked to. And maybe they briefly talked to one or two mainframe-relevant people, and maybe they even stuck a picture of a little mainframe in the bottom right corner of the diagram just to keep from annoying those legacy dinosaurs. But the glorious new technology that is lighting the way and has all the political weight: that is far and away the bulk of the diagram.

Except that, if the IT Architect were to draw a picture that took into account the business value and essential role of each device, the mainframe would take up an unweildy majority of the poster, as it is the keeper of the corporate jewels - but that's "not fair" to all the other IT people affected.

And if the IT Architect were to draw a picture that shows the role of every machine in every application, the mainframe would show up as the foundational platform for just about every major application, with the other platforms providing barely more than cosmetic additions and user interfacing, but the essential data and processing held firmly on the mainframe.

The problem: politics and ignorance (and you thought IT would save us from the human condition). The other platforms take so many people to maintain them that they have far more political weight than the mainframe. And the mainframe works so invisibly well that everyone only notices the squeaky wheel and sizzle platforms that are barely more than nail polish on the underlying functionality provided by the mainframe.

But what has this rant to do with the "Analysis and Planning" value in the "why" dimension? This: not only does the mainframe offer so much value that any legitimate IT Architecture diagram would be mostly mainframe with tiny bits of the other platforms scattered like ornaments on a tree (like the seasonal reference?), but properly characterizing, understanding, and building on that value has the potential to bring more business value to the organization that is paying for IT like few other cost-effectiveness initiatives could.

And the software with this role gives the needed insights into resource configuration, usage, and future scenarios, therefore playing a role with significant business value, ensuring that the return on investment for the mainframe just keeps going up, regardless of what the IT Architects and other decision makers may decide to do with the minor platforms in the environment.  

This is especially important combined with proactively responding to new initiatives - but that's the next (and last) value on this dimension, so I'll save that for the next blog post.

Plumbing the Taxonomy: Why? Part D - Cost-Effective Operations

The "KISS" principle ("Keep It Simple, Stupid" or some gentler variation on that) has long been a key principle for effective living and business. It is closely related to keeping things affordable, as simplicity tends to be a good countermeasure against unnecessary expenditures.

In large-scale IT, keeping to these two principles is essential to maintaining the proper cost-benefits balance that keeps IT viable rather than it becoming an upward spiral of price and complexity.

So, this value of the "why" dimension is all about the business benefit of well-run IT. Over the years, many efforts have been made to document and codify how this is done - one of the more successful ones is ITIL - the Information Technology Infrastructure Library. Interestingly, this definitive set of guides that characterize a well-run environment is essentially the depiction of a functioning mainframe environment - in this case, the one at the British Government.

Where the software relevance comes in here is the selection of tools which create a layer of business-enabling simplicity, keeping IT easily manageable and consequently paying for itself. And that's an important business value!

Plumbing the Taxonomy: Why? Part C - Security, Integrity and Compliance

During my years working as an employee of provincial and civic government, I discovered the importance of a special kind of incentive: removal and avoidance of pain.

We all know (I hope) that it's inappropriate to bribe government employees to get better or faster results from them - and that getting caught doing so could land everyone involved in jail.

What recent history has shown, however, is that there are many other types of business misbehavior that can land people - CEO's in particular - in jail, or at least get them and their organizations sued and/or sanctioned. And some of those types are also business MIS behavior.

So, if you want to incentivize a government employee - or anyone who works for a large, rule-bound organization (i.e. the kind that's prone to have a mainframe) - rather than giving them something, you want to take something away: negative experiences, consequences and potential for consequences, aka pain.

In the world of MIS (does anyone still use that abbreviation? it makes for some great puns), where some of an organization's most sensitive data and activities take place, having data or processing compromised can trigger significant pain, from regulatory audit findings and related sanctions to legal and criminal trouble for executives. Compromise can include exposure of confidential personal information of customers and citizens, leading to great expense to "make it right" as well.

All of which illustrates the value of ensuring your organization's most sensitive data, processing and business behaviors are provably compliant with relevant regulations, and sufficiently secure that only legitimately authorized parties have appropriate access to it.

Consequently, this is an essential value on the "why?" dimension of solutions used to manage large IT enterprise environments, particularly those that include mainframes.

Plumbing the Taxonomy: Why? Part B - Continuity

How quickly can you reboot a bank if it crashes? And how do you access your accounts in the meantime?

What do you do if the air traffic controllers' computers suddenly become non-responsive - can you put the airplanes in a suspended state?

Why is it that we take for granted that the largest, most critical organizations on earth will keep functioning, 7x24, 365 days per year?

Because Continuity is a business mandate that is built into the computers that can be trusted to keep the world economy, and other critical areas, functioning.

And many of the software solutions that keep mainframes running so well have this reason for their existence: to keep the business running even if something bad happens to the mainframe. That can include backup and recovery, real-time fail-over to another mainframe (likely elsewhere in the world in case of natural disaster), and just the ability to see a problem coming and get everything in place to prevent or quickly deal with it.

This value of the "why" dimension is worth the entire existence of some organizations. If a bank suddenly stopped operating for hours, it would take a potentially lethal financial hit. If it stopped for days or weeks, it would likely go out of business. So its mainframe computers must have the necessary solutions for continuity to ensure that the bank doesn't crash. And yet, so few non-mainframe environments have ever done a successful recovery test of their entire production computing configuration - or even the most critical part - often, even in organizations where they have a mainframe that has done such disaster recovery testing and planning.

That's one of the reasons why the mainframe is such an important part of keeping the world economy running, and why Continuity is such an important value of the mainframe.

Plumbing the Taxonomy: Why? Part A - Business Enablement

Welcome to the second dimension of the taxonomy! And this value is the most basic of reasons for running something on a computer, mainframe or not: to do the work of the business that's paying for it!

To be more specific, this is about the applications that provide specific business deliverables that drive revenue, handle accounting, manage products, and basically act as the core competence of the business that's paying for IT.

This is why computers were invented in the first place: to enable organizations to perform their core business activities in a faster, more reliable, automated manner.

Everything else in the taxonomy (with the possible exception of the last value in this dimension) serves the business indirectly, but this value is what it's all about. Therefore, anything that calls itself an "application" probably includes this value of this dimension.

But - and here's the interesting thing - this is only one of several values in this dimension, so there are other business reasons for computing than just performing core competence processing!

However, if you don't have this one, you definitely have a problem with your IT.

Plumbing the Taxonomy Part 7: Production

As we conclude the "what" dimension of the taxonomy, the topic of this post is about "Production" - the day-to-day running of scheduled, coordinated activities that keep the mainframe and related business running smoothly.

Many of the solutions that are responsible for this value also have an automation aspect - most notably, those which are considered Workload Automation. In those cases, this is the "workload" value as complementary to the "automation" value of such solutions.

The workload includes running all of the "batch" tasks that production applications require. Other words used for "batch" include "offline" and "background". 

Your average user never knows or thinks about these things, because they don't talk to them. We're all used to dealing with banking machines, which are online or foreground. But there's a need for additional processing that doesn't require people to intervene - but does have to run regularly.

As an example, when you receive your utility bill in the mail, it was likely created and printed by programs running in batch mode, which pulled up the account information for you and every other customer, turned it into a bill, and sent it to the printer, all without human intervention.

And it is precisely the ability to schedule such things to run regularly without manual involvement that allows these bills to be created and sent out with such regular reliability.

However, it's not just a single step process. Often, there are "jobs" (i.e. a set of programs that are designated to run together in the same sequential order every time) that run first to perform one task - such as get all the billing information for today to be further processed - which are then followed by additional ones that only run if the first ones complete successfully (which they don't always do, for many different reasons).

So workload automation allows for the grouping, scheduling and coordination of many such jobs and applications in a regular, automated manner that only requires human intervention when there's a change or a problem that isn't readily solved by further automation.

Next time, we dig into the "why" dimension.

Plumbing the Taxonomy Part 6: Quality and Lifecycle

So, you wrote a program, tested it, and put it into production, and now everyone's using it to pay their bills.

However, it's part of a larger application with many other programs, each of which has a specific role, such as transferring money between accounts or withdrawing cash from your bank account or any number of other banking functions.

The problem is, a few months later, another program in that application had to be changed to allow for a new feature. And, the structure of your data had to be changed as well, so there was somewhere to keep track of that new feature.

Your program didn't need to use that new feature, but it did need the data, which now had more information, and therefore had a slightly modified structure. So your program had to be changed to use the new data structure.

But, you couldn't just change your program and put it into production and be done, because you had to wait until the data and all the other affected programs had also been changed, and then put it into production all at once.

Then, if even one of those programs turned out to have a significant error that hadn't been found during testing, it could become necessary to back out all the changed programs and data and revert to the previous version so production could keep running smoothly.

Meanwhile, you were also working on further changes to the program that would respond to future functions the application would offer - but not for several more months.

Keeping three concurrent versions of the same program, application, and data structure is quite normal on the mainframe. Often there may even be more. And it's necessary to keep track of each to avoid any possibility of confusion between versions.

The thorough testing of everything to minimize the possibility of problems before you "go production" is a core aspect of the Quality value. The connected value of Lifecycle Management allows for managing and tracking of multiple versions, to be able to develop one or more versions concurrently while having another in production, and even a previous one available in case a backout is needed.

Any true production computing platform needs these features, so that business activities aren't negatively impacted by the dynamic introduction of buggy programs and inability to back them out in a timely fashion.

Of course, such scrupulous practices have the paradoxical effect of making mainframes so reliable we take them for granted, forget they're there, and then focus on the squeaky-wheel platforms that are constantly crashing and having bugs, and give them all of our attention.

At IBM's System z Technical University at the beginning of October, I gave a presentation entitled "Getting a New Generation to a New Normal on the Mainframe." I had some great discussions in connection with that, and one of the concepts that emerged was the Warren Buffett approach as mapped to computing.

As you may be aware, Warren Buffett is one of the richest people in history, and he got that way by identifying and acquiring companies with excellent fundamentals but significantly reduced valuation.

Well, as evidenced by the benefits of Quality and Lifecycle Management, the mainframe is the only computing platform with such excellent fundamentals that we just take it for granted that it works. The problem is, we take it so for granted that we treat it like it doesn't exist. Talk about a reduced valuation!

So, to apply our analogy, if an organization wants to invest in a platform that will bring them a spectacular capacity to succeed - or if an IT professional wants to make such an investment in their career - there's nothing else out there like the mainframe, which has such amazing quality and so nearly invisible a reputation.

Talk about a ground floor opportunity for prosperity! After 48 years, the mainframe is poised for a tipping point of spectacular "overnight success" - will you and your organization be part of it?

Plumbing the Taxonomy Part 5: Optimization

Imagine a computer that normally runs nearly 100% busy all the time without slowing down, uses resources such as storage with maximal efficiency, runs programs that have been tightened up to minimize CPU and memory usage, does backups and restores efficiently and effectively, and keeps network bandwidth down while delivering massive data throughput.

Of course I'm talking about the mainframe, easily the most frugal computing platform in use today. Starting from the early days when available resources such as memory, disk and tape storage, and processor cycles were minimal, it has always been the norm to optimize the usage of the mainframe. Right from the beginning, there have been many ways - and software solutions - for optimizing the mainframe to maximize the value received.

Today, squeezing every last drop of value from the mainframe continues to be a core part of the culture and techology.

That's more important than you might initially think. As I discussed in my CMG article at http://www.cmg.org/measureit/issues/mit54/m_54_11.html, Moore's Law, an observation that has been used to point out that computers keep getting smaller, cheaper, and faster, is winding down. Already, CPU speeds have stopped increasing. The laws of physics tell us that eventually storage and memory capacity growth will also start to plateau.

When that happens, those who are already in the habit of making the most of every resource will be light years ahead of those who have gotten in the habit of letting bigger, faster computers make up for the inefficiency and sloppiness of how their solutions are built.

And, more to the point, the mainframe, which has remained lean, responsible and scrupulous, will be the only platform that is so optimized - right down to the hardware architecture - that the ever-bloating cycles of bigger, slower software on other platforms will result in the mainframe being further and further in the lead.

Let's hear it for frugal computing, and the business-enabling characteristic of optimization so ubiquitous on the mainframe!

Plumbing the Taxonomy Part 4: Managing the Context

Context is everything. Literally!

In the case of the mainframe, that means everything from the hardware to the operating system to the subsystems to the applications that interface with the carbon-based peripherals who pay for everything.

Managing it means configuring, securing, logging, monitoring, modeling and reporting on everything from devices to applications.

So, if something isn't functioning properly, then software with the context management value of the "what" dimension will allow you to adjust and fix this behavior.

And, if you're planning to add hardware for uses such as storage or networking, this would be the function that models possible configurations to enable good planning.

In fact, if you want to know whether anything's going wrong right now, or has gone wrong in the past, this is the feature that tells you - or even alerts you so you can fix it before anyone experiences problems.

That last functionality is particularly relevant for keeping the mainframe running smoothly. In environments without quality real-time monitoring, IT management often finds out from the users of their services that things aren't working and then have to inform the systems and operations personnel so they can fix it. However, where such monitoring is effective, it can be coupled with automation to identify and fix a problem before anyone is affected, and then notify relevant personnel that this has occurred.

Now, before I finish this week's blog, I want to take a moment to give a shout out to Bob Rogers, one of my favorite mainframers, for an excellent brief video in which he explains how western civilization runs on the mainframe. Everyone (not just IT people) should watch this.

Plumbing the Taxonomy Part 3: Applications and Automation

As someone who is familiar with computers, you may be tempted to ask about this value of the "what" dimension, "isn't that everything that computers do?"

After all, applications are written in programming languages, and automation generally includes the option of programming, and computers are all about being programmed for automation of otherwise more manual tasks.

However, this deserves its own broad category, in my opinion, because programming languages and other means of automating activities are a distinct category from the other values in this dimension, with a focus specifically on enabling people to create something versus managing, monitoring and connecting.

Of course, there are many solutions that have multiple values along this axis, so important areas such as Workload Automation and its superset IT Automation will also qualify as "Production" (that's Part 7). In fact, Enterprise IT Automation is an area that I consider significant enough that I'm currently doing some additional writing on it - stay tuned.

Now, the languages used in creating applications and automation range from Assembler - i.e. a text-based representation of the "machine language" that runs the computer - through well-known 3GL's (third generation languages) such as COBOL, to 4GL's (fourth generation languages) such as Natural, Easytrieve and REXX. You'll even find C and Java on the mainframe.

Some of the programs written in these languages originate in the 1960's, and have barely been modified since. Others have been written, rewritten, updated, and continually used throughout the nearly-five-decade history of the mainframe. Certainly, there's a lot of Y2K-proofed code - particularly in COBOL - that has been around a long time, and is of such proven quality that it will likely be around for a long time to come.

Other programs are quite new, as the mainframe continues to take on new workloads as well as supporting the tried-and-proven ones. Java shows up a lot in these new ones.

Automation programs are also an ongoing source of new development and modifications, as the context being automated changes and grows. That's particularly the case given the enterprise-wide nature of leading edge automation, which includes the mainframe along with other platforms for a single point of manageability across IT.

One further note on this topic: while there is significant overlap between products and languages on this value, reducing the number in use is, to put it mildly, non-trivial. For example, while converting all the programs in a given 4GL to run in COBOL or Assembler (in order to eliminate the 4GL and save its licensing costs) may theoretically be possible, the effort to convert and maintain the resulting much-larger programs is often prohibitive.

However, if you have two solutions that overlap in every way, including having programming languages, it can be worthwhile to examine the opportunity for consolidation, particularly if there is not too much in-house programming, or if that programming can be replaced by something simpler and out-of-the-box in an alternative solution.

Plumbing the Taxonomy Part 2: Interfacing with Devices

Last week I elaborated on the first value in the "what" dimension of the Mainframe Analytics Taxonomy.

Before I dig into the second value, however, I have some good news: our official website is finally up and running at http://MainframeAnalytics.com. Feel free to check it out and offer any feedback.

Now, concerning interfacing with devices, of course it is primarily the operating system's role to enable applications to talk with the terminals, tape and disk (and solid state) drives, printers, network, etc. After all, that's one of the main jobs of operating systems: handling the stuff that every application needs but isn't the core functionality that the application is about providing.

However, it's one thing to get data to and from these devices. It's entirely another thing to manage and optimize the usage of these devices.

For example, network problems can occur anywhere between the mainframe and the user, and tracking them down and fixing them can be nearly impossible without network management software. In fact, such software can often prevent or detect such problems before anyone else is affected.

Sharing drives and consoles between multiple different operating system images is also a challenge - for example, making sure that a change made to a drive on one system doesn't accidentally overwrite a change made to the same place on another one.

The software that manages and optimizes these devices is a core part of what makes the mainframe great. While storage, network and other device management software may be available for other platforms, it is not yet nearly common enough that the time and expense are committed to do this as well as is standard on the mainframe.

This is a common enough thread in understanding the value and role of the mainframe that it bears emphasizing: while many of the things that make the mainframe great may also be available for other platforms, it is generally the exception that they are purchased, installed, configured and run properly on those other platforms, but normal to have them on the mainframe. In fact, if a non-mainframe platform were run with all of the things that make a mainframe great, and if all these additional systems didn't degrade that platform beyond usability, it would still make the cost-benefits equation favor the mainframe by a very large margin.

It may be tempting to think of the mainframe as expensive, but for the quality of service, availability, security and reliability that we expect - and which keep the world economy functional - the price we pay is very small indeed, especially compared to the costs of the consequences of doing without.

Plumbing the Taxonomy Part 1: Handling the Data

Back on February 5, 2012, I published a blog post about the Mainframe Analytics Taxonomy, which divides mainframe software products along two dimensions: behaviors (the "what") and business value (the "why").

In that taxonomy, I briefly listed seven values along the "what" axis (numbered 1 to 7) and six values along the "why" axis (lettered A through F).

As I mentioned in the blog post, a given software product may have more than one value along each axis, though often its current primary focus will be in just one category.

So, I thought it might be of interest to do a quick series of brief blogs just explaining each value.

I'll begin with Data Handling, number 1 on the "what" axis:

Now, this is a very big category, and covers everything from storing and managing data in databases, to processing, combining, sorting, modifying and moving data. It's also one of the things mainframes do best.

Right from the beginning, the mainframe architecture was designed to handle massive amounts of data such as a world-class business might regularly process. One example is: all the records a national government has about its citizens' taxes. Another: all the information about a large financial institution's customers and their accounts.

One aspect of this category, databases, has deep roots that go way back. The theory of how to efficiently store and access large amounts of structured data led to the development of some of today's most important databases, including IBM's DB2 and IMS, CA Technologies' CA Datacom and CA IDMS, Software AG's ADABAS, and some distributed databases such as Oracle and Ingres which are available on Linux.

Another is data sorting, which was such an important utility that it was the first product of two important software companies that are still going strong today: Syncsort and their eponymous product, and CA Sort from Computer Associates, now CA Technologies. That was despite the fact that IBM already offered their own sorting utility for the mainframe, but the business need was such that these optimized alternatives were enough to launch their companies.

There are also many utilities designed to examine and modify and move data in many different ways. Interestingly, this is a good example of being in more than one category, since they often also have value 3: Applications and Automation. A good example of this is applications that take address data and turn it into validated mailing addresses printed on envelopes (or statements visible through windows in envelopes). But I'll get to that in another two blog posts.

Pricing Intangibles

How do you price intellectual goods that can be manufactured and distributed for no significant cost compared to the cost of their creation? Whether you're talking software, configurations, architectures, or written works, if it can be distributed virtually without ever being placed/printed on physical media (such as a book), what is the basis of value and pricing?

Back when I started working for Computer Associates International in the late 1990's, I tried to explain to my brother why mainframe software was so expensive. After all, it generally didn't have any more lines of code than PC software that sold for a few hundred dollars at the most. At the time, I suggested that the price was generally a fraction of the cost savings that it brought.

I still stand by that assertion, but over the years, I discovered just how hard that is to prove. Once a piece of software has become embedded in an environment over many years, there's no simple way of knowing how much cost it's saving, because removing it could bring everything to a halt, which would be a completely different order of magnitude of cost.

Interestingly, pricing written works can involve similar issues. If someone asks me to write up a white paper, article, or recommendation, should I be paid by the word?

I'm reminded of a joke, a quotation and an anecdote.

The joke is about a highly-experienced mechanic who is faced with a car that has stopped working, and no one can figure out why. They ask if he'll fix it, and he agrees to for $1,000. Eventually, his price is accepted, and he goes to work.

To the external observer, the mechanic appears to be dancing around the car in a manner reminiscent of Mr. Bojangles - crouching down low, leaping up high, and almost seeming to be performing a rain dance of sorts as he looks over every nook and cranny of the car. Then, he suddenly takes out a ball peen hammer, strikes the car engine with an exacting blow, and pronounces it fixed.

The owner tries it out and, sure enough: the car now works. Then the mechanic presents his bill for $1,000.

Skeptical, the owner asks for a price breakdown. The mechanic replies, "That's $1 for hitting the car, and $999 for knowing where to hit it."

The quotation, attributed to many people, but probably most famously to Mark Twain is: "I would have written a shorter letter, but I did not have the time."

The anecdote is about the production of enameled steel pots and pans during the Soviet era. Apparently, it became harder and harder to find small ones while there was an overabundance of large ones. This was not because having larger ones somehow improved the cooking experience, but rather because the factories that produced them were incented by the amount of material used, rather than any measure of useability or rates of sales.

What all three of these have in common is that the value of things is not always connected to the simplistic, some might say "common sense," measures we apply to commodities. In fact, other than the most tightly-controlled and homogeneous commodities, I suggest size is rarely a good measure of value.

One of my favorite examples of this is the Windows operating system, which I've heard may be the largest software system ever created in terms of sheer number of lines of code. And yet, you can buy a copy for a few hundred dollars, and even get a PC thrown in (or vice versa). Compare that to z/OS, IBM's premier mainframe operating system, which costs a few orders of magnitude more than that. Yet, I doubt IBM would claim there's a commensurately larger number of lines of code; likely, there are fewer.

So, how do you price mainframe software in a way that is fair? I suppose it makes sense to take a lot of factors into account, from the capacity of the mainframe (they vary greatly in capacity), to the cost savings and benefit that a typical customer is likely to derive, to the cost of creating, maintaining, and deriving a reasonable profit from a piece of code that is only installed on a portion of the 10,000 or so mainframes in use in the world today.

That's a very different approach from pricing generic consumer software, of which millions (maybe even billions?) of copies are sold.

Likewise, when pricing the generation and delivery of other intellectual property that has great value to a relatively limited but very economically significant audience, it seems to me that paying per word is like asking for excessively large cookwear, rather than looking for that perfect touché in as few effective words as possible.

Of course, like any good question, this is more of a journey than a destination. But it's one of the important questions in the mainframe world, and one that is of particular interest to me as I look to generate written works of significant value, and don't think it appropriate to charge by the word, since I can often achieve more with a small number of well-chosen-and-aimed words than with a 10-page white paper.

What do you think about the pricing of such intangibles?

"F*** it, I'm buying a server" - the story of distributed IT

"The mainframe whisperer" - that's what my nephew Alex told me I should be after I described the culture of mainframers and explained why it clashes with the ambient business IT culture of immediate results.

Then his friend Stefan, who is tasked with getting results and has to deal with mainframers, told me of his experience of frustration with rigid behavior, leading to the memorable assertion: "F*** it, I'm buying a server." I told him that phrase was the history of IT since the 1980's.

The problem, of course, is that the rigid behavior that frustrates people so much is the reason why mainframes work so well while every other platform keeps crashing, being hacked, and generally failing the test of trustworthiness.

For me, this is the fractal meeting point of ocean and shore, of new and old, of aspiration and reality. And, somehow, mainframes have become a part of experiential reality, shoring up the world economy, while most of IT has continued to float on the waves of aspiration.

As I begin to spin up Mainframe Analytics, our blog, our website, and our business activities again after the passing of my wife earlier this year, this seems like a good leaping off point for this blog.

What can be done to bring together that which works with those who plan? Well, at SHARE in Anaheim, I had the opportunity to give the MVS Program keynote, in which I talked about this topic. And my answer, as you can see in the presentation posted at https://share.confex.com/share/119/webprogram/Handout/Session11474/2012-08-06%20Harbeck%20MVS%20Keynote.pdf, is to get to know your mainframe environment ("know thyself"), optimize it for current needs ("get a haircut") and enthusiastically tell the world how great it is ("fall in love").

And that's what I'll be doing on this blog and in my role as Chief Strategist for Mainframe Analytics. Stay tuned!

x30 Years of Great Ideas and Counting

Today is the 48th anniversary of IBM's announcement of the System/360 mainframe on April 7, 1964, if you count in decimal like many mainframe applications and users do. However, if you count in hexadecimal, or base 16, like many computer scientists, including mainframe systems folks, do, then today is the 30th (or "x30"th) anniversary of that announcement. This seems like a good opportunity to reflect on some of the great innovations and ideas that have continued to come from the mainframe, up to and including the most recent SHARE conference in Atlanta.

First, though, let me offer a tip of the hat to Pandoria13 for comments received on the last blog. Also, I'll point out that I've enable monetization of this blog, and would be interested in feedback on this step.

Of course, the System/360 mainframe did not emerge in isolation - rather, it arose as the culmination of many years of advancement and culture, drawn fom earlier mainframes and ideas, and being the "love child" of IBM, SHARE, and the organizations that were taking the journey of defining what an ideal business computer should do and be.

In fact, unlike UNIX, Linux, Windows and MacIntosh, technologies around which a culture formed, the mainframe was the manifestation of an already-existing culture which has continued to be a core part of that platform.

So, some of the original innovations associated with the mainframe in the 1960's and 1970's were also present, at least as concepts, in other earlier and competing platforms at the time. But they generally received their most enduring manifestation in what became today's leading-edge mainframe, including:

• Virtual memory
• Virtual machines
• Full system integrity and security

And, of course, many, many more.

Which leads us to the latest and greatest insights at SHARE. Though I must confess that some of the best ones I got were from an excellent interview with John Ehrman, a father of modern mainframe assemby language, for the mainframe history book that Dr. Steve Guendert and I are working on. Learning about the sources and outcomes for decisions about how the underlying language of the machine grew and adapted was fascinating.

The keynote about how "Boring Meetings Suck" by Jon Petz followed by a session later in the afternoon where he elaborated was also of interest, and a motivator to be more effective in business, including mainframe IT.

Of course, there were many interesting technology keynotes, sessions and discussions.

Two of the sessions that most grabbed my attention were a Wednesday morning one for new mainframers, where a room full of high school and university students got to learn about the mainframe thanks to the IBM Academic Initiative and some related presentations (including a quick one I was able to give about zNextGen), after which they got to check out the Technology Exchange; and a session about local mainframe user groups - which I hope leads to further discussion.

The evening receptions were great opportunities to network and share and learn information about the latest and greatest on the mainframe.

In fact, the more I think about it, the more I realize that many of the sessions make good starting points for future blogs, so I think that's where I'll leave it for today... stay tuned!

Leading Big Iron Edge

SHARE in Atlanta last week was an excellent event. Not only did I catch some great keynotes and many other valuable sessions, not only did I get to be with hundreds of my friends and favourite mainframers including many of the key players in the mainframe ecosystem, but I had the opportunity to see some of the many ways that the mainframe continues to be the most technologically-advanced business computing platform around.

But before I dig into the details, a couple of other notes, beginning with thanks for the comments on last week's blog post from my friend Marcel den Hartog (zMarcel) in the Netherlands and from my colleague Jerry Seefeldt with whom I attended a great session/discussion about local mainframe user groups at SHARE. It's inspiring to see the growing interest in local mainframe user groups, and I'm looking forward to seeing how they connect up and what role SHARE is able to play in it.

The other thing I wanted to mention is that I met with my friends and colleagues from key mainframe publications at SHARE, including MainframeZone and the associated magazines z/Journal and Mainframe Executive, and IBM Systems Magazine (mainframe edition). I'm looking forward to continuing to publish articles and such with all three. And, I'd like to take the opportunity to refer you to the video series "Big Iron: The Mainframe Story (so far...)" which I worked on with the folks at CA Technologies, IBM Systems Magazine and various mainframe luminaries to produce. It's a great way to get more familiar with the mainframe.

Once you've seen those videos, you're ready to find out about just how leading edge today's mainframe is. I certainly was as I roamed the Technology Exchange Expo floor, and I was impressed with what I saw.

As always, IBM had the biggest booth, and in addition to having an actual mainframe running on the floor, they had other techology and plenty of people and stations to tell the world about all the great things happening on the mainframe that are keeping it at the forefront of high-end business computing, including Linux-on-z/VM cloud computing. One of IBM's biggest emphases was on their Smarter Planet initiatives.

Fortunately, the mainframe is much more than just IBM: it's an ecosystem with many technology vendors and the largest organizations on earth as the customers. So, each vendor had one or more (sometimes many more) things to show the world about how they're making the mainframe better all the time.

Many of the products are about enabling the mainframers of today and tomorrow to be more effective, including CA Technologies' role-based CA Mainframe Chorus workspace, and Chicago-Soft's Application Knowledge Capture™ service to retain valuable understanding from imminent retirees.

Of course, forming and educating a new generation of mainframers is a key focus, so Interskill was there, and CA Technologies announced scholarships for their Mainframe Academy.

There were also solutions for bringing greater end-to-end integration and functionality between the mainframe and the rest of the computing world, such as the Mainframe Event Acqusition System™ (MEAS™) which provides integration of real-time mainframe event information with McAfee's Security Information and Event Management (SIEM) platforms.

One company, UNICOM® Global, even had their Founder, President & CEO Corry Hong at their booth, and giving presentations, in order to introduce everyone to all the solutions - both established and new - that they're involved with.

In addition to the content on the exhibit flor, there were also various other news and articles in the SHAREnews Dailies. And there were many discussions, including a focus group about "Big Data."

Of the many interesting sessions one of my favourites was Cheryl Watson's Hot Flashes, which has many of the latest and greatest tidbits about how to make mainframes run even better.

After a week at SHARE, it's clear that the mainframe is constantly staying ahead with world-class functionality and all the most modern technology to respond to the business needs of the largest organizations on earth, today and for the foreseeable future.

And SHARE is the place where it all connects.

Next blog post, I plan to share some interesting thoughts and insights from the various sessions and discussions I enjoyed at SHARE.

SHARE

Back in the earliest days of business computing, when all printing and displaying of text was uppercase, it became apparent that the users of this technology would benefit from getting together to share their innovations and lobby for the improvements that would best respond to their business needs. Thus it was that, in 1955, nine years before the announcement of the System/360 mainframe, SHARE was born.

57 years later, the semi-annual SHARE conference has now opened in Atlanta with a great keynote by Jon Petz about how to survive and improve business meetings, to be followed by a week full of technical and how-to sessions.

When SHARE was founded, the name was what they did - not an acronym, but uppercase because computers didn't offer lowercase letters back then. One of the most important things that emerged from their first nine years of lobbying for their business computing requirements was the announcement of IBM's System/360, the epitome of business computing and progenitor of today's mainframe.

In keeping with SHARE's business orientation, the Monday and Tuesday of the conference now also include a parallel ExecuForum for key IT decision makers to meet and discuss issues from a business perspective. Many of these folks started their careers as mainframe technical experts before moving eventually to their current responsibilities.

One of the most important things SHARE has always offered above and beyond its sessions is an opportunity for business computing professionals - particularly those reponsible for large-scale business IT that includes mainframes - to network and do dynamic problem solving among peers. This hearkens back to the origins of SHARE, and it's something you'll see and hear in the hallways between sessions, at the various receptions, on the exhibit floor, in the session rooms before and after the presentations, and at meals and coffee meetings between colleagues who only ever see each other at SHARE - sometimes even if they work for the same organization!

While SHARE was the first computer user group ever founded, it didn't take long for others around the world to follow suit, so sister organizations in Europe and Pacific Rim countries have also existed for most of SHARE's history.

However, SHARE is the pinnacle - or, as I prefer to think of it, the nexus - of mainframe and large enterprise computing user organizations. And it's where you'll meet the key players - both people and organizations - in the ecosystem.

Interestingly, while SHARE is now 57 years old, it's actually getting younger. The number of first-time attendees seems to increase each time. Many of these newbies will associate with the zNextGen project at SHARE, but regardless of whether or not they do that, you'll see them taking every opportunity to chat with and learn from the many highly-experienced attendees who are delighted to be able to mentor them.

Of course, the session content is of significant value all by itself, so many people who can't be at SHARE in person are virtually attending SHARE Live! from Atlanta to benefit from the keynotes and other valuable sessions.

However, the opportunities that come from attending in person are even greater, and they include not only networking and mentoring, but also building lasting friendships that can be there for you at a time of need. I have personally experienced this.

Being at SHARE in person has yet another benefit: the Technology Exchange Expo, where you can meet people from just about any organization that wants to be seen as a credible part of the mainframe ecosystem, and learn about the latest in business information technology.

For those who wish to take their benefits even further, there are many volunteering and speaking opportunities, as SHARE is a volunteer-run organization (with the paid assistance of an organization that handles many of the logistical details, of course). That means that, whether you'd like to develop your speaking, people, or organizational skills, there are ways to do so with SHARE.

SHARE also has its share of traditions, from pins and ribbons on badges, to receptions, to group dinners and networking events, to special sessions that everyone tries to attend. One of my favourites has always been "Cheryl Watson's Hot Flashes" which is  at 9:30 am on Friday morning, and contains a summary of everything significant happening in the mainframe ecosystem, much of which she has gleaned from the content of the week leading up to her session.

Why all this detail about a user group and educational conference? Because, until you've understood the mainframe community and culture, you can't possibly understand the platform. The mainframe is much more than merely technology: it's at the beating heart of the key organizations in the world economy, and the beating heart of the mainframe is the people that make it run. And those people can be found at SHARE.

In my next blog post, inspired by all the leading-edge technology being announced and displayed at SHARE, I intend to write about some of the important innovations currently happening on the mainframe.

Easy Does IT

In my last blog post, I discussed the generations of mainframers, and called the current new generation of the technical experts that will act as the beating heart of this platform "Generation Easy." The problem is, getting this generation fully in place before the previous ones depart is not turning out to be particularly quick or easy. This post is about how to make it so.

First, though, I should mention that I also had some nice and appreciated comments from friends of mine in generations Charlie and Easy - thanks!

In 2005, I wrote a whitepaper and an article, and gave a presentation at SHARE, about the need to get a new generation in place on the mainframe, and what steps were necessary to do so. Since then, I've continued to develop my thinking and experience on this, and am continuing to write more articles on the topic as well.

So, this blog post is a good opportunity to sketch out the basics. To find out more, you can read my articles at MainframeZone.com and the related magazines (z/Journal and Mainframe Executive), or contact me for a consultation or presentation.

The first step is to hire new people while you still have experienced ones around to teach and mentor them, and do a proper transfer of responsibilities.

In-house projects and mentoring, including tracking down and updating obsolete configurations and programs, are important activities to get them going.

However, before that happens, you'll likely need to get your new people introduced to the mainframe, unless you're lucky enough to hire people have have done some initial learning at universities and colleges working with the IBM Academic Initiative. Even in those cases, though, some additional training can be helpful. There are a number of good options for this. Three that I'm familiar with (though this is not an official endorsement) are:

1) Have them join the z/NextGen project of SHARE (free). This will give them the opportunity to start connecting and learning, and also give them access to a select number of mainframe introductory eLearning courses made available for free to z/NextGen members by the folks at Interskill.

2) Go for the whole meal deal and sign them up for the complete selection of eLearning courses from Interskill.

3) Sign them up for CA Technologies' Mainframe Academy.

Of course, there are other options for introductory courses as well - and, ideally, if your organization is big enough to have its own mainframe, you should also have some of your own in-house introductory courses to help people get familiar with your particular context.

I can also strongly recommend self-study to complement this, and IBM's Red Books are excellent resources for this purpose.

Now, once your new people have the basics in place and have begun being mentored, getting to know your environment and doing introductory projects, the next important thing is to get them connected and acculturated into the mainframe culture. If you've already signed them up for z/NextGen, you've made a good start. Getting them involved with such communities is important. The follow-on step is to send them to a mainframe educational conference such as SHARE.

In fact, if you happen to be in the Atlanta area (or have the financial and schedule flexibility to make a last-minute travel booking), I can strongly recommend sending your newbies to attend SHARE in Atlanta next week. Or, you can sign them up to attend virtually with SHARE Live! from Atlanta.

In addition to the above, you'll want to update your local mainframe technology and culture to be more compatible with this new generation, and the one that follows it. I intend to dig into that in future blog posts. And, of course, there's room for plenty of elaboration on the above basics.

Next week, however, I plan to blog more about SHARE.

Generations

The mainframe ecosystem has had several generations of people in charge of it, each learning from the previous while bringing their own abilities, insights, and eventually experiences. While it's somewhat arbitrary to draw a line between each of these, it can help in understanding where we are today, so let me give it a try.

But first, I'd like to thank my two commenters from last week's post: Jim Michael, my friend and mentor and someone who is approximately in or next to my "generational band" though much wiser and slightly more chronologically gifted, and Kristine Harper, my friend and a leading member of the current new generation of mainframers (Gen-E referred to below).

Now, I'd say the first generation of mainframers are those who started their careers before the advent of electronic computing. Let's call them "Generation Able." Many of them had been in the military during World War II, and brought that culture and scrupulousness to their establishment of the culture of computing, and eventually to mainframe computing.

I'll designate the next one, "Generation Baker," and group those who started their careers on early computers, and ended up spending most of their careers on the mainframe.

The third one, "Generation Charlie," are those who started out on the mainframe when it was already in place and running - some time in the mid-to-late 1960's, the 1970's, and 1980 to 1982. For them, computing was mainframe was computing for the formative years of their careers.

In 1983, Time Magazine declared the PC "Man of the Year" and the world of computing changed forever. Suddenly, everyone spoke of the mainframe in the past tense as they looked to the future of computing on other platforms. Those hardy (or foolhardy, depending on whom you ask) few who went into mainframe careers were seen as non-mainstream, to put it politely. I was among them. We are "Generation Dog," and I include everyone who came on board before Y2K preparations took off, around 1997. We are few in number, because many from the previous generations were still around, organizations were not investing well in building a new generation on the mainframe thinking it was going away, and mainframes were requiring fewer and fewer people to keep them running, even as they continued to grow their capacities, but also their reliability and maintainability.

Y2K changed everything, as organizations realized they had invested too deeply into highly-functional mainframe environments to simply move off, so they had to update their code to survive the turn of the millennium. The world was slowly waking up to the fact that the mainframe had become a fixed foundation of large-scale IT. Those who have begun their careers since this time, while still slim in numbers, knew they had brilliant careers ahead of them, being responsible for the most important computing platform on earth. I call them, "Generation Easy."

Suddenly, everything is changing, and the ultimate generation is about to arrive: "Generation Fox." They will inherit a mainframe unlike that of their predecessors, and take part in its becoming so. The mainframe will be simpler to maintain, manage and deploy new applications for than ever, and will likely show itself to be the optimal platform for top-quality cloud computing. Unlike their technically-oriented predecessors, many in this generation will be as focused on business results as on the bits and bytes of how-to. And, if (as I expect) a tipping point of rediscovering the mainframe is reached, this new generation will also balloon as organizations invest in using the mainframe for the newest and most leading edge applications.

However, they're not here yet, and the first five generations are made of highly-competent, trustworthy, hard-working technologists who have passed down practices, cultures and user groups that have become the infrastructure of this essential platform. We will continue to need their ilk at the foundation of mainframe computing, regardless of how many of the new business-oriented generation flood in. So, my advice to organizations looking to the future of their mainframes is, hire quality now, mentor them, get them tried and proven, and then you'll be able to ensure that the mainframe continues to run well as all the Gen-F's start to flood in. Because your mainframe's not going away, but Gen's A through D are, and soon.

Next week, I'll talk about some of the ways to get a new generation in place on time to respond to the imminent challenges and opportunities on the mainframe.