More on Ruby in the Enterprise

If it wasn’t because of a favourable comments that readers have made of James McGovern Enterprise Architecture books, I was going to write off what he had said about Ruby as merely trolling around.

I’m trying my best to interpret his thoughts here. Readers, this is just my interpretation OK?

Issue: Should Ruby be on the Enterprise Architect’s radar at the moment?
Answer: No.
Reasons: Enterprises have enough languages to deal with

James McGovern: I guess the average enterprise doesn’t already have enough languages to deal with and throwing a few more on the pile won’t hurt

My response:Adding a new language to an enterprise always require careful balancing of the pros and cons. However, it shouldn’t be discounted altogether. Lesser languages have slipped into the enterprise under the guise of configuration files that are actually little scripting languages, or new languages (e.g. Velocity) or JSTL (new extensions to HTML).

Issue: What should the foremost in the mind of the Enterprise Architect today?
McGovern: auditability, power consumption, maintanability
My response: A lot of the AspectJ work to improve auditability and maintainability are hacks around Java by modifying the bytecode generated. Dynamic languages have these capability built-in. In addition, frameworks like RoR have tenets around convention over configuration. These have general implications on maintanability.

Issue: Does Ruby embed well within existing enterprise architecture?
Quote: … shops that have mature enterprise architecture practices, they simply don’t allow insulting [sic] firms to propose architectures for them
My response: James had already remarked that Ruby should run on JVM rather than it’s own VM. Have a look at JRuby. In addition, Sun is working on improving the JVM for running scripting languages well.

Update: Sadagopan’s views concurs with James’