While it’s one thing to read about the power of a solution, it’s another to see the benefits realized firsthand. Read on to hear some examples of the specific ways I’ve seen organizations benefit from their use of Automic Automation Intelligence (AAI) by Broadcom, and its leading workload automation intelligence capabilities.
With AAI, IT operations teams can establish unified observability for the workload and the business processes that they support. With these capabilities, they can realize significant benefits, including improved SLA compliance, operational efficiency, and cross-team collaboration. These aren’t merely manufactured claims, theoretical possibilities, or desired outcomes; they’re the realities of leading organizations around the world.
I’ve been working with AAI, formerly JAWS, for approximately ten years and during this time I’ve had the fortune of seeing these gains realized firsthand. I’ve used AAI as a Broadcom customer, implementing and operating the solution, and as a Broadcom consultant supporting customers’ implementations. In the following sections, I’ll recount a few examples of some specific scenarios in which I’ve seen AAI provide dramatic, sometimes even surprising, benefits.
Example #1: The Difference Between Monitoring Processes and Monitoring Objects
The following example is one that will hold significant resonance for anyone who’s been on the front lines of providing 24-by-7 support for business-critical services. While working in the financial sector, I was awakened by my pager in the early hours of a Monday morning. I dragged myself out of bed, started the coffee maker, and logged in to my laptop. Once I’d gone through all of the organization’s authentication steps and opened the required apps, I identified the workload object that was responsible for the alert and started to look into the issue.
I saw that the problematic object executed slowly, exceeding a user-defined run time threshold, and triggered an alarm. By the time I had done this much investigation, some 15 minutes after the alert was generated, I found that the job had actually been completed. Although the job had been finished a little later than normal, by that time the entire workstream was completed. It turned out that the associated service wasn’t affected—at all.
In short, I, my wife, my children, and my pets were all awakened in the middle of the night, for no reason. I could add no further value to the service or to the company. For the company, this created extra costs and diminished team productivity (I can definitely say tiredness affected my productivity the next day).
At the root, the problem is that teams are operating in an environment in which they lack visibility into how individual objects ultimately map to business processes. This is a big problem, and it only grows as environments become larger and more complex.
Some organizations may be running thousands, even tens of thousands of jobs within dozens or hundreds of business processes. Consider a simplistic example: one service relies upon four jobs that run sequentially due to their dependencies. Each job has an SLA of 10 minutes to complete. Ultimately, if the entire process completes in 40 minutes, SLAs and user services aren’t affected.
Imagine that during one execution, the first job completes in five minutes, but the next job takes 12 minutes to execute. In this case, an object-based alarm would be triggered based on this second job's run time. However, assuming jobs three and four are completed on time, there would be no business impact from job two’s delay.
Contrast this with how the process works with AAI. With AAI, alarms can be predicated on business services rather than simply at the object level. While object-level notifications can still be helpful for informing optimization efforts, those alerts don’t require anyone to be awakened in the middle of the night. Instead, administrators sleep better, knowing they’ll only need to be awakened if absolutely necessary. Further, the business realizes improved productivity, cost savings, and efficiency.
Example #2: Discovering Dependencies
I was working in a large financial services institution, managing a team that was doing a proof of concept for an executive. We met with the executive and his team of application owners. The target job that the executive owned was a key part of the bank’s overnight processing.
AAI enabled us to model and build the complete job stream, including preceding workloads. As soon as we presented this model, the executive immediately told us that we were wrong and that there were no outside dependencies. The meeting was summarily halted, and the executive and his team left the room.
About 20 minutes later, the executive returned and offered us an apology. It turns out AAI’s modeling was in fact correct. There was a dependency between the batch process and a database maintenance job run by a group of database administrators. This process had been reliant upon the job for years. However, it wasn’t until that morning that the executive and his team became aware of this dependency.
Further, we saw that the very morning of the meeting, the database maintenance job had encountered an issue that resulted in a missed SLA.
It was through AAI that they were able to identify this dependency and see that it was actually redundant. The team ultimately submitted the paperwork needed to remove the dependency from the batch.
This is a great example of how the increasing complexity of workload environments can result in a lack of visibility and knowledge of critical business processing. It also underscores how, by leveraging the power of AAI, teams can effectively discover any upstream dependencies, including those not previously recognized, and bridge the gap.
Example #3: Change Simulation
Some years ago, I was consulting with an infrastructure team responsible for automation and monitoring. The business’ leadership had decided to pursue an initiative in which workload system infrastructure located in the Asia Pacific region would be migrated to a data center in Europe. This infrastructure supported critical automation services, including those powered by AutoSys. All agents and endpoints were running in the Asia Pacific region as well.
The business owners in Asia Pacific were very concerned that this migration would have negative implications. They were fearful of such issues as network latency, scheduler performance issues, and potential degradation in batch processes.
These concerns led to initial delays in the migration.
By leveraging AAI’s reporting capabilities, we were able to generate reports that connected multiple instances in a single pane of glass. We were able to have jobs running in the Asia Pacific data center and in parallel run the same jobs from the European data center. This enabled us to visualize how the apps were going to behave in the new environment and compare that behavior against that of the existing environment. We were able to visualize the way the application would behave and assess latency, efficiency, and performance.
Through this visibility, we were able to demonstrate concretely that the move to the new European environment would actually improve efficiency and performance. Ultimately, we were able to alleviate concerns, improve confidence, and make the migration happen, while minimizing any disruption or degradation.
Learn More
To learn more about how AAI can fuel these types of benefits in your organization, be sure to visit the AAI page on the Broadcom Software Academy.
