Commentary

Tips for local agencies choosing a vendor to update their systems

Commentary: Private sector companies can help agencies efficiently modernize their systems — but what questions should government tech execs ask potential vendors to determine who would make a good partner?

By Neil Hartley

August 22, 2016

Many state software systems are almost half a century old, and the older they get, the more vulnerable they become. As a result, government agencies leave themselves susceptible to crashes, malware and data breaches that they simply cannot afford.

The easy answer, of course, would be to update their systems, but traditionally risk-averse government agencies can be hesitant. Indeed, according to a report from The Standish Group, over the past five years only 29 percent of all software development projects — including new designs and rewrites of old ones — could be described as successful (when considering the time and money it took to complete them and how well the end products work).

At the same time, some localities have proved it’s possible to effectively modernize. Recently, we worked with Miami-Dade County to revamp their back-end systems in an easy and cost-effective way when they updated their database from Oracle Forms. What can other cities and states looking learn from this example?

The answer lies beyond the code itself — it’s related to how each piece of the project connects and how well those working on the project (both within the agency and at the vendor) understand how it works.

Before embarking on a modernization project, consider what additional information do you and your team need to best understand the existing app. This can help indicate whether it makes sense to modernize, and illuminate what issues must be addressed to improve efficiency and ensure security.

After addressing those issues, agencies face three options when they have a software product that is no longer serving its purpose:

Re-write the application.
Check if wrapping the application in a connectivity layer (a la MuleSoft) could fix the problem in the short term. The “wrapping” approach is valid if connectivity is an issue, for example, to enable web/mobile deployment. But if the core functionality of the application needs to be revamped, wrapping only works in the short term because the underlying code must be modified.
Re-architect the application. Re-architecting the application essentially relies on a technology platform to transform the application from its existing language and technology stack to a new (typically multi-tier) language and stack. How much of this can be done automatically and how much requires manual code completion depends on the state of the code in the original application, the source language itself and, above all, the quality of the underlying technology platform.

A vendor specializing in legacy modernization can help identify which applications are candidates for modernization — and work to determine the best approach for modernizing.

Completing modernization projects internally or only having a vendor work on pieces of an update may seem to save money. But outsourcing those projects to experts in modernization can allow agency software developers to focus on projects that most excite them — like, building cutting-edge software for the organization.

Here are some valuable tips and questions to ask when selecting a partner to provide support with re-architecting legacy applications.

Have vendors produce a prototype solution or run a pilot to demonstrate they can deliver what you need.
Be aggressive with the complexity and timescales on that prototype — and be prepared to pay for the work. Consider running a quick-and-easy proof of concept demonstration for free to weed out the weaker vendors, and follow up with a paid round for the two or three leading contenders.
Ask if the vendor can make improvements to your application as part of the transformation process.
If yes, ask what improvements the vendor can make during the automated transformation process. For example, it’s usually easy to make an application responsive at this stage.
Does your partner provide a risk assessment up front? For example, are they providing you reports on the interdependence of modules within the application and indicating modules that carry the most risk?

Neil Hartley is director of U.S. operations for Morphis, an enterprise legacy-to-cloud software company based in Portugal and with offices in the U.K., Spain and Brazil, with its U.S. headquarters in Boulder, Colorado.