By Bjorn Fehrm and Henry Tam.

September 5, 2025, ©. Leeham News: We do a series about ideas on how the long development times for large airliners can be shortened. New project talks about cutting development time and reaching certification and production faster than previous projects.

The series will discuss the typical development cycles for an FAA Part 25 aircraft, called a transport category aircraft, and what different ideas there are to reduce the development times.

We will use the Gantt plan in Figure 1 as a base for our discussions.

Figure 1. A generic new Part 25 airliner development plan. Source: Leeham Co. Click to see better.

IT Support for Development

We will discuss IT development support in a generic, vendor-agnostic manner. We cover a bit of IT support history, as IT application history is an important part of an existing OEM’s reality, and how this can restrict the free choice of an OEM upstart.

Development IT support history

Before computer-aided design support for development engineers became common, paper drawings with lines and instructions were the primary design documentation. Computers enabled the lines of electronic drawings to be drawn faster and more exactly, with 2D MCAD (Mechanical Computer Aided Design) support becoming common in the 1970s. It was still line drawings, but now on computer screens, which were later printed (or, actually, plotted, as the drawings were large pieces of paper).

In the 1990s, the change to working with 3D solid objects started. A bolt connecting two parts now had to be inserted as a 3D bolt object into generated holes in the equally 3D generated parts. Now, the designer had check of fit and tolerance matches. Adapted 3D models, called meshes, could be generated for strength, resonance, and thermal simulation.

The first airliner project that used 3D MCAD extensively was the Boeing 777. Output was still in the form of drawings, as factories and suppliers were unable to generate manufacturing data from 3D models; however, aircraft designers could see and check the design in 3D.

The drawing archives where replaced with database applications called PDM (Product Data Management) which had revision and check- in, check-out control with workflow support, configuration management (what data belongs to what aircraft version), search and presentation functions etc (“ find all the parts and show me the left wingbox structure with fuel system components of version 2C1 of the aircraft with all the design documentation”).

The birth of Product Lifecycle Management

The PDM served as a support system for the company’s R&D. There were PDMs for MCAD, Electrics (wiring, power electrics), Electronics called ECAD, and Software code management. Gradually, the PDM was expanded to support more parts of the company, now called a Product Lifecycle Management, PLM, system. It meant an expansion in scope, both upstream from design to requirements capture/management, specification generation and management, management of all project documents, including design simulation and test data, certification plan generation and substantiation, and data for manufacturing.

To support manufacturing, the PLM had to interface the OEM’s ERP (Enterprise Resource Planning, the company’s bread and butter system for sales/marketing/purchase/manufacturing/invoicing and economic control) system with data for Purchasing, Manufacturing planning and scheduling, and Quality control. The interaction of these systems is depicted in Figure 2.

Figure2. The key IT systems supporting aircraft development and manufacture. Source: PTC video about PLM.

In Figure 2, Quality Management is shown as a system. The reality is that it’s more of a function that uses and stores information in PLM, ERP, and MES, depending on the context. It might have its own applications to generate statistics and reports, but the necessary data is accessed in the other systems, and the results are predominantly stored in these systems.

The PLM is the platform that enables company functions to access and control development data. A PLM typically has the following functions:

Cross-domain collaboration

• Manage MCAD, ECAD, Simulation, and Processes
• Manage relationships and dependencies

Change process management

• Manage the change process across the company
• Manage workflows that integrate your business logic, including design review and release

Product requirement management

• Capture, collaborate, and maintain requirements across organizations and suppliers
• Continually verify that product design meets the requirements

Configuration management

• Create and share a single, accurate product definition (a single truth)
• Empower stakeholders to control configuration and track changes as they make them

Visual product collaboration

• Enable the teams to use 3D models without needing a CAD license by offering viewer functionality with the appropriate rights for additions and changes.

Purchasing’s interaction with suppliers and the manufacturing BOM (Bill of Materials) is housed in the ERP. To complement the semi-real-time ERP, companies add a MES (Manufacturing Execution System), which issues and tracks shop floor work orders in real-time, feeding the ERP and Quality Management System with the work results and any problems that occur during manufacturing.

The Legacy versus New problem

Aircraft manufacturers produce products with up to a 50-year lifecycle. During the full 50 years, the Certificate Holder, the OEM, is 100% responsible for the product. It shall be able to develop, certify, and produce different updates demanded by the regulator, Figure 3. We described this in more detail here.

Figure 1. A graph showing how an OEM and FAA surveys the operation of an aircraft and takes action. Source: Boeing.

To manage all the activities we described above, every OEM has developed and integrated thousands of IT applications to support their operation (Major airframer IT managers have told us these have over 10,000 applications, due to the legacy support problem).

While the transition from 2D CAD to 3D CAD can be reasonably straightforward, as it primarily affects a smaller group of people, mostly in R&D, the larger applications, such as PDM and PLM, significantly impact various parts of the company with diverse needs.

In almost all cases, there is a history problem. Let’s construct an example:

Fifteen years ago, a decision was made regarding the integration of a supplier’s PDM system with the OEM’s own developed Manufacturing planning system. These two, which took some five years to run smoothly, will now be either interfaced with a new PLM system or replaced by it. It means a multiyear investigation of how you should interface to the new PLM or replace both PLM and your own manufacturing system. Once the decision is taken, it takes another five years to complete the change.

The ever-growing problem is that the IT Tools landscape changes major versions with five- to 10-year time horizons, and the aircraft that these tools must support has a 50-year life cycle. For some of the tools used in generating the aircraft, the vendor might have called end of life for this version of the application or the application altogether at half this time.

The fix for the time problem

The remedy for the above is to store as much of the generated data around the aircraft in as neutral and accessible a format as possible. There are neutral formats for documents (XML) and CAD (STEP), and work is underway on a neutral PLM format.

The problem is that the export of data from a vendor-specific application to a neutral format for storage or distribution almost always means a loss of fidelity of data. Any additional information has to be passed to, e.g., a supplier via data files, documents, or Excel files.

The dream of a totally integrated “digital connected enterprise” with only one large application world from a single vendor will remain a dream, according to those who work to get corporate heterogeneous environments to work.

An upstart OEM could theoretically have this luxury.  Yet, it is unlikely that the people, processes, and know-how are in place to select, implement, and deploy these tools in an orderly manner.  It may need to rely on engineering consultants or suppliers to bridge the design knowledge and capacity gap. As a result, it creates an additional layer of interface between the OEM and the Consultant/Supplier, making the project more complicated.

Evaluating and choosing one’s own software tools is also complex.  An inexperienced team could sign up for something without fully realizing the business implications.  This is why tool selection deserves attention and requires stakeholder engagement at an early stage.  A bad choice would be difficult to reverse once a large amount of data has been generated.