The State of your Job Scheduling Software – Evolution, Stagnation, or Slow Death

Posted on

Evaluating the Sustainability of Job Scheduling Software

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:

  1. 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.
  2. 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.

Evolution
(10) The product is consistently enhanced and the development roadmap is well formed. The vendor engages end-users, experts, and stakeholders to guide future enhancements and focus the product’s improvements. The vendor also plans development with future use in mind, gearing upgrades and changes towards user productivity.
(8-9) The product is consistently enhanced and has a list of upcoming features that vendor representatives can speak to. Enhancements include new features and functionality, and the product is generally considered stable and sustainable.
Stagnation
(6-7) The product may have a roadmap, but the vendor generally cannot speak to the features on the roadmap nor provide details on development and implementation. This is a tricky situation for many organizations, as the Stagnation may be misinterpreted as a “slow year” for the evolution of a product. The key to identifying this initial stagnation is collecting and referencing data over time. This is often the most cost-efficient time to replace job scheduling software.
(4-5) The product may not have a roadmap, and may or may not be getting frequent bug fix updates. The vendor likely won’t announce it, but they’re close to a “support only” mode, where maintenance milking starts. Organizations with software in this state should be wary of licensing changes, as vendors may attempt to squeeze out profits before slow death. This is generally the last point where an organization can choose to migrate to a proper solution before migration costs (paid services and internal costs) rise exponentially.
Slow Death
(2-3) The product doesn’t have a roadmap, and gets one or two “Maintenance” releases a year. The vendor is fixing the most critical bugs, but is otherwise leaving the product for dead. This is often the point where organizations can no longer ignore the state of software, and commit to finding and implementing a replacement. Replacement generally involves higher conversion costs, both for migration services and internal requirements.
(1) At this point, the vendor has effectively given up on the software. Customers are asked to pay for bug fixes through the vendor or third-party development, or are given haphazard workarounds. Organizations that do not upgrade software before this level often allow products to continue to software death, where issues worsen and forced migration becomes inevitable.

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:

Get My Sustainability Evaluation