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/)
In theory, APIs should be unlocking travel activities or “things to do.” There should be ubiquitous travel apps that not only have solutions for how to get there, but what to do. Better yet, you may reference an experience like a concert and a museum in another city and the app figures it all out. There are examples of very localized capabilities, but nothing at scale.
This is not a technology problem because AI/ML solutions, along with the cloud, are already capable of this. The problem is getting to the necessary data, the problem is APIs. In technical forums, there is way too much attention on the developer of the APIs and the costs to publish them, with way too little focus on the consumer of APIs and their related costs.
Way too many travel solution providers still think proprietary APIs are a good idea, such as to discourage a customer migrating to a competitor. It’s needless differences between APIs that all have the same purpose to find, reserve, and purchase travel content that drives up costs. High APIs consumption costs shut down the long tail of content, as the cost to access versus potential profit is underwater.
It’s in the interest of all parties in travel, the suppliers, the channels, the apps, from the very large to very small, to cooperate on the technology aspects of APIs to lower costs. This will enable not only experience led retailing, but personalization across supplier and channels. It’s not a technology problem, it’s lack of industry alignment on the use of technology.
OpenTravel, along with existing standards bodies and trade associations, can provide that alignment.
Travel products such as air, car, hotel, cruise, restaurant, golf, tours, etc. are overwhelmingly purchased on an individual basis. Some trips only require one type of travel product, while most trips involve multiple types of products. Products such as hotels, restaurants, tours etc. could be bundled together for a better overall experience and price.
Technology exists that could provide trip level solutions at a massive scale, but data and access to products stand in the way. A major contributor to this is the tendency of travel industry sectors to define message, data, and API standards in a silo.
If one were to build an AI/ML based shopping solution that would provide the most relevant trip level solution to a traveler, offers and orders would need to act similarly regardless of product type. This would require at the data model level to avoid needless confusion over global constructs like customer, location, address, station, etc.. Identity management, security, payment, invoice, and many generic business functions would also need to be common.
Yet today’s common practice is that each major sector defines its own object models, schema, and API behaviors as the industry moves to JSON APIs. Established industry sectors continue to define their own silos, including newer areas of restaurant and tour operator groups.
OpenTravel, as the only organization spanning travel sectors, is advocating a better way. This includes supporting travel industry sector-based standards bodies and trade associations to drive responses to sector business needs but cooperate at the technical and data level through OpenTravel. OpenTravel provides the means for a common object/data model where business objects are built upon common objects and core elements are shared across the sectors.
There is the means to turn those models into XML and swagger schema that provides a common approach at the message level avoiding needless differences that have no business value. This common repository also makes differences between sectors, and there will still be easily discoverable differences.
All of this works to lower costs and speed time to market for all. Lower API costs brings more travel products to the market especially for restaurants, tours, and other areas where there is a massive number of participants. Let the business leaders in each sector lead by setting the direction and priorities, but let’s cooperate on the technical details to avoid unnecessary costs.
Content By: Stu Waldron
Edits By: Kristina Giacchetto, LinksRez (https://lnkd.in/eEz6SQxJ)
Question! What is the value in participating in industry interoperability efforts? Does one only consider existing value such as message standards, or potential future value as well?
Our thoughts: Through community efforts, organizations such as OpenTravel, have defined message standards and provided message examples for all the mainline travel functions across nearly every sector. Work continues to be done to extend XML messages to accommodate edge cases and newer needs, such as amenity-based pricing. While other work is focused on producing object models and tooling to better support OO programming languages like Java, and message protocols like JSON.
There is a lot of interest in the latter, but many companies are looking for JSON definitions that are as complete as the XML body of work, and not necessarily looking to do the work needed to reach the goal. As a result, many feel that the XML messages have immediate value because they are “done” and free. The JSON definitions done to date are also free, and companies will add what they need internally.
But is that the right way to look at value of community efforts?
OpenTravel, with help from OpenAPI and HTNG, is looking beyond message definitions to how a community-based effort can attack many of the drivers of the costs to develop, deploy, maintain, and especially, consume APIs. The overall goal to bring consistency and predictability to how travel APIs work without affecting what they sell.
The diversity in how APIs work, the workflow, the access to rules and more is so chaotic that some basic steps to clean this up can have a large payback. This would be a future value approach which in the short-term can result in cost avoidance more than investment, and in the long term, net new revenue.
In future posts we will outline how this can happen. But our question to you now is should one consider community efforts based only on immediate value or to consider it an investment with future value based on a sound business case?
Content By: Stu Waldron
Edits By: Kristina Giacchetto, LinksRez (https://lnkd.in/eEz6SQxJ)
Call to action! Be a part of a team of engineers and architects as part of the new OpenTravel architectural committee, pulled together by Technical Leader Stu Waldron. All to reboot OpenTravel, the committee’s role will be to determine technical direction, and advise the OpenTravel board.
First steps: to create and agree on a new mission statement that focuses on APIs overall, instead of just a message standard. Because how APIs are constructed, documented, deployed and what behaviors exhibited at runtime, are just as important as message formats.
Our focus is on how APIs work, not the content they convey. A drive towards more consistency in how APIs work, meaning no restrictions on the products prices and rules an API exposes, will lead to bringing down costs for all.
The team consists of individual volunteers from Marriott (https://lnkd.in/ekwDsVAk), IHG (https://lnkd.in/eiTq-URh), Id90 (https://lnkd.in/ex_3P79r), Delta (https://lnkd.in/eUBBFNk9), HTNG, and LinksRez (https://www.linksrez.com/) and plan to start meeting this week. Please join us as we find ways through community efforts to drive down API costs.
Why? Because this makes sense for your bottom line. There are several reasonable efforts which will result in API cost avoidance which frees up capital for better uses. Further, as we significantly drive down API costs, the result will be more cost-effective and available travel content. AKA a net new revenue opportunity.
Come join the discussion and make a difference in digital travel retail. Please comment the company you represent and any goals you may have for OpenTravel, and go to https://lnkd.in/etmYt5gh to get involved.