The Truth About Integrating Rails In The Enterprise

Ruby on Rails is a great RAD framework. We use it all the time. But one place Rails loses its magic–while not the fault of the framework itself–is with external integrations to legacy systems.

First of all, soap4r sucks. Everyone I’ve seen try to pick it up has gotten frustrated and angry at how awkward it is to write a SOAP client in Ruby compared to Java and .Net tools, which can do the same thing in a matter of minutes. Since RoR IDEs aren’t exactly 1337 yet, we need to put some serious love here as a community to prevent larger companies with heavy SOA leanings from running away screaming.

For some reason, many people seem to think that pouring t3h Rails int3rn3ts into an infrastructure will suddenly trim 75%+ off all development and maintenance costs, complete with rounded corners and shrink-wrapped buttons. Wrong. Many of the development tasks will take significantly shorter times to develop under timeframe expectations relative to Java and .Net, yes, but you can’t avoid costs associated with migrating legacy data and integrating with retarded external systems such as your ghetto-ass SOAP services. Nor should you avoid design activities such as usability analysis or proper testing practices. 

So if you have a web project that lives in complete isolation and does not have any legacy issues with which to deal, OpenRain can bust out that web project in a heartbeat. But if you have unresolved data management and integration issues, there is no acts_as_silver_bullet plugin which can save you the burden of having to actually think about and address those problems. Rails isn’t the cold bucket of water for your data nightmares.