My name is Roy, but I want to be Norm when I grow up.
- "USAS Web is great, just finish it so I don't have to switch back and forth",
- or "Just add on-line requisition approval"
- or "Just add HR features"
- or "Just add <fill in your own most desired feature>".
These are a perfectly reasonable things for a user of state software to say, but entirely irrational things for the SSDT to attempt. The SSDT is well aware of the deficiencies and negatives of state software. We would love nothing more than to "just finish".
For the last year or so, I've been using an analogy to help people understand why the Migration Plan and, especially, Phase Two is necessary and why "just finish" doesn't mean what they think it does. If you've seen the results of OASBO's recent State Software Survey, one thing you can glean from it is the SSDT and OECN have not done a sufficient job of explaining the Migration plan, or even the current capabilities of USAS and USPS. A number of respondents seem unaware of what we're doing or even unaware of the current Web interfaces.
For the rest of this blog post, I'll discuss the OASBO Survey and the status of the USxS Redesign projects. But first, I'll repeat the analogy to help you understand why the SSDT is trapped between worlds and why we need to get out of the old one.
[Feel free to skip ahead if you've heard this one, or analogies bore you.]
Roy vs Norm
I'm a fan of PBS. One of my favorites is the Woodright's Shop with Roy Underhill. Roy demonstrates wood working (primarily) using 19th and early 20th century techniques. All the tools are human powered (saws, braces, hand planes, draw knives, clamps and vices). The closest thing to a power tool is powered by a foot pedal. For tools not available off a shelf, Roy shows you how to make your own.
I also enjoy The New Yankee Workshop hosted by Norm Abrams. Norm demonstrates creating furniture using strictly modern power tools (power nailers, cordless screwdrivers, belt sanders and oscillating drum sander,...). If a tool uses electricity, Norm has one. I'm sure Norm is capable of wielding a hammer and screwdriver, but I can't say I've seen him use one on the show.
Both Roy and Norm are master craftsmen and produce marvelous product. The end result is similar but each uses significantly different tools and processes. The main difference between them (for this discussion) is Roy's technique is labor intensive, and Norm's is resource intensive.
While watching these shows one morning, I realized that the Woodright Shop and New Yankee Workshop are almost perfect analogies for the worlds the SSDT lives in (COBOl/OpenVMS and Java, respectively).
COBOL vs Java
When the SSDT is working on the current COBOL "Main Frame" based software, we are mostly restricted to software development techniques from the 1990's. The code is much more verbose. We have to write much more of it. There are far fewer "off the shelf" tools to apply to a problem so we must write our own tools. Advances in software development techniques move quite fast. So 1990's in software development equates reasonably well to 19th-century wood working.
But when we work on the Redesign, developed entirely in Java, we have access to a wealth of "off-the -shelf" tools. Each line of code we write in Java does more than one line in COBOL. We have frameworks for accessing databases, testing, building web interfaces, creating reports, etc. If you want an idea of the tools we use, please visit the Developer's Wiki and to see how the process works visit one of the Team pages (USAS-R or USPS-R).
All analogies break down at some point, and here's where this one gets weak: If you build a table in The Wood Wright Shop, you can create new legs for it in the New Yankee Workshop. Physical parts can be fabricated to work with pieces fabricated differently. This does not always translate to software. If you have a bunch of software written in COBOL, you can't just start mixing Java into it. You can add Java around it and integrate with it, but you can't mix it all together. The technologies are too different and the new pieces won't "fit". At some point, you have to start over and write a new application.
Lipstick on a Pig Veneer on a Table
In Phase One of the Migration Plan, we wrote the USAS and USPS Web Applications. This included the web services (SOAP) (which allow other applications, like Kiosk and FormShare, to integrate seamlessly and supports EMIS-SIF). Phase One was very important. It gave us a cushion if things didn't work and provided immediate benefit to current users. It gave the SSDT time to train our Roy's into Norm's. Projects like the MCOECN's Kiosk would have been impossible without the SSDT's work in Phase One. There are significant benefits derived from Phase One.
However, in the end, the USAS and USPS webapps are lipstick on a pig veneer on a table. It looks nice, is quite usable and many users like it. However, just underneath the surface lurks the original COBOL system. The business logic, validation, security and data storage are based on main frame technologies and designs from a decade or more ago.
At some point, adding more lipstick veneer becomes too costly and less effective. You have to retire the pig table and start a new one.
For the last several years, the SSDT has been working exclusively on the Redesign projects. During this time, the current software (which we now call Classic) is largely frozen. You'll not see many improvements in the Classic software.
USAS-R has reached it's second public Milestone. We've released these to the ITC's to help in testing and evaluation of the import process. The new software can import nearly 100% of the existing USAS data, the current "web interfaces" are (mostly) working and we're starting to develop new web interfaces (to replace the "green screens"). We are making good, steady progress on replacing the software, but there is still much left to do. The scope of this effort is hard to convey. We are trying to take 30 years of evolution of sofware from the "Wood Wright Shop" and reproduce it from scratch in a few years.
If you take time to glance through one of the presentations on my home page (look for slides starting at "Not your Father's USAS"), you'll see that we are not just "porting" the existing application to a new platform. We are entirely re-designing and re-thinking USAS. The new systems will be drastically different and more flexible. The exceedingly rigid COBOL structures will be replaced with an extremely flexible model that can adapt to individual districts needs.
OASBO/OECN State Software Survey
On Jan 24th, OASBO issued a "State Software Survey" in "partnership with the MCOECN ". You can see the results on the Software Advisory Committee Wiki page.
The survey received a surprising number of responses. About half of all state software districts responded. Even more surprising is, on a scale from 1 to 5, 80% of respondents reported three or higher for "level of satisfaction" with state software. 12% responded with the highest rating of 5.
I say this is surprising, because even I think state software sucks more than that. If I didn't, I wouldn't be ruining my health to replace it.
Unfortunately, there is rather little objective data to get out of the survey. It's a shame that the survey was written by someone with so poor an understanding of state software and the SSDT's current efforts.
The obvious flaw in the survey is it presents only two choices: "Keep the current software" (presumably forever) or "Buy something new". An obvious third choice is "Let the SSDT finish the Redesign". OASBO staff might be excused for this, not being as familiar with state software, but the OECN knows better.
There is another question that should always be asked in any State Software survey:
- Which OECN ITC provides your state software support?
This should not be an optional field at the end. A primary indicator of satisfaction with state software is the supporting ITC. The reasons vary (staffing, funding, leadership) but a simple fact is support for state software is not consistent across the OECN.
An unfortunate characteristic of the current software is it requires significant support and assistance from the ITC. There are a number of reasons for this. It's partly about the skills needed to operate OpenVMS. But also state software is not just a software system. It's a collection of tools and practices which can be applied to solve individual district problems. In the present software, those tools can only be implemented by the ITC.
If your ITC actively trains on Safari ODBC, provides custom "FiscWeb" for report distribution, supports USASDW, updates USAS Web in a timely fashion and helps you integrate with other applications, etc. then state software sucks much less for you. You might even like it.
For example, here is a comment directly out of the survey requesting new features:
Report writing - a user friendly way to pull data out of the state software and to organize it in a spreadsheet format.
If you wrote this comment, or one similar, call your ITC and tell them you need "Safari ODBC" and training. If they can't or won't, then call me. State software, with ODBC, does this now and quite well. I can list plenty of deficiencies in current state software, but reporting and data extraction are not among them.
In the Redesign software, reliance on the ITC will be lessened. The software features will be more standardized, the software more user-managable and training costs reduced.
If you take time to read the hundreds of comments in the survey, you'll see some consistent themes. Most of these are familar to the SSDT (workflow, HR, integration) which is why we are concentrating on the Redesign's. Things that are nearly impossible to accomplish in the Classic software will be attainable in the Redesign'ed software.
But you will also see some remarkable extremes in how people feel about state software. Here are two quotes from the survey:
Everything I have ever needed as a School Treasurer for 31 years is in State Software!
The whole system needs to go away! In this day and age to be using DOS based "green" screens and to be using acronyms like "EIEO" and "OINQ" is ridiculous. You can't tell that private entities of similar size use such garbage. It's difficult to use and is one of the most un-intuitive pieces of software to navigate. It's terrible! The state needs to get out of the software business entrely and let professional companies market their products.