@madpilot makes

Enterprise Rails

Anyone in the Rails community would have read Zed Shaw’s rant about Rails. For those of you who don’t know Zed, he wrote Mongrel, which is the default web server library used in Rails. It has blown up and been discussed on just about every list, including Rails Oceania. I’m not going to discuss what he said, or his tone, as it has been done to death, and he seems like the type of guy that you need to know to understand where he is coming from.

What did hit home from me was what he said out enterprise Rails. To frame this correctly, have a listen to the first half of this podcast from RailsConf.

As a rubyist, I could never understand why projects like JRuby or IronRuby existed. Why would you want to run another language in a different virtual machine? After reading and listening to Zed, the answer is obvious – integration for enterprise. If you look at existing enterprise systems they will run on technologies such as Java and ASP.NET and with good reason: Support. You can go to certified training courses and become a certified engineer, which makes hiring for these large corporates easy. There is also a a large number of consultants that have based their business models on these technologies. These guys know things like Tomcat and IIS – they don’t know (or care) about Mongrel or Lighttpd or even Apache.

Web 2.0 is not going to be around forever – regardless of whether you think the web-o-sphere is in a bubble at the moment, it will cycle at some point, and there is going to be a hell of a lot Rails developers out of jobs. Software-as-a-Service will alleviate some of this, but there is one BIG area that has been ignored – and that is corporate and government applications. The beauty of targeting this audience is that it is big and constant – their will always be big business that need IT systems. There is a number of reasons why this segment has been ignored by Rails coders that Zed rattles off – issues with connecting to legacy databases, lack of LDAP/central login system access – but these are technical issues, which are easy for programmers to fix.

I think the bigger issue is the complexity culture of enterprise systems – DRY isn’t something is in their vocabularies, so we don’t like to talk to them, because it makes our lives harder, and they don’t want to talk to us, because they don’t think the systems we build will do what they are asking. Having said that, I’ve seen enough hacked up Access databases in government and the education system to realise that this is complexity, for complexity’s sake.

Things like JRuby and IronRuby are going to make the the integration side of things easier – now we need to start getting back in to the corporate space.

SaaS is basically the same thing as ASP – ASP is what it was called during the last dot-com boom.


  1. Hi,

    I just found an exclusive answer supporting this blog here.

    It clearly explains the advantages of IronRuby over Classic Ruby and Ruby on Rails.

    its here...


  2. As a government user, I'd say that the "culture of complexity" with us partly comes from having to join up different vendor products that were not designed to work that way, in order to meet very particular combinations of legal/technical/political requirements. In some cases we have niche requirements that are not very profitable to serve, so can only choose from a small range of products built from proprietary components.

    The need of ISVs, consultants and in-house developers to meet all the requirements forces low common denominators - tech which is widely supported and adopted (and outdated, and cumbersome compared to newer stuff). We probably have to be about 5yrs behind the curve in some cases.

    The phenomenon of very large vendors heavily promoting overcomplex solutions is probably a natural consequence of large budgets - I've only seen it on big projects.

    The biggest boat anchors for us are probably the core databases - Oracle or MS SQL Server with key apps directly tied to the schema and SQL dialect. They aren't really "legacy" because they are heavily used and actively developed, but we can only use additional development platforms that support them.
  3. As someone who has has been in the enterprise (Java) world since 1998 the advent of "certification", etc has only made hiring much more difficult.

    You say, "You can go to certified training courses and become a certified engineer, which makes hiring for these large corporates easy". This would be what most people who haven't interviewed 'certified' developers would think (it is a logical extension). The reality is that only developers that are entry-level or knowledge-based developers (the ones that only know syntax, but don't understand design, rules of thumb or best practices) go for certification (95% of the time in my interview experiences).

    When hiring for new Java/J2EE/JEE developers I would always throw away resumes that showed Java 'certification' as the only highlight of their Java experience.

    In theory you might be right, but in reality the best developers understand a language at a much deeper level than syntax. Syntax is only useful for newbies and reference manuals. And this is basically all the certification exams can test (and/or purely knowledge questions about Sun-sanctioned blueprint patterns).

    This is not to say Ruby is for all enterprises, but for nimble enterprises that can invest time and money in new ways of doing things than integrating legacy applications, Ruby, Python and probably another few others might be suitable depending on IT organization objectives.
  4. Stuart: That is a really interesting insight. It makes me wonder whether there is scope of simple, custom solutions. With small, agile teams, it is amazing what you can do in a small amount of time. I guess it depends on the how tight the budget it? But surely, trying to shoehorn something costs more in the end?

    Susan: I agree with you - I've just seen it to many times where these "qualifications" look more impressive to the middle management who know no better.

Leave a comment