"Migration from IBM Rational Application Developer to MyEclipse Blue Edition"

If you receive errors when attempting to view this white paper, please install the latest version of Adobe Reader.

"Genuitec is possibly the most interesting of the Eclipse-based IDE players from a disruptive point of view."
Source : Genuitec, LLC

Resources Related to Migration from IBM Rational Application Developer to MyEclipse Blue Edition:

• Development environment (Wikipedia)

Migration from IBM Rational Application Developer to MyEclipse Blue Edition

A White Paper exploring concerns and issues surrounding migration of your development environment from IBM’s Rational Application Developer® (RAD) to MyEclipse Blue EditionTM from GenuitecTM.
September, 2009

EXECUTIVE SUMMARY

The goal of this white paper is to explore and resolve common concerns and issues surrounding a migration of your development environment from IBM’s Rational Application Developer® (RAD) to MyEclipse Blue EditionTM from GenuitecTM. Why might a company choose to migrate their development tools? If the migration is decided upon, how would this be done easily and effectively? This paper will answer these common types of questions, as well as explore any intangibles that may arise during the decision and implementation process. In the following scenarios and discussion, we'll use IBM Rational Application Developer® as an example of a "current" tool, and MyEclipse Blue EditionTM as a "new" tool being migrated to.

...there are a number of accompanying issues that a development team might want to consider when revisiting past tool choices.

WHY MIGRATE?

The decision to stop using one development tool and migrate teams to a new one should not and will not be taken lightly in most businesses. The current sanctioned tooling (in this case, RAD®) was decided upon previously, usually after a long vetting process to discover and implement the tools right for the job.But, beyond simply "finding the right tool for the job," there are a number of accompanying issues that a development team might want to consider when revisiting past tool choices. These other concerns can often make or break a tooling decision from both a technical and a business point of view.

For example, tooling decisions might be made strictly from a monetary standpoint. Reducing the cost of the development tools themselves is high on the priority list, but most discerning companies are also looking at total cost of ownership. For example, a shop utilizing IBM Rational® tooling will look at not only the license price, but also support costs, implementation costs, hardware requirements and so forth. These can all be factored into a total cost of ownership that will be explored in the decision-making process for tool evaluation.

Tools are also often selected because they add components and technologies not available in the current/legacy choice. If the current tool doesn't allow an enterprise to accomplish important goals specific to their needs, it is not effectively assisting that company. Additionally, many companies will look at a tool's extendability as an option to "fill the gaps." A tool that allows for easy, inexpensive and useful modifications is a prime candidate to provide the highest service and lowest ownership cost.

Tools are also often selected because they add components and technologies not available in the current/legacy choice. If the current tool doesn't allow an enterprise to accomplish important goals specific to their needs, it is not effectively assisting that company. Additionally, many companies will look at a tool's extendability as an option to "fill the gaps." A tool that allows for easy, inexpensive and useful modifications is a prime candidate to provide the highest service and lowest ownership cost.

...tools are also often selected because they add components and technologies not available in the current/legacy choice.

Another key factor in tool exploration is the likelihood of the software becoming obsolete - both in technology or support. Some of today's leading organizations release products every 2-3 years (this is historically true of Rational® software). This can unfortunately leave some organizations using tooling a bit behind in terms of technology advances. This ultimately costs time, money and effort to do "new" things the "old" way.

Finally, we are seeing development environment migration take place in the market with a unique twist: a baby step towards a full migration away from specific application server technologies. Until recently, it has been demonstrated that enterprise middleware is unlikely to be expendable. But, with current economic conditions, many corporations are choosing to explore this migration path as well, with front-end tooling being a key step in the progressive process of full-company migration.

Any or all of these reasons could be a driving force behind the decision to migrate from current environments like RAD® to new development environments like MyEclipse Blue EditionTM, and the exact reasons will be unique to each business or department. But, there are likely some commonalities in the challenges companies will face during a proposed transition period. We'll explore those next.

MIGRATION CHALLENGES

The movement from one tool to another doesn't happen in a vacuum. Business are still running, projects are still going and deliverables are still required. So what types of considerations might a company have if they have made the decision to migrate?

Many of these "unique-to-the-company" considerations will be around the projects themselves. Which projects will be moved to the new tool environment? Just as importantly, when will the projects be moved over? Once those concerns are addressed comes the big question: how will the projects be migrated? Does the new environment have technology that can assist users in the process? The answers to these questions will make or break the migration dilemma, and we'll see how MyEclipse BlueTM may be able to help with these a bit later on.

But before that, let's look into the crystal ball and see the challenges enterprises might face as they choose to implement a tool migration process.

PROJECT & TEAM TRANSITION

If enterprises are lucky enough to be in a situation where they can just flip a switch, so to speak, and everyone moves everything to the new IDE on a specified day, migrating is a much simpler process. Though this is not common, if corporations have this ability, the decision is fairly painless. But, even in this Utopian scenario, companies will still need to plan carefully, making sure everyone has the new tools on the appointed day and, if necessary, removing the old tool from desktops before starting in with the new one. Obviously, testing of this transition will need to be done beforehand, but the overall cost seems a bit more palatable. But again, an all-at-once migration seems unlikely for most shops because as we mentioned, projects and deliverables are ongoing.

... most companies will encounter the need to have both old and new tools running on the same machine at the same time.

A more likely scenario is that companies will need to stagger the migration utilizing a stepping-stone process. Whether the transition takes place team-by-team or project-byproject, most companies will encounter the need to have both old and new tools running on the same machine at the same time.

It is also a very real possibility that projects would need to be accessed by both tools if they are sufficiently large, or if some component is used in multiple projects. To identify the real behavior of the tool being tested, in this case MyEclipse Blue EditionTM, each company or department will have to determine the level of production-level access during this process. If your company is employing the SOA approach to development, then this "dual-tool" approach with RAD® seems most likely.

It is therefore crucial that you either plan migration very carefully for any projects with shared components, or that the tool you are migrating to (i.e. MyEclipse Blue EditionTM) supports the old tool’s project format seamlessly. After all, any lag in the production output creates even higher costs and therefore a greater likelihood of scuttling the project completely. These dual-tool concerns become doubly important if the IDE migration is just the first step in migrating to a new application server, since you will have to go through all this again as you bring the new server on-line (we'll discuss this option momentarily).

...any lag in the production output creates even higher costs and therefore a greater likelihood of scuttling the project completely.

Moving forward then, let's assume that companies are looking to migrate their development environments for any combination of the reasons we have discussed. Further, we'll continue with the assumption that the migration process has been mapped out to meet all corporate requirements. That just leaves us with the final step: actually getting the new tooling in-house and using it firsthand.

TOOL CONSIDERATIONS

Many of today's popular development tools, including RAD®, have the capability to become system "resource hogs" very quickly. By the time the tool is running along with some additional plug-ins, connectors to source code repositories and databases, application servers are running and you’ve loaded a project into the workspace, you can be consuming a lot of RAM. For a large project, numbers approaching or exceeding 1Gb of resources are possible before any actual work has been accomplished.

As mentioned above, any tool migration will very likely involve running two IDEs on a machine at the same time. The question is then – will a standard developer machine be able to run both tools simultaneously? Or will they need to stop and start tools individually to free up resources? Companies certainly don't need the added hardware requirements of an upgrade just to accommodate the testing process. How might this effect your selection process?

Today, many tools from different companies use custom versions of, for example, the same Java library. If the tools being vetted use the same underlying architecture – both being Eclipse-based perhaps – then the risk of conflict will depend greatly on how each tool implements that architecture.

For example, both IBM’s® RAD® and Genuitec’s MyEclipse Blue EditionTM are built on top of the Eclipse platform. But since IBM installs its own variant of Eclipse into C:\programfiles\ibm\rational and MyEclipseTM does something very similar into C:\programfiles\genuitec, they don’t conflict. You can even use different JDKs for each if you choose, further reducing the chances of conflict issues.

MIGRATING FROM RAD TO MYECLIPSE BLUE

In this example, a migration from IBM Rational® to MyEclipse Blue EditionTM would be fairly simple using the criteria we listed. They share a common platform and tooling format, but are separately installed and individually manageable. Further, MyEclipseTM is a much smaller installation than Rational® tool sets, freeing up system resources and allowing for the simultaneous running of both tools. Beyond that, MyEclipse Blue EditionTM includes full project compatibility with RAD®, so projects can be run in both tools at once without modification or "breaking" of the project. Perhaps just as importantly, MyEclipse Blue EditionTM is incredibly affordable, at roughly $150 per developer - an inconsequential cost considering the reason for the proposed migration is to save many thousands of dollars per developer seat.

...MyEclipseTM is a much smaller installation than Rational® tool sets, freeing up system resources and allowing for the simultaneous running of both tools. Beyond that, MyEclipse Blue EditionTM includes full project compatibility with RAD®.

WHY WOULD A RATIONAL SHOP CONSIDER MYECLIPSE BLUE EDITION?

MyEclipse Blue EditionTM is designed to make the transition from IBM’s Rational Application Developer® (RAD) as painless as possible. To that end, it will install on the same machine as RAD® and when a RAD® project is imported into MyEclipse BlueTM, none of the RAD®-specific project metadata is removed. After enhancing the project so that MyEclipse BlueTM recognizes it as a RAD® project, you can make changes to the project in either MyEclipse BlueTM or RAD®. Find out how this works by clicking here.

developer starts using a new tool is finding where comparable features are and what they’re called. MyEclipse BlueTM uses a lot of the same naming conventions as RAD®, and because both are built on top of Eclipse, they have a very similar look and feel. However there are understandably some differences and new MyEclipse BlueTM users will find the transition much easier if they take a few minutes and read this.

Finally, getting back to the initial point about the "right tool for the job," MyEclipse Blue EditionTM and RAD® have very similar features sets. Companies certainly need the appropriate tools, and MyEclipse Blue EditionTM delivers with a long list of highly-utilized features that RAD® doesn't offer, including integrated Hibernate® support, RESTful Web Services capabilities, Maven project support and much more. A full list of the direct feature-to-feature comparison between RAD ® and MyEclipse Blue Edition TM is available.

MIGRATION AWAY FROM WEBSPHERE?

It was mentioned earlier that some enterprises are beginning to explore a migration away from their current application server technologies to lighter or more open, extendable options. Since we're exploring RAD® and IBM® tools, it stands to reason that many companies utilizing RAD® are also WebSphere® customers. Thankfully, MyEclipse Blue EditionTM has many options for users exploring this migratory option away from WebSphere. MyEclipse BlueTM has over 35 application server connectors built in, ready to run. This means that companies can easily begin deploying to new servers to test them in-house - all without leaving their familiar tool environments and without intense configuration worries.

...MyEclipseTM is a much smaller installation than Rational® tool sets, freeing up system resources and allowing for the simultaneous running of both tools. Beyond that, MyEclipse Blue EditionTM includes full project compatibility with RAD®.

For example, many companies are looking at keeping their project integrity, but want to move from WebSphere® to, say, JBoss® as the server of choice. There's no hassle or extra charge to do it with MyEclipse BlueTM. Also, some companies are developing with a hybrid approach, using WebSphere® alongside lighter technologies to lower costs and hassles. Your company-specific options are open with MyEclipse BlueTM.

CONCLUSION

Migrating tools or even application servers means change, and it’s part of human nature to find change unsettling. But changing your environment from Rational Application Developer® to MyEclipse Blue EditionTM is a smaller, more pain-free change than you might expect. And it gives your developers a familiar and more flexible development environment at a lower cost. Bosses are happy. Developers are happy. CFOs are very happy. It's the ultimate winning combination for a tool migration.

IBM, IBM Rational and the IBM Rational Application Developer are all registered trademarks of International Business Machines (IBM) in the USA and other countries. JBoss and Hibernate are registered trademarks of Red Hat, Inc. Genuitec, MyEclipse and MyEclipse Blue Edition are trademarks of Genuitec, LLC. All other brand or product names may be trademarks or registered trademarks of their respective companies and should be treated as such. JRE, Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc./Oracle in the United States and other countries.

IBM Rational to MyEclipse
Blue Edition Migration
September 2009

Genuitec, LLC
2221 Justin Road #119-340
Flower Mound, TX 75028
USA

http://www.genuitec.com
http://www.myeclipseide.com/blue

Copyright ©2009, Genuitec,
LLC. All rights reserved.

This document is provided for informational purposes only and the contents hereof are subject to change without notice. This document is not warranted to be errorfree, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document.