If you’ve been paying attention to the Orange and Bronze guy who talked about Spring Roo, you might have noticed that he mentioned something a bit weird. It was something along the lines of:
…and after that came Ruby on Rails. But Rails never really took off so Groovy and Grails came along and took the spotlight…
Now this statement about RoR is weird when taking into account the previous speakers, especially the G2iX / Exist guys who are successfully using that technology to develop web applications for their clients.
So why did the Spring Roo guy handwave RoR as just a fad?
I don’t know the real reason, but I’m betting that it has something to do with the environment he’s working on. That is, as an “enterprise” developer, “internet” technologies like RoR aren’t that relevant to him.
—
The divide between the “Internet” and the “Enterprise” is yet another issue that isn’t taught in college nowadays. Most students are familiar with the former, but only a few are prepared to deal with the latter.
So what exactly is the difference between the “Internet” and the “Enterprise”? One way of looking at it would be to classify the applications used in large corporations or governments as Enterprise Applications and classify those available to the public through the Internet as Internet applications. I don’t like this definition because it doesn’t really capture what goes on behind the creation of application under these two environments.
For me, the biggest difference between the two environments is the amount of bureaucracy involved.
If you’re developing and Internet application, say the next Facebook or Wikipedia, building the application and releasing it to the Internet is a relatively easy task. There are some issues that you have to consider like malicious activity in the Internet and where to get funding to run your servers, but at least you have control over where your application is going.
On the other hand, when you’re developing Enterprise applications, you also have to deal with tons of bureaucracy along with the usual problems involved in developing applications. For example, you can’t start building an application without going through lengthy approval processes. There are also many other bureaucratic processes involved in the design and the implementation of the application.
I’ll have to admit that most of these processes are unnecessary, but there’s really nothing an enterprise developer can do about it. Governments and large corporations consider bureaucracy as sacred: try to bypass the red tape and they’ll accuse you of threatening their survival. Even if you do take away this high regard for unnecessary processes, you’re still left with a significant amount of processes that are there to prevent single individuals or departments from doing risky stuff that could bring down the establishment.
That said, there are a couple of side effects resulting from this (necessary) bureaucracy.
Technology is probably the one most affected by this bureaucracy. Because of the red tape, new technologies don’t seep in the enterprise as fast as it does on the internet. Take for example Web 2.0 level technologies: many of the technologies we see in sites like Twitter and Facebook have not penetrated enterprise markets yet. They have to undergo lengthy investigation and approval processes before they can even be used by those institutions.
If you think that this means that as enterprise developers you’ll be stuck using yesterday’s technology, you’re basically correct. Not only do you have to deal with technology that is at least 2 years old (= “forever” in Internet time), you also have to deal with much older technologies.
Large institutions means large, expensive, and outdated mainframes. They can’t be upgraded on a whim because of bureaucracy and the millions of dollars spent on these equipment. Thus, enterprise application developers frequently have to deal with these aging equipment: sometimes this is dull and boring, sometime the limitations make it frustrating.
Aside from the technology limitations, there’s also the interoperability requirement. Internet applications are mostly self-contained; some might have to connect to other services for other features, but most of the time that application can stand on its own.
On the other hand, enterprise applications have to interface with multiple systems on different platforms. It is not rare for an enterprise application to connect to both the aging mainframe in the Accounting department and the new rack mount Java servers from the Sales department.
Aside from “risk management” and “we can’t throw away these old servers”, bureaucracy also affects enterprise technology through steak and strippers.
Let’s face it, managers and executives don’t care about what goes on in their systems. All they care about is that their company looks good. This is why you’re more likely to see companies go for Oracle or IBM databases in cases where free alternatives like MySQL would work: the latter doesn’t look cool enough and they’ll get laughed at by other executives for not choosing the “cooler” (and much more expensive) option.
And if peer pressure in the doesn’t work, there’s always the aforementioned steak and strippers.
—
Okay, so enterprise development is boring and frustrating. So why would a person be interested in it?
Money.
Unless he/she has a good portfolio filled with Internet applications as well as a bunch of good contacts, the only way a fresh graduate in an IT course can earn a lot of money through software development with minimal risk is by entering a large multinational software company like HP and Accenture. Guess what developers in those companies do for a living?
That’s right, developing and maintaining enterprise applications.
Money is much more abundant in the enterprise compared to the internet. Remember that PhP 80 million GSIS project that got some press attention lately?
That’s just chicken feed. As a former enterprise developer, I had worked on projects that are worth hundreds of millions of pesos. I’m sure that some of my former colleagues and classmates are now working on projects that are worth billions of pesos in their respective companies.
For many developers, the choice between the Internet and the Enterprise isn’t that hard to make.
—
Just some side notes before I end this post:
Some think that enterprise applications scale better (i.e. can handle more users) than their internet counterparts. This isn’t necessarily true as Wikipedia and other social networking sites handle far higher loads than your typical enterprise application. The only difference between the two is that enterprise applications have performance and reliability contracts: the developer of an enterprise application can be sued if the application does not meet the performance and reliability requirements. On the other hand, the only thing that could happen to an internet application when it slows down or crashes is a wave of complaints, something surely much better than getting sued.
Another aspect of enterprise applications that gets over-hyped is their security. In reality, security isn’t that much of a big deal in enterprise applications because it’s much easier to track down hackers in those tightly controlled systems. The Internet is a much more dangerous place when it comes to hacking. Same as scaling, the only reason why security looks like a big deal is the amount of processes like security protocols and security audits that go with developing enterprise applications.
