The CIO snag: how to guarantee ELM success if you're a whale

First, it’s a guarantee. This is basically it. The corporation must be sure that the end justifies the means. Throughout software history, relatively short by the way, a pretty long list of big corporate legacy modernization failures has formed. I’ll place just a couple below, to give you the idea.

See? They’ve learned a few lessons and now they won’t move a finger without some solid guarantees of success.

What ensures that a software vendor and a corporate client collaboration will end as planned?

Let’s turn to our LinkedIn poll results. It says the guarantee of success is a multiflavor mixture of

1. Tech excellence (seasoned vendor),
2. Coordinated stakeholder effort and
3. Efficient knowledge transfer.

Why did we choose those three options to run our public poll? Specifically, as those are the key reasons behind the legacy software modernization successes and failures (if neglected), according to Alex Tsuranov, VP of Delivery at AIS Novations, and we wanted to make sure our experts see the things right.

The issue comes to mind as we discussed our legacy software modernization practice the other day and promptly evolved into a standalone topic.

Why do gigantic companies (let alone small businesses) reject modernizing their often inefficient software?

Low technical performance comes first to mind, when Alex dwells on possible reasons of legacy modernization failures.

“There may be multiple poor technical decisions that may end up affecting system scalability and flexibility, along with rushed system testing. Will I argue with the client’s Team Lead on it or assume that the situation is under control? No assumptions allowed, where big money is at stake. One of our recent cases will serve as a good example. The client came to us with a system design that was a no-goer, and we told them that. Confused, they left. Only to come back later, as they did another business analysis iteration and our suggestion was true. It’s a team effort, after all. We don’t own it, but we act as if we did.”

Which leads us to the poorly coordinated stakeholder effort.

“You’re nothing without a good team. We work as one or we fail.” - Alex continues. “At AIS we take good communication for granted, as our engineers are not hired to code in isolation. Rather, their effort is a part of a bigger picture. Same goes for testing, business analysis and project management. The project is only as good as communication within the team is.”

In his opinion, similar processes should occur on the client’s side. Only they do not.

“Corporate culture is different to what is often overseen as frivolous IT spirit. It’s very unlikely for the company of 10K not to suffer from siloed information and bureaucracy which makes coordinated stakeholder effort impossible”.

Last but not least is inefficient knowledge transfer.

“Corporate clients are very reluctant to open their business logic to us. Their legacy code is dear to them as it encompasses all the essentials and complexities of their money-making mechanism. If a developer forgets to tick a single box, the same business processes may not run again in a new system”.

This is why Alex recommends never to neglect a quality Discovery phase, during which a trio of BA, UX/UI designer and a Tech Lead scan a client's business for details. “Thus the tech team gets the meticulously documented system overview and won’t break a thing when they put their hands on it”. Do the clients follow his advice? “Sure not, they generally start right with the development phase. We understand that. They come for the tech skills, and want to try those first. Few companies turn for business analysis alone, if only those aren’t startups approaching us specifically for our Startup service package (D&E, D&E + MVP, MVP). BAs (along with QAs and PMs) join the team later and add a whole lot of new value, often to the client’s amusement.”

All three options - Tech excellence (seasoned vendor), Coordinated stakeholder effort and Efficient knowledge transfer - received an equal number of votes (14% each) during our LinkedIn public poll. The majority of votes (57%) still goes to the All of the above variant. This supports the logic behind the poll - each component is equally important and together they make what is known as the Great Legacy Software Modernization Project.

“There cannot be one reason for success in such a complex endeavor,” Alex winds up. On the whole, there’s no easy road for a legacy software modernization project. But it’s always a rewarding journey. An engineering genius that revives seemingly inoperable joints and floods in new life blood, isn’t it thrilling? At least it is so to me”.