Upstream vs. Downstream Applications in the Field

Author: Andrew Dvirnyk

Previously, we have talked about different designations for systems, applications, and solutions. Specifically, we dove into the differences between Blackbox and Whitebox approaches for evaluating, diagnosing, and resolving incidents and systems issues. Today, we are taking a closer look at applications. Specifically, we are looking at the following question: what is an upstream application; and what is a downstream application. Moreover, we are examining the difference between an upstream application vs. a downstream application and how to resolve issues efficiently for both.

These questions matter for developers, engineers, and other stakeholders who work with enterprise systems and who manage and maintain business applications running on mainframe. These rely on readiness, sustainability, and the ability to provide services and deliverables without interruption.

Upstream vs. Downstream Applications

When we talk about upstream vs. downstream, we are talking about the direction of the flow of data.

To get at what is flowing where, we look at upstream vs. downstream in the context of systems. In the case of upstream, we are looking at the application sending the data to another application. On the other hand, in the case of a downstream system, we are seeing that data flow in a different direction. In the case of downstream, we receive data.

How Appulse Handles Upstream and Downstream Applications in the Field

Our IBA Group developers handle multiple downstream and upstream applications when resolving issues for our clients. This vantage point gives us the unique ability to attack problems when they happen and to provide solutions that not only resolve an issue in the moment, but also create pathways for faster issues resolution over time. The Appulse from IBA Group is an important resource for helping us create and maintain solutions of this type.

Let’s take a real-world example from the field. In the field, we see that multiple functions on a system are separate. However, even though these functions are separate, they are linked to each other as part of an overall process. Many times, these are the exact processes that are most important for keeping a business running. And running well.

Critical Issues

One perfect example that our developers recently encountered is what happens when issues arise with invoicing and billing. Certainly, invoicing and billing are ultimately part of one overall process. However, on the system, invoicing and billing applications are separate.

In this case, our clients had an invoicing application that was abandoned during the night.  Now, no matter what your business is, you can understand the severity of this particular situation. Our first step to resolving the issue was to determine what created the abandonment of the application. Our developers discovered that it was a small error. However, that small error created a big problem. On the side of the business, the critical point was that the invoice-billing bridge became disconnected. This one disconnection point, of course, created a ripple effect of problems.

The next day, when users came to work, the batch of invoices from the previous day was not available due to the abandoned interface. However, our engineers were able to isolate the problem within the flow of data and re-set the invoice-billing bridge. As a result, users were again able to access all the information they needed to continue performing the critical business functions that make up their days.

When a Small Process has a Significant Impact

There are many examples of scenarios like this. What is most important, both when we are talking about upstream vs. downstream applications, and when we are identifying how to create solutions that mitigate the damage of business interruptions, is that one small part of a process can have a significant impact. It may be payment or billing creation. It may be online transactions that are abandoned (for any number of reasons). Or it may be a situation in which users are simply not able to conduct business as they expect to, and as they need to.

All this drives home just how important every business application is to the overall operation, and to the spectrum of customers you serve.

There is No Time to Waste

Understanding the stakes of business applications this way makes it even more clear that there is no time to waste when it comes to resolving even the small issues that arise. More to the point, there is no time to wait!

We have seen cases in which users are left waiting for reports for long periods of time. These lengthy waits occur because lengthy analysis is required for management. They wait because they think there is no other choice. They need the information. However, if the criticality of the application or operation in question is deemed low overall, an important process ends up getting stopped or abandoned. This makes the task of operational support exponentially more difficult. It also means that small problems grow bigger, faster.

We use Appulse to help operational support generate incident tickets   more quickly and efficiently. Appulse automatically creates incident tickets and assigns them to appropriate support groups. Those support groups are responsible for specific business application.

And we use experience management to help individuals with business applications working on mainframe. Taken together, this means that systems – and the multiple applications that run on them – run more smoothly, more efficiently, and more effectively.

How Appulse Helps in Upstream and Downstream Scenarios

Data moves upstream and downstream. The problems that interrupt the data flow between applications tend to be more critical. The solutions those problems require, therefore, are also critical. And they are not always simple.

In many ways, the genius of Appulse (and certainly one of the chief utilities of Appulse) is the ways in which it assists developers and engineers in both upstream and downstream scenarios. Appulse is able to “learn” each time we asses a given scenario. Once Appulse learns, it provides developers, engineers, and those in charge of support the functionality necessary to execute their own solutions. And to store those solutions in as templates. Those templates are then ready for the future, making issues resolution easier and faster over time.

Having access to these processes and solutions through Appulse, across upstream and downstream applications, means that the response and resolution time for our developers and engineers improves significantly. And we deliver a better result faster for our clients and their customers.

Having Appulse in our arsenal makes it easier for us, and for our clients and their customers to benefit from the work we do. It saves us time. It makes us smarter, more reliable, and more efficient. And it does the same for the systems that keep all our businesses running.