What type of business/technology use might justify the high cost of a Websphere license?

Question

In a large corporation I worked in previously a manager purchased a $50,000+ Websphere production license despite the fact that he only needed a container to run a couple of servlets on a small intranet system.

Assuming we agree that this was overkill, to say the least, and that a free servlet runner like Tomcat would probably have sufficed, what type of business/technology use might justify the high cost of an application server such as Websphere? I'm thinking that integration projects are the most likely candidate - i.e. in environments in which multiple legacy systems need to be glued together using Java/Websphere as a bridge or wrapper. Any other good cases?

Answer 1

I don't necessarily agree with the following, but there is a fairly strong argument there...

<devil's advocate>

The key thing to remember when looking at licensing isn't necessarily the cost of the technology, but rather the cost of having someone point their finger at you at 2am when it's all gone belly up that you want money for.

There are a bunch of companies who have built their business model on this approach (eg Sun - leaving the obvious debate aside on whether that actually worked or not, RedHat, et al).

The benefits that IBM can provide for their products don't really come down to technology per se (as you said, you can get something that'll do the same job for a much better price), it's more about the business process around their products. If you're in an environment where you need predictable uptime, scalability, etc etc. (Banking for example)

IBM's products are reasonably well tested (one of the reasons they're usually a couple of releases behind the bleading edge elsewhere). You know that the things you're getting will be pretty robust, integrate well with other big-business systems (both legacy systems as you said, and other business systems like Siebel, Oracle, SAP, etc) not to mention the one-stop-shop support for integration with other IBM products (if you've drunk the full IBM cool aid).

You also know that where there are issues with what's being delivered, it's relatively transparent and there will be documented workarounds available for things you're likely to bump into.

</devil's advocate>

If you have smart enough people, you don't necessarily need the support that folk like IBM can offer (take the RedHat example - people can still go and download Linux for free and run their business on it). But at 2:00 you're on your own - you can't ring up Linux (or one of the Tomcat committers) and get them to tell you what you're doing wrong and help you fix it.

Answer 2

Remember that Websphere is not just an overengineered Servlet container - it's an overengineered J2EE container. Hence, things like EJBs that are also supported in J2EE are present within WebSphere - so if an application does need them, they are available. Of course, why one would need WebSphere instead of a generic J2EE container is beyond me - unless they need overengineered feature Y that is due to be released in Milestone X of competing freely available product Z.

Answer 3

To be precise, Websphere is not a product. It's a product line. As stated by Martin, service is a crucial part of why people purchase IBM Websphere products (and btw. a big chunk of IBMs revenue).

Websphere consists not only of the J2EE stack (aka Websphere Application Server). It has many components/products built on top of it such as the Websphere Process Choreographer (workflow engine), Websphere Portal, Websphere Business Monitor and other useful components to run a business.

Answer 4

Websphere is a terrible product. Unless you need all the other IBM products that integrate with it and nothing else, theres no sensible reason to buy it. If all you want is a servlet container, grab Tomcat or Jetty.

They are infinitely faster and wont give your developers headaches. Websphere is a royal pain in the arse. Things that take seconds in tomcat eg deploying a small WAR, literally require minutes and a thousand clicks in Websphere.

In the end Websphere only gets sold to big corporate types where the manager, knows little technology, doesnt care about wasting^h^h^h^h investing the companies money, and becasuse of the old addage - nobody got fired buying IBM.

Many people dont use EJBs and stick to Hibernate and Servlets. If you do that in the beginning theres no reason why your WARs wont work in the future when you decide to move to Websphere because it - integrates with something. Then again you really should also be sure that you are aware of what other products you might need in the future and use that in your decision making process.

Im sure many other java types when forced to work with Websphere with just servlets often develop in Tomcat and then deploy at the very end in WS.

Answer 5

If you continue to look around, you'll find that many decisions like this aren't as based on technical considerations as you'd think they should be. I, like most other experienced practicioners, would choose one of the other stacks like Tomcat or JBoss. This isn't because they don't have licensing costs; it's because developers can build the best product in the shortest amount of time with them compared to the other J2EE products.

As to why IBM and other J2EE vendors still have as big a market share as they do, it's because of thought patterns like "Having a throat to choke", and "Can't get fired for buying IBM". Neither of which contain much technical merit, but that's because most of the time the people making these decisions aren't technically curent enough to understand the real factors, and don't have or don't trust the people that are qualified to make the decision.

This question is a little too fine-grained to give a short technical answer, since there are so many complicated aspects to building a successful product in the context of your situation. A couple general "Containers For Dummies" guidelines though:

• Use either Tomcat or JBoss, move on, and focus on writing a good application. I see a strong up-vote for Glassfish, but I'd caution that it might not have the critical mass you'd be comfortable with. You can use one of the other vendor products and still succeed; They'll just weigh you down more.
• When in doubt, listen to Rod Johnson. He and his company Spring Source are paving the way for the evolution of Java today. He's doing for Java containers today what Josh Block did for Java 1.2 (anyone use the Collections framework???)