Archive for April, 2006

Dev2Dev Days – Bangalore’06: BEA’s Blended Strategy

Thursday, April 20th, 2006

Recently I attended BEA’s Dev2DevDay 2006 held at Bangalore. It focused on BEA’s blended strategy along with sharing information about the latest in enterprise development. The session was well thought covering presentation tier (Struts, Ajax), business layer (Spring framework, POJOs) and persistence layer (Kodos, Hibernate, JDOs) along with demonstrations.

Here are few highlights from the session:

  • Blending strategy to meet OSS challenges like integration testing, enterprise production deployment etc. Gel together best of open source with commercial product.
  • Demonstration of BEA workshop Studio 3.0 with focus on
    • AppXRay – Application scanning and dependency checking
    • Support for standard/ open source technologies like JSP, JSF, Struts, Spring, Kodo, Hibernate
    • Forms the part of blended development tools built over eclipse.
  • Blended strategy in deployment platform by providing weblogic console for Tomcat Server Management, widely used open source server.
  • Blended strategy in data tier layer by integrating with JDOs, Hibernate.
  • BEA open sourcing a version of Kodo, the best persistence engine in market today.

Here is my take on Blended strategy:

BEA talks of making things simpler by blending with the best of open source technologies/framework in market. Weblogic’s latest server uses spring framework, hibernate etc. to ease the use. But the bigger question is how BEA is contributing to open source community in return? BEA thinks that just by using best of breeds and integrating in their products to make life simple will help community. But is BEA ready to open source its Application server which is using most of the open source technologies/frameworks? -NO is the answer.

Just open sourcing a version of Kodo is not the contribution that one looks from a company like BEA. What I think Kodo is open sourced is to make people aware of Kodo, get the best out of community and take latest version to make it a part of their Kodo productline. So the bottom line is that OSS community did free work for BEA who is then earning money over it.

Open Source Product customization a better option than Grounds up?

Thursday, April 13th, 2006

None of the Product directly fit 100% to clients’ requirements. There is always customization required little/more to meet the end goals. Customization means integration/modifications in the underlying product architecture and not at the usability level. A very frequent example is search engine customization/integration with the product which is in use in the company for years or integration with their existing CMS or security model.

So what’s the criteria to decide whether an open source product could be selected and customized or an option to build the system grounds up?

Let me give you a case that I came across recently. One of the clients, using a well known commercial portal product, was looking for open source solution in order to overcome issues it’s facing and of course, also the cost. The options came down to either grounds up solution or using one of the open source portal available in market.

Open source portal looks to be the obvious choice at first thought since building a grounds up *Portal* is not the right path both in terms of cost and time to market. But that’s not always right. Here are few things that we need to analyse before coming to conclusion:

  • What are the strengths and weakness of the product?
  • Are we making use of the product strength?
  • Or are we customizing the products strengths and living with its weaknesses?
  • Are required integrations supported by product?
  • Is product architecture best of technologies breed to be extended easily?
  • Is Product architecture extensible?
  • Does the product fall in line with the existing architecture and technologies at clients’ place?

Its not always that the effort and time required to customize an Open source product is less since there are cases where we need to do a Proof of Concept and require a lot of time to understand the existing code base.

So, I think that if we are not going to use a products’ strength and instead customize or integrate them, then it’s better to think again. Grounds up solution will at least not have overhead of that product’s features that are not used and its weaknesses.