The State of your Job Scheduling Software – Evolution, Stagnation, or Slow Death
Organizations tend to spend time and resources when first evaluating and implementing job scheduling software, but once it’s in, it’s in. It’s great to have software you can “set-and-forget”, but apathy around Job Scheduling software inevitably leads to organization-level issues with service deliverability, hardware requirements, and productivity. Every business should conduct a yearly review to categorize their software into one of the standard states, and determine whether they need to evaluate other solutions against their current products.
In the world of Enterprise Job Scheduling, products have three states:
- Evolution
- Stagnation
- Slow Death
Slow Death – AKA the March to Forced Migration
Most professionals have dealt with (or are dealing with) a product in the Slow Death category. The signs are apparent. Product updates are slim and very rarely contain features. In some cases, an end-of-life date looms on the horizon, or the vendor announces “maintenance focused” product development – also known as maintenance milking. The software is effectively dead, and lags progressively further behind other products in its space. Organizations that own products in this category generally fear migration, and prefer to ignore the issues until they are forced to migrate to a new solution. Products without an official end-of-life date will eventually be considered dead as they become obsolete. Providing a business case for conversion in this category is often difficult due to costs and internal resistance, but is absolutely necessary to prevent future harm to the business. Nothing will ever be more expensive than a forced migration.
Job Scheduling Software Stagnation
Most tools available are solidly in the “Stagnation” category – including many tools that have “releases”. When a tool’s releases only include maintenance fixes and infrequent enhancements, the tool isn’t evolving – it’s stagnating. It can sometimes be difficult to distinguish true stagnation from long development cycles. One way of getting around this block is to request a product roadmap from the software vendor. If the vendor doesn’t have a roadmap, there’s a high chance the product is already in the Slow Death category. If the vendor has features on the roadmap, but cannot speak to the features or their timetables, the product is likely stagnating.
Grading on a Curve – How Stagnating Software can have New Features
One of the most difficult parts of evaluating job scheduling software sustainability is grading on a curve to distinguish between stagnation and evolution. When a tool has been in place for years and users see one or two new features each year, it is easy to consider it evolving. Unfortunately, that tool doesn’t exist in a bubble. There are many different Job Schedulers available, each releasing their own new versions and new features. When identifying whether a scheduler is evolving or stagnating, drawing comparisons between an existing scheduler and other options in the market allows users to quickly identify where their solution stacks up. Stagnation is the point at which an organization should begin planning and executing software migration. As a tool continues to stagnate, it inevitably causes migration costs to rise and creates a skill gap for users that can make changing software more difficult.
Evolution
Evolution should be the software state that every organization strives for. In Evolution, the software is not only consistently enhanced, but also has a well-plotted development roadmap. Organizations with software in the evolution category are typically confident about the sustainability of that software, and don’t consider evaluations. Because multiple products fall into the evolution category, it’s important to take stock of how the solution evolves. If features that matter are ignored and enhancements don’t make the product easier to use, is the software evolving in the way you need it to?
To compare evolving solutions, you can use two key indicators:
- Product enhancements are planned with users in mind. That means end-users, solution experts, and stakeholders are prompted for input before enhancements are plotted or released. Often, champions are chosen at customer companies to test and give feedback on enhancements to ensure the direction of product development stays relevant over time.
- Ease of use is a key development principle. For a product to truly be sustainable over time, it shouldn’t require tribal knowledge. Keeping ease-of-use as a key principle means the software will continue to boost user productivity over time – a benefit that scales with the organization.
Measuring Product Sustainability with the ESS Model
The ESS model uses three categories (Evolution, Stagnation, and Slow Death) to rate the sustainability of a given Job Scheduler on a 10-point scale.
Note: Software Death is not a recognized category. Organizations relying on unsupported, non-developed, or archaic job scheduling software are beyond the point of product evaluations and should plan to immediately replace the dead software. This also applies for in-app schedulers that exist within other software. Every moment without implementing a proper solution actively costs the organization in productivity, and passively increases the eventual costs of migration.
Not sure where your software scores? Get a sustainability evaluation from an automation expert:
