Toll Transitions builds IT for Defence relocations

By on
Toll Transitions builds IT for Defence relocations

Loses four senior programmers in six-month project.

Page 1 of 2  |  Single page

Relocation service provider Toll Transitions is extending its use of a policy automation engine after building out the system for a 2009 contract with the Australian Defence Force.

The company, which is part of logistics giant Toll Group, stood up IT systems to manage the nationwide relocation of Australian Defence Force personnel in just under 11 months.

It won the five-year relocation and removal contract in late 2009, partially on the basis of the technology innovation it offered to Defence in the tender process.

Toll Transitions manages the relocation of up to 25,000 Australian Defence Force personnel and their families every year. It doesn't physically perform the moves, but rather manages the process end-to-end, farming the work out to approved suppliers.

Defence personnel seeking to relocate submit an application either in-person, online or by post.

Data in the application is converted into an electronic format (if paper-based when submitted), and listed in a custom case management system.

Details of the application are automatically checked to determine if the applicant is eligible for relocation assistance, such as allowances, travel and accommodation, and the entitlements are calculated.

The checking and calculation is performed by a business rules engine that automates sections of Defence's Pay And Conditions Manual (PACMAN), which set out the rules and process for determining eligibility and payment.

The rules engine is Oracle Policy Automation, which was formerly known as Haley RuleBurst. Oracle bought Haley in October 2008.

If the applicant is eligible, the rules engine spits out a determination that is filed and forwarded to a case manager, who oversees the arrangements for the relocation.

Toll Transitions strategic systems national manager Nigel Maloney told iTnews that the company had "very little in the way of code base for a system to run this contract" when it bid for the work.

"We actually developed the whole case management system and the integration of [Oracle Policy Automation in just under 11 months," he said.

"I think what really impressed Defence in the tender process was not only our capability to bring innovation to the market, but also that this piece of [Oracle] software, which was core to what we were tendering for, could actually quickly determine what the allowances were and ... provide a very extensive document at the back, which met all of the process requirements of PACMAN.

"So [for example], 'Chapter six, paragraph three, line five [of PACMAN]. This is why you qualify for that amount of money'.

Bridging systems

Although the two components - the case management system and rules engine - were operational from day one of the Defence contract, they weren't integrated, and it took the best part of six months and a succession of programmers to bring them together.

Maloney said that hooking the rules engine into the case management system "was more difficult for us than it was for Oracle to take the legalistic [PACMAN] document and turn it into the rule engine".

(Toll outsourced the translation of PACMAN into the rules engine to Oracle Consulting, which worked closely with Defence).

The complexity of the integration cost Toll Transitions four successive senior programmers.

"They resigned and walked away because they couldn't get their heads around it," Maloney said.

"That was a bit of a shock to us, but we eventually got there with the assistance of Oracle's technical people and by educating the programmers."

Maloney saw the integration challenges firsthand.

"Oracle Policy Automation is unlike any other program I've ever seen - and I've worked in IT for over 30 years - in the sense that it took essentially a Word document, wrapped a few if-then-else statements around [the] document and miraculously it manages to interpret that.

"Now when you give that to a programmer who's used to working with thousands of lines of code - we use C# as our code base - they can't instantly get their heads around ... how to hook that in."

Maloney was pleased with the integration. "It's been up and running for just on 18 months and it has never proved to be wrong," he said.

"Every determination that we've done has been spot on".

However, because Toll Transitions assumed contractual responsibilities prior to the integration being completed, it instituted a stopgap measure to run the necessary determinations.

"Because we were having problems with the interfacing of [Oracle Policy Automation] into our then system, we went back to Oracle and said, 'We're struggling a little bit with this. What can we do?'

"And they said, 'Well we've got an out-of-the-box web capability ... If you like, we can build the web front-end'."

The website was produced in "under four weeks". Toll staff keyed data from the application forms into the site to produce the determination and supporting documentation.

The integrated system has all but replaced the stopgap website. However, Toll is still keeping it online.

"We keep it as a backstop," Maloney said. "It's a bit of a DR [disaster recovery] capability if anything should go down."

The site is also used to perform rough calculations of entitlements for Defence Force personnel seeking more general information on their entitlements, prior to submitting an application.

"If, for instance, an Australian Defence Force member rings into a [Toll] office, and says, 'This is my circumstance. Can you give me a brief understanding of what entitlements I would be receiving?', [Toll] can do the calculation using the web given that it's only based on the information that they supply at that point in time," Maloney said.

He continues: "The whole thing about having that [web-only] capability and an integrated capability is that they're both running off the same rule base, they're both using the same base to do their calculations.

"So no matter where a [Defence Force] member rings or whichever Toll office they walk into, the same process is run and, based on the same information, they would get the same answer every single time regardless of what office they go to.

"Now if we were to do that manually we could almost guarantee that you would get a different answer every time."

Continue to page two to find out how much complexity the system can handle and how Toll will extend the platform for use by other customers.

Next Page 1 2 Single page
Got a news tip for our journalists? Share it with us anonymously here.
Copyright © . All rights reserved.

Most Read Articles

Log In

Username / Email:
  |  Forgot your password?