I was at the San Jose Tech Museum of Innovation this past Saturday, April 19 to deliver a presentation at the SDForum Third Annual Ruby Conference. The theme of the conference this year was "Using Ruby and Rails for Innovation and Creativity". Given this theme, and what I have been involved with in the past several years, I decided to talk about how I have been getting Ruby on Rails applications developed in the enterprise environment.
The main message that I tried to convey in my presentation is that enterprise application development could be fun, when done with Ruby and Rails. Another equally important message is that a very effective way to get Ruby and Rails accepted in the enterprise application landscape is through thoughtful penetration from the skin, down to the core.
The enterprise environment is a complex one, no doubt about it — typically involving more than one operating system platforms, multiple legacy data sources, many existing components and affecting various organizational units. So, why add more noise and complexity to this circumstance? I would prefer dealing with YAML to XML for configuring things, Ruby to Java for spelling magic, and Rails to — heck, I am not even sure what the comparable legacy alternative would be… Struts or Spring plus Hibernate, or servlets and EJBs? — for building applications so I could reduce, rather than add complexity to this environment.
But, Ruby and Rails are not even enterprise ready, right?
If your plan was to conquer the enterprise world — gut the systems, remove all of the legacy stuff, and replace them with Ruby and Rails components — then of course, Ruby and Rails are not nearly ready for that. But there are tons of other things that happen in the Enterprise 2.0 landscape, and Ruby and Rails are the best candidates to be the tools for developing the solution to the problems occurring in this turmoil. These days, we blog, use wikis, tag and share bookmarks, and build social networks regularly outside and inside the enterprise. Business stakeholders start to see the benefits of these activities, and they would like to build applications that can mash up legacy services and can have the features that enable these activities.
This is what I mean by penetrating the enterprise landscape from the skin, down to the core. Rails provides a great framework for orchestrating web services, whether they are SOAP- or REST-based. It enables experienced enterprise developers to be even more competitive — by being able to build better mashup applications at the edge of enterprises at a lower cost, and faster. Rather than aiming to replace enterprise systems, the plan should be to complement them by continuing to take advantage of Rails strongest suit: being the services orchestration platform of choice at the edge of the enterprise. In other words, closer to the skin of the enterprise architecture. Over time, as Ruby and Rails age gracefully and become more mature, it would only be natural to build systems closer to the core of the enterprise architecture with them.
As far as being able to run Ruby and Rails applications on a traditional enterprise platform, I have gotten that done recently on the IBM zSeries mainframes. Well performing, elastic, and scalable applications that are integrated with and stand tall alongside other more traditional enterprise applications. If that is not enterprisey enough, I don't know what is.
So, last Saturday, I closed my presentation by appealing to the community to be more creative about looking for opportunities to use Ruby and Rails to build edgy Enterprise 2.0 applications.