Novopay Technical Review for Dummies

I’ve worked on “enterprise grade” software for a large chunk of my career. Do not get me wrong: I could not build a payroll system capable of running the NZ School payroll without error, but I do know a grade-A clusterflop* when I see one.

LATEST: Datacom working on spec

This post attempts to cut through some of the veiled (albeit admirably blunt as far as political documents go) language in the Novopay Technical Review (heretofore known as the NTR)

Bear in mind: the NTR is focussed specifically on the current situation and how to get out of it, not how we got here. However based on the findings, it’s pretty easy to see some of the how.

So, let’s run through the “key findings” and break those out:

1. In some areas system functionality does not adequately support the business processes.

The system, as built, does not do what it was meant to do. This could be because the requirements were poorly documented from the outset (probably), but also because the system is an “off the shelf” system that has been “customised” to meet the requirements.

At some point, a decision would have been made that the “off the shelf” software was an 80% (or 70% or 90%) fit for requirements, and the rest could be built as customisations. Hold that thought and read on.

2. Usability issues and lack of data input validations contribute to processing errors.

To me, this is the most egregious finding. As I understand it, the entire purpose (or at least a key selling point) of Novopay was to reduce costs by moving from Datacom’s human-intensive workflow to a system whereby schools do all the data entry, and the “system” just needs to calculate pay.

For a system like this to work, a massive amount of time and focus has to go into usability of the front-end system. Later on in the review there are comments about tab keys not working properly, and links between pages of the same input form not working. This is fundamental stuff, and points to Talent2 and ALESCO not giving a flying fish* about end-users.

This, while fairly typical of an “enterprise” system build on Oracle Forms, is completely unacceptable if it’s so utterly important that data is entered correctly and quickly. It is an absolute core failure of a system intended to be user-driven.

As an aside: this is what “enterprise” software users work with every day. Usability and User Experience are pretty much dirty words, with SAP and Oracle making their money from systems that are actively hostile to end users.

3. School management visibility and control is limited by reports that are sometimes poorly presented or inconsistent.

See above.

4. Data quality has been affected by system issues, raising the risk of future errors.

Sh*t’s gone bad, which makes future sh*t worse. There’s a comment later in the report that data integrity is often managed by code, rather than by database constraints. Not inherently evil when done for the right reasons, but this sort of code approach more often than not points to coders that don’t understand the underlying system.

Think about a situation where your pay has been calculated incorrectly, then fixed up by a manual adjustment, what happens when the pay calculation is fixed? Does your tax liability for the year include the adjustment?

10 points if you answered “I have no f'ing idea”. Perhaps we just cross our fingers? With no test suite there’s no way to know.

5. Quality controls on data entry have not adequately prevented errors.

Too much reliance on the computers, not enough overview by experts.

6. A high degree of customisation in high-impact areas has made on-going development more difficult.

This is another one that really sets my alarm bells ringing. Talent 2 sold Novopay to the government as an ALESCO system with some customisation (see point 1). This is the dirty not-so-secret of any “out of box” enterprise software installation: the base system is next to useless without massive amount of customisation.

More often than not, when you add up the cost of an “out of box” solution PLUS the required “customisation”, a greenfield development fine-tuned to your own requirements becomes a much more comparable solution.

In the case of Novopay, the core system itself has been “customised”, which makes a complete mockery of the “out of box” solution. Expect upgrades to come with significant pain. Also expect ALESCO to wash their hands of any errors because the system is no longer “as-sold”.

7. Aspects of the application architecture make customisation difficult.

See above.

8. Service support processes have struggled to manage the volume of issues.

Sh*t's gone so bad that Talent2 don’t have the people or expertise to get it under control. Expect the costs to continue to escalate while the government throws money at a solution.

Conclusion
Like I said on Twitter: Novopay appears to be the wrong solution sold by people with a poor understanding of the problem, implemented with the typically lax approach of enterprise software development.

In other words, pretty much business as usual for Enterprise IT.

If you think this thing has run its course, you’re kidding yourself. I’ve seen Oracle systems quoted as costing $6m run up $30m of cost before being completely scrapped – as in yes, uninstalled and reverted to the system they were meant to be replacing, completely wiped away. Or there’s the  $1 billion spent for “no significant capability” on an US Airforce SAP system.

Auckland software developer Ben Gracewood is practice lead at Marker Metro, founder and director of the Codemania conference, and a former principal architect at Datacom. During his time at Datacom he was not involved with the company's payroll division. He blogs at Ben Geek.

* Language has been modified in multiple instances - CK