Three weeks before an audit, engineering teams rarely discover new technical problems. What they usually discover is how fragile their engineering setup has quietly become.

Someone opens a spreadsheet that has not been updated in months. Another person starts searching for test evidence that “should be somewhere.” Design decisions are remembered differently by different people. Traceability exists, but only because someone has been manually maintaining it in the background, hoping nothing critical has changed.

This moment feels uncomfortably familiar in both automotive and aerospace programs. Not because teams are careless, but because most organizations have grown into their tool landscape over years. What once worked for a small project slowly becomes a liability when products grow more complex, lifecycles stretch into decades, and compliance expectations increase.

In regulated industries, compliance does not arrive once a year with the auditor. It is present every day, whether teams acknowledge it or not. 

At first glance, standards like ASPICE, ISO 26262, and DO-178C appear very different. They use different terminology, focus on different domains, and come from different regulatory worlds. Yet when you look at how engineering teams experience them, the similarities are striking.

Products live for a long time. People come and go. Suppliers change. Variants multiply. Requirements evolve. And through all of this, organizations are expected to retain a clear line of sight from original intent to final verification, often many years after the initial development effort.

Neither automotive nor aerospace standards tell teams how to engineer their products. They do not mandate a specific lifecycle or tool. What they do require is much more fundamental: that engineering decisions are controlled, traceable, and reproducible. That evidence exists not as a collection of documents, but as a coherent story of how a product came to be.

This is where IBM Engineering Lifecycle Management becomes relevant. 

Teams that mature in regulated environments eventually arrive at an important realization: compliance cannot be “added on” at the end. It has to emerge naturally from how engineering work is done every day.

ASPICE, ISO 26262, and DO-178C are not document standards. They are expectations about discipline. They expect that requirements are clear, that changes are controlled, that verification is meaningful, and that evidence can be trusted long after it was created.

When engineering artifacts are truly connected, compliance becomes less visible - and far less painful. The same structures that help teams reason about their system also produce the evidence auditors are looking for.

This is the context in which IBM Engineering Lifecycle Management becomes relevant. 

IBM ELM is often misunderstood. Some expect it to define their process. Others hope it will “make them compliant.” Neither expectation is realistic.

ELM is a platform. Its value lies in the fact that it connects requirements, design, implementation, verification, change, and configuration into a single information model. Instead of documents referencing each other loosely, engineering artifacts become explicitly linked.

This distinction matters more than it sounds. When a requirement changes, the system does not rely on memory or manual checklists. The impact becomes visible. When a test fails, its relationship to the original intent is clear. When a baseline is created, it reflects the actual state of engineering data, not a snapshot assembled for reporting purposes.

ELM does not replace engineering judgment. It makes that judgment visible, reviewable, and durable. 

In automotive programs, compliance rarely stays within one organization. Safety requirements flow across company boundaries. Variants share components but differ in behavior. Changes are frequent, yet every change carries potential safety implications.

ISO 26262 and ASPICE both expect teams to demonstrate not only what they built, but how they controlled the journey from concept to production. Safety attributes, allocations, reviews, and verification results all need to remain connected as the system evolves.

When ELM is used effectively, these connections are not reconstructed for assessments. They exist as part of everyday work. Engineers do not maintain traceability because a standard demands it; they rely on it because it helps them understand their own system.

This is a subtle but important shift. Compliance stops being an external pressure and becomes an internal capability. 

Aerospace and defense programs add another dimension: longevity. DO-178C expects evidence that can survive organizational change, long maintenance phases, and sometimes decades of operation.

Here, document-centric approaches show their limits. Files get lost. Context disappears. Decisions made years ago become impossible to explain with confidence.

ELM addresses this by treating traceability, configuration, and evidence as living engineering data. Plans, requirements, tests, reviews, and problem reports remain connected, even as teams and tools evolve. The result is not faster certification by default, but something more valuable: engineering that remains defensible over time. 

There is an uncomfortable truth worth stating: implementing ELM poorly can be worse than not implementing it at all.

Over-structuring, excessive customization, or treating the platform as a document repository quickly alienates engineers. Instead of becoming a backbone for engineering work, the system becomes something to work around. Traceability exists on paper, but not in practice. Trust in the data erodes, and with it the value of the entire setup.

What makes the difference is not the tool itself, but how the platform is designed, deployed, and evolved within an organization. That requires understanding both the intent of standards like ASPICE, ISO 26262, and DO-178C and the daily realities of how engineers actually build, change, and verify complex systems. It means knowing where structure adds clarity - and where it creates friction. It means designing information models that support engineers first and make compliance a natural outcome of good engineering, not an afterthought.

This is where experience matters.

At Softacus, we bring years of real-world IBM ELM experience to solving precisely these kinds of challenges. We support engineering organizations through the full lifecycle of ELM adoption - from initial assessment and design to rollout, integration, and long-term support - informed by decades of work with regulated programs in automotive, aerospace, medical devices, and more.  

Our ELM Service Portfolio & Project Experience includes consulting across:
• IBM ELM application design, setup, and configuration (DOORS Next, ETM, EWM, Rhapsody, reporting)
• Methodological guidance on link strategies, data models, and reuse concepts
• Migration services, including large-scale data transitions and legacy tool migrations
• Custom reporting, automation, and integrations
• Dedicated long-term ELM support and application professionals
• Infrastructure setup, hosting, and monitoring
structured training tailored to your team’s needs (all designed to increase engineering confidence, not just tool adoption).

You can explore the full scope of these services and how they apply to real projects on our ELM Service Portfolio & Project Experience page: https://softacus.com/services/Elm-Service-Portfolio-Project-Experience.

In regulated engineering, getting the structure right early is one of the most effective ways to protect delivery, quality, and compliance over the long term. Strong experience doesn’t replace engineering judgment - it ensures that judgment becomes visible, reviewable, and durable. 

We work with engineering organizations in regulated environments to turn IBM ELM from a technical installation into a true engineering foundation. That often means moving away from spreadsheets, local files, and legacy tools - but more importantly, it means helping teams rebuild trust in their own engineering data.

In many programs, IBM ELM already contains the right information, but not always in a form that is usable across roles and disciplines. Engineers, quality managers, safety officers, and program leads all need to see the same data - but through different lenses. This is where the combination of IBM ELM and ELWIS, a web application platform developed by Softacus, becomes especially powerful in regulated environments.

IBM ELM provides the authoritative, traceable information model: requirements, designs, tests, changes, baselines, and approvals, all connected and controlled. ELWIS builds and connects on top of that foundation, exposing the data through structured, role-specific applications that reflect how regulated organizations actually operate. ELWIS enables organizations to create workflows, dashboards, and domain-specific applications, allowing flexibility and engineering efficiency to reinforce each other rather than compete. It provides a web-based application layer that allows teams to build and deploy role-specific applications in addition to IBM ELM - quickly and without custom coding. More information about the platform and its capabilities is available at www.elwisapp.com

Designed for speed and flexibility, ELWIS enables organizations to create modern web applications without coding by leveraging drag-and-drop builders and customizable components. With built-in tools such as advanced page layout, flexible data types, and secure access rights, ELWIS helps teams turn complex enterprise data into intuitive, purpose-built applications. 

Most engineering teams do not struggle with compliance because they lack discipline. They struggle because their tools no longer reflect how complex their products have become.

If you are responsible for engineering delivery in an automotive or aerospace program and want compliance to become a natural outcome of good engineering, rather than a recurring source of stress, then it may be time to rethink your engineering backbone.

We specialize in IBM ELM and application development in regulated environments, and we are always open to an honest conversation about what works, what doesn’t, and why.

Let’s talk.
Lukas Jancar