Congratulations AsA - a modern IT wonder.
 

Congratulations to AirServices Australia on the roll-out of the new briefing system this week. Slower, more complex, fails to interface with standard industry tools and makes everyones life harder.

I am sure some of the worst squarks will be ironed out over the next couple of years, and we will learn to work-around the rest.

I have heard of a practice where major software and hardware changes are rolled out in parallel with the old system for a period of trial before switching the old system off.

This practice is normal for high-risk environments. I guess they decided not to do it this time because Aviation is low-risk... and we all know how safe it is, don't we?

YES I had plenty of time to think abou this, I spent 22 minutes on hold yesterday trying to lodge a flight plan, forced to listen to ASA dribble on about how they are world leaders in this and that and the other.

ON A SERIOUS NOTE than you and well done to all the BN and ML Center controllers, who kept an even tone and bent over backwards this week to help all the flights with lost, deleted, unlodged or seriously delayed flight plans.

Cheers

Rubbish. :)
So there. :cool:

Even if the server thingees are sped up (NIS works great at 2300 at night) the whole thing is going backwards. Still, at least it's free...

I tried 10 times on their website yesterday and gave up. Ended up submitting with tower on taxi. Held sar with a friend.

Got a call from CENSAR that afternoon saying my plan did go through and I didn't cancel SAR. Sigh.

Shag, Bloggs and Blowy,

Have you tried the system since 1620K BNE yesterday?

Techs reckon they made changes at that time and from what I have been seeing since and so far today is that NIS responding quite well.

Aside from the utter disaster of the change implementation, why choose to do it on one of the busiest days in the week? :ugh:

As previously stated, much respect to BN briefing who handled all the calls while maintaining professionalism and patience.

In AsA's defence, the planned intro was last Sunday. It's just that it failed then and somebody decided to do the second intro in the middle of the week.

I have, as stated above, and it's currently working well. The Test site also worked well. It seems to me (apart from the clunky, harder website design itself) that the problem is the site performance under load. Peak hour on Monday morning will be the real test of "the changes".

Ok. Ta.

The thing that is missing here is that with the ICAO Flight Plan changes, all the systems have to be changed to cater for the new requirements in a specific order and short time frame.

Given that making >1 significant change (and this includes data set changes as well) at a time is a considerable risk (read up about the skyguide disaster) then there are very limited opportunities to reschedule a change.

For example, there is a significant change to the AFTN switch going on tonight and nothing else. The longer NIS took to get out there, the less time the Flight Plan 2012 changes will be on the external test bed and that in turn has its impacts.

There is lots of pieces to the puzzle that are waaaaay beyond the view of external users.

Understand. But the external users are usually the ones who end up in the dock (ala Norfolk) when things go pear-shaped (through no fault of their own); Flt Notification stuffups, lack of briefing material...

If things have been rushed, then they haven't been planned properly. If things fail on implementation, they haven't been tested properly.

Good afternoon, this is your Captain speaking. Welcome aboard.

We incorporated a modification to the aircraft pressurization system that had limited testing due to a lack of test beds and very limited opportunities to get the work done. There are lots of pieces to the puzzle that are waaaaay beyond the view of passengers.

So that’s why it’s OK if you encounter some discomfort and loss of consciousness.

Slug: explanation does not equal justification. :=

The Ops Support man told me that the test NIS site was to have been available in July but was only available in late Oct! :sad: gives no one time to get ready, work out issues and plan ahead. I suspect this is part of the reason it's been overloaded. Many, many folk trying to come to terms with it, transfer SPFIB & Flight Files, etc. :eek:

Puff,

I'm not justifyin anytin simply saying how things are. Take it how you like it as I really don't care. I'm here to pass on info as I find it.

My comment about pieces of the puzzle refers to the necessary timing and very small windows of opportunity to deploy an and almost unprecedented series of changes on a world wide basis and not the context you have applied.

Claret,

Nope, it was not the amount of server traffic I am told.
Yes, there was to be a NIS test site but that got overtaken by other events as can happen.


Bottom line with the changeover was that something went wrong that was not seen in the test bed - both internally and externally - and has now been corrected and with the change on 10 Nov, will improve again.

If you all really are so put out by this weeks events, sit down, write a letter/email to the airservices CEO and ATC general manager and put forward your thoughts rather than setting them down here and winding each other up.

Bloggsie, it was me who said that and I stand by it. From a user interface perspective, in my opinion, NfW was a steaming pile of poo.

If I am going to be sitting at a computer to file a plan, I would much rather do it with the new website.

Unless there is a specific thing you used in NfW that I didn't and so don't miss, I am going to say NIS ****s all over NfW.

In corporate IT, failed initial deployments are the norm, and Airservices did a clean roll back. Kudos for that.

And the slowness was solved in 48 hours? Well done.

The reality is that this stuff happens in companies with as many employees as there are pilots in Oz all the time, except we don't hear about it, it is all internal.

Overall, I am still very critical about the late access we as 3rd party developers got and the lack of response to our issues. Not to mention trivial firewall changes taking many days in test and many hours after go live.

But, as these things go, it wasn't too bad at all.

I hope next time they take us developers more seriously... On day one, over sixteen thousand requests to NAIPS went through our servers, I reckon pilots love their iPhones...

Darwin departures were a mess over the last two days., hardly anyone had a plan come through whilst ready to taxi., I gave up and departed VFR, had to pull out the good ole' VTC and rattle up the brain on how to do it ! ;)
Thanks a lot to the Darwin ATC guys n gals, great accommodating and controlling given the scenario :D

Smoothie.....:ok:

But were any Qantas flights delayed? If not, it's a 100% success! :ok:

Nothing like Aussies ... Can't stand change, expect everything for nothing and bitch about anyone who tries to improve something.

Poor diddums, if you all had your way we would still be using MS DOS

Slug: If you are merely a messenger rather than an apologist for this debacle, my apologies. :ok:

I naturally assume that, ultimately, no one's responsible. :ugh:

Aussie Bob, fair dinkum that comment is about the intelligence level of a goose mate. I had a 4 leg plan lodged the evening before we were to be airborne (RPT turboprop) at 0600 local out of a military AD tracking to and within 20 minutes flight time of SY on Friday morning. The same 4 leg plan and call signs that have been lodged literally hundreds (if not thousands) of times previously with ATC in our operation.

After going to bed at a reasonable time for the 0400 wake-up I was contacted by BN ATC at 2300, 0010 and again at 0113 LMT to query info, WPTs and departure times that had been submitted the evening before (not normal procedure but done as our company had been having lost and inactive plan issues the day previous, so one of our senior people popped a few plans in the system at a quiet moment). The issues that were arising were WPTs that wouldn't gel with routes and departure times that would dissappear as they were lodged...

I feel for the poor bloke who rang me each time (as they were trying their best to get it all sorted), however that first three hours sleep I got was the only sleep I ened-up with that night - which makes it difficult to call our OPS and tell them I don't feel rested due to being constantly interrupted.... Certainly wasn't the most alert I've ever been at work.

Let me guess, the Air Services boss and associated managers responsible were all safely tucked-up in bed asleep while the coalface staff were left to make sense of the s#!tfight their masters left them?

Change is good mate, especially when it is thoroughly designed and tested for function and fit first. The bunfight that Slugfest has mentioned is as good a reason as any for Air Services to tell ICAO "Nope sorry, not happening - need more time."

This is a "Safety First" industry, not the "Chuck it in there and then work it out as we go" fun we've just had over the last few days. Maybe this is one of the reasons GR did a runner a few months ago?

No it's not. In small organisations who don't plan properly it is. Larger organisations, faults affecting 0.1% of the customer base are considered a MAJOR issue. Most of the IT companies I've worked for have considered 99.999% uptime the minimum standard, and generally did better than that.

Wait, what, used anyone's online banking lately? Or trying to buy insurance? How often do those systems slow down and go down? "5 nines" my ass! And that isn't even talking about their internal use systems.

Besides, I don't think AsA sees us GA pilots as "customers". They have one or two customers, the rest of us they are just doing a favor...

And you haven't experience ANSP IT failure until you've been stuck in Dusseldorf for 2 days before taking a train back to London because the bloody POHMS cocked up an upgrade that grounded the entire UK. :ok:

So, in the grand scheme of things...

I've been in IT for many years and have been involved at the project management end of some largish rollouts.

I agree Baswell that issues routinely occur with these types of rollouts but I believe they could have done more to ensure a smoother cutover.

You always need to conduct load testing prior to cutover, how did they go about accomplishing this ? Clearly what they did was not sufficient.

The test site should have been up for much longer at least 1 -2 months. Cutover date should have been delayed to allow for this.

My approach would have been to have a parallel implementation of both systems with a cut off date for NFW.

This would have meant a gradual transition, realistic load testing rather than simulated and instant rollback in case of serious issue.

No doubt tricky to achieve but worth the effort IMO.

On positive note I do think they have made the right choice going web based as its going to allow for rapid and simple deployment of additional functionality. (should benefit all of us hopefully)
Lets face it updating a Windows app on large scale is a pain in the neck. No doubt why NFW hasn't changed in a long time.