Tuesday, June 02, 2009

WebSphere Strategy

I have used IBM's WebSphere Application Server in the past and I work on it on a daily basis. Something that astounds me is the direction IBM is taking the server. Every year a new feature pack is released and there are also stack products, which are pieces that build on top of the base WAS product and add some extended benefit(such as the XD offering which gives many health monitoring processes to the server, among other things). Overall it's not too bad of a strategy, the problem comes in the form of the base WAS product. It's so bloated and overpriced I can guarantee many people don't use it because they would only use the Web Container and nothing else. Why pay thousands of dollars for a product you would only use a small part of when you could use a free offering(such as Glassfish) and only use what you want at a price that can't be beaten? This is where I think IBM is falling behind and needs to redesign and re-release WebSphere as a whole. However this isn't going to be easy and it's not going to happen over night.

The first part would be disassociating all the individual components of WAS. In doing this WAS could be broken down to the most basic level and the base would be only the things needed to run servlets(pretty much just the WebContainer and Channels). These newly designed components would be pluggable into a base WAS framework and new ones could be created by hooking into the existing base. Developers would be able to easily hook into the base WAS and create new components quickly. Not only would the WAS footprint be much smaller but users could get exactly what they want without any of the bloat.

The second part is building all the new components. It wouldn't be "new" per say, but just a redesign of all the existing components and stack products. The new stack products would just be many of the components bundled into an easy to manage package. These could be dropped in and out easily. This is sort of how they work now, however with the current way of doing things each component couldn't be dropped into the base WAS. For example, lets say you wanted health monitoring and Web Services. In the current model that would mean installing a whole feature pack and stack product, which leads to more money and resources required. With the new model a customer could purchase just the health monitoring and Web Services component, drop it into the environment, and be ready to go. No wasted space on things that aren't going to be used, only exactly what is required.

Finally we come to pricing. The base product would be free, the very very basic components would be included. Customers could pay for support if they wish. All the components that aren't included in the basic level would be a pay per component basis, each coming with support as well as the ability to drop it into an environment. Doing it this way would let customers pay for exactly what they want, and only get exactly that and nothing more. If we stay with the current pricing model we see customer paying 10s of thousands of dollars for a piece of software and not utilizing it to its full potential.

One downfall to this new model is that it could create a lot of fix pack issues. With all of the different little components it would be hard to install the fix packs for each one and keep track of it all. One option would be to create on big fix pack that encompasses all the components and the product is smart enough to only install the ones it needs.

As the years pass WebSphere is showing it's age. It continually gets bigger with each new feature and shows no signs of stopping. I think if properly packaged up and sent out this would be a vastly superior model for IBM to follow. WebSphere would have a smaller install and fesource footprint. Customer would get exactly what they want at a lower price. It's a win, win: customers are happy and IBM is happy. But, like I said: it's not going be an easy road to travel.

0 Comments:

Post a Comment

<< Home