News Stay informed about the latest enterprise technology news and product updates.

How database legacy modernization is like peeling an onion

Migration efforts can seem daunting, but upgrading legacy databases isn’t an impossible task. During the “Mainframe and Database Legacy Modernization” session at Red Hat Summit 2013 in Boston, Red Hat services delivery manager Emily Brand likened the process to peeling an onion.

“Every layer you pull off, try to remove the layers of the legacy,” she said Wednesday morning.

To get started, Brand recommended people begin with analyzing their current infrastructure and then think about the ultimate mission they are trying to accomplish. This is how one begins to map out a plan to make their goals a reality.

Brand said, “Ask yourself, what does your environment look like? Is it monolithic or do you have a bunch of scattered databases and applications?” She noted it’s difficult to move a project forward when there are multiple versions of everything.

Throughout her session, Brand touted the benefits of enterprise data services (EDS), saying the platform makes it easier to move to more modern middleware. She said an EDS can be a layer above databases that can integrate multiple data services or just be a layer between them.

It’s also important for people to standardize databases to the version they want, choosing as few as possible. Middleware, programming languages and SOA governance also need to be standardized, Brand said. The more stringent one is with frameworks and languages, the more agile developers can be within an organization.

There are, however, times when flexibility is key. By allowing for exceptions, one can maximize IT infrastructure, Brand noted, “Instead of being a maintenance machine, you can be a development machine.”

There are several benefits to modernizing legacy databases that make taking on what may initially seem like a scary migration effort worthwhile, even from an ROI perspective. Brand said some of them include:

    – Decoupled business applications from several sources
    – Isolated data layer
    – Companywide semantics

Look ahead
Don’t just work with the present in mind, perform work anticipating future needs. Everything should be able to talk everything else in a way that can easily be tracked, Brand said. This is because ambiguity can lead to unnecessary headaches. “Think 10 years down the road,” she said, elaborating that new employees will be forced to deal with the ramifications of whatever decisions are currently be made.

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Testing is a big issue here.  How to do a thorough Proof of Concept or Bake off with potential vendors.  

To make this work, in a minimal amount of time and with repeatable results, they need seed each vendor with realistic data that has been de-identified.
In this way, they are secure, their clients are secure and as the data is fictitious, there is no risk that hackers or rogue employees (aka Mr. Snowden) will get their hands on real data.

Testing can be done quickly and a true comparison can be done between vendors.

Additionally, Implementation is facilitated as data is extracted from the legacy data base, de-identified in memory (you don't want to create additional copies) and then loaded in the new data base.