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).

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

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.

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

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.

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.

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.

How can you stop this from happening to you?

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.

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.

I’m not in the habit of linking from this weblog, nor do I habitually include cartoons. However, this Dilbert strip rings very, very true.

Here at Pragmetric, we find it, frankly, ridiculous how hard it is to compare offerings from vendors – even when they’re quoting to provide exactly the same thing. It shouldn’t take a complex spreadsheet to determine how much you’re going to end up paying for a given product or suite of services.

But, even for us, with years of experience in the industry, it does.

How can someone without our experience have a hope of making sense of things?

This is one of the ways in which we add value to our clients – we strive to make pricing transparent, our own included. That way, you can make your decision (with our support), based on the best possible information.

The goal of a business is profit. Fairly simple, right?

In order to make a profit, you have to actively seek out and maximise opportunities while you analyse and minimise risks that have a potential to negatively impact on the profit potential of those opportunities.

Business Technology is present on both sides of the equation.

There are some quite major risks associated with getting it wrong.

The biggest risk, and probably the one that comes first to people’s minds, is the financial risk associated with a failed implementation, or with making a bad purchasing decision. There’s also the cost of a lost opportunity if you follow the wrong path, or if you don’t look forward far enough to see a change coming. Consider the myriad of risks of entering into a 3 year support contract with someone who turns out to be an unscrupulous cowboy.

While the risks are important and, as such, need to be managed, we try to focus on growing opportunities, ways in which we can have a positive impact on your business.

Of course, the ultimate decision rests with our clients – we need to convince them that the rewards from taking up an opportunity will more than repay the associated cost. Our expertise, in support of your decision.

There’s a new generation of pending CIOs who are working their way up the industry ranks. They’re different to the old school in a number of ways. They need to be, the technology world is changing faster than ever. Some of them have reached CIO level positions, while others are still in the early stages of their IT careers, and won’t be there for a few years. The CIOs of the future are a very different breed to the CIOs of now.

Big Iron vs Overgrown Desktops

Traditional CIOs come from the days when mainframes were for business, and everything else was a toy. Back then, if you wanted to do serious work (is there any other kind?), you needed big iron that cost (at least) 6 figures, required re-inforced floors and a pallet-jack or forklift to move.

Next-Generation CIOs cut their teeth on Linux and Windows, they’re used to “small iron” servers, they’re on board with clustering, redundant failover. They understand how the cloud works, and the love the idea of not having to actually have hardware to look after.

Bare Metal Coders vs High Level Hand-wavers

Assembler, Cobol and Fortran – real languages for when you need the job done right. Back in the day, the computers were slow and stupid – you needed your code to be fast and precise. Traditional CIOs are horrified to realise that modern coders can’t code for bare metal, have no idea how to address memory directly, and really don’t care about what CPU they’re writing for.

Modern coders write in high level languages, letting the computer figure out the optimal way to do things, and knowing that most of the time, it’ll get things right. They know that it’s more cost-efficient to add another CPU to each server than for them to spend 2 months optimising the code for a few microseconds here and there. RAM is cheap, we’ll just add more of it, no need to be overly careful about memory.

Many CIOs who’ve had skin in the game for a while come from a development background. But the type of background it was, that makes a difference.

In-house vs outsourcers

Back in the day, if you had IT needs, you had an IT department. These days, if you’re not in the IT business, why would you? Leave it to the experts! Of course, it’s never that simple, that cut and dried – but your Next Generation CIO is onboard with outsourcing, pulling in expertise as and when it’s needed rather than keeping it all in-house.

Technology vs Business

Your CIO has to have something of a technical bent – but these days, as IT reaches its tentacles further and further into every aspect of the business, your CIO has to know more and more about anything and everything. CIOs these days are generalists, who know lots about almost everything, and even more about technology. More importantly, they know how these things inter-relate, and look for ways to leverage technology to make everyone else’s job easier.

What does it all mean?

A good CIO is flexible, adaptive, and able to not only move with the times, but able to foresee where things are heading, and align their business to take advantage of change at the most opportune times.

A good CIO drives organisation change that benefits the organisation in tangible ways.

And remember… a good CIO doesn’t have to be onboard full time.