"Chaotic Architecture" At NASA's Jet Propulsion Laboratory

New submitter CarlaRudder writes: NASA's Jet Propulsion Lab (JPL) is ditching old, rigid, legacy tools and adopting a much more flexible approach that allows people within the company to pick and choose the technologies that help them do their jobs better. CIO Jim Rinaldi and IT Chief Technology Officer Tom Soderstrom are calling it "chaotic architecture," and they are using it to better prepare for change and to attract the next generation of IT talent to JPL.

Comments

Moar Struts!

[wikthemighty]

They probably just signed a contract with Jebediah Kerman's Junkyard and Spaceship Parts Co.

Open Parametric CAD Standard

[trout007]

What the Mechanical Engineering world badly needs is an open Parameteric CAD Standard. Right now it's horrible. Each company uses it's own proprietary file that cannot be easily shared with other software. There are some portable formats but you basically give up all of the engineering data. A CAD file should be an engineering document not just a model of what the perfect part should be. It should contain all of the important parametric data and the tolerances, GTOL's, surface finishes, fabrication notes, etc. It is amazing that this still doesn't exist and the costs of dealing with it are astronomical.

Sounds scary, but it makes sense.

[JaredOfEuropa]

A few things I have learned from 20 years in IT:
1) On every project, (individual) people have been the critical success factor, not process.
2) While you will always need process, process is not a replacement for good people. Most common IT processes attempt to ensure that errors made by poor performers are caught, but they also ensure that your best people will not be operating at peak performance. This is sometimes called "predictable mediocrity"

This Chaotic Architecture thing sounds like a step in the right direction... putting trust (with oversight) in people rather than an ivory tower dictating company-wide policies. The real trick is how to organize that oversight without ending up with the same dictatorship by corporate architects. This requires effective management at all levels; daring to delegate and trust rather than dictate... but I've noticed a bad shortage of such Leaders in the places I've worked the last few years.

Re:Sounds scary, but it makes sense.

[vux984]

I agree with everything you said. However, there is the other side of it too:

'chaotic architecture' could just as easily be the state where users are given control and IT has to support whatever nonsense users want. We've all seen it. Company goes "BYOD" and "chaotic architecture" follows... every piece of crap random consumer grade device gets brought in... half of it doesn't run the business critical apps properly, centrally managed A/V isn't possible, virus infections run rampant and IT finds itself working on some twits $300 Sony Vaio with 1GB RAM and Vista Home Basic... torrent software consumes all bandwidth. Some nimrod installs an inkjet color printer that's only compatible with XP, then buys a Windows 8 laptop and wants IT to make it work...

IT needs to facilitate users getting the tools they need, WITHOUT letting it get TOO chaotic. :)

Re:Sounds scary, but it makes sense.

[thinkwaitfast]

From 20 years in aerospace:
You need a good process if you having things break is unacceptable.

Re: Sounds scary, but it makes sense.

[JaredOfEuropa]

It doesn't mean to just let everyone use whatever they want; you still need oversight, from your peers as well as your manager. And good individual choices can (and should) at some point be incorporated into company guidelines.

I've worked with software that came from a "chaotic" environment. When it came to fixing bugs, there was a lot more moaning about "why the hell did he do that?!" compared to software developed against corporate standards, however the time and cost of fixing a bug were similar for both types of software. When it comes to adding enhancements, I found that the success factor was not having a company standard software architecture, but a good one. Software developed by a lone but clever developer entirely doing his own thing turned out to be easily enhanced due to outstanding software architecture. Software developed to company standards was equally maintainable if the standards were good enough, however in many cases one would find that the standards were applied poorly, or were themselves incomplete, leading to poorly structured and hard-to-maintain software. Again, in the end it comes down to people