Black Box vs. White Box Approaches: How to Understand Appulse for Mainframe
We like to describe Appulse as a problem solver. Large enterprises face the challenge of legacy issues when their businesses run on mainframe. Simply put, in almost all organizations the person who wrote the code is no longer on the team. In fact, that person is usually long since retired! So the current development and engineering teams are left trying to make sense of pieced together one-off solutions and other attempts to keep things running. What adds to the problem is that there is little to no consideration for how to maintain systems over time or how to manage, collect, and store knowledge.
That means that every real fix for an operational problem on the mainframe requires a deep dive into the history of the system, including the application business logic and technical implementation. And that requires a significant investment of high-level engineering talent and time. How much time? It can take 3 – 5 years to really get inside and understand what makes the mainframe tick and understand the current (and historical) state of systems and applications enough to deliver reliable, sustainable solutions.
In that time, you have pulled some of your most talented developers from other projects that allow them to flex their creativity and create new, more efficient, and more effective solutions.
Certainly, the problem of problem solving for mainframe is clear. But what is the solution? And how can we apply different types of approaches effectively to deliver the support that enterprises need to keep running in ways that are smart, sustainable, and reliable?
Who Uses the Blackbox Approach?
We see the Blackbox approach most frequently in these older systems whose original developers and engineers are long gone. However, let’s be clear. We are not talking about antiquated enterprises, or inconsequential organizations. In fact, some of the biggest enterprises around the world are running on mainframes.
And those organizations, upon which so many other businesses and individuals rely, have lost any sense of what has been done with their applications. As our engineers often say, “The older they are, the more Blackbox they are.” So, what does that mean, why does it matter, and what can we do to fix things?
What is the Blackbox Approach?
What qualifies as a “big problem”? Things like program records issues and other problems that threaten system operability at its most basic levels. You might classify these as “triage level problems.” The problems that threaten the vitality of the system so much that they must be addressed and resolved immediately. When you apply a triage-style solution, though, you are not addressing the underlying issues that caused the system problem in the first place. Nor are you considering the level or type of maintenance that you need to apply to keep the fix going, and to prevent the issue (or similar issues) from arising again.
In this scenario, the Blackbox Approach to resolving operational problems in applications that run on mainframe is like an emergency room doctor’s response to a broken bone, as opposed to a primary care doctor’s response to overall health and wellness.
Then, it is like returning to the same emergency room doctor the next day with another (possibly related problem). However, the doctor has no access to your medical history. So, the doctor needs to start from the very beginning, without any information that would make it easier to solve your problems.
Blackbox Approach Limitations
As we know from that scenario, the Blackbox Approach certainly has its place. But it also has serious limitations when you consider overall application sustainability.
We see the first limitation when we look at who in your organization is responsible for resolving application operational issues and maintaining application health. Using the Blackbox Approach, when a newcomer comes to a project, that engineer or developer does not need to know every line of application code and every type of operational problem that can occur in order to start doing his/her job. Rather, that person can locate and fix the most difficult problems. This is not all bad, as we have noted. It allows you to provide an acceptable way to support an older system.
However, it does not provide a sustainable path, nor does it ever give you the opportunity to drill down to the root causes of issues in a way that will prevent the same or similar issues from arising. Or in a way that will allow you to create more seamless solutions that maximize the operability and the health of the system.
As we all know, acceptable in the moment is not the same as effective over time.
What is the Whitebox Approach?
The Whitebox Approach includes the following: learning, documenting, and sharing. Remember, we are dealing with complex systems. That means that you are looking at multiple applications and a variety of issues. In this context, as all developers know, you start to see patterns and gather knowledge. The Whitebox Approach allows us to pull from that stable of knowledge.
How Does the Whitebox Approach Resolve System Issues?
Based on that growing body of knowledge, we can add new solutions for specific issues. Once we have learned, and documented, we are able to make that information available to others who are working on the system.
This ability to share solutions helps to resolve some of those legacy issues that we associate with mainframe in general, and with the Blackbox Approach specifically.
Whitebox Approach Challenges
While it is obvious that older systems are not likely to use the Whitebox Approach, we also recognize that, even some of the newer systems are not set up for the Whitebox Approach. However, the younger the system, the more information we have about it, so the easier it is to apply the Whitebox Approach.
However, do remember, a young system does not mean a problem-free system. We have encountered three-year-old systems where all the documentation was lost. In that situation, we had to figure out the logic entirely on our own, with no guide and no record.
In cases like this, which you have likely run into in one way or another, most of your energy as a developer goes into the process of reverse engineering the problem to determine how and why it happened. Only after that sometimes grueling (and always time consuming) process, can you begin to take steps to finding a solution. Often, you find yourself building things back from the ground up.
New Code Takes Time and Money
One of the most important takeaways here is the unavoidable. New code takes time and money. Most organizations, the very large organizations included, simply cannot afford that. Appulse fills the gap. Customers expect a sustainable level of quality, service, and performance. We have designed Appulse to help make that a reality.
What we are doing with Appulse, is catching the problems related to the mainframe products and subsystems objects owned by application (such as stopped transaction, failed batch job, bad status of tablespace, etc.), not to the application code itself. Then, we are making a critical next step that benefits your system over its lifecycle and saves you time and money.
Through Appulse, we are noting and storing the lessons that we learn through the problem recognition and resolution process. Then, through Appulse, we are making it possible to apply those lessons to multiple scenarios. Lessons we learn in one industry can be applied to another, rather than remaining siloed.
Appulse Moves from Black Box Approach to White Box Approach
Initially, Appulse takes a Blackbox Approach in that it comes from the varied experiences of support engineers. We do not learn everything first. Rather, with Appulse, we deal with problems, collect them in a knowledge base, and document how we solve those problems. Then that knowledge base grows, making it easier to address problems next time.
Ultimately, Appulse functions as a Whitebox Approach because we build on that stored knowledge base. We operationalize our expertise by learning, documenting, sharing, and continuing to improve.