In all the recent talk (some would say hype) about the Ruby programming language,relatively little has been said about Ruby's usefulness in enterprise development shops, but that is beginning to change.
Many have asked whether enterprise developers need a new language. This question rarely gets farther than "who needs anything but Java?" And when it does, the debate usually degenerates into vehemently opinionated arguments about Ruby's performance, language features (like dynamic typing, protected namespaces, native threading, etc.), and lack of a major corporate sponsor.
I'm going to sidestep that usual debate by turning the question around. What do enterprise developers need, that they're not getting from their tools today? Based on the answers to that question, we can look at whether Ruby currently has anything valuable to offer. And the place to start looking is in the software infrastructure that's needed to support complex enterprise applications.
Message Queueing
Application messaging is all about interoperability and integration. In other words,"glue." The technical and security issues here are rather well understood, but for some reason this area has lacked full-featured and dependable open solutions. The presence of JMS as a de facto API-level standard has caused the available solutions (free and commercial) to be strongly Java-centric, which slows down the integration of more agile software components into enterprise networks. Another major problem is the rigidity created by traditional integration techniques, which makes message-based architectures difficult to use and to scale.
A competent Ruby-based message-queueing system based on the most recent standards and security practices can fill the gaps in this picture. It would be particularly interesting to support the emerging AMQP protocol, which promises interoperabiility with new and established Java-based solutions. Agile development promises rapid and flexible solutions to business problems. An agile software-integration infrastructure is a major step toward realizing this vision.
Central Authentication/Authorization
There has been a lot of emphasis on Identity Management in the last several years, and most enterprises now have a competent approach to authentication.Authorization, however, has been left to the domain of individual applications, shoe-horned into authentication solutions, or both. And many smaller enterprises, which often do not run large "silo" applications apart from email, haven't really approached the authorization issue at all.
But the emerging "applications" which will provide much of the future value from IT investments often look more like ad-hoc vehicles for collaboration and information sharing than like traditional applications. And for these, the need for properly-managed access control is even more important and challenging. Especially since this new generation of information systems will generate tremendous value by extending your ability to touch your customers and partners, taking you right into the realm of federated access control. Many large enterprises wrongly view all of this as an application-integration challenge. Many small enterprises don't even see it coming.
None of this fits into the standard solutions for either authentication or authorization, in large enterprises or small. A centralized access-control infrastructure is needed, that is secure and auditable, but also highly scalable and easy to integrate with applications and with attribute servers like presence engines.
Some interesting academic work has been done in this area, but much remains to be done to bring the benefits to enterprises. This area is sensitive enough to require solid vendor offerings and support, but much of the required development and integration will benefit from Ruby's agility and flexibility.
Databases
Databases are basically fine the way they are, and Ruby is already well known for making it easy to integrate databases via functional interfaces rather than by exposing data models.
Web Development
Ruby has had some highly visible success in this area, with a product (Rails) that addresses an important problem domain (web applications with newly-developed data models and light integration requirements). It's not enough to say that Rails solves this problem. Rails *annihilates* the problem, and richly deserves its success.
But enterprises have considerably broader requirements in regard to "web development" (which is really to say, client-side development in general). Client-facing applications also need integration with existing databases, high performance and scalability, deployment flexibility, and the ability to work closely with other applications.
It's easy to see from the Java world, which has literally hundreds of different Web-development frameworks, that one size does not fit all in the world of client-application development. The Ruby world is already beginning to see some new approaches to client-development, with more to come. Frameworks similar to Java's Tapestry that are based on component models rather than on MVC will be particularly noteworthy. These will provide a totally different way to apply Ruby's agility and productivity benefits to the broader requirements of enterprise shops.
SOA
The SOA world faces substantial challenges today, after several years of hard work, and the road ahead is not clear. Vendors are driving a lot of controversy over standards and methodologies, which bogs down the process of delivering real value. I suspect that Ruby can bring agility and flexibility to SOA, but it's not clear yet exactly how.
Deployment Infrastructure
Java has been very successful indeed at providing manageable and dependable facilities for deploying large, critical applications and providing a wide range of runtime services to them. However, these infrastructures depend on extensive, rigid, and complex procedures for configuration and management. Therefore, it's often difficult to rapidly integrate new facilities and respond to changing requirements.
At the same time, agile software has been rightly criticized for finessing the critical issue of manageable deployment. Indeed this has been a key reason not to deploy Ruby applications in enterprises. For example, Ruby today provides not much more than manual processes for deploying an application to, let's say, a hundred production servers.
Ruby needs a comprehensive set of deployment facilities and runtime containers (supporting Inversion of Control and Dependency Injection patterns). These must provide a range of services to Ruby applications (including logging, messaging, persistence, access-control, eventing, and more) that can be managed and controlled by system administrators rather than programmers. Java has done well in this area, and has much to teach Ruby. But when the lessons have been learned, we'll have an agile application-management framework that will bring scalability and flexibility far beyond what is currently available, and may even transform the way that today's applications are deployed and managed.
Conclusion
Enterprise IT managers value application stability, manageability, and professional support. Programmer productivity barely makes the priority list. However, the business owners of IT value fast, comprehensive solutions to problems, and the ability to use information to grow the top line and the bottom line, and to improve customer service. The need to bridge these divergent priorities will create opportunities for Ruby in the enterprise.
Why do we need my Enterprise Ruby Wish List, when many of the pieces already exist as both free and commercial Java solutions? To reduce friction and costs, speed up solution delivery, and catalyze the behaviors that IT's business drivers demand.Java will be hard pressed to do this because it's become tightly-bound by established practices, methodologies, and traditions.
The pace of real innovation in the Java world has slowed, as important (but relatively minor) language improvements come to the fore, and much energy goes into creating incremental improvements to existing solutions, while major innovations like EEv3 see surprisingly slow uptake. At the same time, critical pieces of the application stack have been taken over by well-defended (and extremely expensive) commercial offerings. On the whole, the Java world is vendor-centric rather than community- or business-centric.
But does Ruby have what it takes to go beyond today's challenges and make a valuable contribution to enterprise IT? That's my next column.
