<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Does Commerical Enterprise Software Suck?</title>
	<atom:link href="http://blog.danzrobok.com/2008/03/25/does-enterprise-commerical-software-suck/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.danzrobok.com/2008/03/25/does-enterprise-commerical-software-suck/</link>
	<description>Business Integration and SOA with an IBM WebSphere slant</description>
	<pubDate>Thu, 04 Dec 2008 21:15:57 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Aaron Miller</title>
		<link>http://blog.danzrobok.com/2008/03/25/does-enterprise-commerical-software-suck/#comment-322</link>
		<dc:creator>Aaron Miller</dc:creator>
		<pubDate>Wed, 28 May 2008 18:09:46 +0000</pubDate>
		<guid isPermaLink="false">http://blog.danzrobok.com/2008/03/25/does-enterprise-commerical-software-suck/#comment-322</guid>
		<description>I'm gonna lean on Eric Schmidt's wisdom here...Enterprise customers will pay for two critical features: security &#38; quality of service.

With Enterprise software, you vote with your wallet and can sue someone if a guaranteed service doesn't work per service level agreement or compromises security. Having someone to sue gives enterprise customers a level of security (however misguided, it's reality) that they do not get with pure open source projects. Also, you can pay for maintenance and extended support. How many great open source projects go the way of the wind because the lead developer decided to move on and no one took up the reins? You rarely see this with code that still has a guaranteed revenue stream. Those are the key differences I've noticed: security, QoS, maintenance.

There are great developers out there who do it for the love of code and share their code openly, knowing that sharing will lead to more gains more quickly than proprietary, closed approaches. Thank God for them, without something to read, our state of the art would be even more retarded than it is today. Even traditional closed source shops have learned this and have trusted partners to gain more resource.

Anyway, obviously there are other products that are easier to use out there and more reasons than we can divine about how and why people make the choices they do. Ultimately, my answer is to agree with Dan on this...no, not all Enterprise software sucks...the ones that do go out of business. Are there open source projects that suck? Certainly. But ultimately the hope that keeps us going are the successes: Firefox, Linux, UNIX...in the proprietary arena: zSeries, iPod, and yes, even Windows.</description>
		<content:encoded><![CDATA[<p>I&#8217;m gonna lean on Eric Schmidt&#8217;s wisdom here&#8230;Enterprise customers will pay for two critical features: security &amp; quality of service.</p>
<p>With Enterprise software, you vote with your wallet and can sue someone if a guaranteed service doesn&#8217;t work per service level agreement or compromises security. Having someone to sue gives enterprise customers a level of security (however misguided, it&#8217;s reality) that they do not get with pure open source projects. Also, you can pay for maintenance and extended support. How many great open source projects go the way of the wind because the lead developer decided to move on and no one took up the reins? You rarely see this with code that still has a guaranteed revenue stream. Those are the key differences I&#8217;ve noticed: security, QoS, maintenance.</p>
<p>There are great developers out there who do it for the love of code and share their code openly, knowing that sharing will lead to more gains more quickly than proprietary, closed approaches. Thank God for them, without something to read, our state of the art would be even more retarded than it is today. Even traditional closed source shops have learned this and have trusted partners to gain more resource.</p>
<p>Anyway, obviously there are other products that are easier to use out there and more reasons than we can divine about how and why people make the choices they do. Ultimately, my answer is to agree with Dan on this&#8230;no, not all Enterprise software sucks&#8230;the ones that do go out of business. Are there open source projects that suck? Certainly. But ultimately the hope that keeps us going are the successes: Firefox, Linux, UNIX&#8230;in the proprietary arena: zSeries, iPod, and yes, even Windows.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mr.white</title>
		<link>http://blog.danzrobok.com/2008/03/25/does-enterprise-commerical-software-suck/#comment-94</link>
		<dc:creator>mr.white</dc:creator>
		<pubDate>Sat, 12 Apr 2008 08:59:37 +0000</pubDate>
		<guid isPermaLink="false">http://blog.danzrobok.com/2008/03/25/does-enterprise-commerical-software-suck/#comment-94</guid>
		<description>I don't understand why the development process suddenly gets all nice and jolly by replacing appserver X with appserver Y - or even homegrown appserverish Z. 

Although this Z-variant must have been fun to bring forward and if this open source-tooling based appserver-killer installation is something that has general applicability to the java-world then I am sure everyone would be just as happy and jolly. When the clientbase grows from 1 to a bit more than 1 I might pay attention.

In my organization the appserver choice is not that big a deal -  I still don't see why deployment cycles for several hours can have that much with the choice of appserver to do, as the claim "you schedule a deploy task that the product expert will perform in a few hours" in the original blog states. Don't understand it.

http://www4.java.no/javazone/2006/show.do%3Fpage=92&#38;articleid=4433.1.html</description>
		<content:encoded><![CDATA[<p>I don&#8217;t understand why the development process suddenly gets all nice and jolly by replacing appserver X with appserver Y - or even homegrown appserverish Z. </p>
<p>Although this Z-variant must have been fun to bring forward and if this open source-tooling based appserver-killer installation is something that has general applicability to the java-world then I am sure everyone would be just as happy and jolly. When the clientbase grows from 1 to a bit more than 1 I might pay attention.</p>
<p>In my organization the appserver choice is not that big a deal -  I still don&#8217;t see why deployment cycles for several hours can have that much with the choice of appserver to do, as the claim &#8220;you schedule a deploy task that the product expert will perform in a few hours&#8221; in the original blog states. Don&#8217;t understand it.</p>
<p><a href="http://www4.java.no/javazone/2006/show.do%3Fpage=92&amp;articleid=4433.1.html" rel="nofollow">http://www4.java.no/javazone/2006/show.do%3Fpage=92&amp;articleid=4433.1.html</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nils-H</title>
		<link>http://blog.danzrobok.com/2008/03/25/does-enterprise-commerical-software-suck/#comment-79</link>
		<dc:creator>Nils-H</dc:creator>
		<pubDate>Wed, 09 Apr 2008 06:52:30 +0000</pubDate>
		<guid isPermaLink="false">http://blog.danzrobok.com/2008/03/25/does-enterprise-commerical-software-suck/#comment-79</guid>
		<description>You're right, it's not so much about the "runtime" (although I have had some seriously funny bug encounters there as well, e.g. session values leaking between users, exception swallowing etc). But both you and I know that WebSphere is just as much about the tooling than the app server itself, so you can't just ignore that fact. And I still believe that in most cases, you would be better off using "lightweight" alternatives.</description>
		<content:encoded><![CDATA[<p>You&#8217;re right, it&#8217;s not so much about the &#8220;runtime&#8221; (although I have had some seriously funny bug encounters there as well, e.g. session values leaking between users, exception swallowing etc). But both you and I know that WebSphere is just as much about the tooling than the app server itself, so you can&#8217;t just ignore that fact. And I still believe that in most cases, you would be better off using &#8220;lightweight&#8221; alternatives.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dan</title>
		<link>http://blog.danzrobok.com/2008/03/25/does-enterprise-commerical-software-suck/#comment-78</link>
		<dc:creator>dan</dc:creator>
		<pubDate>Tue, 08 Apr 2008 16:33:07 +0000</pubDate>
		<guid isPermaLink="false">http://blog.danzrobok.com/2008/03/25/does-enterprise-commerical-software-suck/#comment-78</guid>
		<description>Hi Nils-h, 

I'm curious if your poor experiences are more focused on the tooling for WebSphere or the runtime itself? I've opened tons of problem reports on the tools, but rarely do I encounter an honest WAS PMR.</description>
		<content:encoded><![CDATA[<p>Hi Nils-h, </p>
<p>I&#8217;m curious if your poor experiences are more focused on the tooling for WebSphere or the runtime itself? I&#8217;ve opened tons of problem reports on the tools, but rarely do I encounter an honest WAS PMR.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nils-H</title>
		<link>http://blog.danzrobok.com/2008/03/25/does-enterprise-commerical-software-suck/#comment-77</link>
		<dc:creator>Nils-H</dc:creator>
		<pubDate>Tue, 08 Apr 2008 07:30:47 +0000</pubDate>
		<guid isPermaLink="false">http://blog.danzrobok.com/2008/03/25/does-enterprise-commerical-software-suck/#comment-77</guid>
		<description>I have the same experience as Johannes. I know most of the ins and outs of WebSphere, and it is more of an obstacle than a tool in _most cases_. It just adds complexity and reduces developer efficiency, and in most cases it's not necessary. And the words "rapid" and "WebSphere" just don't fit together. Sure you can automate the building and deployment processes with it, but not _nearly_ as easy and elegant as with for instance Jetty. Believe me, I fought too many battles in that area... Oh, by the way, I'm a WebSphere consultant as well.</description>
		<content:encoded><![CDATA[<p>I have the same experience as Johannes. I know most of the ins and outs of WebSphere, and it is more of an obstacle than a tool in _most cases_. It just adds complexity and reduces developer efficiency, and in most cases it&#8217;s not necessary. And the words &#8220;rapid&#8221; and &#8220;WebSphere&#8221; just don&#8217;t fit together. Sure you can automate the building and deployment processes with it, but not _nearly_ as easy and elegant as with for instance Jetty. Believe me, I fought too many battles in that area&#8230; Oh, by the way, I&#8217;m a WebSphere consultant as well.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dan</title>
		<link>http://blog.danzrobok.com/2008/03/25/does-enterprise-commerical-software-suck/#comment-44</link>
		<dc:creator>dan</dc:creator>
		<pubDate>Mon, 31 Mar 2008 22:13:59 +0000</pubDate>
		<guid isPermaLink="false">http://blog.danzrobok.com/2008/03/25/does-enterprise-commerical-software-suck/#comment-44</guid>
		<description>Hi Johannes,

"My experience is “no”, “no” and “no” to all of these questions. We have burned a lot of money on consulting and training services from IBM, and we were never able to master our servers. Maybe we’re just too stupid for WebSphere. Luckily, everybody master the standalone Java server with Jetty with no problems."

I guess the question that bares asking is what was the background of the developers on the project? If you were trying to skill up people on J2EE for the first time, I can understand the types of problems you are describing. WebSphere can be overwhelming if you don't have the experience to know what to look for and where it is. 

I can also believe that developers who were Java strong took to a non-J2EE solution faster because its what they already knew, thus you leveraged the skill of your resources on a technology they understood. Again, this doesn't condemn WebSphere. 

"However, we never were able to write unit tests that *start up* WebSphere and *deploys* our application into it. "

Again, I know that these features do exist in WebSphere. A cursory google search turned up some articles on the subject. I don't know which version of WebSphere you were using so maybe it didn't exist then. 
(http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.etools.wrd.freeform.doc/topics/cwrdrapid.html)

"My real point is this: In 2008, there is nothing that you get from an app server that you can’t get better and cheaper with an open source solution."

This is a bit tongue-in-cheek but what you can't get from the open source community are the things that a single vendor solution can provide. Anyway, I can actually partially agree with your statement in the sense that as these open source system mature, they begin to commoditize the markets they are in. What keeps companies like IBM in business is staying ahead of this curve via Business Integration products that build upon a solid base of WebSphere and basically "value-add" the core server. 

That being said, I'm not a specialist in OSS servers so you may be right. But I still think that a WebSphere server is at minimum equivalent to them.

"When I ask WebSphere proficient developers in my company whether they would use WebSphere if it was their personal project, they just laugh at me. If I said: “What if you got it for free?”, they just shake their heads."

Well I think it depends on the context of personal project. If you were asking if they'd go home and code up a few EJB's to share photos on the internet, thats not the same as trying to integrate a business in a highly available manner.  If you wanted me to write up something with five 9's support, yeah, I'd probably take WebSphere and leverage the clustering capabilities. 

"What about you, Dan: If it was your person loss or gain, would you still use WebSphere?"

See, I already make that statement every day by being a WebSphere consultant. I'm accountable to my clients to provide systems that meet their business and technical needs. If I don't create a system that can live up to the hype, it's my reputation that gets tarnished, not IBM's.

"Is danzrobok.com running on WebSphere? Why not?"

Because I'm cheap and this bad boy is share hosted :-). 

Anyway Johannes, I do enjoy hearing about the other options in the field and I'm by no means a zealot to IBM software. I think that you found the right solution for your business problem and skill set. I just think that WebSphere could also have been a success for you.</description>
		<content:encoded><![CDATA[<p>Hi Johannes,</p>
<p>&#8220;My experience is “no”, “no” and “no” to all of these questions. We have burned a lot of money on consulting and training services from IBM, and we were never able to master our servers. Maybe we’re just too stupid for WebSphere. Luckily, everybody master the standalone Java server with Jetty with no problems.&#8221;</p>
<p>I guess the question that bares asking is what was the background of the developers on the project? If you were trying to skill up people on J2EE for the first time, I can understand the types of problems you are describing. WebSphere can be overwhelming if you don&#8217;t have the experience to know what to look for and where it is. </p>
<p>I can also believe that developers who were Java strong took to a non-J2EE solution faster because its what they already knew, thus you leveraged the skill of your resources on a technology they understood. Again, this doesn&#8217;t condemn WebSphere. </p>
<p>&#8220;However, we never were able to write unit tests that *start up* WebSphere and *deploys* our application into it. &#8221;</p>
<p>Again, I know that these features do exist in WebSphere. A cursory google search turned up some articles on the subject. I don&#8217;t know which version of WebSphere you were using so maybe it didn&#8217;t exist then.<br />
(http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.etools.wrd.freeform.doc/topics/cwrdrapid.html)</p>
<p>&#8220;My real point is this: In 2008, there is nothing that you get from an app server that you can’t get better and cheaper with an open source solution.&#8221;</p>
<p>This is a bit tongue-in-cheek but what you can&#8217;t get from the open source community are the things that a single vendor solution can provide. Anyway, I can actually partially agree with your statement in the sense that as these open source system mature, they begin to commoditize the markets they are in. What keeps companies like IBM in business is staying ahead of this curve via Business Integration products that build upon a solid base of WebSphere and basically &#8220;value-add&#8221; the core server. </p>
<p>That being said, I&#8217;m not a specialist in OSS servers so you may be right. But I still think that a WebSphere server is at minimum equivalent to them.</p>
<p>&#8220;When I ask WebSphere proficient developers in my company whether they would use WebSphere if it was their personal project, they just laugh at me. If I said: “What if you got it for free?”, they just shake their heads.&#8221;</p>
<p>Well I think it depends on the context of personal project. If you were asking if they&#8217;d go home and code up a few EJB&#8217;s to share photos on the internet, thats not the same as trying to integrate a business in a highly available manner.  If you wanted me to write up something with five 9&#8217;s support, yeah, I&#8217;d probably take WebSphere and leverage the clustering capabilities. </p>
<p>&#8220;What about you, Dan: If it was your person loss or gain, would you still use WebSphere?&#8221;</p>
<p>See, I already make that statement every day by being a WebSphere consultant. I&#8217;m accountable to my clients to provide systems that meet their business and technical needs. If I don&#8217;t create a system that can live up to the hype, it&#8217;s my reputation that gets tarnished, not IBM&#8217;s.</p>
<p>&#8220;Is danzrobok.com running on WebSphere? Why not?&#8221;</p>
<p>Because I&#8217;m cheap and this bad boy is share hosted :-). </p>
<p>Anyway Johannes, I do enjoy hearing about the other options in the field and I&#8217;m by no means a zealot to IBM software. I think that you found the right solution for your business problem and skill set. I just think that WebSphere could also have been a success for you.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Johannes Brodwall</title>
		<link>http://blog.danzrobok.com/2008/03/25/does-enterprise-commerical-software-suck/#comment-43</link>
		<dc:creator>Johannes Brodwall</dc:creator>
		<pubDate>Mon, 31 Mar 2008 20:03:57 +0000</pubDate>
		<guid isPermaLink="false">http://blog.danzrobok.com/2008/03/25/does-enterprise-commerical-software-suck/#comment-43</guid>
		<description>Hi, Dan

It's interesting to read your take on my post. It seems like I  a haven't done a very good job of conveying my points, though.

"Does it do the job competently and reliably? Yes. Does it actually do everything listed in its marketing slides? Yup. Does it perform? In 6.1 IBM seems to think so."

My experience is "no", "no" and "no" to all of these questions. We have burned a lot of money on consulting and training services from IBM, and we were never able to master our servers. Maybe we're just too stupid for WebSphere. Luckily, everybody master the standalone Java server with Jetty with no problems.

"This experience with a long deployment cycle isn’t really valid. You can script all of this stuff through ant tasks and JUnit cases."

Again: We tried, used a lot of money, and ultimately found we didn't archive a satisfying result. And you're right in that you *can* write JUnit tests that use WebSphere. However, we never were able to write unit tests that *start up* WebSphere and *deploys* our application into it. With Jetty we get 10-30 seconds one-click turn around on tests.

"Rolling your own message service implementation? Thats not a path I’d want to go down any time soon. Also, what happens to this system two three years down the road?"

We have been about five developers actively maintaining this implementation from different parts of the organization. However, I would not recommend the same approach under all circumstances. In our case, we were controlling the process on both ends of the queue, we had a very simple scenario, so we didn't need the full JMS capabilities, and we found that the transactional model of Java EE didn't mesh well with our problem.

My real point is this: In 2008, there is nothing that you get from an app server that you can't get better and cheaper with an open source solution. We rolled our own message service, but you could use ActiveMQ. Connection pooling is provided by c3p0 or dbcp. CTM is provided by Spring. Servlets by Jetty.

In our experience, it took a lot less work to put these tools together (Maven is key here!) than to get WebSphere stable and usable.

When I ask WebSphere proficient developers in my company whether they would use WebSphere if it was their personal project, they just laugh at me. If I said: "What if you got it for free?", they just shake their heads. If I say "What if you got free support as well?" they start considering it.

What about you, Dan: If it was your person loss or gain, would you still use WebSphere? Is danzrobok.com running on WebSphere? Why not?</description>
		<content:encoded><![CDATA[<p>Hi, Dan</p>
<p>It&#8217;s interesting to read your take on my post. It seems like I  a haven&#8217;t done a very good job of conveying my points, though.</p>
<p>&#8220;Does it do the job competently and reliably? Yes. Does it actually do everything listed in its marketing slides? Yup. Does it perform? In 6.1 IBM seems to think so.&#8221;</p>
<p>My experience is &#8220;no&#8221;, &#8220;no&#8221; and &#8220;no&#8221; to all of these questions. We have burned a lot of money on consulting and training services from IBM, and we were never able to master our servers. Maybe we&#8217;re just too stupid for WebSphere. Luckily, everybody master the standalone Java server with Jetty with no problems.</p>
<p>&#8220;This experience with a long deployment cycle isn’t really valid. You can script all of this stuff through ant tasks and JUnit cases.&#8221;</p>
<p>Again: We tried, used a lot of money, and ultimately found we didn&#8217;t archive a satisfying result. And you&#8217;re right in that you *can* write JUnit tests that use WebSphere. However, we never were able to write unit tests that *start up* WebSphere and *deploys* our application into it. With Jetty we get 10-30 seconds one-click turn around on tests.</p>
<p>&#8220;Rolling your own message service implementation? Thats not a path I’d want to go down any time soon. Also, what happens to this system two three years down the road?&#8221;</p>
<p>We have been about five developers actively maintaining this implementation from different parts of the organization. However, I would not recommend the same approach under all circumstances. In our case, we were controlling the process on both ends of the queue, we had a very simple scenario, so we didn&#8217;t need the full JMS capabilities, and we found that the transactional model of Java EE didn&#8217;t mesh well with our problem.</p>
<p>My real point is this: In 2008, there is nothing that you get from an app server that you can&#8217;t get better and cheaper with an open source solution. We rolled our own message service, but you could use ActiveMQ. Connection pooling is provided by c3p0 or dbcp. CTM is provided by Spring. Servlets by Jetty.</p>
<p>In our experience, it took a lot less work to put these tools together (Maven is key here!) than to get WebSphere stable and usable.</p>
<p>When I ask WebSphere proficient developers in my company whether they would use WebSphere if it was their personal project, they just laugh at me. If I said: &#8220;What if you got it for free?&#8221;, they just shake their heads. If I say &#8220;What if you got free support as well?&#8221; they start considering it.</p>
<p>What about you, Dan: If it was your person loss or gain, would you still use WebSphere? Is danzrobok.com running on WebSphere? Why not?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
