Minimize the cost of change

Your state government will exist longer than any piece of software. And that means one day, your exciting new software system could someday become your hard-to-use, old software system.

As good as software may be today, eventually you’ll need to switch to a new system – whether that’s in whole or in part. And acquiring software as a completed monolith guarantees it will gradually become unable to support an agency’s needs.

Technology changes, government policies change, regulations change, laws change, grant requirements change, and leadership’s priorities change — any project that is planned in great detail up front will be unable to adapt to those changes, and will be at significant risk of failure, significant cost and deadline overruns, or costly "change orders."

So rather than acquiring one giant piece of proprietary software, insist that your vendors default to practices like using open-source software and service-oriented architecture. That way, you can optimize for reducing the cost of updating and changing the system from the beginning.

Checklist

  • [ ] Systems, whether cloud-native or being moved to the cloud, will use service-oriented architecture (SOA) that is vendor- and product-agnostic
  • [ ] To ensure data portability, files will be stored in open, non-patented formats supported by multiple vendors
  • [ ] APIs will use open schemas
  • [ ] To avoid product lock-in, open source software will be used instead of commercial software whenever possible
  • [ ] Government will own all vendor work products
  • [ ] If using COTS components, the vendor will provide a path to leave for a competitor — both contractually and technologically — with a cost-effective way to export all stored data

Key questions

  • What is the plan for reducing the time and cost of future updates to the system due to technology, policy, or vendor changes?
  • How much will it cost to change the system to reflect needed technology or policy changes?
  • Are the APIs open and usable by other vendors?
  • Are the data formats standardized, open, and usable by other vendors?
  • Keeping a software system up-to-date will take regular, on-going work — what is the plan to do that?