SodiusWillert Blog

How to Reverse Engineer Code and Models into IBM Rhapsody with AI?

Andy Lapping — Tue, 23 Jun 2026 15:51:23 GMT

Many engineering teams have at least one system that nobody fully understands anymore. The developer who originally created it has left, the documentation is minimal, and the model (if there ever was one) is likely out of date. So, getting back to a working understanding of that codebase can take weeks. And that's if they're lucky...

Reverse engineering is commonly suggested as a solution within IBM Rhapsody. However, the process of reverse engineering can be complex, time-consuming, error-prone, and generally unpopular among team members. On top of that, Rhapsody's built-in reverse engineering is limited to C, C++, and Java. For any other language or format, IBM Rhapsody cannot help you.

This is where AI can make a significant difference.In this article, I’ll show you how to use AI Modeling Assistant for IBM Rhapsody to reverse engineer existing code and design artifacts directly into a Rhapsody model, using nothing but natural language prompts.

How to Bridge the Traceability Gap Between Requirements and Models?

csimon@sodiuswillert.com (Célina Simon) — Fri, 05 Jun 2026 12:45:17 GMT

If your teams use both a requirements management tool and a system modeling tool on cross-domain engineering programs, you’ve probably experienced what happens when these two environments are not connected. Requirements change, but the modeling team is not properly notified. Coverage analysis depends on manual checks, and impact analysis often relies on the person with the most experience and knowledge of the model. If that person is unavailable or has left the project, the analysis takes much longer or gets done incompletely.

How to Architect System Models for Cross-Program Reuse

Eran Gery — Fri, 29 May 2026 15:43:26 GMT

Many organizations invest in MBSE but struggle to reuse system models beyond a single project. Architectures, behaviors, and patterns are recreated instead of being leveraged, leading to rework and inconsistencies. This article explains why model reuse across programs is challenging and how to overcome those challenges successfully.

We will first explore the different types of system models that can be reused, from simple types and interfaces to full mission-level architectures, to understand why reuse becomes increasingly difficult as model complexity and context grow. Then, we will examine the root causes that make reuse so challenging in SysML, and walk through practical strategies for both homogeneous and cross-organizational environments, showing how SysML v2 can address these issues.

SysML v1 vs SysML v2: What Changes for Engineering Teams?

csimon@sodiuswillert.com (Célina Simon) — Tue, 26 May 2026 08:29:39 GMT

SysML v2 is built on a different foundation than SysML v1. For engineering teams, that difference directly affects how models are defined, how behavior is specified, how tools integrate, and how teams collaborate. This article focuses on what actually changes for engineering teams when moving from SysML v1 to SysML v2. It includes modeling practices, interoperability, extensibility, and day-to-day workflows.

How to Create a System Model from a PDF with AI in IBM Rhapsody?

Andy Lapping — Mon, 11 May 2026 07:34:39 GMT

If you work with IBM Rhapsody, there is a good chance many of your projects start the same way: someone sends you a PDF full of textual requirements and expects a model. What follows is usually hours of manual work, reading through the document, identifying requirements, creating model elements one by one, structuring them into packages, and hoping nothing gets lost along the way.

AI can help streamline this process. With the right tooling, an AI assistant can read that PDF, extract the requirements, and build the initial model structure in IBM Rhapsody. You'll still want to review and refine the design, but the heavy work is done. Plus, the model stays faithful to what the PDF actually contains.

In this article, I’ll walk you through how to do this using AI Modeling Assistant for IBM Rhapsody, SodiusWillert’s AI extension that brings AI-assisted MBSE directly into the Rhapsody environment.

Reliable Impact Analysis Starts with Interconnected Engineering Data

csimon@sodiuswillert.com (Célina Simon) — Mon, 13 Apr 2026 14:27:01 GMT

Impact analysis refers to the structured process of evaluating the potential consequences of a proposed change before it is implemented. It helps identify the scope, scale, and dependencies affected by modifications to systems, requirements, or processes. As such, it plays a central role in change management within complex engineering programs. Despite this, impact analysis remains inconsistent and difficult to rely on in many organizations. The reason is that they repeatedly face the same issue: engineering data remains siloed and disconnected across tools and domains.

A Practical Guide for SysML v2 Adoption

Eran Gery — Fri, 03 Apr 2026 14:42:43 GMT

SysML v2 marks a significant evolution in MBSE, designed from the ground up with greater precision, rigor, and a strong focus on interoperability and ecosystem enablement. Rather than a simple update to SysML v1, it introduces a fundamentally different architecture and modeling approach, which creates challenges for organizations with existing SysML v1 investments.

This article explores practical adoption strategies, emphasizing incremental approaches and the coexistence of SysML v1 and SysML v2 rather than encouraging a wholesale migration.

Best practices for Managing Baselines with IBM Doors Next

csimon@sodiuswillert.com (Célina Simon) — Wed, 01 Apr 2026 16:35:58 GMT

👉 Managing Baselines with IBM Doors Next - What do you need to learn?

Define your baseline strategy →
Create a baseline →
Use baselines for impact analysis →
Avoid the most frequent baseline management issues →
Prepare for audits →

In IBM DOORS Next, baselines capture the approved state of requirements at specific lifecycle milestones. They intend to preserve the configuration that was reviewed, validated, or authorized before downstream work begins.

A strong baseline strategy, established right from the start, is a foundational governance decision that determines whether your projects can demonstrate compliance, manage change, and support certification activities with confidence.

In this article, we share concrete recommendations for creating and managing baselines effectively in IBM DOORS Next.

How to Connect Requirements, Changes & Tests Across Different Tool Vendors?

csimon@sodiuswillert.com (Célina Simon) — Mon, 09 Mar 2026 16:54:55 GMT

Engineering organizations don’t build their toolchains from scratch. They inherit tools from past programs, comply with customer-mandated platforms, or adopt domain-specific solutions that genuinely work better for some tasks. Over the years, this has created a heterogeneous environment. What may appear as an issue is simply the reality of long-term engineering programs.

So the question to be raised here is not whether you should have multiple vendors in your stack. Most of the time, you already do. It’s more about how to connect requirements, changes, design, and tests across different proprietary tools without disrupting what already works.

However, achieving this requires a shift in perspective. Instead of seeking uniformity, for instance, through consolidation into a single suite, organizations should focus on connecting engineering artifacts across different tools. The presence of multiple tools in your environment is the natural consequence of real operational, technical, and organizational constraints. So, we don’t want to eliminate heterogeneity. The real challenge lies in making diversity strong over time.

Why Interoperability Is More Than a Tooling Problem?

csimon@sodiuswillert.com (Célina Simon) — Tue, 03 Mar 2026 09:03:32 GMT

Conversation with our experts #3

Today, many engineering organizations heavily invest in modern toolchains. Yet they still experienced challenges with fragmented data, duplicated artifacts, and late discoveries of inconsistencies, including traceability gaps.

The reality is that interoperability is often seen as a tooling challenge. But what if the real bottleneck was not the technology itself? What if it lies in how engineering work is structured across domains, how data ownership is defined, and how configuration flows, or fails to flow, throughout the lifecycle?

As systems grow more complex and regulatory pressures increase, it’s becoming clear that interoperability cannot be seen as just a tool integration effort.

To explore this shift in perspective, we spoke with Thomas Capelle, President of SodiusWillert. In this conversation, he explains why silos persist despite significant investments in tools and processes, how fragmented engineering information flow affects quality and compliance, and why interoperability must be addressed at the organizational level before even becoming a tooling discussion

This third episode of the "Conversations with our experts” series invites our readers to reconsider interoperability as a structural and strategic challenge.