Modularity is a term often used. It is well associated as one of the benefits of moving away from a legacy, monolithic Passenger Service System and towards a componentised ecosystem.

Earlier this year at a conference, unsurprisingly the concept of modularity came up a lot – but there were many different interpretations and assumed benefits. We hope with this blog post to leave you in a better position when it comes to modularity.

First, on definitions.

Modularity itself refers to a system design principle that breaks down a system into smaller, self-contained units or modules. Each module is designed to perform a specific function and can operate independently, but when integrated, they form a cohesive system. In plainer English, it is a stand-alone capability, it is triggered by passing information to it, typically via an API, and it returns a result. For example, a well-known IT vendor has the concept of a “Segmentation” module. It has one job; it will take ingest customer data and context and return the likely segment for the customer. This information can then be used by another module to tailor the offers a customer is given. You can buy a module off-the-shelf and there is no additional requirement to buy any other module to make it useable.

What does modularity look like today?

Some mature airlines already have this concept. They work with the concept of an orchestration layer. It is typically built in-house or by a system integrator. This layer receives requests from channels (e.g., their website, mobile app, call centre, NDC) and sends requests to a module. This provides the airline with full control. For example, it can allow an airline to send a set of offers to a dynamic offers engine for repricing but only do so for its direct channels as that is the channel where it offers dynamic pricing.

Each module can theoretically be swapped out without having to change the overall ecosystem. Airlines can even run multiple vendors for the same module at once. For example, an airline may have two shopping engines and can choose to route requests to Shopping Engine A or B based on certain conditions.

What is the benefit?

There are benefits to modularity from a commercial, technical and organisational prospective.

From a commercial perspective, an airline can procure modules from different vendors, choosing the best solution for each function. This can lead to better strategic options related to pricing and vendor selection and reduces the need to compromise on capabilities. Additionally, procuring many modules rather than one monolithic system can lead to improved negotiation power. Lastly, on the commercial front, an airline can spread their investment over time, adding modules as and when they need them, rather than a substantial upfront investment in a monolithic system.

From a technical angle, there is the opportunity to conduct maintenance more easily and push changes without having to take an entire system offline. There is also the possibility to scale parts of the system. For example, an airline may need to more compute capacity because it has a sale upcoming, it can scale the parts related to offer management, without doing so for other parts of the system.

From an organisational perspective, modules align with modern ways of working. As a company’s technology architecture often mirrors its organisational structure over time, adopting a modular approach allows an airline and its vendors to clearly define areas of responsibility, fostering a modern organisational structure. This modularity ensures capabilities are created once and owned by a single empowered team responsible for uptime and business KPIs. Currently, airlines often use a monolithic, channel-based architecture with different teams managing the same capability. For instance, seat selection by travel agents is managed by an airline’s indirect channel team, the e-commerce team for the website, and the operational team for airport enquiries.

Potholes ahead: What to watch out for as you drive towards modularly.

When designing and procuring a modular ecosystem, there are many elements to watch out for. Here are just three of them:

1. Is it standalone?

If a vendor offers a module that has a pre-requisite for other products, then it is not standalone. Be cautious of this especially when expanding with an existing vendor and ensure any new modules you are purchasing could work without existing products. You may well decide to change those in the future.

2. Understand the true cost of purchasing an orchestration layer.

If you are procuring an orchestration layer, then ensure you understand the cost of integrating other vendors into the ecosystem. Will the vendor charge a substantial amount to integrate a competitor’s product vs. their own? If the cost feels too high relative to the work required, consider whether this is to artificially better position their own product. It’s not an open and fair ecosystem if that is the case and this will prevent you from obtaining the best product.

3. Bear in mind overall complexity.

It may be tempting to shop for the best vendor for each module. Whilst at Travel in Motion, we do believe in a best of breed environment being suitable for some airlines, they must have the procurement and technology maturity to get the benefits a best of breed environment has on offer. Taking on board too many vendors, at this early stage of industry maturity, may leave you with headaches to run your ecosystem.

How can the whole airline industry achieve modularity?

To achieve modularity, an airline needs the capability to have control over its channels and orchestration layer. Not every airline will develop this, nor will they have the ability to instruct and monitor a system integrator. Airline-industry focused vendors have responded. They are developing channels and orchestration layers “as a service”. All major vendors are also now offering the ability to integrate other vendor modules, typically as a customisation. However, this customisation can be a lot of effort to set up. A vendor’s own modules come readily integrated, and sometimes this can be a benefit to get up and running more quickly but also to only pick up the phone once if it goes wrong.

It’s one thing to build and launch a multi-vendor ecosystem. It is another to operate it. Airlines, as risk averse beings, may be tempted to stick with a single vendor, based on promises of reduced risk and increased ease. Doing so would put aside the benefits a best of breed multi-vendor environment offers. Instead, airlines ensure that you are mitigating the risk in order to take those benefits. Airlines wanting to approach this environment must consider how it will:

• Run the ecosystem and rectify issues across a multi-vendor technology stack. For example, how will you ensure all vendors are cohesively working together, rather than blaming each other.
• Coordinate improvement to its capabilities, acknowledging it will need to do so across multiple vendors.
• Stay active in evaluating the market’s capabilities now that it has the options to swap out modules.

So, what next?

We recommend that airlines whose PSS or related systems contracts end in the next few years consider the options you have for the next generation of systems you will require, and which will meet your future needs. Consider how you can benefit from modularity, or where you see challenges in a multi-vendor environment.

If you are unsure, rely on the experience of companies such as Travel in Motion. We stand ready to help you evaluate your strategy in keeping competitive by moving towards a modern retailing environment. We have already helped several airlines to craft their ideal technology state based on its starting point, and its desired business ambitions. We have equipped such airlines with detailed transition plans, and some have already started implementation.

 

Jason Balluck, Travel in Motion AG