Jama Company and Community News

Jama Connect® vs. IBM® DOORS®: Migration & Data Mapping: A User Experience Roundtable Chat

By |

Migration & Data Mapping

Jama Connect® vs. IBM® DOORS®: Migration & Data Mapping: A User Experience Roundtable Chat

Increasing industry challenges and complexities are pushing innovative organizations to consider modernizing the tool(s) they use for requirements management (RM). In this blog series, Jama Connect® vs. IBM® DOORS®: A User Experience Roundtable Chat, we’ll present several information-packed video blogs covering the challenges that teams face in their project management process.

In Episode 6 of our Roundtable Chat series, Richard Watson – Practice Director at Jama Software® – and Alisa Eikanas  – Senior Consultant at Jama Software® – discuss migration & data mapping, and how to migrate your DOORS® data to a new tool.

To watch other episodes in this series, click HERE.

Watch the full video and find the video transcript below to learn more!

VIDEO TRANSCRIPT:

Richard Watson: Hi everybody, I hope you’re all enjoying watching the vlog so far and that you take the time to watch some of the others. I’m Richard Watson, and I’m part of the solution management team at Jama Software. In this vlog, I’ll be giving the DOORS angle on things. I’ve been a systems engineer for about 35 years, 20 of which was as the product manager for DOORS and DOORS Next. I now spend much of my time advising clients on migration strategies to Jama Connect. Today I’m joined by Alisa, who’s going to give the Jama side of things.

Alisa Eikanas: Hello everyone, and good morning Richard. My name is Alisa Eikanas, and I’ve been a consultant here at Jama Software for just about five years. In that time, I’ve supported hundreds of successful implementations and have extensive experience supporting customers with complex migration needs, so I’m tickled to be here.

Richard Watson: Organizations are often black and white when it comes to migration. Either they believe migration is too risky to form, and so they’re stuck in their current tool, or they trivialize things, and they think it’s as simple as pressing a button and everything is done.
In my experience migration isn’t complex, but it does involve taking a lot of very small decisions and then repeatedly executing against those decisions when you’re migrating the data itself.

Alisa Eikanas: Mm-hmm, I couldn’t agree more. I often use the analogy of moving to help illustrate this very same point to customers. When you’re making the decision to move to a new house, the benefits are obvious. A bigger house, better schools, et cetera, and there’s things you can do to make that moving process more efficient. You can hire a mover and do all of that stuff, but there’s no shortcutting the fact that you still have to label the boxes, tell the movers where they have to go.

So again, we can take care of the heavy lifting, but that attention to detail is something that’s not ever going to be avoided. And it might seem tedious, but it’s so necessary in order to avoid unnecessary frustrations if not given the proper attention at the proper time. There are typically two blocking points regarding migrations.
So first, management would like to… The migration process itself to be predictable so that they can follow the progress and predict how long it will take. Ultimately, what they’re trying to avoid is disruption to work, additional costs, making sure that the proper resources are available during that process. And secondly, for end users themselves, they expect the migration to run smoothly and for us to be able to demonstrate that the migration task has been executed without error.

For example, I was recently working on a migration with a team and the data that we were migrating from DOORS Classic, they’ve been working on that data for 20 years and some of the original engineers are still involved in the project. And so, you can imagine for them how stressful it is to consider 20 years of their work being moved and just wanting to make sure and not have any fears or reservations.

That as the data was moved, that there would be no negative impacts to that data. So it’s completely understandable, but again, these are things that Jama Connect has found ways to address proactively to ensure that both of those concerns… Having the efficient be predictable so that it can be efficient and not overly expensive. As well as for end users, just ensuring again that data integrity is maintained from point A to point B.

RELATED: 2023 Predictions for Product & Systems Development Teams

Richard Watson: Generating a business case for migration is also often terribly difficult. In fact, it’s very difficult to justify moving from IBM DOORS to IBM DOORS Next because it’s more of an emotional decision. One reason to move away from DOORS is the aim to adopt more of a model-based systems engineering approach. If you have that, then it becomes consistent for your engineers, easier to create reports, and cheaper for integrations.
We all know that without DLX, it’s terribly difficult in DOORS to keep a consistent data model between your different modules. Thinking about consistent data types between modules, for example. DOORS Next, unfortunately, is very much the same as DOORS. While it has got shared information types within a component, those types are independent of other components and other projects. So you can very quickly have different data sets in DOORS Next that diverge apart exactly the same as you do inside DOORS.

Alisa Eikanas: Yeah, I would add that there’s typically always a great deal of desire to migrate, but defeating the perception that it’s an insurmountable obstacle can be tricky. This, as in many other cases, is where Jama Software really excels and exemplifies our customer-centric approach to solutions. We don’t treat or expect our customers or their data to be the same.

So, before we even begin a migration effort… Or for those of you that are considering looking into migration, Jama Software offers a free DOORS data model diagnostic service, providing a financial breakdown of the benefits, removing your DOORS data to an MBSE approach. And following that migration, your data, both old and new, we’ll consistently respect the data model defined by your organization within your Jama Connect instance.

Richard Watson: Another fallacy is that sticking to a single vendor for migration makes things simpler. Migration tools must be stronger between those tools from the same vendor. So DOORS, migration to DOORS Next is not the case, unfortunately. So DOORS Next is a wholly new requirement system, it’s just like moving to a different tool from a different vendor.

The data inside of DOORS Next is very different to DOORS, so it’s not a natural upgrade. You do have to do data migration. When adopting a new requirements tool, it’s really important to establish that data model so that you can exploit the benefits of the new tool with a consistent data model.

Migrating your data from DOORS to DOORS Next attempts to recreate your DOORS data in DOORS Next exactly as it used to look like in DOORS, and that leaves the reshaping of that data to the end user. We all know that the end user will typically not clean the data once he starts using DOORS Next, and so inefficient data in DOORS effectively becomes inefficient data inside of DOORS Next.

Alisa Eikanas: Absolutely, and what you’re talking about is a missed opportunity. That opportunity to recognize we can look at our data, see that perhaps we’re not treating it consistently or in a standardized way. And as we’re migrating that data, there is an opportunity to, again, apply a data model that’s going to be consistent and afford you so many benefits.

So, when approaching migrations here at Jama Software, firstly we identify. We work with organizations to identify and define the data model most appropriate for your development process, and then we migrate your DOORS data into that model. This doesn’t result in compromised data in any way, but it avoids the mass reshaping or cleaning of data after it’s been migrated.

Jama Software brings over 150 years of shared DOORS experience that we can bring to bear in helping clients migrate to Jama Connect. And in addition to that, we have extensive experience supporting customers going through that actual process of moving their data from DOORS or D&G into Jama Connect.

RELATED: When Evaluating Product Development Software Tools, Not All Cloud is Equal

Richard Watson: Alisa, perhaps the best thing to do next is simply to take a look at the tool. Should we take a look at Jama Connect?

Alisa Eikanas: Absolutely, let’s take a look at a project in Jama. But before we actually start poking around the project itself, let’s start with that data model we’ve been talking about. So, what we’re looking at here on this project dashboard is a rendering of that data model. So if we take a look at this example, we see that we have user needs, we have system requirements, system architecture, subsystem requirements, et cetera.

And in addition to showing each of those artifact types or item types, we also show the traceability paths between them. So for example, here we see our system requirements, and we see that we have those traceability lines established between the appropriate artifact types. We’re not ever going to see a user need directly connected to a subsystem requirement because through our data model, we’re just ensuring that that proper decomposition path is respected.

So again, that process of… As we’re migrating our data, taking the opportunity to identify and to establish a data model is just incredibly powerful and beneficial to our teams. Once we establish that model, and again, we’re going to migrate your data into that defined data model, we want to ensure that that transition is still comfortable for DOORS users. So again, this data model might be new, but the data is still the same.

It’s the same data that they had in DOORS. So that transition from DOORS to Jama is, for the most part… Or, it is a very comfortable one. Navigating around the project itself feels very similar for DOORS users, and I’ll give you an example of that. So, for example, if you’re looking at a DOORS project, you might see a folder with a number of modules located underneath that folder. And then of course, within our modules we’re going to have our individual objects.
So here we’re looking at a Jama project, and what we’re looking at is the project explorer. This will probably visually look similar enough to DOORS users, and what I’ve done is I’ve built out just a quick little example here. So, Jama has a different container name for this, but it’s essentially a DOORS folder. And then underneath that DOORS folder we’re going to see our individual modules listed out, and then if we open up one of our modules we’re going to see our individual objects.

Heading objects as well as our regular requirement or text objects. And that same hierarchical document structure that was established in DOORS, we’re able to carry that over seamlessly in Jama so that for DOORS users, again, it’s… Everything looks and is organized the same way that they’re used to seeing it, and it just makes it very comfortable.

But going back to that added benefit of having an established data model, for example, if I open up this system requirement, if I’m looking at the traceability information, here I can see that the system requirement has a parent, it has a child. But in this downstream bubble right here, I see that it’s red. That’s telling me that there’s a problem, it’s obviously not that it doesn’t have any children because I can see that, again, this user need has…
Or, that this system requirement has a parent user need and a downstream subsystem requirement. So, taking this example of a system requirement where Jama is telling me, “Hey, we’re missing some required coverage.” If I go back to that data model and I take a look at my system requirement, I can see that yes, I’ve satisfied that need to have a parent user need, and I’ve satisfied that need to have a child subsystem requirement. But I’ve yet to satisfy that need for a downstream architecture and a downstream verification.

So again, this is a very brief glimpse of the many benefits of having that established data model. But most, I would say the key takeaway again is that we can kill two birds with one stone. We’re migrating you to a more efficient system and tool as well as just ensuring that we’re able to also bring in efficiencies to your process by establishing that data model.

Richard Watson: That’s cool Alisa, thank you very much. So, that brings us to the end of this vlog for today. Hopefully, you’ve had some high-level overview of migration. Alisa, thank you very much for your discussion and perspective, that was super useful to actually see the tool.

I hope those listening to the vlog do have a reasonable starting point for migration, and I look forward to hearing about your successes in the future. We truly hope you’ve been enjoying this vlog series so far, stay tuned for the next entry in our series, it’ll be coming in a few weeks’ time. Thanks very much, Alisa.

Alisa Eikanas: Yep, thank you.

Is your data working for you? A consistent and scalable data model is instrumental for achieving Live Traceability™ and making data readily available across the development lifecycle.

Download our Jama Software® Data Model Diagnostic to learn more!

Thank you for watching our Episode 6, Jama Connect vs. IBM DOORS: Migration & Data Mapping. To watch other episodes in this series, click HERE.

To learn more about available features in Jama Connect, visit: Empower Your Team and Improve Your Requirements Management Process

We hope you’ll join us for future Jama Connect Jama Connect vs. DOORS topics, including: Industry Templates; Reuse and Variant Management; Requirements-Driven Testing; Total Cost of Ownership; and Why Did We Move to Jama Connect? A Customer’s Story.

Richard Watson
Latest posts by Richard Watson (see all)