What happened to the NAB can happen to you.

/
30Nov2010

What happened to the NAB can happen to you.

  • By Andrew Garrett
  • 1 Tags
  • 0 Comments

You’ve probably heard about the problems the NAB has been having over the last few days (some details here). Details are somewhat thin on the ground, and probably will remain so (at least as far as those of us who aren’t inside the NAB are concerned).

\n

What’s come out is some fairly light information that mentions a ‘corrupted file’ being at the root of the situation.

\n

One of the key fundamentals of systems design is ‘be liberal in what you expect, and strict in what you export’. This means that you should expect there to be things wrong with your inputs, and make sure that they meet your requirements before you start acting on them. It’s fairly obvious that this wasn’t the case here – otherwise a corrupted file would not have had impact on the system’s data. If you detect an error in the file, you simply stop processing, and report the problem.

\n

Of course, determining that there is an error is just part of the equation. How should you move on from there?

\n

Well, hopefully you have a means of recovering a copy of the file from a known good source. Then, you just start the process again – in this case, transactions would have gone through, possibly a few hours delayed. This is the sort of thing where it’s best to involve a human, at least the first couple of times it happens.

\n

Think about when you last filled in a form on a website: You enter your information, and if there’s something missing, you get an error message. You don’t get a situation where there’s invalid information entered into the system, because the system has been built in such a way that it expects some people to get the occasional thing wrong, and figures out how to let them know so they can correct the information before it’s stored.

\n

While the ‘corrupted file’ is being blamed, that’s really a cop out. It’s the first order cause. Blame should, more accurately, rest upon the system designers and programmers, who didn’t validate their system inputs before starting to process the file into the live system. It’s possible that this mandate came down from management, or that deadlines were pushed, but ultimately, a flaw in system design has to rest with the designers of the system.

\n

How can you stop this from happening to you?

\n

If you’re designing systems, make sure that you have good system designers involved – and that you listen to them. Don’t skimp on doing things right for the sake of expediency. If you’re buying systems, make sure they’re thoroughly tested at the evaluation stage, before you embed them into your organisation.

\n

Things that ‘should never happen’ DO happen. Good systems deal with them cleanly, and make it easy to recover from them. Poor systems fail, and cause huge amounts of work to clean up.

\n
Linkedin Twitter Facebook Digg Delicious Reddit Email

CATEGORIES Uncategorized

COMMENTS
00132407