By Karl Steeves

Airlines and business jet operators alike often weigh investment decisions related to aviation-related digital software and technology. Large operators may have internal software teams with hundreds of employees working on various projects, ranging from consumer-facing eCommerce solutions to rudimentary electronic tech logs and everything in between. Indeed, these development teams are established, competent in-house tech firms in their own right.

Yet, a robust market exists of third-party aviation software developers — like TrustFlight — dedicated to the behind-the-scenes tools that allow these operations to fly — including the aforementioned electronic tech logs, maintenance tracking software, and advanced analytics. When it comes to aviation software, the question becomes: is it better to buy, or try to build these tools in-house, and what are the risks?

Building aviation IT in-house works for many airlines

Examples abound of airline and aviation companies capable of building customized software in-house, starting with development and customizations of off-the-shelf instances of SAP or Salesforce, or development of entire applications from scratch. In my view, internal software development teams work particularly well for customer-facing systems such as eCommerce, loyalty programs and apps for the consumer. Airlines want to ensure a high-quality and on-brand customer experience. It makes sense: the DNA of the tech leadership at airlines and business jet operators leans toward digital agencies and eCommerce. Sometimes, airline IT leadership will have a development background and, for example, Maintenance & Engineering teams can be very proficient in SharePoint or Excel. They feel they can scale development internally — even in areas where the Maintenance & Engineering team might have specific requirements.

Who develops the software, compared to who uses it

Software development is still quite niche and specialized in aviation, let alone aviation maintenance systems and —critically — the resulting analytics and reporting that can come from software excellence. From time to time, the Maintenance & Engineering team at an airline wants to engage TrustFlight but they need to sell the dream internally to their IT team. The IT team might initially feel our tools can be replicated in-house, at lower cost. (We know that most smaller airlines and business jet operators don't have this capability.) It can also be challenging when the IT team controls the budget — but don’t directly benefit from the efficiency outcome, as they aren’t the end users. Tech Ops might lose out on slick user interfaces, ease of use or the system that its users need, instead matching budget or functionality requirements — with the latter not well-defined in the first place. In my view, it is difficult to marry the experience and specialty of Maintenance & Engineering with the experience and specialty of IT and development. There is also a lead time to internal development which is often overlooked (or underestimated), which generates an opportunity cost on short-term efficiency gains.

Configurability: How technology addresses specific requirements

Most of the airline and business jet operators we work with will have very specific requirements. We know from experience that when they analyze third-party aviation software, they might say: ‘Well, we have a specific way of doing things, so this doesn’t fit.’ A lifetime of technology at an airline or business jet operator has shaped those processes.

The path of least resistance is to take existing processes and build around them as opposed to rethinking them. That might work as a short-term outcome but not in the medium and longer-term and possibly not be the safest outcome.

With internal development, there’s an expectation that the solution is fit-for-purpose, rather than to force an organization to make a step change in the process. Once an operator has invested in a system, it is hard to say, ‘No. We should stop this and move to something completely different.’ It is harder to critique internally-developed tools. A developer might have more to lose than to gain by proposing changes rather than just keeping elements running for an airline or large operator. At the same time, successful development requires strong internal leadership, because an airline cannot approach digitization on a committee basis. You can’t please everyone.

Outside vendors are held to exceedingly high standards

By design, TrustFlight incorporates elements of configurability that support most customers. That is based on the hundreds of years of collective experience we have at airlines, business jet operators, and regulators. On the surface, the tools and systems look easy to use, but there's a lot of thought that goes into the design and functionality.

I believe we're held to a higher standard. If there’s a critical bug in a system, you’ll be sure we’ll receive and act on feedback. TrustFlight develops aviation technology tools that scale to as many airlines and business jet operators as possible. There will be more edge cases that need to be tested for, and the systems will perform at the highest standard through the volume of cases. The pace of technology change and systems is fast, and it is almost a necessity to include outside influence on systems and processes. Employees move from internal organization to internal organization, and to competitors. An organization might miss out on the collective improvements that might arise from competitor advances. A management team might feel it is giving up some control by outsourcing. I believe our airline and business jet operators gain more control, because partners like TrustFlight are commercially incentivized to perform. Internal teams may not have such pressure.

Reducing technical debt

Companies will have sunk cost into development, often from decisions made years ago. The company may have a web of tools developed over time, and are self-reliant. The more interconnected, the harder it is to move away from it. We understand that. Consider Southwest Airlines’ technical debt, the topic of many recent articles. Their systems started when they were a smaller, simpler airline and grew over time. They may not have been coded for scale. It becomes more difficult to maintain the systems simply because there is a shrinking pool of people that have the talent or skills to maintain those systems. Tech debt becomes embedded. An airline might use in-house software for 20 years to pay back its development costs. (That’s several lifetimes in digital technology.) Accordingly, decisions can't be made as much in the long term as previously. The alternative now is to use a system that might work for five to ten years — still quite a long time — which might require less upfront investment.

Stay ahead of cyber security risks

Cyber security is an escalating risk for airlines and business jet operators. Every operator is moving to cloud-based systems to reduce internal overhead, and the regulators are now more focused on cyber-security risks to operations from this fact. There are now wide-ranging regulations across all aviation organizations to enforce better oversight and due diligence on IT systems. Some jurisdictions require a cyber risk assessment internally and with suppliers. There is internal pressure to get software out the door, without appreciating risk or the right level of penetration testing on systems. That can be obviated with a developer with an external, wide-ranging viewpoint informed by a variety of clients.

After-implementation support

Delivering software is not a matter of deploying developers once, and it’s a fait accompli. Support systems are required to both deliver and maintain software. There are initial implementation teams, teams responsible for training and documentation for the software, ongoing maintenance of the software, securing and updating processes as systems change, threats or dependencies change. It is easy to underestimate the amount of non-developer resources required to support and deliver software. For example, our systems are built to provide internal documentation for our team and external documentation for our clients. We know that documentation is the first thing to go in development, especially with in-house, under resourced teams. A small team might hack something together that works, but the documentation is lacking. Of course, it varies, as some airlines have strong teams with have more standards around documentation.

Making the decision to go in-house or entrust a vendor

Aviation’s renewed focus on improving its aging software and legacy tech debt has forced airlines and operators to expand their technology budgets. They each want to maximize profits and prevent future meltdowns. But internal teams may not have the talent, experience, pressures, standardized procedures, documentation requirements, after-implementation support and focus on analytics to produce high-quality and futureproof systems. Partnering with a vendor for complex systems provides the best of both worlds, freeing up the organization’s IT team to focus on oversight, internal systems integrations and improving customer-facing systems, whilst leveraging the benefits of an external vendor for more complex operational systems. The nature of our work is that we are incentivized to keep things on the cutting edge and adopt more recent technologies and practices. Ultimately, it means that we can continue growing and supporting more customers, and innovating all the while.