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.