The travel industry has been leveraging software for more than 60 years, starting with American Airlines’ installation of the first automated booking system in 1946 (hat tip to Stephen Joyce) and led the way for electronic commerce even as Gates, Jobs and Packard were playing with blocks. So what that really means is that there’s a lot of old code out there on old platforms.
And to a large extent, while these systems are still running, they cause their fair share of problems:
- High cost of operations: can’t take advantage of lower cost hardware or Cloud-computing
- Fragility and Inflexibility: the systems don’t allow for rapid feature enhancement or make integration with other systems challenging.
- Mortalityware: literally there are fewer people alive who know the old development languages and how these systems work. And it’s not a problem that gets better.
Now it’s kinda scary that a trillion dollar industry is so dependent on what many would consider to be outdated tech. And the movement of the industry towards a la carte pricing, a.k.a. ancillary revenues is being blunted in part by the ability of the underlying software to merchandise and manage the distribution of these different offerings through multiple channels.
But modernization is a challenge that the industry has struggled with for years and while some systems have been moved to modern platforms, many more are still tied to the past. So what’s holding things back?
It’s not technology. Certainly a big part is an organization’s appetite to expend the resources to make the move. But I believe an underappreciated aspect is the psychology of taking on a modernization project. Many of the applicationsthat we’re talking about have millions of lines of code that have built on top of each other like an archeological dig with one civilization built on top of another. So the task can seem daunting and lead to paralysis. Few want to undertake a full re-write which can feel like a Cecil B. DeMille film, costing millions of dollars and thousands of lives (or at least man-years).
So it’s good to have a framework with which to view your choices. A good model is my “Six Degrees of Modernization” which covers the main paths to modernize your application.
When dealing with a huge project as we’re discussing, the big bang approach of re-writing the code is often a recipe for disaster and porting really doesn’t buy you a lot. So an evolutionary approach can be of great help. An example of such a strategy is where you’d start by separating and Wrapping the different bits of functionality into a SOA harness. Now that you have the code broken into more manageable pieces you can start the process of Translate/Refactor or Replace piece by piece — with the dual benefit of shrinking the size of the problem to a more manageable level that will help create early “wins” for your team and momentum for the project, as well as delivering a more flexible, higher code quality platform.
But this is not something that everyone should try at home. This is not a coding activity, although that’s a big part of it. More than anything this is an architectural challenge (even more so if you’re trying to transition from an on-premise to an On-Demand model). And it’s an area where Ness Software Product Labs Strategic Consulting team have helped many clients.