How security should be defined.
- Identify all the users that will need access to the Scheduler System (Read, Write, Execute)
- Logically group them into roles either by department or by how they will use the scheduler
- Add users to these roles
How to organize the jobs that will be scheduled via the scheduler.
- By time of day
- By Business process
- By Job Type
- By Platform, etc.
Queues and Threading
- How many queues are needed?
- Should queue be defined by business process, by the type of job, or by the server when these jobs will run?
- How many threads can each queue have? This will define parallelism.
Define date calendar (fiscal or Gregorian) ahead of time so that you define job constraints or exclusions that are based on date.
Priority & Alerting
Define how alerting will work.
- Define the priority of the jobs that will be added to the scheduler. This will help define how alerting has to be setup.
- Who will receive the alerts and how (e-mail, pager, etc)
- Understand the difference in alerting requirements during business hours and non business hours
Distribution Groups for Alerting
Where do you want to maintain the distribution groups for alerting?
- Enterprise Scheduler
- Enterprise e-mail system
- ERP System
- What kind of reporting is needed – should only jobs that failed or complete run frequency be reported?
- How often should these reports be generated – Daily, Weekly or Monthly?
- Who is the intended audience?
Do you have jobs that are similar in nature but behave differently, depending on the time of day they are run or who runs them? Consider using job templates so that they can be reused.
I truly believe that there are other aspects of the design that need to be considered however what I have tried to describe in my blog above are some of the important aspects that everyone needs to consider while implementing an Enterprise Scheduling System.