IRD: How to Avoid Catastrophic Failure

Greg James of IRD (NZ's tax department for anyone not from NZ) has chosen to replace the current obsolete, unmaintainable monolithic bespoke software system (that's what, 30 years old?)... with a similarly monolithic COTS (Commercial Off-The-Shelf) system. This fills me with dread. He is repeating all of the structural blunders which has led to us having a 30ish year old tax software dependency in the first place.

No, I repeat, NO software project can justify a price tag of $100 million dollars, much less $1.9 billion. I honestly believe that it is absurd to think any IT project that size could be anything other than an unmitigated disaster, even before it's begun. It's simply not possible to manage something of that complexity. To put it into perspective, that price tag is more than a million hours of top-price consultants' time. Who's going to be able to coordinate all of that? Our government hasn't got a great track record for managing projects even 1/100th that size.

Wrong on Principle

Monolithic software solutions to address problems of this complexity simply don't make sense today. They didn't make sense 30 years ago either, but to be fair, the technical mechanisms (i.e. software languages and the software discipline) supporting the creation of modular systems, where logically distinct aspects of the software were "loosely coupled" chunks of discrete functionality rather than bound into a highly interdependent monolith, probably weren't in widespread use at that point.

But achieving rich software solutions in complex problem domains using loosely coupled modular components - where each component addresses a facet or part of the problem at hand - is now both well supported by software technologies, and is, duh, considered the obviously better solution by any software engineer worth her salt.

Modularity, Interfaces, Reduced Risk

The approach the IRD should be taking is to identify a number of internal IRD tax-domain experts, and to find and cajole a selection of credible technical software developers (NZ-owned, preferably) to sit down and identify:

  1. a sensible set of logical/functional modules of this system,
  2. define the interfaces between the modules, and then
  3. codify those interfaces as vendor-neutral published open standards for reference and public comment, and finally,
  4. start publishing RFPs for vendors to create the modules meeting the requirements and adhering to the interface standards...

This would allow them to break the problem down (as all engineers and planners know is the best way to estimate cost and risk associated with something complicated, like a nation's tax system) into bite sized-chunks with minimal risk.  They could then engage multiple software vendor candidates who might provide a good fit for specific components of the system (because different components might suit software developers with different sets of skills) to respond to tender documents for each module, and also select other vendors to vet the delivered solutions for compliance with the open standards (all compensated, of course). This approach, unlike that promised by Greg James, would allow any functional module created now to be swapped out at a later date for a different and better module without requiring any changes to the existing, happily functioning modules.

Learning from past debacles

Yes, a future IRD system, rather than requiring a big-bang, $1.9 billion project to replace it entirely, in one fell swoop, could instead be replaced module by module as tax requirements or technical capabilities change over time... at far far lower cost, and with far less risk. And, more-over, by smaller - maybe even local, NZ-owned - software developers. But no, the IRD's project lead has stated categorically that they are going to repeat precisely the same flawed pattern of development which left them in the very undesirable situation in which they find themselves today. One might think that they have learned absolutely nothing from their past failures.

In-built discount

I also wonder whether the IRD has considered the fact that they'd effectively receive a 30% price discount if they use NZ owned software vendors (unlike any of the multinational vendors considered)... in the form of tax. I haven't noticed anyone asking this rather obvious (well, one would hope this would be obvious to the NZ Tax Department!!) question... One can only marvel at the overall level of competence involved (or lack thereof).  I'll leave it to you to judge, gentle reader.

I'm motivated to write this because, after all, that $1.9 billion is my money. And probably yours, too, if you're reading this.

No comment...

I've suspended commenting on this site because I'm not happy with the proprietary Disqus platform I have been using as it is antithetical to much of the site's content and my own stated positions.

I originally chose Disqus because it helped to minimise the spam commenting that, previously, required a lot of administration time. I justified its use based on the idea that I always use Free and Open Source Software if a viable option exists in a particular domain. I haven't yet found something comparable that works with Drupal... but still, the cognitive dissonance of requiring people wanting to comment on my posts to sacrifice their freedom to do so became too onerous.

If you have a comment (or a suggestion on a Drupal 7-friendly, spam resistant commenting process with good admin and commenter notification recipes! - I recently tried isso, and it's cool, but sadly, not well suited to Drupal, although given it's open source, I might have a go at changing that) - get in touch!