App Location

Why do we use computers? What led to them being developed in the first place? What is it they do that we can't just have lots of people do instead? The simple answer is, we use computers for the applications that run on them, which do valuable things that would be impossible, unpleasant or prohibitively expensive to have people do them for you instead.

By now, most of us are used to the concept of "apps" - those single-user-focused applications that run on personal computing devices such as smart phones. Of course, "app" is just an abbreviation for "application" which is what mainframes were built to run.

The journey of recognizing the "application layer" of computing as distinct from the rest of the technology has been a long one, and it could be argued that it will never be entirely complete, because some people will always buy technology for the sizzle (i.e. bells and whistles) rather than the steak (the value it actually brings). However, on the mainframe, this journey substantially concluded a long time ago.

Today, the applications that run on the mainframe handle business at a global scale. They do billing and accounts receivable, HR, decision support, customer account handling, large-scale postal sorting, addressing and stamping, and many, many other business functions that require a massive capacity for data and throughput with total reliability.

As with smartphones and PCs, some mainframe applications can be bought from vendors, and may even run with very little customization. However, there are also many applications that are highly customizable - ERP systems (i.e. Enterprise Resource Planning, such as SAP, PeopleSoft, Oracle Financials, etc.) are a good example of this kind.

The nice thing about those vendor-supplied applications is that they're kept current and maintained, so the customer's job is just to keep installing and configuring the latest upgraded version - which is a lot more work than it sounds like, but a lot less work than writing and updating their own.

However, one of the most important kinds of application on the mainframe is in-house. These are the trade-secret, competitive-advantage, bread-and-butter applications that do unique things that no other organization does in exactly the same way. In fact, they generally embody an organization's essential identity. They have been written and maintained in-house, often for decades, and they provide core functionality, which is often built on and extended with distributed applications that sink deep roots into them.

Interestingly, while these can be some of the most valuable applications, they're also some of the most problematic, because, as they get more and more established, it becomes harder and harder to change them to respond to new needs and opportunities without adversely affecting other mainframe and non-mainframe applications that rely on they way they behave.

This often results in very complex circumstances when two large organizations merge, and they have applications with overlapping functionality. Trying to modify them to work together can be something of a nightmare, complicated by the fact that they also use data sources (usually databases) that have completely different natures as well. This is the point at which frustration may set in, and tried-and-proven applications may be set aside for vendor-provided solutions, often on non-mainframe platforms. Which, in my opinion, is a shame, given the functionality, reliability and competitive advantages that can often be sacrificed for the sake of short-term convenience.

There is a whole range of solutions that exist to enable "modernization" of mainframe applications that have been around long enough to get into an inertial funk. These include: lift-and-shift solutions to run mainframe applications mostly unmodified on other platforms; solutions that reverse engineer applications into a business rules representation for re-generation to the platform (and programming language) of choice; and solutions that build connections into and around the established ones to enable building on their functionality (on and off the mainframe) without substantially modifying them.

In any case, there are many billions of lines of programming in the mainframe applications that run the world economy, and they have proven themselves over the decades to work very well, so they're generally not going away any time in the foreseeable future. Which means that it's time for responsible people to start making long-term plans to maximize the benefit of their mainframe applications to their organizations, rather than just taking them for granted and trying to squeeze value out of them without sufficient care and feeding.

Care and feeding... yes, that's a very important topic, and not just for the mainframe hardware and software, because an essential part of what makes the mainframe great is the human side: people and culture. I'll write about that next time.