What About Application Automation?
Applications that we create automate and enhance the way we do things from payroll and inventory to how we communicate and innovate. But how do we automate the applications?
This post is part of the series that I have been developing about automation on IBM Z. You might say that I have been working my way up the software stack through system, network and middleware. This week, I continue the discussion with a focus on application automation.
How do You Automate Automation?
When you’re writing an application, you’re using computers to automate something. That’s what we were taught and that’s what we were doing when we took the wide array of manual processes from our organizations and computerized them. Initially, we just computerized the manual processes. We didn’t reengineer them. That came later, and for some processes for some organizations, it hasn’t come yet and is badly needed. Yes, reengineering. The process part is still needed.
The other day, I received notification that a company I use was closing some of their warehouses and limiting their reach to one type of customer. This same company has computerized processes that support sending items back to the supplier at the same time they’re ordering the same item from the same supplier. I don’t mean to sound like a know-it-all, but maybe they need to reengineer their processes, eliminate waste and expand their customer markets, not contract them.
Applications that we create automate and enhance the way we do things from payroll and inventory to how we communicate and innovate. But how do we automate the applications? The answer is it depends. If the application runs daily, weekly or monthly in cycles that are focused on data consolidation and reporting, then it’s likely to be called a batch or background application. Generally, to automated these often-complex applications, we need a tool that is reliable, robust and flexible. This type of automation is “outside in”—a tool outside the application helps it run efficiently.
Scheduling Batch Workloads
An industry-leading “outside in” tool is IBM Z Workload Scheduler. The tool is used to automate the execution of batch and near real-time workloads and activities that are running in support of the organization’s business services. The workloads can run on a single-image z/OS system or multivendor networks and systems from a single point of control such as AIX, HP, and IBM i, Linux, Solaris, Windows, and z/OS. It’s a big deal that you can manage workloads from many different servers from a controlling system, a z/OS controller supported with plans and trackers. How is a production workload managed?
The scheduler builds operating plans from descriptions of the production workload. The scheduler consists of a base product, the tracker and a number of features. All the systems in the complex require the base product. The tracker is the link between the system that it runs on and Tivoli Workload Scheduler for z/OS controller.
One z/OS system in the complex is designated the controlling system and runs the controller feature. From this system, you automatically plan, control and monitor the production workload. Only one controller feature is required, even when you want to start standby controllers on other z/OS systems in a sysplex.
Managing Real-Time Workloads
Batch automation is easily understood—you schedule jobs to run in sequence—but can be very complex when it comes to timing and dependencies. Real-time workloads present different automation challenges. The pattern to handle them is both “outside in” and “inside out” operating at the same time. How so?
Detect and Automate—Routine or Recovery
“Outside in” involves scheduling activities to detect and automate routine or specific recovery actions. Previously, I wrote about the IBM NetView AT, EVERY and AFTER commands that provide the flexibility needed to monitor for situations that would otherwise go undetected without human involvement. Before there was support in software for timed operations, a need like “starting at 7 a.m., run order fulfillment check every 30 minutes until 9 p.m.” was done by people sitting at terminals doing the checks manually. Now, software can do this automatically and raise an exception for human involvement when the test fails.
Software developers have anticipated the need for this kind of support and have built it into the automation features of IBM System Automation for z/OS. Using a CICS example, the product has automating recovery for application components, event monitoring, health monitoring and link monitoring.
Respond to Specific Application Messages
“Inside out” involves responding to specific messages or alerts in support of application exception handling. This may read like “outside in,” but it isn’t. The messages or alerts are generated specifically by the application, not detected through active monitoring. These messages are captured by message handling routines, even if they’re suppressed from view, and sent to an application-specific routine to take necessary actions. There are many versions of this approach. Some messages stay inside CICS or IMS and are handled there whereas other approached have the message flow to the system level. The point is that the very interfaces that support system or subsystem-level recovery and action are available to the user application as well.
In the early days of automation, handling application message was the main job. If you did an automation project at a bank or insurance company, the organization had a list of application messages that needed attention as they were an opportunity for human error that created challenges for the organization. The application, not the system, was the priority.
What’s Next?
Next week, I’ll finish developing the automation story with a specific focus on cloud automation.