Do you know what’s running?
May 29, 2008
Answer the following questions…How many automated processes are running to support your organization’s operational, tactical, and strategic systems? When specifically do they run? Where are they run? What dependencies exist between them? Not easy questions to answer given that most organizations will support multiple flavors of systems. Microsoft, Oracle, Peoplesoft, Mainframe, UNIX, SAP, etc. all have some sort of job scheduler or better phrased workload automation capability. The problem is most are good at only running processes specific to their own platform or software.
If you support or have supported a system or application (who hasn’t?), keeping track of what processes run throughout the day (or go bump in the night) can be a formidable challenge. Enter an enterprise workload automation solution. These solutions help bridge the gap between various systems and infrastructures.
Providing a centralized application that is solely responsible for running required processes (i.e. database backups, journal entry postings, data warehouse loading, system tune-up routines, application health monitoring, etc.), better equips a support team to monitor and respond to events and in some cases become proactive rather than reactive to issues.
Workload automation applications are built to execute workload jobs. Jobs are basically anything that can be run from a command line prompt. Dependencies between jobs can be set that can range from simple (Job B runs after Job A) to complex (Job C in Application X runs after Jobs D & E in Application Y and Job F in Application Z). They often provide functionality that allows for time dependent execution as well. This allows an application to only run a job during certain times of the day or alert support if a job is running longer than expected. In the event that a server can only handle a certain amount of workload before become overly taxed, workload automation applications can be configured to only submit a certain number of simultaneous jobs at a given time.
It is not uncommon for organizations to have multiple “calendars” for their systems. Fiscal days vs. calendar days in the Accounting department for instance. Workload automation tools allow for custom calendars to be used by applications. Need to run system maintenance routines on Christmas or 4th of July…setup a holiday calendar. Need to close the books on the 9th working day of the month, setup a financial closing calendar.
The workload applications are centralized on a workload server. This provides visibility into what applications affect what servers. You can also see when they affect them. If a system needs to be scheduled for service, the workload server can be a good repository to determine when the best “window of opportunity” for the service would be. All output of job submission and execution is logged on the workload server. Metadata such as start & stop times, completion states, script output, etc. is available for analysis. This proves to be an excellent source for understanding system SLA adherence as well as application/job trending for potential future maintenance issues.
All systems run processes “behind the scenes”. Just because these are invisible to the end-users doesn’t mean they are meant to be forgotten. A workload automation solution can be a good “one stop shop” for the management of these processes. Something to consider if you have to go to 5 different places to determine what ran when and where did it fail?
Dave
Comments
One Response to “Do you know what’s running?”
Got something to say?
You are so right. It’s very easy to set and forget – but when things head south, knowing what ran where, when and what was the result is vital to recovering (in a sane way) – especially when the enterprise spans lines of businesses across silos of unrelated leadership. That information be vital – it becomes the real facts, so that the observations are ‘recorded’. Then starts the fun stuff…interpretations!