Four tips to choosing your digital partner

• Pingback: News about IT | Michał '13mhz' Hunger

• Benon

  I wonder how much you know about Ruby on Rails (ROR) considering you think its difficult to integrate with legacy systems. We’ve done it with no issues. I think ROR is scarey for most developers as you can build out applications extremely quickly and react to client changes far faster than most other platforms. It has the potential to make some developers neverous as a lot of the dog work is taken care by the framework. And with the dog work done, sometimes the high fees can be difficult to justify. In fact I think a lot more clients locally should consider this over PHP and .net as the fast builds and quick changes match well with the demands of a changing consumer environment.

• Brattstar

  +1 Benon – You hit that nail on the head. 

• http://twitter.com/craigraw Craig Raw

  I fully expected a comment like this. You make a lot of good points about RoR I agree with, but I’m only contesting one: In general, it is certainly more difficult to integrate with legacy applications in RoR than it is in a more widespread language/platform. It’s great that you’ve managed it so far without issues, but I think you’ll find it hard to argue that Ruby has as many client adapters or as much legacy enterprise system support – and that is precisely what I am addressing.

• http://www.facebook.com/xcal55 Robert Fall

  This is a very uneducated view of the Ruby environment. I would argue exactly that Ruby has more adapters, and that it would be far quicker to build and disseminate them to the user base! The ruby gem system makes creating plugins for ANYTHING very simple and efficient and the open source community behind it means that this actually happens!

  If the legacy system is worth integrating with there will be either a gem that does it for you, or a service with which you can interact, and ruby is very good at consuming web services. I’d like to hear about problem cases with regards to legacy integration before I accept the judgement that it struggles.

  I’ve used ruby to interact with LDAP servers, Oracle and MSSQL as well as SOAP based services and I know of SAP integration plugins etc. 

  The point I’m trying to make is, if it’s worth integrating with there’ll be a plugin. If there’s not, the open source community behind ruby will be a great resource to help build it. Even proprietary legacy systems are easier to build a new project against with ruby than with the more tiresome languages.

  Legacy enterprise programmers are used to doing a lot of the “dog work” as mentioned and then when they experience the ruby eco-system they see a lot of it done for them and tend to think “If it’s not done, it probably can’t be done.” That’s rubbish. Ruby is as powerful a language as C# and Java and moving much faster. The integration you would have had to build with Java or C# can be built in ruby.

  Each tool has it’s place, but don’t slander the ruby/rails platform unduly. The average rails developer is often working on something far more exciting than integrating with legacy systems purely because they can, while the enterprise is languishing behind building boilerplate. That doesn’t mean they can’t integrate, it usually just means they don’t want to.

  (I may be biased for ruby, but there needs to be some to counteract that against it in the article.)

• http://twitter.com/luke_randall Luke Randall

  I have to disagree with your offhand remark to “beware Ruby on Rails if you need to integrate with legacy systems”. It seems to be a cargo culted opinion proffered by those without Ruby experience. A far more useful insight would be to beware integrating with legacy systems, full stop.

  However, if Java supports your legacy system then by extension Ruby (in the form of JRuby) does as well. JRuby is a mature implementation of Ruby that runs on the JVM. It allows you to reuse your existing knowledge of and invest in a JVM stack, and lets you call out to Java code as needed.

  Secondly, even if JVM doesn’t provide a solution, your best solution might still writing an SOA wrapper for your legacy system which you can then consume from Ruby, as well as any other systems that might need to integrate it. The investment will not only give you greater flexibility in the future, but might be repaid in the time savings you realize from using a more productive language (and framework, if you use Rails or the like).

  I’m not suggesting Ruby is always the best choice, but that a casual dismissal of it if you have legacy integration concerns is likely to prove ill-founded.

• http://twitter.com/luke_randall Luke Randall

  I have to disagree with your offhand remark to “beware Ruby on Rails if you need to integrate with legacy systems”. It seems to be a cargo culted opinion proffered by those without Ruby experience. A far more useful insight would be to beware integrating with legacy systems, full stop.

  However, if Java supports your legacy system then by extension Ruby (in the form of JRuby) does as well. JRuby is a mature implementation of Ruby that runs on the JVM. It allows you to reuse your existing knowledge of and invest in a JVM stack, and lets you call out to Java code as needed.

  Secondly, even if JVM doesn’t provide a solution, your best solution might still writing an SOA wrapper for your legacy system which you can then consume from Ruby, as well as any other systems that might need to integrate it. The investment will not only give you greater flexibility in the future, but might be repaid in the time savings you realize from using a more productive language (and framework, if you use Rails or the like).

  I’m not suggesting Ruby is always the best choice, but that a casual dismissal of it if you have legacy integration concerns is likely to prove ill-founded.

• http://twitter.com/craigraw Craig Raw

  Robert, your argument falls down at the statement “if there is a legacy system worth integrating with” and “that doesn’t mean they can’t integrate, it usually just means they don’t want to” - unfortunately developers in an enterprise environment are not free to decide what is worth integrating with. 

  You name some well known and well used technologies as examples, but these are not the problem. It’s the lesser widespread systems, such as the myriad of accounting packages, process control automation and other lesser known software that do not get the loving you describe. Yes, it’s always possible to write a bridge, but that’s precisely where the challenge lies – not just around the code but deployment and maintenance as well.

  While Ruby has been around for a long time, it is only with the relatively recent Rails that it has become really popular. No universal programming language poll I’ve seen places it in the top 3. You are fooling yourself if you don’t believe that history and momentum don’t play a role in legacy integration.

  What’s also true about your argument is that you could have read it 10 years ago, replacing Ruby with Java and Java with C++. I remember many such posts. The truth is that it took Java years to develop the momentum it has, and we should learn from that history.

• http://twitter.com/craigraw Craig Raw

  Luke, JRuby is an interesting option if you need to call out to a Java adaptor from a Ruby stack. Another option is to write an SOA wrapper. There are always options and workarounds, that’s not the point.

  The point is simple: A platform with more historical support will integrate more easily with historical platforms. I’m not saying dismiss it – I am pointing out the obvious casuality link here, and suggesting appraisal of the implications before steaming ahead.

• http://twitter.com/craigraw Craig Raw

  Luke, JRuby is an interesting option if you need to call out to a Java adaptor from a Ruby stack. Another option is to write an SOA wrapper. There are always options and workarounds, that’s not the point.

  The point is simple: A platform with more historical support will integrate more easily with historical platforms. I’m not saying dismiss it – I am pointing out the obvious casuality link here, and suggesting appraisal of the implications before steaming ahead.

• http://www.facebook.com/people/David-Tinker/754660423 David Tinker

  Its not so much “can ROR integrate with enterprise systems” as “is it as good as Java in that space?”. And the answer to that is no.

• Benon

  The way you position it, is that its
  not suitable at all, which is misleading. And considering this article is aimed
  at the man in the street it is only adds to the confusion other there. While I
  agree that Java and .Net probably have a lot more in terms of client adapters etc.
  out there, its more as a result of the fact the technology has been around
  longer than RoR. But given that RoR has a strong open source following I would
  say that this will most likely change in the near future.

  Interestingly enough we were looking at Java for a new project that involves
  connecting to devices via USB, and it seems that there is nothing available in
  terms of libraries for USB. On the other hand we found a number of suitable
  libraries for Ruby. Using these facts one could state that if you want to do
  anything modern avoid Java. Equally I could tell you about a new client who had
  a Java based application that was developed by a top Java company in Cape Town,
  it took 18 months to do and millions of Rands. At the end it was slow, missing
  key features and had numerous other issues. We rebuilt the entire application
  using rails in 6 weeks with one developer, resulting in a product that met all
  the clients needs.

  Another issue I have with the article is that is your view on the IT dept. I’ve
  worked on both sides as an analyst at a corporate and an owner of a large
  agency.  While at a corporate the experience of the “Web Guys”
  was one of that they would engage with the marketing team, implement technology
  for their solution, without consulting with other areas of the business, this
  resulted in solutions that didn’t align with the overall corporate strategy,
  governance, etc. This approach leads to the project becoming isolated in the
  company, rather than it being embraced across the board, this ultimately
  resulted in failure, not the fact that SharePoint was used. I’ve seen some
  shocking system choices work well for an organization because of how the idea
  behind the project was embraced by all in the organization. Most IT departments
  are very reasonable in choice of technology if they are involved in the process
  and they don’t see it as another mess that they are going to have to deal with
  when the agency moves on.

• http://twitter.com/craigraw Craig Raw

  Benon, I think you’re misreading my argument. In it, I caution against using Java (and C#) for being heavyweight – but they do not need to be heavyweight. I caution against using Ruby for legacy integration – but it does not need to be a problem. Note the use of “In general, …”.

  Regarding your USB issue, it’s all about using the right tool for the job. An enterprise web app that needs to access the server’s USB port? Not so much – this is not the kind of legacy system integration I was referring to.

  Regarding your “top Java company” – well, I’d contest that they are not a top Java company. I hope you’re not suggesting that preferring Ruby over Java made the primary difference here.

  Regarding IT,  my point is yours in reverse – the IT team implementing a solution without considering the marketing team, and certainly without proper consideration of the primary goal of the business in generating revenue and profit. Yes there are good points around maintainability and I’ve covered them in the article – of course I agree getting the IT team on board in a best of breed solution is the ideal situation and one to aim for from the outset.

• http://www.facebook.com/xcal55 Robert Fall

  I’ll say one thing, there may be a bigger pool of resources when looking for programmers who have experience integrating with legacy systems in the Java/.NET ecosystem purely because thats a major portion of the work in that ecosystem. History and momentum only influence the ability of the programmers who use the language, not of the language itself. So if you’re warning against hiring Ruby developers for integration instead of the language I may pay more attention. Then again, when looking for a team who can integrate with a system you should be looking for one with experience integrating, not one with experience in a certain language.

  Also, if we learn from history and Ruby is the new Java, then adopting it now and using it will mean years of productivity and a huge base in the future. Can we promise that? No. That’s why you can’t always make your decisions based on history.I’m going to agree with Luke here on a SOA for anything that you can’t interface with Ruby directly, or where it would be too much of a pain. I’ll leave the JRuby argument out.Lastly, I’d be more accepting to  the argument if you’d put it “Beware Ruby on Rails programmers if you need to integrate with legacy systems” rather than off handedly writing off Ruby and Rails. I would hate to see the platform ignored and older “enterprise” languages used instead because people are told “Ruby and Rails should be avoided if you need to integrate with a legacy system.”

  PS: I’d love to see that post about a good use of Ruby in the enterprise. There’s too much Ruby bashing from the enterprise space, would be great to see some love.

• http://www.facebook.com/xcal55 Robert Fall

  I’ll say one thing, there may be a bigger pool of resources when looking for programmers who have experience integrating with legacy systems in the Java/.NET ecosystem purely because thats a major portion of the work in that ecosystem. History and momentum only influence the ability of the programmers who use the language, not of the language itself. So if you’re warning against hiring Ruby developers for integration instead of the language I may pay more attention. Then again, when looking for a team who can integrate with a system you should be looking for one with experience integrating, not one with experience in a certain language.

  Also, if we learn from history and Ruby is the new Java, then adopting it now and using it will mean years of productivity and a huge base in the future. Can we promise that? No. That’s why you can’t always make your decisions based on history.I’m going to agree with Luke here on a SOA for anything that you can’t interface with Ruby directly, or where it would be too much of a pain. I’ll leave the JRuby argument out.Lastly, I’d be more accepting to  the argument if you’d put it “Beware Ruby on Rails programmers if you need to integrate with legacy systems” rather than off handedly writing off Ruby and Rails. I would hate to see the platform ignored and older “enterprise” languages used instead because people are told “Ruby and Rails should be avoided if you need to integrate with a legacy system.”

  PS: I’d love to see that post about a good use of Ruby in the enterprise. There’s too much Ruby bashing from the enterprise space, would be great to see some love.

Services

Feeds

• RSS
• Email
• Twitter
• Facebook

About us