ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: Please Help in arguing for iBatis SqlMaps
Date Fri, 08 Apr 2005 03:34:47 GMT
Hi Kaushik,

I was going to respond with a technical rebuttal, until I read: "my business 
acumen says that IBM will definitely take care of that". (apparently from 
your supervisor or something)

Let me instead tell you how IBM made $96 Billion dollars in 2004. Or you can 
read it yourself at: http://www.ibm.com/investor/filings/index.phtml

IBM basically makes money in two ways: 1) By selling software (that may or 
may not work) and 2) By selling services to "help" you with that software. 
The profit from these services is about 50/50 and together they make up 70% 
of their total profits (their proprietary hardware makes up another 25%).

Because 35% of IBM profit depends on also selling you services, it's in 
their best intersts to offer you products that are over complicated, 
underdocumented and that generally don't work well (i.e. WebSphere). It 
simply makes business sense. If you doubt my motives for this, let's look at 
how IBM spends their money.

All of IBMs expenses can be categorized in two areas: 1) Sales, General and 
Administration and 2) Research, Development and Engineering. They spend 80% 
of their money on SG&A and a measly 20% of it on RD&E. 

So, when we look at how IBM makes and spends money we see this:

* IBM depends on selling you complex software and proprietary hardware
* IBM depends on selling you services to support, extend and maintain that 
software and hardware
* IBM spends 4x more money on SELLING you these things, than IMPROVING them
* IBM makes you pay for all of this up front, but you won't know how bad it 
really is until your project fails
* IBM is a sales organization that succeeds in business by taking your 
executives out for lunch.

In contrast, open source software:

* Depends on compatibility and openess to achieve network effect
* Depends on an energetic community of smart people to keep it alive
* Spends 100% of resources on IMPROVING the software and none on selling it 
(except for this thread) ;-)
* You don't pay a dime for it EVER whether your project succeeds or 
fails...you're never any worse off

Open source software succeeds solely on its merits.

Chances are your organization will still choose to buy into IBM (or Sun, or 
HP, or Microsoft, or ...). I see it happen every day in large companies. The 
other nice thing about open source software though, is that no matter what 
your boss chooses...I don't lose a dime. ;-)


On Apr 7, 2005 10:55 AM, Kaushik Ashodiya <kaushik.ashodiya@ucop.edu> wrote:
> Hi,
> I have hard time arguing for iBatis SqlMaps (not because something wrong 
> with SqlMaps).
> Please give me more reasons so that I can convince them.
> Their argument:
> 1. For small project SqlMap is adding unnecessary complexity.
> 2. Why learn one more tool when you have a simple base data access object 
> that gives you connection, prepared statement and a result and does cleanup? 
> (only when extended class calls cleanup() !!!)
> 3. Generally open source projects dies shortly and does not have support.
> 4. Adding many jars of those open source projects make out project more 
> complex and un-maintainable.
> 5. What if SqlMaps goes out of market? It is fairly new and not hardened.
> <my-peers-arguments>
> Again to re-iterate a point I was trying to make yesterday, 
> architecturally speaking you should always try and keep it simple (not on an 
> individual application level) but as far as possible on an enterprise level. 
> I'm going to ask you the same question that I asked yesterday...what do you 
> think are the advantages/disadvantages of O/R mappings for relatively small 
> applications where persistance is not the deciding criteria (or for that 
> matter not even a criteria)?(I've attached yesterdays email thread for Kevin 
> since he didn't get that one :))
> I'll list the disadvantages:
> 1) You add multiple third party jars (open source or otherwise), which you 
> need to be aware of when building new apps. These include components which 
> the vendor will eventually provide if the market demand is high...
> 2)You add multiple configurations for each of those products, which you 
> need to understand on how to tune in case there are performance issues.
> 3) Most of these components seem to be build on the current versions of 
> jdk which take a decent time to hit mainstream commercial product support.
> 4) If these products are not built to a spec (even though they may end up 
> driving a spec), the migration process becomes an added overhead. Even when 
> they do become a part of the spec, the implementation differences of the 
> vendor of choice may be so different that you pretty much waste any 
> advantage of early adoption. If you are a vendor of a product, an effective 
> early adoption can translate into you either being bought out by the bigger 
> established vendor or you getting to be a key player in that space....but we 
> don't fall in that category.
> 5)You need to be able to train existing resources to use the product 
> (unless there is a plan to let go people and get "new" fresh resources who 
> may have had experience with the adopted product). Now if the existing 
> resources themselves have a discomfort moving over to an object oriented 
> paradigm, putting up them up against the challenges of going thru the 
> learning curve of extra products further lowers the probability of success.
> 6) You increase the possibility of chaos and reduce flexibility of 
> resource utilization.
> Besides the six points above, I would not recommend use of products like 
> iBatis in applications at UCOP is because in my opinion the applications 
> that we do or have done are relatively small and O/R mapping for those kinds 
> of apps is probably an overkill (again personal opinion.) To some level 
> Hibernate is a valid candidate for evaluation (taking into account that it 
> is driving the EJB spec). But again, my business acumen says that IBM will 
> definitely take care of that. 
> Now my perpective looking at the example below, one of the key 
> shortcommings that I see is it couples the "Display/View" with the model 
> (Data Access).... Basically what this means is that if you wanted to create 
> the same object tomorrow from not a "non" database/jndi source, you would be 
> re-writing the logic for creating the same object. Another disadantage that 
> I mentioned yesterday was if your display object gets created from multiple 
> datasources (one db2, one sybase) transaction management becomes an 
> issue.... How would you use iBatis in a system which does not need 
> persistanc but needs transaction management?
> Isn't the whole idea of going with some big commercial vendor like IBM to 
> consolidate your infrastructure source so that you dont knock on different 
> doors? Often such a vendor is selected based on how many services required 
> by a business are provided by the vendor. Nothing against Hibernate or 
> iBatis. I'm sure they are great at what they are designed to do. But each 
> one of them doesn;t do all that we probably need (they still need an 
> underlying EJB container.) If thats the case, why would you want to 
> introduce the additional learning curve and the additional layer associated 
> with each product? Do you truely think that it's a necessity? 
> Short of long: I would recommend usage of vendor supported spec based ejb 
> conatiner for applications needing persistance or transaction management. 
> Eventually these will be simplified (if there is fear of complexity....thats 
> an issue the specs and the commercial vendors like IBM will definitely 
> answer). If persistance is not required, use the existing framework 
> component. What that does is you dont have to code the basic JNDI lookups, 
> creation of connections, clean ups. Since you are pretty much just accessing 
> data, there is no coupling between the dataaccess and object creation. The 
> learning curve is almost next to nothing. So I'd recommend for the present 
> continue usage of the existing "Model" framework...
> Just a small note on the side we'll still need to maintain components that 
> we develop to be UCOP specific...(e.g. Employee Object etc). These will 
> have to be harvested in a generic layer outside individual applications, 
> else we commit the same mistake that was made on ucfy, fje and danris (you 
> copy the same code over and over again!!)
> I wasn't ever saying iBatis is an O/R tool... that was for Hibernate (I am 
> trying to get your view on advantages/disadvantages of O/R mappings for 
> relatively small applications where persistance is not the deciding 
> criteria.) The last email was just providing my thought process for not 
> recommending the use of products that probably have little or no advantages 
> for a business like UCOP.
> Its a perspective with substantiation. In the end we should try to do 
> things becuase they make sense to our environment, not just because it's 
> cool technology. Is there a significant business advantage to using either 
> iBatis or Hibernate, considering that we have existing solutions, be it ucop 
> framework's jdbc component (comparing it with iBatis) or EJB/CMP (comparing 
> it to Hibernate).
> I've listed some of the disadvanatges of using iBatis and Hibernate in our 
> environment. Just to be fair, let me try to list some Advantages:
> iBatis:
> 1) Probably good documentation and support from user forums as compared to 
> the ucop jar's jdbc component. However, the design principle used for all 
> ucop component is to enable novices to use it within minutes (and thats 
> something that has already been proven)
> 2)Resources with iBatis experience can be hired (Is there a plan?)....
> All right I guess I can't think of more reasons
> Hibernate V/s CMP:
> Actually I cant think of any advantages since I know we have a EJB 
> container.... 
> we should talk... it'll be an interesting discussion.
> </my-peers-arguments>

View raw message