State of the USAS Address

At its October 2009 meeting, the SAC recommended making the second phase of the Migration Plan the SSDT highest priority.  This is the first time the SAC had recommended reducing development on the webapps and concentrating on migration of the OpenVMS backend to a modern, commodity platform.

The SSDT initiated the USAS-Redesign (USAS-R) project and has a small core team working on it.  This blog post is intended to describe the state of the overall migration plan, the USAS-R project and some of the initial design decisions that have been made to date and to initiate dicussions among the ITC and State Software users.
Nothing in this post should be construed as written in stone.  We are in the early phases of these design decisions and much of it is subject to change.  If you have concerns or questions, feel free to post a comment here or in a relevant forum.

Brief History of the Migration Plan

If you have seen me in any meeting, presentation or on the street in the last five years, you've likely heard of the "State Software Migration Plan".  For the last five or more years, we've been running "Phase 1" of the plan, which called for developing a web-based user interface for data entry and a SOAP API for integration with other software.  The "Back End" (business rules and database) of the applications have remained on the legacy OpenVMS/COBOL application .

There a number of problems and bumps along the way during Phase 1.  There were real problems with the web software (reliablity), and user adoption was slower than hoped.  We had originally planned to write relatively simple web applications and move on to Phase 2.  But users had difficulty accepting the application so we added additional (unplanned) features as carrots (since sticks failed miserably).  This means that we have better web applications than expected but Phase 2 has been put off longer.

The fact that there were problems, and we survived it, actually means the migration strategy worked.  One reason to "Migrate" rather than "Rewrite from Scatch" was to reduce risk.  If we had rewritten from scratch, we would not have  had the safety-net of the "green screens". With the Migration, when something went wrong, the green screans were still available.  Users can be unhappy about using a green screen, but AFAIK, nobody had to break out a typewriter to do a purchase order...

The addition of "SOAP APIs" for USAS and USPS has also enabled other projects to extend state software that wouldn't have otherwise been possible.  For example,  "eProcurement" and "OECN Employee Kiosk" would not have been possible without the migration plan.  Those projects might still be waiting for the "complete rewrite".

In any case, the SAC and SSDT have agreed that we've gone far enough with Phase 1 and it's time to get on with Phase 2.

Phase 2 - Back End Re-implementation

Phase 2 means that we will be building a completely new "back end" architecture (relational database) and re-implementing USAS's business rules.  We will not be "porting" the design to SQL.  That is, we will not lift the existing COBOL design and dump it into an SQL database.  Over 20+ years, USAS has grown plenty of warts and thorns.  The current design (might) be reasonable for a COBOL/ISAM application, but it would be completely horrible as a modern SQL/relational database.

So, the goal is to re-implement USAS's features on a fresh, clean design that will be expandable into the future.  The first goal of Phase 2 (Phase 2A, if you like) is to reproduce what USAS can do now but without constraining what we can do later.

Phase 2A - Constraints

All projects have constraints and risks.  This one has a number of constraints, but for today I'll only mention a few.

Data Migration

We expect 100% data migration from existing USAS (V6.1) to USAS-R.  A district moving from legacy USAS to the USAS-R implemenation, should be able to expect 100% of relevant data to move painlessly to the new system.  This places some constraint on the new design because each bit of USAS data must have a home in the new database.  This doesn't mean all the field names or table names will match something in USAS or even that the structure of the data will match.  Only that the data from USAS must convert automatically and fully to USAS-R.

Developer Resources

The SSDT's budget was impacted by the State's budget and we have fewer developer resources than in the past. Therfore, one of our major constraints in getting the re-design finished is the availabilty of developer resources.  Further, resources that we thought would be freed by the EMIS-R project have not yet materialized.  

In software development, as in many other things, simplicity is a key determinate of productivity.  A design that is simple, straight forward and cleanly modularized leads to  faster development.

While you read the rest of this post, keep in mind that some of the design choices below are influenced by the desire to reduce complexity to increase productivity. However, do not read "simplicity" as "fewer features". USAS needs to at least do what it does now. Simplicity means the least complex design that can meet USAS's requirements and allow future growth.

Initial Architectural Choices

One District = One Database

At the October SAC meeting, we discussed a central design issue of the redesign regarding the database architecture.  Specifically, whether we wanted a "Multi-Enterprise" database (all districts at an ITC in one big database) or multiple "Single Enterprise" databases (one database per district).   See SAC Phase 2 DB for background.

The discussions we had with the SAC and subsequent discussions with other ITC personnel tended to favor a single district per database approach.  Although this potentially leads to higher adminstrative overhead for an ITC, the gains in recovery procedures, security and developer productivity weigh higher.

Therefore, the initial plan is to implement USAS-R as a single district database.

One District = One Software Installation

Resolving that the database will be single district, leads to the next issue of how many software installs ("instances") should exist.  On OpenVMS, we install the software in one location and all districts use the same install.  We use a combination of logicals, SETUPENV, rights identifiers to wire a user to their database. This leads to a fair amount of complexity in the software and configuration and adds security risk.

Also, USAS is full of "features" that not all districts use.  But we load all the features into memory, consume resources and make users deal with options they may not care about.  USAS has many "configuration options" that try to control what it does. Internally, there is a lot of code to figure out what it should to for a particular district.  In modern application architectures, these things are handled as "modules".

Imagine a future USAS which consisted of "modules" that each district turns on or off depending on their needs.  Don't use Requisitions? Then don't load the module.  You need pre-encumberance tracking? Load the module.  You use a document management system? Load a module.  In this way, USAS could be tailored to a particular district.  It might even be possible for third-party developers to integrate with USAS by writing modules in the back-end. 

This is the future we see for USAS.  But these things are only possible if each district has their own "install" (or their own "server").  Focusing on a "single district" implementation of the software simplifies the design, development and implementation and yet maximizes flexiblity and future growth.

Furthermore, the IT industry is moving toward "cloud computing".  Whether the cloud be external or a "private cloud" run an ITC, there should be no reason that USAS can't run in the cloud.  Many ITC's are already deploying virtual environments for both server and desktop deployment and disaster recovery.

Therefore, the current plan is to implement USAS-R as a single database and single installation per district.  Although this potentially increases the admistrative burden on an ITC, there are  tools for deploying and managing VMs, software upgrades, etc.  The increase simplicity and flexiblity of deployment options favors a single district installation.


The USAS-R project has been running since November, 2009.  We've made good progress in selecting the tools, laying down the basic architecure and are building out the "Domain Model" and database storage techniques.

In addition to redesigning USAS, we are also re-designing how the SSDT develops software. For most of our history, we've used  modified waterfall or  Big Design Up Front process models.  However, over the last few years, we've been adopting more "Agile" development practices, like Test Driven Development and Continuous Integration.  For this trip, we're moving to even more agile incremental approach.  We believe that this will fewer design errors, better communication and higher productivity.

If you'd like to follow along, you're welcome to visit the USAS-R project page.

p.s. I might have to apologize for the title of this post.  I started drafting it during last night's speech.  It seemed funny last night, but not so much today...