Companies have been trying, and oftentimes failing, to get rid of legacy systems for decades. It was mostly an economic attempt to remove costs, but costs were often higher even where the migration happened. When it came to mainframe systems in particular, the replacement strategies failed to account for all the functions hosted and the real economics implied. Aside from major reservation functions, the mainframes sometimes hosted numerous other functions that were supported at a nominal incremental cost.
There was also consistency and reuse of the skills, tools, and operational infrastructure already in place due to the mainframe. We are not advocating to go back to the mainframe, but rather see it as a lesson learned. The lesson is to fully understand the architecture and the cost model of current state and future state when planning large strategic projects. The replacement of one, or a few, major business functions may leave other smaller but critical functions in a terrible cost and support model.
Another factor in legacy replacement is availability of skills, tooling, and operational infrastructure. It’s been hard for a while to find assembler programmers, and surprisingly hard to find C/C++ skills and tools. It is near impossible to find recent graduates of university that have been taught the necessary skills for programing and maintaining server functions (as opposed to client/user interface). In most companies, the age distribution of staff working on legacy systems is worrying at best, with most of the staff probably having AARP subscriptions.
Another large area of concern that does not get much attention is data privacy. The various system and data architectures in major use, until recently, were not built with data privacy for individual customers in mind. They were built to make sharing and exploitation of data across the enterprise and partners easier and faster. Security to the access of a database is relatively good, but not granular. Since the rollout of privacy standards like GDPR, travel companies have worked to understand where customer information is stored. Once documented however, is quickly out of date. For the travel industry, the data privacy and protection problem are not easily fixed in most systems older than 5 or so years.
Moving to the cloud following a REST architecture is a means to address these three areas. But there are large impacts that are a challenge to understand ahead of time. Costs are better for many functions that have seasonal highs and lows. However, this also means moving from a CAPX to an OPEX focus for accounting. Speaking from experience, this is not trivial. Just this one aspect illustrates a knock-on effect of fundamentally changing how things work, which affects many other teams in the enterprise.
The skills issue helps developers working on business function with modern tools, and many others as support and maintenance functions are passed to the cloud provider. However, this is also a major change in how things work. Data privacy and protection is now doable at scale as the cloud and REST imply a shared nothing architecture. The concept of a centralized database is replaced by views of business objectives defined around data privacy. Individual travelers and hotel or car providers have different views regarding trip level itineraries and wallet spend. Regardless, cloud/REST as architectures were defined with data privacy in mind.
In conclusion, there are more reasons than ever to move away from legacy systems and move towards what we call cloud native solutions. It is important to not underestimate how the fundamental changes will impact across the enterprise. The opportunity here is to cooperate as a travel community on many of these issues, rather than individually working to solve the same issues repeatedly. Individuals may think that they, or a designated vendor, have it all sorted out. But exchanging ideas may help find better (cheaper) solutions for known, and possibly unknown, problems.
A final word more on the point of OpenTravel. As stated, these changes have wide knock-on effects. These effects affect enterprises and customers and suppliers as well. Solving the many challenges as one offs represent unnecessary cost and risk.
Content By: Stu Waldron, Open Travel. (https://lnkd.in/d6FrRSTs)
Post/Edits By: Kristina Giacchetto, LinksRez (https://lnkd.in/eEz6SQxJ) (https://www.linksrez.com/)