Most analysts agree that we have been witnessing in the last few years the greatest disruption in IT that we have seen in twenty-five years, since the appearance of the Internet and customer/server architectures.

The convergence of technologies like Cloud (IaaS and PaaS), Big Data, Machine Learning, microservices, asynchronous architectures, API Management, etc. and methods such as Scrum, DevOps or continuous delivery allow for the development of digital products in ways that five or ten years ago, when companies like Google started using them, seemed nothing short of magic.

These new ways are radically changing the IT ecosystems of large companies all over the world. This is what we call velocity development. Facing this new technological train, many companies continue basing the core of their business on hosts with architecture and applications that are more than 30 years old. Many of them ask us if it is time to change and how to do it.

The mainframe and resistance to change

In the early nineties, there was already a technological transformation of a similar calibre to that which we are living now and, nevertheless, the mainframe, against all odds, has survived.

An anecdote on this topic has already become famous: in 1991, Stewart Alsop, a well-known technology writer, predicted, in light of the capabilities that he saw in the Internet and customer/server architectures, that the last mainframe would be shut down before the 15th of March 1996.

The reality is that, give or take one year, the prediction seemed to make total sense at that time, however, in 2002 Stewart finally admitted his error and ate his words (literally), taking a picture of himself that is already history:

[caption id="" align="aligncenter" width="800"]

Stewart Alsop[/caption]

Why was Stewart wrong and today many companies worldwide still maintain the core of their business in an architecture that has been obsolete for more than 25 years? Because these companies were doubtful at the time, they decided to bet on new technologies in a half-hearted way and to stay in their comfort zone, at least in their primary applications.

The consequences have been years of license over-cost, complication in their IT architecture, and underuse of state-of-the-art technology.

So, why consider changing now if we haven’t done it in 25 years?

Now, as we were saying, we are witnessing a similar change, but the difference is that digital leaders are not hesitating to take a decisive step forward. There are those who say that these leaders have the advantage, because they are digital natives, companies born in the digital age that have been able to choose these technologies from ground zero.

However, this is not entirely true. Companies like Amazon began with 20th century architectures and have had enough determination to change them radically. In fact, one famous story is that of Jeff Bezos, the CEO of Amazon, who years ago gave an order to his entire company through an internal memo that required them to work on third-generation technologies. He signed this memo saying: “Whoever doesn’t do this will be terminated. Thanks, and have a nice day!”.

Facing this scenario, which poses a clear threat to companies that don’t know how to advance at the same pace as these digital leaders, there are still companies that cling to their comfort zone with arguments similar to those that were used 25 years ago, but which today, however, are even less sound.

There are those who think that being leaders, or being among the leaders in the sector, demonstrates that there is no need for change (“we must be doing something well if it’s working so well for us”). Nonetheless, we already have multiple examples of companies like Kodak, Blackberry, Blockbuster, AOL, Marsans or Nokia, among many others, that have paid the price for not changing when they were leaders.

Others, facing the prospect of such an important change, simply put it off (“surely we don’t need to tackle this now”). These ones exhibit perfectly one of the wisest ideas from the Cluetrain manifesto: “Intelligent companies will do whatever necessary to make the inevitable happen as soon as possible”.

At Paradigma, we believe that the moment has arrived to confront the host monster, which has become strong in the heart of the IT ecosystem of many companies. We encourage all of our clients to consider if they want to be masters of their own digital future, or continue being slaves to their own monster.

Now, how do we confront the monster?

As with many things in life, the first (and most important) step is deciding to do it. From there, you have to assume two fundamental premises:

• The process of shutting down a host is not only a technological project. It must be accompanied by a reinvention of the business processes to capitalise on these new technical capabilities.
• The process will be long and, therefore, it is necessary to accomplish it gradually and make sure that it doesn’t impact day-to-day operations.

From here, based on our experience, we propose a model based on four large phases:

1. Chop up the monster: Not by operations, age, department, or applications, but by vertical businesses that allow us to make a controlled change in stages. We’re talking about getting return on investment as soon as possible; to this end we will identify the main areas and priorities through specific business dynamics. This phase allows us to create a common language of communication between business and technology.
2. Corral the monster: We deal with the pieces one at a time, and we round them up through mediated tools based on data access. We will try to avoid getting close to the monster through APIs or any other type of direct contact with applications. These mediated co-existence tools generate approximately 20% extra code which at the end of the process will be thrown away.
3. Eat up the monster in bites: Minimise risk by guaranteeing replacement without interruption of service. Support tools are developed parallel to production and never involves a big bang replacement.
4. Innovate free from the monster: It’s common to find very suboptimal processes, whose justification is "it’s always been done this way". It’s time to take advantage of improving them, simplifying them, and equipping the business with new capabilities: real time, data intelligence, omnichannel, customer centric, etc. without confines or restrictions.

Is it that easy?

Clearly, although in this post we have tried to simplify, as far as possible our vision on migration processes and shutting down a host. “The devil is in the details”, and we cannot think that it is going to be simple to replace in a non-traumatic way applications that in many cases have been in development for dozens of years, and, what is worse, there is no one in the organization today who knows how they work.

Our detailed model of the migration process, which we have devised based on our experience with different clients and which we summarise in the following image, is a process that can take months of planning and years of execution in large companies:

Our experience with real clients is that no two processes are the same, and the first phase of analysis and context is fundamental in order to map out a customised migration model.

We are aware that it is a difficult and costly process for most companies, thus the importance of having a specialized technological partner that can help do it in the most practical way.

Conclusion

The challenge is great, but the final reward at the end of the path is immense: a future free from technological chains that allows us to accomplish a real digital transformation process. From here we encourage you to follow this motto applicable to all aspects of life: if you question whether to do something or not, DO IT!