In my last post, I talked about how to observe the impact of modernisation through a data quality lens.

I asked you to consider the quality of your legacy data and what that means on the "shiny new toy" you intend to buy in the future.

In this post, I want to talk about how you can design and plan for modernization with some simple tweaks that won't bust your budget but will save you time (and sanity) when you go through another modernisation cycle.

Which will be sooner than you think.

Modernisation: The new normal

Consider for a moment those legacy systems you've been hoping to modernise.

Perhaps you mock their poor performance or lament their unsupported code base. But at one point, probably less than a decade ago, those systems were considered state of the art or a component of the "modernised IT platform" your organisation invested heavily in.

The reality is that modernisation cycles are getting shorter.

I once worked on a modernisation project where a utilities ERP system was scrapped and modernised six months after going live. I'm sure you can imagine the morale of the business after learning they were "next to benefit from modernisation."

And this is not an isolated case. In every organisation I've consulted for, the shelf life of legacy systems is shrinking.

So the writing is on the wall. If you want to compete and stay nimble, you need to build systems with modernisation in mind.

The Fortune 500 are lagging behind

One thing I've witnessed in twenty years of modernisation initiatives is that young, highly aggressive firms have a massive advantage compared to the legacy Fortune 500 companies when it comes to modernisation.

In Business Stripped Bare, Richard Branson talks about how in some of his startups they rapidly introduced systems that surpassed the functionality of legacy competitors and allowed Virgin brands to race quickly to billion dollar revenues.

In the excellent book New IT, the author and Data Roundtable colleague, Jill Dyché, talks of how the typical "IT department at a 40-year-old Fortune 500 company [takes]herculean efforts to sustain costly, outdated and unwieldy transactional systems at the expense of leveraging technology to drive business value." The entire book is a call to arms for technology leaders to embrace modernisation and fuel business strategy.

Legacy firms need to step up and begin designing and preparing for modernisation; because for many, it may already be too late.

How can you design for modernisation?

Want to know one of the biggest obstacles to modernisation? Knowledge.

In one modernisation project, the client didn't know how many systems in their legacy real estate contained their core plant data. They gave up counting at 27 systems, but the real answer remained unknown.

Consider that for a moment.

If you can't even put a finger on what systems contain your most vital information assets, how could you ever hope to plan an aggressive modernisation strategy?

And this is not an isolated incident. As Jill points out above, this is the norm in a lot of organisations.

So your first task in designing for modernisation is to create an enterprise directory of what each system holds in terms of conceptual, logical and physical data.

You also need to track which functions and processes are supported by each system. Because as I discussed in my last post, a thorough understanding of functional change is vital for a successful data migration.

This knowledge needs to be maintained, so you also need to factor in data stewardship.

(Sorry, but at least it's another selling point for data governance! :-)

Once you have a solid understanding of your legacy landscape, you need to ensure that any new systems are designed with modernisation in mind:

• Don't buy proprietary black box systems that will refuse access to the underlying data models and metadata. These are a nightmare to migrate from in the future.
• Determine what the migration flight path will be from your new system right from the outset. For example, if you're moving to a cloud-based system, what assurances can you get regarding ease-of-migration?
• What data quality measures and controls are built into the data design of the new system? Can you enhance them? One of my clients purchased a billing app that prevented them from standardising the data entry form logic. They constantly had to run post-transactional cleansing processes to check for defects as a result. Make sure thay any new system is built with data quality in mind so that when it comes to the next round of modernisation, there are far fewer issues to resolve.
• If you are designing the system in-house, make sure that your database table architecture features record creation and update timestamps, and record creation sequence numbers. This seems a trivial addition, but it can make a vast difference when migrating data to a new platform because you can create an audit trail and manage synchronisation far more efficiently.

Summary

Modernisation is not a strategy; it's a design imperative.

You should be designing, creating and governing for modernisation now. There is no time to lose, particularly if you have a lot of legacy baggage in your IT stack.

What are your experiences of modernisation? What do you think companies should be doing to prepare their data and systems for modernisation? Welcome your thoughts below.

Read what TDWI has to say about data integration modernization.