Feature:

Java EE 7 migration: Risk mitigation strategies

With Java EE 7 scheduled for rollout in the 3rd quarter of 2012, enterprise developers are
already considering if and when they should migrate to the newer version. The Java EE platform is known for its
incremental development and improvement. New releases aren’t necessarily groundbreaking or flashy.
Instead, they often represent maturation of the existing technology. This means users of older
versions may consider their version perfectly adequate even if there’s a newer release
available.

For example, respondents to TheServerside.com Readership Survey 2011 consider both EE 5 and EE 6
to be “current” versions of the EE platform since both offer basically equivalent capabilities for
application development. Many organizations aren’t having significant issues with older versions.
Others have already spent the time and energy to find workarounds for known problems. So, it’s not
surprising that they don’t feel a pressing need to upgrade every time Oracle makes a big
announcement about a new product.

Will Java EE 7 be different?

There will be changes in EE 7 that could catch the interest of some enterprise users. A
standardized caching API and a modularization API are being added. But the most talked about
upgrade is improvement in cloud support and integration. Java EE 7 assumes that enterprises are
poised to make a move en masse to embrace the PaaS model. The cloud is certainly becoming a more
popular tool for large businesses.

However, some detractors point out that a focus on certain issues like multi-tenancy are
misguided since it’s the private cloud and not the public cloud that is getting the most love from
enterprise level businesses these days. That being said, some in the Java community already view EE
as woefully behind in the development race. An upgrade that ignored the requirements of the cloud
environment would certainly be seen as yet another version that presents new features that are “too
little, too late”.

Organizations may trickle rather than rush to adopt Java EE 7

Enterprises that are currently using PaaS or planning to migrate are most likely to be attracted
to this newest version. Other firms may continue to hold back. It’s not actually because they lack
faith in the latest release. Java EE is a respected technology – perhaps partly because Oracle does
show caution in rolling out significant changes. Let’s take a look at some of the most commonly
cited reasons why enterprise users say they may delay adoption.

Time required to perform backwards compatibility testing
30% of respondents expressed concern over the resources that would have to be committed to this
aspect of an upgrade. When you adopt a new version, there are several potential outcomes. Best case
scenario, you can still use all the assets created previously. Usually, there will be some tweaking
necessary to migrate successfully. Worst case, you miss something and software that used to
function just fine breaks down catastrophically.

Time required to investigate the latest release
This reason ties in to #1 because actually taking the time to fully explore a new release is
absolutely necessary for determining what types of compatibility testing are needed. Otherwise,
it’s impossible to assess the risks involved. A busy CIO or IT manager who is juggling multiple
projects isn’t likely to feel a compelling need to investigate an upgrade if everything is already
working fine. That leads us to reason #3

No need to switch
As mentioned at the start of this article, the older versions of Java EE are working fine for
plenty of companies. The risk of not upgrading seems low compared to the risk of upgrading and
having something go wrong. After all, no one outside of IT is even likely to notice when
applications are running smoothly. In that situation, moving forward with the latest version
violates the prime directive of IT management “If it ain’t broke, don’t fix it.”

Other issues that are likely to slow the acceptance of Java EE 7 include lack of buy-in from
management and heel-dragging from vendors in releasing products that implement the latest
release.

Risk mitigation strategies

What can businesses do to make the migration to Java EE 7 less risky? Actually, waiting to jump
on the latest EE version bandwagon until it has some time to prove itself is not a bad idea. The
wait and see approach provides an opportunity for others to discover any bugs with the new version.
There will always be more intrepid users who take the plunge and blog about it for the rest of the
enterprise population.

Staying in the discussion during the pre-rollout phase is another good risk mitigation strategy.
It’s a lot easier to make a decision about if/when to upgrade when you know what’s going on leading
up to the release. Potential conflicts and poor decisions on the part of the designers are often
easy to spot long before the version is released. The role of monitoring industry publications and
relevant forums can actually be delegated to an IT team member so the IT executive just gets the
“executive summary” about what’s going on when it’s relevant to the decision making process.

What if the upgrade process has the potential to be beneficial but inertia is still holding your
company back? One way to overcome this obstacle is by bundling the Java EE 7 migration with another
project. For example, if there’s a cloud development or migration project in the works, that’s a
valid reason to dedicate some resources to a Java upgrade as well. This can add to the overall
complexity of due diligence and testing. But once it’s done, there’s more to show for it.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.