Why Eclipse
Monday, March 27th 2006 | Ismael Ghalimi
This is the third edition of our weekly BPM 2.0 post. Today, I will try to explain why Eclipse matters. My definition for BPM 2.0 states that a BPMS should be built around one single tool in Eclipse, and this radical statement deserves further explanation, as was illustrated by some of the discussions that followed the original post on BPM 2.0.
Integrated Development Environments (IDEs) are very much like Operating System, in the sense that they provide the foundation upon which software vendors can build their tools, without having to re-invent the wheel all the time. And much like Operating Systems, they tend to be the victim of commoditization and consolidation, rather sooner than later. Oracle became one of Eclipse’s strongest supporters, Borland has decided to sell its JBuilder group, and NetBeans is not exactly driving developers to Sun’s platform in droves. This pretty much leaves two contenders on the ring: Eclipse and Microsoft Visual Studio. But because Microsoft does not like to leave much room to its competitors, the vast majority of BPMS vendors have adopted Java as a development platform, and this is where Eclipse comes into play. In other words, if you’re Microsoft, your BPMS will be built around Visual Studio, but if you’re not, Eclipse is the way to go.
The main benefit of using a standard IDE for developing the tools that are part of a BPMS offering is that you can leverage existing components that have been developed by third-party vendors. For example, Intalio is using a rule editor from Corticon, a KPI designer from Celequest, and a WYSIWYG XForms editor developed with Orbeon, all of which are available as Eclipse plugins. Also, because Eclipse provides support for the most popular source control systems, integrating with the customer’s application lifecycle management infrastructure is greatly simplified, and the BPMS vendor gets all this essentially for free.
That being said, using Eclipse instead of a proprietary framework creates a couple of challenges. First, Eclipse is a very complex platform that makes extensive use of advanced technologies such as EMF and GEF. The learning curve for these is pretty steep, and the productivity of an average Java Swing developer converting to Eclipse can be significantly reduced for the first three to six months. Second, because Eclipse was originally developed for software engineers, it makes everything more complex than it should be for your average process designer. As a result, a BPMS vendor adopting Eclipse as underlying IDE must make sure to hide this complexity under simpler user interfaces. This is not an easy task, but the benefits you can gain by running on top of Eclipse largely compensate for the migration effort. Thank you IBM for such a fine piece of software!
Entry filed under: BPM 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ismael,
Are up on the (very) young team from RadRails? Kyle Shank and team have swept the floor at Eclipsecon, and I have been following them since the very first versions. I tried to get Kingsley and OpenLink to look into a potential partnership with Kyle, but no soap radio. I see a synergy between Eclipse and a visual BPEL thingy, with Rails in the mix.
These guys are like 21, yikes!
Alan,
Yes, we are following what the Rails guys are up to. Very cool.
Complete agreement. Eclipse is a definitive advantage, especially for BPM platforms, because they contain such a broad range of functionality and typically involve sets of users collaborating on different design tasks during development. Having a single IDE platform is crucial to keep everything in sync and provide a consistent design experience. In fact, a BPM vendor won “Best Eclipse RCP Application” at EclipseCon: Lombardi Software, for whom I work (full disclosure).
Trevor,
Congratulations! I’m glad to see that Lombardi is finally embracing Eclipse. Would it be time for you to consider adopting BPEL as well? If so, you might want to take a look at our Open Source BPEL engine. We would love to help you guys get it embedded into your product.
Ismael,
Thanks so much. We are proud of our deep adoption of Eclipse which began in our 5.0 release over a year ago. It is a key reason we did so well in the Forrester BPM Wave around the development environment.
We have a deep commitment to standards, both technical standards (J2EE, WS, XML, etc.) and BPM standards (BPMN, BPEL, etc.) and believe that will be a key differentiator for us. We currently support BPEL, including the ability to import and export BPEL process representations and execute them. For a refresh on how we are adopting standards and contributing to standards bodies, please feel free to stop by our website.
Thanks again!
Trevor,
Thanks for the clarification. If you need native BPEL support, let us know.
[…] Back in March, I explained why using Eclipse was critical for a standards-based BPMS. Today, I will try to illustrate this with a couple of customer examples, as part of our second BPM 2.0 weekly series. […]
Ismael,
Thanks for an interesting article. Do you know whether Intalio offers Designer as an Eclipse plug-in? Since I already have Eclipse installed, I’d like to pull in the Designer with my other tools.
JTD,
Yes, we do.
-Ismael
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment