What is Enterprise Software
Enterprise software has been being bashed for years. “Why is that?” How come building software for large organizations has become synonymous with boredom? Some people say it’s boring because it is not rewarding. It’s hard to stay excited working for “evil” corporations. In my view, this isn’t the right attitude. I’d say that helping millions of people to manage their bank transactions has greater value than building another Twitter analyzer. Let’s at least not reject the idea of building enterprise software for money. Instead, let’s think a little about what enterprise software is and if Ruby can be a good platform for building it.
What is enterprise software? Martin Fowler’s definition is:
- Enterprise applications are about the display, manipulation, and storage of large amounts of often complex data and the support or automation of business processes with that data. 
Essentially, it’s software used by companies to manage their business. There is nothing here saying that it has to be ugly or overly complex. It doesn’t have to look like this.
Are We Ready?
In order to be a good platform for developing enterprise applications, Ruby has to provide remedies for the following challenges: integration, domain modeling, and deployment.
If you think developing a new application is hard, try integrating it with others. It’s extremely difficult. You usually have no control over the other systems. This means that you have to deal with their homemade (or non-existent) APIs, you need to support their new releases, and handle their downtimes. It’s tough. But I have some good news for you-writing integration code, for example, in C# is not any better.
Over the last few years the situation with all major means of integration has been improved significantly. ActiveMQ? No problem. Using Oracle, MSSQL, and Sybase databases has become possible. But even though it has improved, you might still encounter a few technologies with no Ruby adapters available. Thankfully, there is a great solution for this problem: JRuby. Everything integrates with Java, which makes JRuby a ‘silver bullet’ against all integration problems.
Enterprise systems tend to contain a large set of business rules expressing non-trivial domains. Configuring the rules and making decisions based on collected data is usually the purpose of those systems. Is Ruby a good solution for domain modeling? It sure is. Ruby is a high-level language; it is extremely readable and has some meta-programming features making it a good fit for implementing internal Domain Specific Languages (DSLs). I’d say Ruby is a better language for domain modeling than, for instance, Java or C#.
Deployment might have been an issue a few years ago. EY (Engine Yard) and Heroku are great solutions that work amazingly well for companies willing to get rid of their IT operations departments and move their software to the cloud. However, not everyone wants to do that. Some companies still have Windows servers. They still deploy manually (it’s a drag-and-drop process). For such companies EY and Heroku are not an option. Managing another stack to deploy Ruby applications? It is not going to happen. Using their existing infrastructure is crucial. This is one more area where JRuby really shines. Having a self-contained deployable package that you can just drop into Tomcat’s folder makes a huge difference for these companies.
Are They Ready?
If we accept that the Ruby platform is mature enough for building enterprise applications, can we get large enterprises to do the same? In my experience, some of them really want to try. They are striving to make their processes more efficient, deliver more often and with less bugs. It’s hard. That’s why they are looking for technologies and platforms that can make it happen. I strongly believe that the Ruby platform can be one of them.
For those who are interested in building enterprise software I highly recommend the following books:
There are a few good books about JRuby:
I wrote a few posts related to the topic:
Martin Fowler. Patterns of Enterprise Application Architecture.