According to a recent poll by Travel Technology Europe, legacy systems are the biggest barrier to digital transformation and modernization within the travel industry. Around half of travel professionals, representing travel technology companies, tour operators, hoteliers and TMCs, put legacy technology on top of the list of obstacles to transformation.
Before the pandemic, companies were functioning under a ‘legacy on premise technology’ arrangement, hesitant to make large investments in cloud adoption due to concerns about cost, time, and security. But in a post-pandemic world, the travel industry must adapt quickly to survive and thrive. Furthermore, the travel industry is converging with mobility, health, financial services, and the supply chain industry. This has further accelerated collaboration in the travel ecosystem and has forced legacy systems to adapt or risk becoming obsolete.
The Origins of Legacy Systems
The first legacy systems came about in the 1960s. American Airlines and IBM created the world’s first computerized airline reservation system, which evolved into a technology ecosystem that impacts every stage of the travel experience, be it business or leisure. In the 1990s, computing became ubiquitous in all kinds of administrative environments, from science to government and business. This was hailed as an opportunity to improve the efficiency and effectiveness of business processing. The PC put an end to manual and semi-manual work like checking, indexing, searching, and it even solved storage and archiving problems.
Issues with Legacy Systems
If it ain’t broke, don’t fix it.
Legacy architecture is usually known to have come into existence in an unplanned manner. These systems are complex, poorly understood, slow, and expensive to operate, support and enhance. Overall, they are old-fashioned in their interfaces and reporting capabilities and have many hidden redundancies. From an IT perspective, they are difficult to monitor, control, and recover and are susceptible to countless security issues. In terms of versatility, they are by definition hard to integrate with newer models and technologies, like cloud computing or mobile devices. Because legacy systems were designed as application silos, slight changes to business or internal processes can require an unintended rework in multiple IT systems.
Attempts to improve this architecture by building a singular system to replace the legacy system often result in yet another system being added to the pile, increasing the costs and effort required to support, fix and patch it.
While these systems do work, they fail to properly serve the needs and demands of the end consumer (the business traveler, the tourist, the hotel guest, the restaurant client, or the digital nomad, to name a few). Integrating old applications, systems, and data sources with new ones can be incredibly difficult. Doing so seamlessly can be almost impossible. This lack of agility in legacy systems is a huge barrier to improved customer service, satisfaction, and retention.
The first obvious solution to this monumental problem is to completely redesign the system. This sounds good, but the biggest hidden risk is “throwing the baby out with the bath water.”
First and foremost, when thinking about a possible elegant solution, it is important to consider your perspective. CTOs and CIOs often deal with legacy systems that have evolved organically over many years. This frequently has created an institutional inertia toward agile change out of a desire to remain competitive. However, the problem then becomes one of continuously over-extending intertwined functionalities, which can be costly, time-consuming, and complicated.
With experience, it is possible to replace legacy systems. However, consider this: can you implement a complete system overhaul while your business continues to run at full capacity? It is highly tempting, and many large organizations have attempted an enterprise-wide re-design approach to resolving their legacy systems problem. Let us look at some of the real risks and pitfalls associated with this solution.
One approach often proposed in boardrooms is to design and implement a new, more modern architecture using a clean slate approach. Starting fresh is very tempting, but a big-bang approach to legacy IT systems replacement can be naive, expensive, and filled with risk. Instead, pragmatic approaches that deliver improvements using ‘whatever still works currently’ are preferred and highly recommended. They are often cheaper, less risky, and have a faster turnaround.
Obsolete on Release Day
Why is a complete redesign not a good idea? The IT consultancy industry has come across many such initiatives that were abandoned when the scale of the challenge or the impossibility of delivering against a moving target became clear. A business simply cannot stand still or freeze in time while advisors draw up an amazing, revolutionary, cutting-edge blueprint. Re-designing an entire system, especially for multinational corporations, is a massive undertaking. The process of building or purchasing a replacement system takes quite some time. During that time, a company will need to launch a new product or service, change existing business processes, experience changes to regulations, witness the birth of a disruptive technology, encounter new competitors (remember the startups we mentioned earlier?), or exit a business sector. All of these things conspire to make your system redesign obsolete before it even goes live. Sadly, by the middle of the project, the CTO is already too invested in terms of money, effort and time to just throw it all away. At the same time, they often recognize that their approach is futile.
This sort of major project come with notoriously high failure rates. A survey by KPMG in 2005 showed that “in just a twelve month period 49% of organizations had suffered a recent project failure.” In 2008, IBM found that “only 40% of projects met schedule, budget and quality goals,” and in 2012 McKinsey disclosed “17% of large IT projects go so badly as to threaten the very existence of a company.”
Now that we know what to avoid, what can we do about legacy systems? Oftentimes, trying to fix all of the problems simultaneously is a logistical impossibility besides all the risks.. There are simply too many unknowns and unintended consequences.
In these situations, problems should be tackled in priority order, as there is rarely a silver bullet for the whole job. Luckily, some practical and cost-effective approaches can mitigate many of the problems with legacy systems.
Speed, scalability, robustness, and other similar features have to be designed in, not expected to emerge from, the process of development. This is an area where DataArt, with its years of experience and hundreds of successful projects, brings unique value to new customers.
When modernizing any legacy system, the process should begin with considering how to improve services for customers, how to grow the business and how to stay ahead of the competition. Based on those answers, experts can begin to model the solution from the ground up.
The technology choice must enable business improvements and better services for customers, but should not be implemented for its own sake. Once the business goals align with what that technology can deliver, the solution will emerge. There is no need to create a completely new solution to achieve the business goals.
People vs Systems
The conversation about solving legacy systems must be extended to include the human element — the people in the organization. The issue of legacy systems is a people issue as much as it is a technology one. When thinking about legacy systems, organizations must resist the natural urge to get rid of old systems and build new ones, absolutely convinced that the new is always better than the old. They should resist the temptation to launch “big deal projects,” for all the reasons that people launch big deal projects — from genuine belief that they are required (or the only way), to being a way of self-promotion, and everything in between. Instead, it requires people to understand that their systems are business critical, both to their own business and to that of their clients. In the case of B2B companies, the organization must take into account that their clients also have clients of their own and thus depend on their systems.
The shift in mindset and company culture requires continuous improvement to become the default method of change as opposed to step change projects. This approach might face resistance in companies where many employees have the words ‘project’ or ‘program’ in their job titles. Oftentimes, at these companies, such employees find out that their skills and behaviors valued highly over the years are suddenly exposed as they may have actually contributed to the problems. It can take time to convince your employees that change starts with them, and not with the systems. Resistance to change should be expected, and, as long as it is overt, it is a good thing. That is because it shows that your employees are engaging and opening themselves up to discussion and the possibility of learning. The agile methodology is the actual key to success of many companies and brands we love. Continuous improvement means that change is iterative rather than a step-change approach.
To summarize, resolving the problems of legacy enterprise IT systems can provide significant gains in productivity, efficiency, agility, and customer satisfaction. For these reasons, this undertaking should be a high priority for any travel company. However, there are many risks attached, all of which should be considered before beginning this kind of project. After all, the systems are business critical — not just to the organization that owns and operates them, but also to the businesses of your clients.
Luckily, we now have technical tools and modern approaches available to achieve radical improvements without incurring the expense, effort and risk commonly associated with major replacement projects. Using these tools requires a change in mindset and approach that may run counter to the ethos of some companies. It can mean a move away from “long-march” projects in favor of continuous improvement. Education, organizational engagement, and depth of capabilities will be key to making it happen.
Originally published at https://blog.dataart.com.