You can't manage
what you can't observe.

No and that’s the point. apsware observer sits on top of your existing scheduler or orchestration environment as a visibility and monitoring layer. It connects to them, reads from them, and gives you a unified picture across all of them. Your setup keeps running exactly as it does today. No migration needed. 

apsware observer currently connects natively to IBM Workload Scheduler (OPC, TWS for z/OS, IWS for z/OS, IzWS), HCL Workload Automation for z/OS (HWAz) and Control-M. The support of Apache Airflow is currently under development. These cover the majority of enterprise scheduling and orchestration environments we see in practice — but we know this does not cover all.

We’re actively working on native support for Automic Workload Automation, with more integrations in the pipeline beyond that. If your environment runs something different, get in touch, we’ll give you an honest answer on where things stand and what’s possible.

Most environments are connected and returning live data within days. There is no lengthy onboarding process. apsware observer connects to your existing scheduler environments, and the view is available immediately or, depending on the underlying scheduling system, no later than when the daily plan is created.

It depends on the type of dependency. Jobs and workflows within each scheduler are tracked automatically, as they’re created, updated, or removed in the tool itself. apsware observer reflects those changes without any manual intervention. You’re always looking at a current picture of what’s actually running.

Cross-scheduler dependencies — the connections between jobs running across different schedulers and orchestration tools — are set up once manually. That’s a one-time configuration effort, not an ongoing maintenance task. Once those cross-system relationships are defined, they can be monitored from there.

No, apsware observer is read-only by default. It observes and surfaces, it does not write to, trigger, or modify jobs or configurations in any connected scheduler.

apsware observer’s data layer was built for high-volume automation landscapes from the start. The architecture handles large numbers of concurrent jobs across multiple schedulers. For IzWS/HWAz users: You don’t need to worry about high MIPS consumption during the data collection process.

Pricing is based on the scale of your environment, the number of schedulers, platforms, and workload volume.  We don’t publish a pricing page because the costs depend on your setup. 

apsware observer comes with a built-in role-based access control. Connection to Active Directory and LDAP is supported and recommended. You define who can see what across the full landscape and who can see particular job details. This matters particularly in multi-team environments where different teams own different schedulers but need shared visibility without shared access.

Native scheduler interfaces show you what’s happening inside that scheduler. They don’t show you what connects across schedulers and that’s where most operational blind spots live.

When a job in Control-M depends on a workflow completing in IzWS, neither tool shows you that relationship. When something breaks in that chain, you’re correlating information across multiple interfaces manually. apsware observer gives you the cross-system picture that no individual scheduler can provide — one view of the full dependency chain, regardless of where each job runs.

Nevertheless, some scheduling environments provide limited graphical real-time visualization of the automated processes. apsware observer overcomes these limitations.  

Since apsware observer is a read-only layer on top of your schedulers, it never writes to or modifies your scheduler environments. Any changes to jobs and workflows happen directly in your schedulers, where they’re already covered by the audit mechanisms of those systems. apsware observer simply reflects those changes automatically – so there is nothing to log on the change side. 

Onboarding is structured to get you operational quickly without creating a long-term dependency on apsware. The initial setup — connecting to your schedulers and configuring cross-system dependencies — is guided by our team. From there, your team takes the wheel. The interface is built for people who work in scheduling environments daily, so the learning curve is short. apsware stays available as a partner, but the goal from day one is that your team owns it.

No. apsware has no built-in access to your observer environment. Once deployed, your environment is yours — only users with valid login credentials can access it. apsware cannot log in, view your data, or access your scheduling landscape without being explicitly granted credentials by you. If you ever need apsware support to look at something directly, that’s a deliberate action on your side — you share access, it doesn’t exist by default.

When something breaks, the observer shows you the failed job in the context of its full chain — what ran before it, what was supposed to run after it, and what’s now blocked or at risk downstream. You see execution history, the last successful run, and exactly where in the process the failure occurred — across all schedulers in one place. Root cause investigation that typically requires correlating logs across multiple tools is consolidated into a single view, significantly reducing time to resolution.