The critical development work for our research company is going to get done via notes jotted on paper or blackboards with help from packages like Mathematica, and therefore won't actually affect us IT grunts until the researchers start to produce prototype code. When that happens, however, at least one of the key players is likely to make a federal case out of wanting to impose Fortran on everybody - and that's a problem because it's a terribly bad choice.
Except, perhaps, for the alternatives, all of which are as bad or worse on at least some dimensions.
Most importantly it's been my experience that a researcher who thinks he knows Fortran will nod at all the right places when you tell him about the cost and performance consequences of using something from the 1950s on problems taking terabytes of input to solve - and then continue to work in Fortran "for now" just as soon as you turn your back; eventually producing the predictable Fortran mess that nobody else can understand, maintain, debug or even get near without breaking out in hives.
So what can you do? Nothing directly - it's like telling a PC business applications developer not to express the application in SQL stored procedures or not to rely on proprietary Microsoft "server" functions. You can do it, but it's worse than a waste of breath because he'll change how he thinks about you long before he changes he changes his behaviour - and while he may intellectually understand the hole he's digging for the company the truth is that he won't care because his values are very different from yours.
Indirectly, however, there are things you can do - and the parameters limiting your options include finding people with useful skills who can clear the security vetting needed for the project's members and the duplication implied by the requirement that the on-board and back-check programs have to express the same processes, but should not be written by the same people or use the same programming languages or tools.
On the back check side, therefore, I'd suggest having the researchers nominate a couple of graduate students they consider qualified to work with them, and hiring those people explicitly for the job of converting from Fortran to something more appropriate - and right now I'd bet on Sun's forthcoming Fortress compilers for that because of the functional fit with both the core problem and the CMT/SMP processor generation we plan to use for ground based data management and back-check programming.
The situation on the cell side is much more difficult because you need Linux to access it, but Linux is heavily optimised only for x86. Basically, IBM made a marketing driven choice to use Linux instead of BSD on Cell and hasn't yet developed array compilers to support that decision - leaving problems of this kind without a good toolset solution. What you would do instead, if forced to make the decision today, would be to use C - and therefore find yourself looking for the unlikely combination represented by people qualified to understand the research and willing to learn how to program for Cell under Linux in C.
Luckily, you can put off the choice of language for production and maintenance work on Cell for some time because ground based tests will precede space based testing by a considerable margin - meaning that the burgeoning use of Cell in super computing may well have produced the people and tools you need by the time you need them.
You hope - because "Plan b" is C and it's almost as bad an answer as trying to hand optimise the intermediates produced by the IBM Fortran compiler - something that could ruin your whole year while making on the fly "maintenance" (i.e. adaptation and correction) impossible.